What Technical Decisions Matter at MVP Stage: Lessons From Shipped Apps

The first thing I look at in a young product is not the pitch. It is the repo, a build I can install, and the list of people who have touched the code. Ten minutes in, that list tells me more than the roadmap does, because a startup's technical problem is rarely the one on the slide. It is usually a decision somebody made in month two that nobody wrote down.

That observation is the thread through this article: at MVP stage, technical leadership is judgment on a small number of decisions, made before the expensive ones get made by default. It is not a second pair of hands on the keyboard. Here is what long experience shipping mobile apps has taught me about those decisions.

Diagnose before you build

A retail app team I assessed was stuck on native-UI integration, and that blocked the iOS launch. I came in as an outside technical assessor, and the deliverable was an architecture roadmap, not code. The app is live on the App Store today.

The judgment call that mattered was what not to rebuild. The obvious move for a team stuck on native integration is a from-scratch native rewrite, and it was the wrong move here: reusing what already worked got them to launch. The assessment was mostly an inventory of which parts were fine, which were the actual blocker, and which were merely ugly. Ugly code that ships is a different category from code that blocks you, and a stuck team tends to lump them together.

The lesson: when an MVP is stuck, the first useful artifact is a written answer to "what is actually blocking us, and what can we leave alone." An assessment like that costs days. A rewrite decided without one costs quarters.

Validate cheaply before you commit

The second lesson is about pushing back on the maximal version of a feature. On one marketplace project the question was whether AR was worth investing in for high-ticket browsing, with unproven ROI. I directed a cross-discipline team to ship a focused AR proof of concept against the real use case, not a full product. It validated AR for high-ticket browsing and unlocked the next phase of investment.

The point was to de-risk the decision, not to build the biggest thing we could justify. A proof of concept is only cheap if it can fail. If nobody agrees in advance what failure looks like, it turns into a slow-motion product build with a "PoC" label on it.

I would do one thing differently now: set a success threshold before the first line of code, so the go/no-go is mechanical. A decision that depends on people agreeing in a room is fragile. It needs a number, not a mood.

Set the review bar for whoever builds

Most MVPs are built by an agency or one or two early hires, and the person paying can't judge the output. The fix is not reading every diff. It is a review bar written down, a short list of things that must not merge, and someone accountable for holding it. I've written about how this works when the reviewer is partly an agent in how we cut code review time with Claude Code agents, and the finding transfers: the value is in encoding what "good" means for this codebase, not in reading faster.

The same goes for AI-generated code. Coding agents produce the average of the internet, and in my experience that average is worse in Swift, where there is less training data to average over. A short, opinionated instruction file for the repo goes a long way, and I covered what belongs in it in CLAUDE.md for an iOS team.

Don't build for the twentieth customer

Advice that sounds senior is often wrong for the stage. Design for scale, abstract the integrations, build the platform. I've made this mistake myself. On an ad-mediation SDK I built an abstraction so that adding the next ad network would be cheap. It was the right call for a product that ended up integrating 20+ networks. It was also over-built: two of the adapters I wrote were never used.

For a product that hasn't found its first hundred users, that lesson should be sharper. Build the abstraction when the second integration arrives, and add networks, screens or tenants on real demand. Planning for scale before product-market fit spends runway on a problem the company might never have.

Know which decisions are expensive to undo

Cheap-first is a rule about most decisions, not all of them. A small number of choices are costly to reverse: the data model, the auth approach, the boundary between what's shared and what's per-platform, whether the app is one target or several. Getting them wrong doesn't hurt in month two. It hurts in month eighteen.

I wrote about the mobile version of this in choosing SwiftUI or UIKit for a team, and the pattern is the same at MVP scale. Start from the constraints of the team you have, write the decision down with the reason, and leave yourself a way to revisit it. If the code needs restructuring later, modularizing without stopping delivery is possible, but it is far cheaper when the first boundaries were drawn on purpose.

What I got wrong

On that assessment I should have gotten the constraints in writing on day one: budget, deadline, who decides, what's off-limits. I took them as given instead of confirming them, and the team spent about a week going in the wrong direction before it surfaced. Any gap between what was said and what was written down is cheap to fix in week one and expensive to find in month three.

A short checklist

These are the checks I run on any young codebase in the first two weeks:

1. Can someone other than the lead explain the three most expensive-to-reverse decisions and why they were made?
2. Is there a written review bar, and has a pull request actually been blocked by it?
3. Does every proof of concept have a pass/fail threshold set before it starts?
4. Did the assessment name at least one thing to leave alone?

If any answer is no, the process is working on luck.

What is the decision in your codebase that you suspect was made by default, and never actually made?