Two and a Half Years as the Only Developer

I joined Eiendomsavtaler.no in the autumn of 2023 — first as a contracted consultant through my own agency, Spiderweb AS. There was no technical platform yet. The job was to build it. In January 2025 I became a full-time employee, and that same year I wound down Spiderweb to focus fully on Eiendomsavtaler. I was the only developer. Everything from architecture to production, from security to monitoring, sat with me.

In May 2026 I'm handing it over. The platform is in stable operation, has been for a long time, and there's no dramatic reason for me leaving — I'm moving on to Redi AS to build other things. But the transition is a good occasion to write down what I've actually learned. Not in LinkedIn format with "drove growth and optimized performance", but what stays in your bones after two and a half years.

Three generations in two and a half years

The first thing you need to know is that I built the platform through three technical generations.

Generation 1 was a WordPress installation. Advanced Custom Fields for structured forms, WP User Frontend for uploads, WP Statistics for tracking — the plugin stack you end up with when you need to get going fast and validate that the product has a place in the market. I chose it deliberately. An MVP is meant to ship, not to be architecturally impressive.

Generation 2 was my first Next.js app — an investor platform, a side project within the same organization. I wrote it while I was still running the WordPress site. In practice it was my training ground: the first time I worked with the App Router, server components, server actions. It's still alive, but it never became the main product channel.

Generation 5 (yes, we skipped 3 and 4 — more on that below) is the one running today. A full rewrite to TypeScript, Next.js, PostgreSQL. No WordPress left. This is what I'm handing over.

Why the version numbering jumps

Versions 3 and 4 aren't rewrites — they're architecture drafts that never got deployed. I first tried a heavier approach with a separate backend API and Next.js as a pure frontend. It was oversized for a team of one. Then I tried an architecture with more specialized modules. Also oversized.

What I landed on in Version 5 was boring: one Next.js app with server actions, PostgreSQL as the primary database, image processing via sharp, type validation with zod. No microservices, no separate APIs, no event bus I'd spend three months setting up properly.

The most important lesson from the discarded versions was that complexity punishes you exponentially when you're alone. Every abstraction you add is something only you know, only you can debug, only you can change. And two years from now, not even you are sure you remember why.

Why I took it

Sole-developer jobs are polarizing in the industry. Half the people warn you: no pair programming, no code review, no one to spar with, full responsibility when things break at three in the morning. The other half talk about ownership, speed and the absence of committees.

Both sides are right. Neither side prepares you for what it's actually like to do it.

The reason I said yes wasn't the romance of "building everything myself". It was that I wanted to know whether I could. I had worked in teams for several years, and I'd always had a feeling that when something went well, it was because the team was good. I didn't know what was me and what was them. Being the only developer is the only way to find out.

What I underestimated

The first months went to technical decisions. Framework, hosting, database, auth, monitoring. I had an architecture I was happy with on paper, and I got it running.

What I hadn't planned for was everything else. A sole developer isn't just the developer. You're also:

• The security officer who has to keep up with CVEs
• The DevOps engineer who owns the deploy pipeline
• The database administrator who has to answer "why is it slow now?"
• Support when something doesn't work for a customer at 4:30 on a Friday afternoon
• The tech lead who has to say no to features that are cool but unnecessary
• The product person who translates "couldn't we have a button that..." into something actually buildable

The last one is what I was least prepared for. Code is a surprisingly small part of the job when you're alone. Far more of the day goes to communication, prioritization and explaining why things take the time they take.

WordPress had some of the answers

One of the most surprising things along the way was how much WordPress actually got right. I had developed in WordPress before, and I knew the stack has a bad reputation among more "modern" developers. But it solves real problems very effectively:

• Structured forms without writing them (ACF)
• User-generated content with moderation (WP User Frontend)
• Analytics without third-party trackers (WP Statistics)

When I built v5, I had to re-implement each of these. And that's a lot of code for something that used to be filled in in fifteen minutes in an admin panel. What I gained was type safety, better performance, and control over the entire stack. What I lost was development speed on things WordPress had simply solved.

