What Belongs in an MVP | Codelithic Labs

What belongs in an MVP, and what founders keep putting in that shouldn’t2026-09-03 — 6 min readThe point of a first version is to answer one question. Most of what founders want to build in round one has nothing to do with that question.Every founder we meet has a version of the same list. Accounts, profiles, notifications, an admin dashboard, a settings page, billing, and somewhere near the bottom, the thing the business is actually about.That list isn’t wrong. It’s just the wrong order, and building it in that order is how six months disappear.Start from the question, not the feature listA first version exists to answer the one thing that decides whether the business works. Usually it’s something like: will these people pay for this, or can we deliver this at a cost that leaves a margin?Write that question down in a sentence. Then look at every proposed feature and ask whether it helps you answer it. Most won’t, and those can wait.Things that almost never belong in version one

Your own login system. Use a hosted provider. Nobody has ever failed because their auth was rented.

An admin dashboard. In the first months you have few enough records that you can manage them directly, and every hour spent on internal screens is an hour not spent on the product.

Billing, if you can invoice people manually. Ten customers can be billed by hand. Build billing when the manual version starts hurting.

Settings and preferences. Pick sensible defaults. Preferences are usually a way of avoiding a decision.

Native mobile apps, when a good mobile web experience would answer the same question for a fraction of the cost.

Scale work. You do not have traffic yet. Designing for a million users before you have ten is the most expensive form of optimism.

Things founders cut that they shouldn’t

Analytics. If you cannot see what people did, you learn nothing and the whole exercise was decorative.

A way to talk to users. An email field and somewhere to reply is enough, but you need it.

Basic security. Rented auth, no secrets in the repo, encrypted connections. Cheap now, ruinous later.

Anything that makes the core thing feel good. If the one feature your business depends on feels clumsy, you will get a false negative and conclude the idea failed.

The signs you have built too muchA few patterns show up again and again before launch:

You are three months in and nobody outside the team has used it.

You are building screens for situations that have never occurred.

You can list features but not the question those features answer.

The launch date has moved twice, each time for something that isn’t the core feature.

If you aren’t slightly embarrassed by the first version, you probably spent too long on it.What we usually recommendStart with a clickable prototype. It costs a fraction of a build, you can put it in front of ten people in a fortnight, and roughly half the time it changes what gets built. That is a cheap way to be wrong.Then build the narrowest thing that answers the question, ship it to real users, and decide what is next from what they do rather than what they say. Keep the code clean enough to hand to an engineer you hire later, because if this works you will hire one.A note on raising moneyIf you plan to raise, someone technical will eventually look at what you own. They aren’t looking for elegance. They want to see that the code is understandable, that there are some tests, that deployment isn’t one person’s laptop, and that the accounts are in the company’s name. None of that requires building more. It requires building tidily.More reading

What a website costs in Calgary (and what drives the number)

Build or buy? A decision framework that survives contact with reality

Core Web Vitals, explained for people who don’t write code

Local SEO for Calgary businesses: what moves the needle

Why your most important business process is running on a spreadsheet