MVP Features: What to Ship and What to Hold Back

Somebody put this into a small-SaaS community thread, about a browser extension they had made:

Built a chrome extension for tracking SaaS metrics a while back. Put 2 weeks into building what I thought was the killer feature…

That is a real piece of somebody’s life, and the sting in the sentence is that the work was finished before anyone found out whether it mattered. In 2026 the sting arrives faster and cheaper. Most people now asking which MVP feature belongs in the first version are asking after the fact: they described a product to an AI builder, the builder produced working capabilities in an afternoon, and nobody paused in the middle to decide which ones the product actually needed. Instead of happening before the building, the choosing is happening now, with the app already on screen and a launch date somewhere ahead.

This page is about that one decision and nothing else: which of the things already sitting in your app go out with the first version, and what happens to the rest.

The first version carries whatever you can stand behind when a stranger uses it. Everything else has two homes rather than one, and neither is deletion: take away the way in and leave the code alone, or finish it properly.

What the advice ranking for this question actually assumes

Four pages on this search publish a real method for choosing. All four were opened and read on 1 September 2026, and all four are written for somebody whose software does not exist yet.

Pragmatic Institute publishes an article arguing that an MVP is not the smallest collection of features, at www.pragmaticinstitute.com/resources/articles/product/an-mvp-is-not-the-smallest-collection-of-features/. It renders its full body text, shows no date anywhere a reader can see one, and gives 19 June 2014 with a 23 May 2023 update in its own page data, which makes it the oldest piece in the set by four years. It leans on Eric Ries’s definition, which turns on how much a team can learn about its customers for the least work spent, and it builds that into a working method: rank the customer problems you have written down, map solution elements onto those problems, and only then mark each feature in or out of the MVP and size what it would take. The verb “size” is the tell. You size effort you have not spent.

thoughtbot’s post on defining and prioritising features for an MVP sits at thoughtbot.com/blog/how-to-define-and-prioritize-features-for-your-mvp, dated 4 July 2018 and updated 4 March 2025, and it renders in full. Its filter runs off a value statement and the goal of proving product market fit, and it advises treating software as a last resort for handling edge cases. It is also the only one of the four that talks about taking something away: strip the feature from initial launch, put it back on the back burner, and revisit it when it becomes necessary. Read that against an app that already runs and it will not translate, because the thing it strips from is a plan.

solvd, which sells development work, publishes a piece on not overloading a minimum viable product at solvd.com/articles/mvp-features/. It renders in full, shows no date anywhere a reader can see one while its own page data gives 12 April 2023 with a 15 May 2026 update, and organises the choice three ways: identify the assumptions the product depends on, define a clear purpose for the MVP, and build a hierarchy of features by mapping the user’s workflow and asking which features support each step of it. Its own framing places the whole exercise before committing any significant time or resources to development. That sentence only parses if the development is still ahead of you.

Codevelo, also a seller, publishes the closest incumbent by title at codevelo.io/blog/what-features-should-an-mvp-include, dated 16 February 2026. It renders in full and names no price anywhere on the page. Its headings run from understanding the purpose of an MVP, through a core rule about starting with the primary user action, to must-have features in three groups, and then to a section headed what not to include. That heading is the nearest thing on either search to the subject of this page, and the piece still stands earlier than the reader does: before defining an MVP feature list, it says, it is important to clarify the purpose.

None of the four is linked here. Three sell development work and Pragmatic Institute is a training publisher, so one consistent rule covers the set rather than four separate judgements about who deserves a link. Read the last column downward and the four say the same thing together: each one hands you a way of choosing between things that do not yet exist.

That follows from who they were written for rather than from any flaw in their writing. Both result sets behind this page, pulled on 1 September 2026, are made up of a training publisher, a work-management vendor’s agile guide, a roadmap vendor’s glossary, an encyclopaedia entry, a design vendor’s resource library, a product-design firm, a practitioner essay from years ago, a product-management publisher, four sellers of development work and one community thread. Every one of them is a good answer to a question this reader answered by accident the moment they opened a builder.

Why the question inverts once the features already exist

