I finally had an idea worth building. That's exactly why I never shipped it.

What two years bought me

By the end of the second attempt it had five apps: a NestJS API, a Rust API, a KrakenD gateway, PostgREST, and a Next.js frontend. Four data stores — Postgres, Redis, Mongo and Google Cloud Storage. Ninety runtime dependencies. Two auth providers that disagreed with each other.

Here’s a fragment of the Rust service’s Cargo.toml:

# MongoDB
mongodb = "2.8"

# PostgreSQL
sqlx = { version = "0.7", features = ["postgres", ...] }

Two databases. One service. No users.

The infrastructure was in good shape. The product was the part still ahead of me, and it was all of it.

Why I thought it deserved that

I didn’t do this to a throwaway. I thought the idea was finally the one. Every freelancer and agency I know prices work in a spreadsheet that drifts out of date, and nobody had solved it properly. Real problem, real users, the holy grail.

So obviously it deserved the best of everything. The best architecture, because one day it would have to scale. The fastest language for the API. A new feature idea every few days, because I kept thinking of things it should do before anyone had used what it already did.

The importance I gave that idea is why it never shipped. If I’d thought less of it, it would have been online in a weekend.

None of the steps were stupid

I started in NestJS because I know NestJS — the last purely practical decision I made. Then I swapped it for Rust, partly for speed, partly because I wanted to learn Rust; learning is good, so it didn’t feel like a detour. I put KrakenD in front, because decoupling, because that’s what a serious architecture has.

Inside, it was clean architecture and SOLID all the way down — repositories behind interfaces, dependency inversion, patterns I could point at by name. All so I’d be ready if I ever switched database provider. I never switched database provider. Nobody has ever asked me to switch database provider.

And I spent real time considering Fresh on Deno instead of Next — partly to learn something new, and partly, if I’m honest, ego. Every junior uses Next. I wanted to be past that.

Performance, learning, principles, pride. Four respectable reasons, and not one of them was “a person needs to be able to do X.”

Why it’s so easy to do

Infrastructure work has a definition of done. A migration completes. A gateway routes. A harness goes green, and you get to cross something off and feel it.

Product work never announces itself. Nobody tells you a feature is good enough to show someone. You just stop, and hope.

So I kept picking the work that could be finished. A migration. A gateway. A service that benchmarked well. Every one of them completed — and not one of them was the product. I was manufacturing the feeling of shipping.

How it ends, twice

Neither time did I stop dramatically. Both times I totalled up what was left, saw how big it was, got busy with other things, and the motivation never came back. The second time I wrote the total down: a four-phase plan, 18 to 24 days just to reach a foundation. The last thing that attempt produced was a folder of issues describing what still needed building.

What took me longest to see is that the infrastructure is what made the rest look impossible. Every service added surface to maintain. The product never got closer, so the total kept growing. The thing that felt like progress is what made it feel hopeless.

The third time

Nine months later I started again and did the boring version. One app, one database, twenty dependencies. The four ways I’d had of serving an API became zero — server-side functions, no API layer at all.

I built it in Next.js. The framework I’d decided was for juniors.

It was feature-complete in three days.

The rebuild has clean architecture too. Four folders and one rule about which direction imports point.

And this isn’t a “skip the tests” argument. The rebuild has 921 tests where the old one had 14 test files, and permission checks the old one never got to. The rigor didn’t go away — it stopped being aimed at problems I didn’t have.

The question that would have saved me two years and two attempts wasn’t “what’s the best stack for this.” It was “what could someone use on Friday.”

The thing I was building is RateHive — estimating for freelancers and small studios. There’s a version at /try that runs without an account.