The most expensive sentence in early-stage software is "we'll fix it later."
The five decisions, up front: size your stack for your scale rather than Netflix's, don't scale what isn't broken yet, don't bolt AI onto a weak foundation, don't ship AI-generated code without architectural judgment, and audit before you add. Each one is cheap on day one and brutally expensive to retrofit at month eighteen.
Sometimes "later" arrives gracefully, the team refactors during a calm sprint, the migration ships, the codebase keeps moving. More often, "later" arrives the week your traffic 5x's, your top engineer quits, an acquirer asks for a code audit, or an AI feature you bolted on collapses under real load. By that point, "fixing it later" costs four months and a fundraising round.
Every startup we've worked with that survived its growth phase made the same five architectural decisions early. The ones that didn't usually came back to us 18 months later asking us to rebuild what they had, only this time with the runway pressure that should have been spent on growth.
Here are the five decisions, in the order they tend to bite.
1. Choose your tech stack for your scale, not for Netflix's
Founders copy what big tech uses and break their own product in the process. Netflix runs on Java, Go, Cassandra, and a fleet of bespoke distributed systems because Netflix has 250M users and 8,000 engineers. You have three users and you're hiring for engineer #4. The stack that scales to 100M users will reduce you to zero before you reach 1,000.
The three real questions at the early stage:
- How fast can you build and change things on this stack? Velocity is the only metric that matters until you find product-market fit.
- How easy is it to hire for this stack? Your first developer's preferences will become your company's permanent architecture if you let them.
- Does the stack grow with you for the next two years, not the next ten? You'll re-architect when you cross meaningful scale thresholds anyway. Don't pre-pay for a problem you may never have.
For most B2B SaaS and AI products at this stage, the right answer is unfashionable: TypeScript on Node, React on the front-end, Postgres for storage, plus a small set of well-understood services for queues and search. It's not exciting. It's the stack that doesn't slow you down, which is the only stack that matters.
2. Don't scale what isn't yet broken
"We need to scale" is the second-most-expensive sentence in startups, and it's almost always said before scale is the actual problem.
Teams add microservices before they have product-market fit. They migrate to Kubernetes when one well-tuned VM would do. They hire three more engineers when the bottleneck is a single database query that takes 12 seconds.
Scaling isn't about preparing for millions of users you don't have. It's about not collapsing under the users you already do. The best architecture decisions we've made for clients almost always removed layers rather than added them. Fewer services. Simpler deploys. Less clever, more reliable.
If your system gets slower every time your team gets bigger, the bottleneck isn't your infrastructure. It's the decisions that shaped it.
3. Don't bolt AI onto a broken foundation
This is the most common architectural mistake of 2025 and 2026.
AI features get jammed into codebases that weren't built to handle them, vector databases duct-taped to monoliths, LLM calls embedded in synchronous request cycles, prompt logic scattered across 15 microservices with no observability, no caching, no fallback path.
The result is a product that demos well and collapses under real traffic. Token costs spiral. P99 latency turns unbounded. Your team spends more time firefighting than shipping.
The uncomfortable truth: AI doesn't fix architectural debt. It multiplies it.
The startups winning with AI right now aren't the ones with the fanciest models. They're the ones with clean data pipelines, async-first architectures, observability on every model call, and systems explicitly designed to evolve as the underlying models do. Get that foundation right and AI becomes a multiplier. Skip it and AI becomes the most expensive liability on your balance sheet.
We covered this in more depth in AI Is a Multiplier, Not a Fix.
4. AI-generated code without architectural judgment is a bomb on a 3-month fuse
Adjacent failure mode, slightly different shape: teams ship an MVP in weeks using AI-generated code. Three months later they're drowning in technical debt, the database can't handle the load, every new feature breaks two old ones, and the founder is wondering why velocity has collapsed.
The problem was never the speed. It was the absence of architectural intent.
AI-generated code is excellent at producing the fiftieth implementation of a known pattern. It's terrible at picking the right pattern for your specific data model, your specific load profile, your specific compliance constraints. It will happily build you a system that works for the demo and crumbles under real users, because it has no concept of your real users.
The fix isn't to stop using AI in the development workflow. It's to put senior architectural judgment in front of every system-level decision and let AI handle the implementation under that judgment, not in place of it.
5. Audit before you add
The most leveraged hour of work on most early-stage codebases is not writing new code. It's reading the existing code carefully enough to understand which decisions are load-bearing and which are accidents waiting to compound.
Every engagement we start at WeAreFabbrik begins with a codebase audit before we write a single new line. That audit consistently surfaces the same patterns:
- A single database query responsible for 60% of P95 latency
- Authentication logic forked across three places with subtly different behaviors
- A "temporary" worker process that has been in production for two years
- Configuration values hardcoded in seven files because the original
config.jswas "going to be cleaned up later"
None of these problems are exotic. All of them are operational. All of them are cheap to fix early and ruinous to fix late.
What does it cost to skip these decisions?
The pattern we see, again and again:
- Cheap shortcut at month 0 saves €30K
- Compounding cost between month 6 and month 18: roughly €200K of engineering time spent firefighting instead of shipping
- Rebuild at month 18: €150K and a six-month roadmap reset
The shortcut didn't save anything. It borrowed €30K and paid back €350K plus a fundraising round.
The real cost of software isn't what you pay to build it. It's what you pay when it breaks, and what you give up while you're rebuilding it.
Get the architectural decisions right early
If you're a funded founder, a CTO inheriting a codebase, or a board member trying to understand whether the engineering plan you're being shown is credible, book a 30-minute strategy call. We'll give you a defensible read on which of these five decisions are working and which are about to cost you, before they do.
You can also see the 3-phase engagement model we use to take projects from blueprint through build to ongoing scale.
About the author: Konstantinos Tsolakidis is the Founder of WeAreFabbrik and works as Fractional CTO with funded startups and PE-backed scale-ups across Europe. WeAreFabbrik is a senior engineering team based in Athens and Tallinn that has shipped 50+ AI, SaaS, and automation products since 2018.