A new MVP for product development used to start at an empty folder, and every method on that search still assumes it does. You opened a builder instead, described the product in a few sentences, and had working screens back before you had finished deciding what the product was. That is what the tools do, and it is why they are worth using. Discipline on your part never came into it.

It has a predictable side effect. One owner with no coding background sat down to make the smallest useful version of a two-sided service and found that the thing had somehow accumulated far more moving parts than they had ever chosen. Nobody decided on those parts. They arrived as a by-product of describing what the product should feel like, which is the natural way to talk to a builder and a poor way to keep track of what you now own.

So the four methods above have nothing to operate on. There is no queue of candidates to rank, because nothing was ever queued. There is an app with things in it and a date you would like to launch on.

What genuinely changes is the unit of cost. Before the code existed, a feature cost build hours, and choosing wrong cost you those hours. The hours are now spent and you cannot get them back by leaving something out, so the cost of including a capability is no longer what it took to make. It is what you take on by exposing it: every question it generates, every way it can be wrong in front of somebody who is not you, every promise it quietly makes on your behalf while you are asleep.

That is why the answer moves even when the analysis does not. A prioritisation method sorts candidates by value against effort, and it has no move for something that is already built and not ready, because for the reader it was written for that combination cannot occur. Built and not ready is the ordinary state of an AI-built first version, and it is the state this whole decision is about.

What can you actually do with a feature that already works?

Three answers exist rather than two. Ship it, if you can stand behind what it does. Take away the way in and leave the code where it is, which is reversible in minutes. Or finish it, the one answer of the three that costs real time.

Ship it. The test is whether you can stand behind what it does the first time somebody who is not you touches it: without being in the room, without a note explaining the order to do things in, and without hoping they will not try the obvious wrong thing. Impressive is not the standard here, and neither is whether the thing behaves when you are the one driving it. If you can answer for it in those conditions, it belongs in the first version. Most of what a builder produces passes this test for the main path and fails it about three steps to the side, which is exactly the information you need.

Take away the way in and leave the code where it is. Remove the menu entry, the button, the link, the row in the navigation. The capability stops being part of what the first version promises. Nothing gets deleted, nothing gets rewritten, and if you were wrong the decision reverses in the time it takes to put the link back. This is the answer nobody on that search offers, because for their reader “not in version one” already means “not built”, so there is nothing to hide and nothing to reverse. For you there is code, and removing code you cannot read is the expensive option: you cannot check a removal you did not make, and you would be doing it under launch pressure to save nothing.

Finish it. The last answer is the only one that costs real time, because finishing does not mean the capability runs. It means it holds up for somebody who does not know how it is meant to work: the wrong input, the second account, the browser tab left open for a day, the person who quits halfway through. That is different work from the job the builder did, and it is worth reserving for the one or two things the first version genuinely cannot launch without.

There is a faster way to run this than reading anything, and it is to look at the thing. Open the first version the way a stranger would, on the device they would be holding, and walk it end to end without touching anything you built it with. Whatever you catch yourself explaining out loud as you go is a candidate for the second answer, because you will not be there to explain it. Walking the screens surfaces this quicker than any written exercise, because the promises arrive in the order a real person meets them rather than in the order you happened to think of them.

One caveat belongs right here, because it is the thing readers assume and it is not true. Taking away the way in is a product decision and it is not a protection. If a capability is reachable at an address, it stays reachable whether or not anything on the screen points at it, and a hidden control is not the same as a closed door. So anything that holds other people’s information or moves money is either finished properly or genuinely taken out, and it is never merely unlinked. That distinction, and why a hidden control is a suggestion and the server is the decision, is settled for a specific app on the page written about it.

What it takes to put one of the held-back items back later, and what somebody prices when you ask for exactly that, is a purchase of its own.

What each feature you keep is promising

Somebody running a free tool that had begun to catch on described the next decision this way in a community thread:

I wasn’t charging anything for it, but it’s gaining traction. I’m now thinking about implementing accounts since I’ve received a few requests from the community for them … How do I make sure I’m doing this right.

That is the right question, and notice what it is really about. Accounts are a standing promise rather than one capability: people will lose their password, people will want their information taken out, two of them will sign up with the same email address, one of them will use the product in a way you never pictured, and every one of those events is now yours to answer on a normal Tuesday when you are doing something else.

