Last year I rewrote a product from scratch. Not because the original code was bad. Not because the architecture was wrong. Because I made a stack choice based on what I enjoyed building with, and enjoyment turned out to be the wrong constraint to optimize for.
The original stack was TypeScript, React, and Remix. Full-stack, modern, ergonomic. It's still what I'd reach for if you asked me what I like building with. But liking it wasn't the point. I was a solo founder trying to validate a product, and every time I reached for an LLM to accelerate a problem, I spent most of the session not solving the problem but explaining which version of Remix I was using, which adapter, which breaking change had landed since the last time I'd asked a similar question. The ecosystem was fragmented enough and fast-moving enough that AI assistance, which is now a real part of how many people build, became a drag instead of a multiplier.
Beyond that: every time my product needed the next capability, it was a separate project. Queues, scheduled jobs, caching, notifications, background workers. Each one meant finding the right tool, evaluating options, standing it up, wiring it in. That overhead compounds fast, and it compounds at exactly the wrong time. At early stage, your only real job is finding out if your product is something people actually want. Every hour spent making infrastructure decisions that don't move that needle is an hour you've stolen from the only thing that matters. You don't need the perfect queue implementation. You need to know if anyone cares that the queue exists at all.
So I rewrote the whole thing in Laravel. PHP. Not cool. Not what I'd have put on a list of technologies I enjoy. But it had batteries included for almost everything I needed next, a community that had already converged on strong opinions about how to do things, and an ecosystem stable enough that AI assistance actually worked. When I needed a queue, it was already there. When I needed a scheduler, same answer. When I eventually need outside help, the hiring pool is large and the conventions are widely understood. (And to be clear: good Laravel developers absolutely use TypeScript. The comparison is not Laravel versus TypeScript. It is Laravel versus the fragmentation of a fast-moving meta-framework ecosystem where the ground keeps shifting under you.)
The rewrite cost me time I didn't have. But it cost me less time than continuing on the wrong path would have. That is the only math that matters when you are evaluating a rewrite. Not how much you lose, but what you stop losing by making the change.
What I realized in making that call was this: the architecture you choose is a statement about which constraints you believe are real. Get the constraints wrong and the architecture will fight you the whole way.
The Clojure problem
I've watched this play out from the other side too.
Earlier in my career, at a company I worked at, we needed a proof of concept. Someone was brought in to spin it up fast. They liked Clojure, so they chose Clojure.
I raised a flag. Not because Clojure is a bad language. Because the choice revealed a misdiagnosis of the constraints.
The constraint was not "what is the most interesting tool for this problem." The constraint was "what can we staff, maintain, and build on if this becomes real."
You probably know how this ends. The proof of concept became a product. The product needed a team. Hiring Clojure developers was hard. The codebase got harder to maintain and extend. Eventually someone had to bite the bullet and rewrite it.
This is one of the most expensive patterns in software: the accidental production system. A throwaway prototype built under personal preference constraints, promoted into production because the deadline moved and the demo worked. The technical debt isn't really technical. It's a record of the wrong constraints being applied at the wrong moment.
What early-stage architecture actually is
There's a persistent myth in engineering culture that stack choice is a craft decision. That choosing the right tool for the job means evaluating languages and frameworks on their technical merits: performance characteristics, type safety, ecosystem richness, community momentum.
That framing is mostly wrong at early stage. At early stage, architecture is a constraints optimization problem, not a technical problem. The technical merits are nearly irrelevant compared to the operational realities of where you actually are.
The constraints that matter when you're a solo founder or a team of three trying to prove a product:
- LLM compatibility. AI is now part of how many teams build. The question is whether your stack's ecosystem is stable and conventional enough that AI assistance actually accelerates you, or whether version fragmentation and rapid churn mean you spend half your prompts debugging the assistant's outdated context rather than solving the actual problem.
- Time to the next primitive. Early products grow in predictable ways. You'll need jobs, queues, caching, notifications, and background workers. The question isn't whether those are good primitives. It is whether reaching for each one costs you a side project and an afternoon of evaluation, or whether you just open the docs.
- Hiring pool when you need it. The stack you choose at the beginning is the one you'll be recruiting for when your assumptions about staying solo collapse under the weight of actual traction. Optimizing for a narrow or fast-evolving ecosystem when you're bootstrapping means front-loading a recruiting problem that will hit you at the worst possible moment.
The point isn't that Laravel is the right answer for everyone. The point is that the right answer depends entirely on your actual situation. Your architecture choice is a legible signal of whether you've diagnosed that situation honestly, or whether you're making the decision you wanted to make anyway and dressing it up as technical judgment.
When the stack starts to matter differently
Here's where it gets more complex: these constraints don't hold across company stages. The constraint set that defines a good architecture at ten people is almost completely different from the one at five hundred, and different again at ten thousand.
At ten people, the constraint is ruthless: can we move fast enough to find out if this is real? Architecture serves velocity. Anything that slows you down is expensive. Anything that eliminates a decision is valuable.
At five hundred people, the stack is no longer a velocity tool. It's a coordination mechanism. Conway's Law isn't a theory at that scale1. It's a daily operational reality. Your architecture defines the seams between teams, the ownership model for services, the degree to which competing priorities across different parts of the organization can be resolved without constant cross-team negotiation. A microservices decision at this size isn't about deployment topology. It's about organizational independence. A monolith decision isn't laziness. It might be the only architecture that keeps a mid-size team from drowning in distributed systems complexity they haven't earned yet.
At ten thousand people, the frame shifts again. Stack decisions made five years ago are now institutional inertia. The question stops being "what's the right architecture" and starts being "what's the migration path that doesn't kill productivity across hundreds of teams while we move." The technical merits of your destination barely matter compared to the organizational cost of the journey.
Most cargo-culted architecture mistakes come from applying the constraint set of a larger company to a much smaller one. Someone read about how Netflix does it. Watched a conference talk from a team at Google. And applied those patterns to a context where the relevant constraints are completely different. The architecture that's right for Google's scale is almost certainly wrong for yours. Not because the technology is bad, but because the problems it was designed to solve don't exist in your company. And frankly, they may never exist. Not every company becomes a ten-thousand-person organization. Designing for that outcome when you are at fifteen people is not forward-thinking. It is a distraction wearing the costume of ambition.
What the choice reveals
I have made the mistake I'm about to describe.
When I see a three-person startup with a microservices architecture, I recognize it. I have been that engineer. Confident that the technically correct decision was the right one, without stopping to ask whether it was the right one right now, for this company, at this stage. It's an easy trap. You know the patterns. You know what breaks at scale. You're solving for a future you can clearly picture, because you've read the postmortems and the architecture blogs and you want to get ahead of it.
But solving for imagined future scale instead of proven present-day problems is its own form of constraint misdiagnosis. Martin Fowler's "MonolithFirst" makes a similar point about defaulting to simpler architectures until you have real evidence you need more2. The architecture doesn't tell me the team made a bad technical choice. It tells me they applied the right solution to the wrong problem. The architecture reveals a belief about where the risk is. And at early stage, almost every architecture-level risk is downstream of one prior question: is this thing real?
The best engineering leaders I've worked with share one habit: they treat architecture decisions as explicit bets on what the actual constraints are right now, not on what the constraints might be eventually. They can tell you exactly why they made the choice they made, what constraint it was solving for, and when that choice should be revisited. They're not attached to the decision. They're attached to the reasoning.
That's a different relationship to the stack than most engineers have. And it's the relationship that tends to define the difference between someone who builds software and someone who builds organizations that build software.
The architecture you choose doesn't say much about your technical taste. It says a lot about how clearly you see where you actually are.
What's the constraint you're actually optimizing for right now, and is that the one that actually matters? That's the question worth sitting with before you touch the stack.
Objections you might be thinking (and my take)
"This over-indexes on hiring pool. Great teams can learn anything." They can. The point is cost and timing. If you are early stage, every hour spent ramping a niche stack is an hour you are not validating the product. Once product-market fit is real, the tradeoffs change.
"Microservices are fine for small teams if they know what they're doing." Sometimes. The pushback is not about competence. It is about surface area. Distributed systems add failure modes you do not get back in early-stage leverage unless coordination and deployment independence are already your bottlenecks.
"Laravel is slower, less modern, not the best technical choice." Maybe. And it often does not matter. Early stage is rarely constrained by raw performance. It is constrained by iteration speed, staffability, and how quickly you can reach the next reliable primitive.
"LLM compatibility is a weird constraint." It is new, and it is real. If AI is part of your development workflow, ecosystem stability and convention density become productivity multipliers. If AI is not part of your workflow, you can ignore this constraint.
"This sounds like post-hoc rationalization for a rewrite." Fair. A rewrite can still be the wrong call3. The point of the framework is to make the bet explicit: what are you optimizing for, what are you giving up, and what signal would make you change your mind.
