MVP and prototype development that proves the idea before the full build.

Put real evidence behind the investment decision. We scope a clickable prototype, a proof of concept, or a minimum viable product to answer one question, and build the MVP so it becomes the first release.

Scope an MVP How the work runs

Who hires us for this

Founders and operators with an idea that needs evidence: a new product, a new line of business inside an existing company, or an internal tool the team is not sure will be used. Also companies that need a working demonstration to win over a customer or a board.

Why now

The idea needs something real in front of users before more money goes in.
One technical question decides whether the product is possible.
A customer or investor wants to see it working, not described.

A decision, not a pitch

Prototype, proof of concept, or MVP?

People ask for these three interchangeably, but they mean different things. Each answers a different question.

Consideration	Prototype	Proof of concept	MVP
Question it answers	Will people understand and want this?	Can the hard part be done?	Will people use and pay for it?
What is built	Clickable screens, little or no backend	The risky piece, end to end, nothing else	The core loop, real accounts, real data
Who uses it	A handful of target users, guided	The team and technical stakeholders	Real users, unguided
What survives	The design	The technical approach	The product; it becomes the first release
When to choose it	The concept is unproven	One technical risk dominates	Concept and approach are proven

What this covers

What MVP and prototype development covers.

Prototypes

Clickable screens that let target users react to the idea before anything is built.

Proof of concept

The one risky piece built end to end: an integration, a model, a data flow.

Minimum viable product

The core loop, real accounts, real data, and a release process, built to become the product.

Validation support

Instrumentation and the questions to ask, so the MVP produces evidence.

From MVP to product

The next release scoped from what users did, not from what was planned.

PrototypeWill people want it?
Proof of conceptCan the hard part be done?
MVPWill they use and pay?
First releaseThe product, on the same foundation

Scope grows only when the previous question is answered.

Each step is sized to answer one question. The MVP is built on the foundation the first release keeps.

When companies call us

If this sounds like your business, here is where we start.

A founder needs to show users something before raising

A prototype in front of target users, then a decision on what to build.

A product depends on one integration nobody has tried

A proof of concept that connects the systems end to end and reports what it found.

A company wants to test a new service line

An MVP for the first customers, on the company’s existing systems where possible.

An internal tool might not be adopted

A minimum version for one team, measured, before the full build.

How the work runs

Scoped in writing, built in releases, handed over.

01
Name the question
What must be true for this to be worth building? The scope is built to answer it.
02
Choose the instrument
Prototype, proof of concept, or MVP, and the smallest version that answers the question.
03
Build to the scope
Working software in front of the people whose reaction matters.
04
Measure and decide
What users did, what broke, what it cost, and a recommendation.
05
Grow it or stop
If it works, the MVP becomes the first release. If not, the evidence has done its job.

Deliverables

What you receive.

ScopeAgreed

First release · version 1.2Scope and acceptance

Includes: The core workflow, roles and permissions, and the first integration
Left for later: Reporting and the second integration
Acceptance: Criteria agreed with your team
Price: Fixed before the build begins
Start date: Agreed in writing

Approved by operations Approved by finance

RunbookHanded over

Operations · version 1.0Running the system

01Deploy a releasePipeline
02Roll back a releaseTested
03Restore from backupTested
04Alerts and who respondsCurrent
05Access and secretsBy role

Written scope
What the first release includes, what it leaves for later, the integration decisions, the acceptance criteria, and the price, agreed before development begins.
Release notes
What changed in each release, what was tested, what the security review covered, and how to roll it back.
Documentation and runbooks
How the system is built, how to run it day to day, and what to do when something fails.
Training and handover
Sessions with the people who will use and run the system, and a handover checklist your team signs off on.

Every release ships with tests, a security review, and documentation, so your team can run what we build.

Your first release

What the first release could include.

The scope is written and agreed before development starts. This is the shape it usually takes.

In the first release

A written scope naming the question and the success signal
The prototype, proof of concept, or MVP
Instrumentation so behavior is measured, not guessed
A short findings report and a recommendation

Usually later

The first full release, scoped from the evidence
Accounts, billing, and operations for paying customers
The second loop the users asked for

Systems it may connect

Built to work with what you already run.

Identity and sign-in providers
Payment services for early revenue
Analytics and product instrumentation
The existing systems an internal MVP must read from
Email and notification services

Commercial cleaning company

A booking page tests whether small offices will buy cleaning online without a site visit.

Commercial cleaning companies usually sell through a site visit and a written quote, and the open question is whether small offices would book online instead. A focused MVP answers it: a booking page for a single service area, with instant pricing from the company’s rules, connected to the crew schedule and instrumented so behavior is measured. A findings report sets out what visitors do, where they drop off, and whether bookings arrive without a call. If the evidence supports it, the MVP becomes the first release, and accounts and billing follow.

In plain terms

What is MVP development?

MVP development builds the smallest version of a product that real users can use and pay for, so the idea is tested with behavior rather than opinions. Prototype development tests the concept with screens; proof-of-concept development tests the risky part with working code.

We scope each to the question it must answer, and we build the MVP on a foundation that becomes the product. An MVP that has to be thrown away was a prototype with the wrong name.

Questions

Questions about MVP and prototype development.

What buyers ask before a project starts, answered plainly.

Which one do we need?

Choose a prototype if the concept is unproven, a proof of concept if one technical risk dominates, and an MVP if both are settled. We decide on the first call and write the scope around the question.

Will the MVP have to be rebuilt?

Not if it is built as one. We use the same foundation, tests, and release process as a production system, scoped down. The prototype and proof of concept are disposable by design; the MVP is not.

How small is minimum?

It covers one core loop for one kind of user, with real accounts and real data. Everything else waits for evidence.

Can it use our existing systems?

Yes. An internal MVP usually reads from the systems the business already runs, which is what makes the test realistic.

What do we get at the end?

We deliver the working software, the instrumentation, and a findings report with a recommendation: grow it, change it, or stop.

What if it does not work?

Then it worked as an experiment. The evidence stops a larger mistake, and the scope was sized for that outcome.

Scope an MVP.

Tell us about the work and the systems around it.
We’ll come back with a written scope for a first release.