MVP design: what to build, what to skip, and what to fake

Most MVPs are small products. They have a settings page, an account area, three ways to sort a list and a pricing tier nobody has bought. They took four months, and when they launched they proved that the team could build software, which nobody doubted.

An MVP is supposed to be a test. It exists to find out whether a specific person will do a specific thing, and the design job is deciding what has to be real for that test to be honest. Everything else is either skipped or faked, and the skill is knowing which.

Start with the thing you need to learn

Write down the one question the MVP has to answer. Not the vision, the question. Will restaurant owners upload a menu without being walked through it. Will finance teams trust an automated reconciliation enough to stop checking it by hand. Will people pay before the feature they asked for exists.

If you cannot write that sentence, you are not designing an MVP, you are designing a product with fewer features, and it will take as long as a product. Every decision below depends on having the question, because build, skip and fake are all measured against it.

Build: the one path that answers the question

The path from a user arriving to the moment that answers your question gets built properly. Real design, real states, real handling of what happens when it goes wrong, because a broken core path teaches you nothing except that it was broken.

Properly does not mean big. It means the sign-up, the first action and the moment of value are designed end to end, including the empty states and the errors, and tested on a phone. For most products that is somewhere between five and twelve screens. If your core path is thirty screens, the question is too big.

Skip: everything the first ten users will not touch

• Settings. A new user changes nothing in the first week. Hardcode the defaults.
• Account management. Password reset, profile editing, billing history. Handle it by email until it hurts.
• Admin tools. You are the admin. Use the database.
• Every second way of doing the main thing. One way to add data, one way to view it, one way to export it if export is on the path at all.
• Multi-user, roles and permissions. Unless the question is about teams, the MVP is single-player.
• Integrations. Unless the question is about the integration, a CSV upload proves the same thing.
• Onboarding tours, tooltips and guided setup. If the core path needs a tour to be understood, fix the core path.

Skip means the screen does not exist. A greyed-out settings link is a promise you will be asked about every week. No settings link is a decision, and nobody asks about it.

Fake: what a person behind a button can do for now

The most underused MVP move is making the interface real and the machinery human. The user uploads a document and a categorised summary comes back in an hour. It looks like software. It is you, reading the document. The user requests a quote and receives one by the next morning. It is a spreadsheet and a founder.

This works because the question is almost never about whether you can build the machinery. It is about whether people want the outcome, and a human can produce the outcome long before the code can. You learn what people ask for, where the edge cases are, and what the output has to look like, all before writing the expensive part.

Design it honestly. Set the expectation on time, so an hour does not feel like a bug. Do not claim it is automated if someone asks. And set the number at which it stops being viable, because the point of faking is to learn enough to build the real thing, not to run a services business by accident.

What AI builders changed

Lovable, Bolt, v0 and the rest made building cheap, and the effect on MVP design was the opposite of what people expected. When building took months, scope was forced on you by time. Now a founder can generate settings, roles, integrations and three dashboards in an afternoon, so nothing forces the decision, and the MVP turns into a small product by default.

The discipline moved. The hard part is no longer getting the thing built, it is refusing to build the parts that do not answer the question, and then cleaning up what the tool generated on the path that does. We have written about which builder to start on and the cleanup checklist for what they produce. Both assume you have already decided what the product is for, which is the step the tools cannot do.

The mistakes

• No question. The MVP is a smaller version of the vision, and it takes as long as the vision.
• Skipping the core path to save time, and building the settings page properly. Exactly backwards.
• Faking the thing the question is about. If the question is whether the automation is good enough, the automation has to be real.
• Building for the tenth customer's edge case before the first customer exists.
• Treating the MVP as version one. It is a test rig. Some of it should be thrown away on purpose.
• Skipping the empty states, because the demo always has data in it and real users never do.

A short test

Before anything gets built, go through every screen on the plan and put it in one of three columns: answers the question, nobody touches it in week one, or a person could do this by hand for the first fifty users. Build the first column properly. Delete the second. Fake the third. If the first column is more than a dozen screens, the question needs cutting down, not the design.