Early-stage architecture is a bet on your own success. Over-engineer and you spend money you don't have solving problems you don't have yet. Under-engineer and you hit a wall exactly when traction arrives and you can least afford to stop and rebuild.
The trick isn't "build for a million users." It's identifying the specific decisions that are catastrophic to reverse — the one-way doors — and spending your care there while staying scrappy everywhere else. This post is about telling the two apart, in the context of an AI-native MVP where a language model sits in your request path.
The mental model: two-way doors vs one-way doors
Most decisions are two-way doors. Your UI framework, your hosting provider, your background-job system, your CSS approach — pick something reasonable and move on, because swapping them later is annoying but bounded. Agonizing over these is a form of procrastination.
One-way doors are different. They're cheap to decide now and brutal to change once you have production data and users. There are only a few, which is good news: you can afford to think hard about a short list.
One-way door #1: the data model
This is the hardest thing to change once real data is flowing through it. Migrations on a live system with customers are slow, risky, and sometimes impossible without downtime you can't take. For an AI-native product, the data model carries extra weight because it also determines what context you can retrieve and how cleanly you can feed it to a model. Spend the extra time here. It pays back every month.
One-way door #2: auth and multi-tenancy
Authentication, authorization, and tenant isolation shape everything downstream — especially for B2B. Retrofitting a real permissions model onto an app that assumed a single flat user space is a rewrite, not a patch. And this is precisely the area where AI-assisted coding lulls you into danger: a model will generate a plausible-looking permissions layer in seconds, but "plausible-looking" and "won't leak data across tenants" are very different guarantees. Generate if you want, but the verification is human work.
One-way door #3: the seam between core and AI
Here's the one people miss. Keep a clean boundary between your deterministic core (accounts, data, workflows, payments — must be correct every time) and your intelligent layer (summaries, extraction, recommendations, agents). If that seam is clean, you can swap models, add a caching layer, change providers, or move inference off the hot path without touching the rest of the app. If it's smeared through your codebase, every one of those becomes surgery.
Concretely, that means the AI layer talks to the core through well-defined interfaces, its outputs are validated before they touch anything that matters, and you can turn a feature off without the app falling over. Treat model calls like any other untrusted, latency-variable, occasionally-wrong external dependency — because that's what they are.
Why the AI layer forces discipline early
A few properties of LLM-backed features make casual architecture expensive:
- Latency is variable and often high. A model in the synchronous path changes your whole UX budget. Decide early what's sync vs async.
- Inference is a per-call variable cost. Unlike a server you provision once, this scales with usage. If your design fires dozens of calls per user action, you've built a margin problem.
- Outputs are probabilistic. You need evaluation and guardrails as first-class parts of the system, not an afterthought — otherwise a feature that demos in an hour takes weeks to make production-safe.
None of this means gold-plate the MVP. It means the shape of the AI integration is a one-way-ish door, so sketch it deliberately before you build UI around it.
De-risk the hard part first
The cheapest code is the code you never write because you proved, in week one, that the plan was wrong. For AI-native products, run a short spike that answers the scary question before you build the product around it: does retrieval return good answers on real data? Can the agent complete the core task reliably? Finding out the hard part is genuinely hard in week one is a gift. Finding out in month four is a crisis.
Full write-up
This is the architecture slice. The complete founder's guide — cost, timelines, platform choice, build vs. buy vs. fine-tune, staffing, and success metrics — is here:
→ Startup App Development in 2026: The AI-Native Playbook for Founders
We also build these systems for founders; if you want a second set of eyes on your architecture, get in touch.
Frequently Asked Questions
What is a "one-way door" decision in software architecture?
One that's cheap to make now but expensive or impossible to reverse once you have production data and users — as opposed to two-way doors you can change later without much pain.
Why is the data model so hard to change later?
Migrations on a live system with real customer data are slow, risky, and sometimes require downtime you can't afford. For AI products it also governs what context you can retrieve, so mistakes compound.
How should I structure the boundary between my app and the AI layer?
Have the intelligent layer talk to the deterministic core through well-defined interfaces, validate model outputs before they touch anything critical, and make every AI feature independently toggleable. Treat model calls as untrusted, latency-variable external dependencies.
Should AI features run synchronously or asynchronously?
Decide early based on your UX budget. Because model latency is variable and often high, many AI features are better run async with a loading or progressive-reveal state rather than blocking the core interaction.
Can I just let AI generate my permissions system?
You can generate a draft, but you must verify it yourself. "Looks plausible" and "won't leak data across tenants" are different guarantees, and only human review closes that gap.
What should I NOT over-engineer in an MVP?
Two-way doors: UI framework, hosting, job queue, styling approach. Pick something reasonable and move on — these are cheap to change later.
Top comments (0)