How to Scope an MVP for an Internal Operations Tool

Most internal tool projects start with a features list: a dashboard, a form, a report, an approval flow. The features list is honest. It says what the requester imagines. It says nothing about which parts of that list actually change what happens on the floor tomorrow.

Consumer MVP thinking asks: what is the smallest thing we can put in front of a stranger to test if they will use it. That question does not apply inside a company. Nobody in your plant is choosing whether to "adopt" the tool the way a consumer chooses an app. They are told to use it, or they route around it and go back to the phone call. The real question for an internal MVP is different: which decisions does this tool need to remove from someone's head on day one, so the business runs on information instead of on somebody's memory.

What does "MVP" mean for an internal tool, compared to a consumer product?

For a consumer product, MVP means the smallest set of features that proves people want the thing. For an internal operations tool, MVP means the smallest set of decisions it can take out of a person's daily judgement without breaking anything that currently works. The build is not testing demand, demand already exists because someone asked for the tool. The build is testing whether removing a decision from a person's head actually holds up when the exceptions arrive.

This changes what "minimum" means. A consumer MVP can ship broken edge cases because a user who hits one just leaves. An internal MVP cannot skip the edge case that happens every Friday when the transporter is late, because the plant will simply stop trusting the tool and go back to the phone call. As MVPable notes, internal tool builds succeed or fail on whether they replace an existing workaround, not on how many screens they ship.

How do you scope by decisions instead of features?

You scope by decisions by listing every judgement call a person currently makes without looking anything up on a screen, then ranking those calls by how often they happen and how expensive it is when they go wrong.

Start with a plain question to the person doing the job, not the manager who requested the tool: "When you don't know what to do next, who do you call, or what do you check?" The answers are the decisions. A store clerk who checks a WhatsApp group before releasing material against a purchase order is making a decision: is this order approved. A production supervisor who eyeballs the shop floor before promising a delivery date is making a decision: do we have capacity this week. Neither of these appears on a features list. Both are exactly what the tool needs to remove first.

Once you have the list, rank each decision on two axes: how often it happens per day or per week, and what it costs when someone gets it wrong. A decision made fifty times a day with a low cost of error, such as which shelf a part goes on, is not v1. A decision made twice a day with a high cost of error, such as whether to release a shipment against an unpaid invoice, is exactly v1.

What does a decision inventory look like in practice?

A decision inventory is a short list, usually under fifteen lines for a first release, of the specific judgement calls the tool needs to make redundant. It is not a requirements document and it is not a wireframe.

Take a mid-size trading firm running dispatch on spreadsheets and phone calls. The features list a founder writes might include order management, an inventory dashboard, dispatch tracking, a customer portal and reporting. That is five modules. The decision inventory looks different:

Decision currently made by judgement	Who makes it	How often	Cost of getting it wrong
Is this customer within credit limit	Accounts clerk, by memory or a call to finance	10-15 times/day	Bad debt, blocked cash flow
Do we have stock to promise this order	Sales executive, by walking to the warehouse	20+ times/day	Overselling, customer disputes
Is this dispatch approved to leave	Warehouse in-charge, verbal from owner	5-8 times/day	Unauthorised stock movement
Which order ships first when trucks are short	Dispatch head, by gut feel	Daily	Missed delivery commitments, penalty

None of these four rows map cleanly to a single module on the original features list. Two of them, credit limit and stock to promise, sit inside "order management." One, dispatch approval, sits inside "dispatch tracking." The fourth, truck allocation priority, does not exist on the features list at all, because nobody wrote "help me decide which order goes on the truck" as a feature. It is, however, the decision losing the company the most money. That is the one that goes into v1.

How many decisions should a first release actually remove?

A first release should remove somewhere between three and six decisions, not build every module the business eventually needs. Fewer than three and you have not changed anyone's day. More than six and you are no longer running an MVP, you are running a full build with an MVP label on it, and the timeline and testing burden grow accordingly.

The number three to six is not a feature count and not a screen count. A single decision, such as "is this dispatch approved to leave," might need a form, a status field, an approval button and a notification. That is one decision and four small pieces of interface. A features list would count those as four items and mis-scope the effort. Counting by decision keeps the scope honest, because it forces the question "does this actually stop someone guessing" rather than "does this look complete."

What goes wrong when internal MVPs are scoped like consumer MVPs?

The most common failure is building the dashboard before fixing the decision underneath it. A dashboard that shows "stock on hand" looks like progress, but if the sales executive still has to walk to the warehouse to confirm what is actually promisable versus what is on the books, the dashboard changes nothing. It gets checked once during the demo and ignored afterwards, and the phone calls continue.

The second common failure is scoping by department instead of by decision. A CTO asked to "build a tool for the warehouse team" will naturally list warehouse features: goods-in, put-away, picking, dispatch. But the decision that actually costs the business money might sit at the boundary between two departments, such as accounts and warehouse arguing over whether a dispatch can proceed against an overdue invoice. Department-shaped scoping misses boundary decisions almost every time, because no single department owns the question in the org chart, even though someone answers it by phone every day. Digital Royalty's scoping guide makes a similar point: internal software scope creep usually comes from mapping the tool to the org chart rather than to where decisions actually get stuck.

The third failure, and the most expensive, is automating a process nobody has questioned. If the current approval chain for a purchase order requires four signatures because of a fraud incident from six years ago that no longer applies, digitising four signatures does not fix anything, it just makes the delay faster to log. Before any decision goes into the inventory, ask whether the decision should exist in its current form at all, or whether it is a workaround for a problem already solved another way. Do not automate a bad process.

How does decision-based scoping change build time and stack choice?

It shortens the build, because a decision inventory of four to six items produces a smaller, sharper backlog than a features list, and it changes what "done" means for each sprint. A feature is done when it is built. A decision is done when the person who used to make that call by judgement stops making it and the system's answer is trusted enough to act on without a second check. That second bar takes longer to hit, which is why internal MVP timelines should build in a verification period, not just a build period. Alder VC's write-up on operator founders makes a similar point from a founder's seat: the MVP is not finished when it ships, it is finished when the workaround it replaced actually stops happening.

Stack choice follows the same logic. A tool that removes a small number of high-stakes decisions does not need a flexible plugin architecture or a configurable rules engine on day one, because you know exactly which four or five decisions it needs to get right. Over-engineering for future flexibility before the first four decisions are proven in daily use is the internal-tool version of gold-plating a consumer MVP nobody has used yet. Related to this is the question of running new and old systems in parallel during rollout, which we cover in migrating off a legacy ERP without stopping the shop floor: the same discipline of proving one decision at a time, before switching everyone over, applies whether you are replacing an ERP module or building a new internal tool from scratch.

What to do with this on Monday

Sit with the person actually doing the job, not their manager, and ask what they check or who they call when they are not sure what to do next. Write down every answer as a decision, not a feature. Rank the list by frequency and cost of error. Take the top four to six. That is your MVP scope, and everything else waits for v2.

If you are scoping an internal build and want a second pair of eyes on the decision inventory before development starts, our custom software development work starts at exactly this step, not at the wireframe. For more on how we approach builds like this, see the Building Software hub.