MVP development for internal tools: the smallest version that answers one question

Eric Ries, whose Lean Startup made the term famous, defines the MVP as the version of a new product that collects the maximum amount of validated learning about customers with the least effort. Frank Robinson, who used the term before him, called it the right-sized product: big enough to be adopted, not so big that it's bloated and risky.

Both definitions were written for a product that has to find customers. An internal tool is in a different position, and the differences change the MVP:

• The users are known. You know who will run it, and you can sit next to them while they work.
• Success can be measured. The time a task takes, the errors it produces, how often a file is sent back: all of it can be recorded before anything is built.
• The competitor is the current way. An internal tool competes with Excel, with manual copying, and with years of habit.

An internal tool has users who can't switch to a competitor. They can go back to Excel, though, and they usually do, quietly, on the second day.

The three terms get used interchangeably. Each one answers its own question, and a stage whose question is still open shouldn't be skipped:

• Proof of concept: can it be done at all? Does the Revit API expose what you need from this kind of element? Is the other program's export readable? The result is usually code only its author can run.
• Prototype: is this how it should work? The inputs, the order of steps and the shape of the output are shown to users, even if fake data sits behind them.
• MVP: does it deliver in real work? One workflow, one team, real project files, and a measure written down before the build.

Proof of concept software development is worth doing when the main risk is technical. A prototype is worth doing when the main risk is how people will use it. If neither risk is serious, go straight to the MVP.

Not every idea needs custom software. Before building anything, check whether an existing product, an add-in someone already sells, or a better organised Excel file does the job. If your question is whether a product already does this, answer it with a free trial. You don't need us, or anyone like us, for that.

An MVP earns its cost when several of these hold at once:

• A repetitive task that happens every week or every project, with a rule you could write down.
• Data that lives in the office's own files, Revit models, drawing sets, spreadsheets, where off-the-shelf products don't reach.
• An error whose cost shows up late, usually at issue or on site.
• A task that depends on one person and stops when they're away.

AEC workflow automation covers where those processes usually hide in an office. The MVP is the next step, once the process is known.

An MVP without a measure turns into a small version of a product nobody can call a success or a failure. Before building, write down three things:

1. The question, in one sentence: "Can this number a project's sheets without anyone editing them by hand?"
2. The current state: how long the task takes today, who does it, and where it usually goes wrong. Record it from a real run, not from memory.
3. The measure: which result means yes, and which result means stop.

The stop condition matters as much as the success condition. If nobody decided in advance what result means stopping, every result becomes a reason to continue. It's the same approach research and development at ARTINEXT runs on: the measure comes before the build.

An MVP's scope is set by cutting. Anything that doesn't help answer the question moves to the next version:

• Cut: admin panels, configurable settings, support for several software versions, final visual design, and any feature only one person asked for.
• Keep: correct results, a report of what the tool couldn't process, and a way back, Revit's Undo or a backup of the file.

In a technical office the shortest path is often inside the software the team already opens every day. A Dynamo graph or a pyRevit script can test a plugin's logic on a real project before anyone pays for an interface, an installer and upgrades. Custom Dynamo script development covers when a graph is enough and when it should become a plugin. Done this way, the script becomes the plugin's specification.

Smaller scope is not lower accuracy. A tool that delivers a wrong result silently costs more than the manual way, because checking each of its outputs takes longer than doing the task by hand.

A test on a sample file the developer prepared proves the tool works on that file. Real project files carry inconsistent naming, legacy elements and exceptions no sample file has.

The GOV.UK Service Manual describes its alpha phase as the stage where you try out different solutions to the problems found during discovery. For an internal tool, that test has three conditions:

• A real user: the person who does this task today runs the tool.
• A parallel run: for a while, the work is done both ways and the results are compared.
• Everything logged: every error, every unprocessed item, every point where someone had to finish the job by hand.

That log is the most useful thing the MVP produces. It decides what the next version has to solve.

An MVP ends in one of three ways, and all three are worth having:

• Build it: the measure was met, and it's clear what the full version has to add.
• Change course: part of the idea worked and part didn't. The next version concentrates on the part that did.
• Stop: the tool doesn't save enough time, the data can't be trusted, or an existing product does it better.

The third outcome is also a result, at a cost you haven't paid yet. Martin Fowler calls the mindset sacrificial architecture: accepting now that what you're building may be thrown away later. MVP code is written to learn. If the full version is built on a different structure, the MVP did what it was for.

Once the full version is approved, the questions change. It's no longer whether the tool works. It's whether it still works next year:

• Upkeep across releases: Revit ships a new version every year, and plugins have to follow.
• Code ownership: the source code, documentation and repository access belong with the office.
• Support: who answers users' questions, and how errors get reported.
• Onboarding: how new staff learn the tool.

What Revit plugin development costs breaks those after-delivery costs down item by item. The MVP makes sure they're only paid for a tool that has already proved itself in real work.