That is the rule that decides between the three answers above. Keep what you can answer for. Hold back what you cannot answer for yet. It is a much easier rule to apply than a value ranking, because instead of estimating anything you are asking whether you know what you would do when the ordinary bad day arrives.

Two promises are worth naming, because they are the two that turn a hobby project into an obligation. The first is about other people’s information. Once a stranger has an account, they can ask you to take their records away, and answering that request properly means knowing where their records went, which is rarely one place in an app a builder assembled. What removing somebody’s information actually involves is worked through for a small product on its own page, and it is a fair test of whether accounts belong in your first version at all.

The second is about money. Charging is the promise with the shortest fuse, because a payment that half works produces a person who has been billed and has nothing, and that person writes to you today rather than eventually. How a checkout lets money escape before it ever reaches you is set out on the page about checkouts, and the honest reading of that page before a first launch is that a payment path is either finished properly or genuinely taken out on the server, and never merely unlinked. It is almost never a ship-it item.

Everything else on your screen sits somewhere between those two, and the same question sorts it. The question is only this: when this goes wrong in front of somebody at eleven at night, do I know what I do next. Whether it is good, or how hard you worked on it, does not enter into it.

Finding out whether anybody wants the parts you kept is a different job from deciding which parts to keep, and it has its own method.

The things no cut decision ever reaches

A disposal decision only works on things that are on a list, and the parts of an app that cost the most to add late were never on anybody’s list. They are properties of the way the whole thing got assembled rather than items in the product: whether a failure anywhere is visible to you, whether the thing can be changed without a stranger noticing, whether the parts that hold data hold it consistently. Nobody prompts for those, so nobody gets them, and no amount of walking your own screens will surface them, because they have no screen.

This matters for the decision in a practical way. When you hold something back, you are reducing what the first version promises, and leaving what it rests on untouched. The foundation does not shrink when the list does, which is why holding several things back can leave an app exactly as far from ready as it was before you started cutting.

Which parts of an AI-built app tend to exist at all is recorded, as counts, on the page about finishing a half-built app, and no count from it is repeated here. Two things are worth doing with that: read what a builder actually produced across a set of real apps beside your own product, and check it against the fixed cohort behind those counts and how it was scored, which is published separately so the numbers can be examined rather than taken on trust.

There is a short and specific set of parts an AI builder reliably does not produce, itemised elsewhere with what each one takes to buy, and none of them is on any list you are cutting.

When the first version has to reach people through a phone store, that same decision picks up a second half that is not about features at all.

What an MVP feature list is for once the code exists

Write the list anyway. Just be honest about what it is now, because that changes what it should contain.

A build plan is the one thing it can no longer be. The build happened, in an afternoon, before you wrote anything down, so a list of what to build would be a record of the past. What the list is now is a statement of what this version promises, and that gives it two real uses.

The first is deciding what you are allowed to say. Every claim on your landing page, in your launch post, in the message you send the people who said they were interested, has to be backed by something you have decided to ship. An MVP development strategy that consists of shipping quietly and describing accurately outperforms one that ships loudly and describes hopefully, and the list is what keeps the second from happening by accident.

The second is telling anybody you pay exactly what is in and what is out. The single most expensive misunderstanding in this whole area is a person being asked to work on an app without being told which parts are meant to be finished, which are meant to be reachable but rough, and which are sitting there behind a removed link and are not to be touched. That last group is invisible in the code and obvious on the list, and stating it plainly is worth more than any amount of description of what the product is for.

An MVP roadmap is a different object with a different job, and confusing the two is common enough that the question gets asked below. Which label the thing you ship deserves once you have decided what is in it is a separate question and is answered on the page that compares the labels.

The order the remaining work happens in, once the version on your screen is where the plan starts, is a separate question from which parts of it go out.

The wider subject this one decision sits inside, and where each of its other parts gets answered, has an overview of its own. The rest of the subject, including what it costs, who does it and how long it takes, is routed from the overview rather than answered here.

How this page was put together

Each of the four sources above was read on one day, 1 September 2026, against a single question: what rule does it give a reader for deciding whether a capability belongs in a first version. The sellers among them are named without a link. Nothing was built or run for this article.