My conclusion after the migration isn't "WordPress is bad" or "self-built is better". It's that choosing a framework is a calibration exercise, not a principle. WordPress was the right choice for the phase the platform was in. It isn't right for this phase. The next phase will show whether v5 is still the right choice.

Being your own code reviewer

The single heaviest exercise in being alone is assessing your own work soberly. It's well known, a lot has been written about it, and still it was harder than I thought.

When you're on a team, you get pushback. Someone asks "why did you do it that way?", and you have to defend the choice — and sometimes you realize mid-defense that you don't have a good answer. Without that counterpart, the defense disappears too. You write code, you merge it, you forget why.

What I landed on was two simple things:

Writing small commits with clear messages. Not because anyone would read them later — no one would — but because I, the one writing them, forced myself to articulate what I had done and why. At least I got halfway to a justification.

Letting it sit overnight before merging when it was big. The evening glow after something finally works is the worst reviewer. Morning-me is a stricter colleague than evening-me.

Neither of these replaces a real pair. But the two together meant I took fewer dumb shortcuts than I otherwise would have.

On building for one client you never meet

Eiendomsavtaler.no has real users. Brokerage professionals, real estate players, people who use the platform to close actual deals. I have never met any of them face to face. What I knew about them, I knew through the business side — people who translated needs to me and took my technical answers back to them.

That shaped how I worked. I had to get better at asking questions that didn't assume I'd seen the problem myself. "What is the user trying to do when this fails?" instead of "what's the error?". The first gives you context. The second gives you a stack trace.

When you work alone without direct user contact, the business side is your only bridge to reality. I learned to respect that role a lot more than I did before.

The performance work I learned the most from

One of the most instructive exercises in v5 was the performance work. I kept a simple audit file in the repo where I noted which pages dragged, what caused it, and what I did to fix it. Nothing advanced — just a markdown file that grew over time.

What I learned from that exercise was that most performance problems are boring. The solution is rarely "switch to a faster runtime" or "implement a caching strategy". More often it's that an image isn't lazy-loaded, a database query fetches more than necessary, or a component renders client-side because the developer (that is, me) forgot to check whether it could run server-side.

Boring fix, big win. That kind of work isn't rewarded by the tech community — nobody gives talks on "I added the sizes attribute to <Image>" — but it's what actually makes the difference in Core Web Vitals.

Why simple solutions won

I started the project with an architectural ambition that was a bit too big for the problem. Microservices here, event-driven there, a queue for the heavy jobs, Kubernetes at some point in the future. None of it was technically wrong — it was just the wrong size.

What I ended up with was much closer to boring. A monolith with clear boundaries between modules. A primary database with a replica. A cache layer in the obvious places. CI/CD that's straightforward enough that I can make changes to it without being afraid of breaking it. Monitoring that gives me two or three metrics I actually keep an eye on, not twenty I ignore.

The reason this worked isn't that I was right in my choices. It's that I was the only developer, and complexity punishes you exponentially when you're alone.

If I were building the same platform today, I'd start even simpler.

What was worth it

What I take with me isn't that I managed it — that was never the question. What I take with me is that I now have a calibration for what actually costs time when you own the entire stack. I know what "we just need to get it out" means for a real-world deploy, not just for a sprint. I know what gets choked when an architecture is too big for the team that has to run it. I know what you gain by moving away from a ready-made framework, and what you lose.

That calibration is hard to get any other way. It costs you two and a half years, a fair number of weekends and some evenings you wish you could have back. But it sticks once you have it.

What happens now

The platform lives on without me — the handover has been orderly, the documentation is there, and the new team has access to everything they need. I'm moving on to Redi AS and fullstack development on a multi-tenant product, where I'm one developer among several. It will be a different job in ways I probably still underestimate.

But I think it's easier to be part of a team when you know what you actually contribute — and what you need from the others.

You'll find the platform at eiendomsavtaler.no.