The two search result sets referred to above were pulled the same day. Where a page is described as showing no date a reader can see, that is a dated observation about how it rendered on 1 September 2026 rather than a claim that it carries none at all: two of the four state dates in their own page data with nothing on the screen, and those dates are printed above as the pages give them. All four are living documents that can be rewritten.

Common questions about MVP features

What is an MVP feature?

An MVP feature is a single capability that the first version of a product actually exposes to the people using it. The word does most of its work in the second half of that sentence: something the builder produced but nobody can reach is code sitting in your app rather than a feature of your first version, and the difference between those two is the whole of this decision.

How many features should an MVP have?

There is no right number, and any number you have been given was worked out for a different product. The useful test is whether you can stand behind each one the first time a stranger meets it, without being there to steer them. That is a question you can answer honestly this afternoon, which is more than a number will ever do for you.

What is a good MVP strategy?

A good MVP strategy in 2026 starts from what you already have rather than from what you would like to build. Walk the version on your screen as a stranger would, ship the parts you can answer for, take the way in away from the parts you cannot, and finish only the one or two things the launch genuinely cannot happen without.

Everything a phone store adds to this decision, including the parts that have to exist before a single stranger can install anything, belongs to the page about a first version that ships to a phone.

What are the characteristics of an MVP?

The usual MVP characteristics are that it is small, that it goes in front of real users, and that it is built to teach you something you do not currently know. The one that matters most for an app a builder produced is the second: a version nobody outside your household has touched has not done the job yet, no matter how complete it looks.

Whether what you end up shipping still answers to those three letters, or has quietly become the label that comes after them, is a naming question with its own page.

Is an MVP roadmap the same as an MVP feature list?

No, and keeping them apart makes both more useful. An MVP roadmap is an order for later: what you intend to do after the first version teaches you something. A feature list is a statement about now: what this version promises today. An MVP development roadmap that has been written before anyone has used the product is a guess, and a feature list is not, which is why the list is the one that has to be right on launch day.

What goes into an MVP development plan?

An MVP development plan, once a builder has already produced the app, holds three things: what goes out in the first version, what is present in the code but has had its way in taken away, and the small number of items that have to be properly finished before launch. That is a shorter and far more honest thing than the plan the word usually describes, because the building it would have planned has already happened. People searching for an MVP development template are usually after the same thing, and the awkward truth is that no template can fill in those three groups for you, since they depend entirely on what your builder happened to produce.

This page settles which parts go out; the order the rest of the work happens in is settled on the page about building a first version that already exists.

Do I need an MVP development checklist?

An MVP development checklist is useful for the parts of a launch that are the same for everybody, and useless for the part this page is about, which is specific to your app. Keep one for the mechanical work by all means. Do not expect it to tell you which of your own capabilities you can stand behind, because that judgement depends on what your builder made and no general list has seen it.

Can I remove a feature an AI builder already built?

You can, but it is usually the wrong move before a first launch. Taking the way in away achieves the same product outcome, takes minutes, and reverses just as fast if you change your mind, whereas deleting generated code is a change you cannot check yourself. If you cannot read the code, you cannot verify that the removal took only what it was meant to take, and doing that under launch pressure to gain nothing visible is a poor trade.

Putting a held-back item back later is a purchase, and what it involves is covered on the page about paying somebody to add a new capability to an app that is already running.

What should I not include in an MVP?

Anything you cannot answer for when it goes wrong in front of a stranger, and in particular anything that moves money or holds other people’s records that has not been properly finished. Those two are not candidates for the take-away-the-way-in answer either, because both stay reachable at their address whether or not the screen points at them, so they are finished or they are genuinely out.

What a builder reliably leaves out is itemised, one entry at a time and with what each takes to buy, on the page about hiring somebody to finish the app you started, and it is not itemised here.

What if people are already using the feature I want to hold back?

Then it is a change to a live product rather than a first-version decision, and the two follow different rules. Tell the people using it before you take the way in away, give them a date, and if the capability holds anything of theirs, make sure they can get it out first. A quiet removal costs more goodwill than the capability was ever worth.

Whether the parts you kept are wanted by anybody is its own job with its own approach, and it starts after this decision rather than during it.