Skip to content

Custom Business Software

Product MVP: the smallest thing that answers the riskiest question

A first product usually starts as a list of everything it could do. An MVP starts with the one belief that would sink the product if it were wrong, and builds only what's needed to test it with real users. The rest is done by hand, left for later or dropped. The foundations that would be expensive to redo are built properly from day one. We help you name the belief to test, then build only what tests it.
Talk through your productSee what's in, and why ↓
the riskiest beliefProperty managers will send maintenance requests through a link instead of calling.Build nowrequest linkphotos on the requestcontractor inboxstatus updatesBy hand firsturgent-request sortinga person, for 8 weeksLaterinvoicingreportspaymentscalendar syncseveral contractorsNot doingmobile applink works on phonestenant accountskept from day oneaccounts and roles · the request record · history · each firm's data aparttest · 5 firms · 8 weeks · decide at 60% of requests through the link

A feature list is not a plan

Most first products are built from the list: everything users might want, prioritised by enthusiasm. Months later there's a product that does a bit of everything, and still no answer to the only question that mattered: will people use it instead of what they do now?

An MVP is built backwards from that question. It names the riskiest belief, decides what evidence would settle it, and builds only what produces that evidence, with real users and real data. When the answer comes, the code is still worth keeping.

A prototype, and an MVP

A throwaway prototype

  1. 01Built to show the idea, often with sample data.
  2. 02Shortcuts everywhere, because it won't last.
  3. 03Shown to people, who say they like it.
  4. 04Rebuilt from scratch if the idea goes ahead.

Polite feedback instead of evidence, and the first real build starts from zero.

An MVP you keep

  1. 01Built to test one belief, with real users and real data.
  2. 02Shortcuts only where they won't matter later.
  3. 03Measured against a threshold agreed before launch.
  4. 04Extended, not rebuilt, when the answer is yes.

An answer you can act on, and a codebase that's a head start.

What's in, what's later, and why

Every idea gets a decision and a reason. The reason is always about the hypothesis.
Request link with photosBuild nowIt is the hypothesis
Contractor inbox and status updatesBuild nowWithout them, managers go back to calling
Sorting urgent requestsBy hand firstA person can do it for five firms; automate once the rules are known
Invoicing and paymentsLaterDoesn't change whether managers use the link
Mobile appNot doingThe link works in a phone browser
Accounts, roles and data separationKept from day oneExpensive to add once real firms rely on it

Eight weeks, one answer

The test · 5 firms · threshold 60%

  1. Belief, measure and threshold agreed

    60% of requests through the link

    done

  2. Built and tested with one firm

    weeks 1–3

    done

  3. Five firms onboarded

    week 4

    done

  4. Requests counted every week

    link vs phone, per firm

    done

  5. Week 8 result

    54% through the link

    below threshold

  6. Calls reviewed

    most calls came from tenants, not managers

    done

Not yet, with a reason. Managers used the link; tenants didn't have it. The next question is whether tenants will use a link of their own, and the same code tests it.

The parts it's built from

Each part is built and tested on its own, so you can start with one and add the rest.

  1. Question

    Technical Roadmapping

    The riskiest belief, and the evidence that settles it.

  2. Scope

    SaaS & MVP Development

    • the belief
    • the threshold
    • the idea list

    doesn't help answer it → later, or by hand

  3. Build

    Backend Architecture

    Foundations kept; shortcuts only where they won't matter.

  4. Measure

    API Services

    Every request counted by how it arrived.

Underneath every stepIdentity & Access ManagementEach firm's people see only their firm's requests.

What changes from one product to the next

The beliefWhich assumption, if wrong, sinks the product
The evidenceWhat you'll count, and the threshold you'll decide at
The usersWho tests it, how many, and for how long
What's keptWhich foundations are built properly from day one

A common starting point is a Next.js application, a Postgres database, hosted sign-in, and analytics events for the one measure that matters. These are starting candidates, not requirements.

Is an MVP the right next step?

Good fit

  • You can name the belief that would sink the product.
  • You can reach a handful of real users to test it.
  • You expect to keep building if the answer is yes.

Avoid when

  • You only need to show an idea to investors or colleagues. A clickable prototype is cheaper.
  • The product is already proven and needs to serve many customers. Look at a SaaS product.

How we'd approach it

Most of the early work is naming the belief, the evidence that would settle it, the first users and what must be built properly from day one.

  1. 01

    Understand

    As much as the problem needs

    We map how the work runs today: who does what, which systems hold the records, and where it breaks.

  2. 02

    Design

    Decided before it's built

    Ownership, rules, integrations and exceptions, agreed with you and written down with acceptance criteria.

  3. 03

    Build

    Connected to what you use

    We build the scoped system, connect it to the tools you already run, and test it on the cases that matter.

Related systems

The capabilities underneath

Questions about MVPs

How small is an MVP?

As small as the question allows. Some are four screens; some are one form and a person doing the rest by hand.

What if the answer is no?

Then you've learned it with eight weeks and one small build, not a year and a full product. Often, like the example, the answer is “not yet” and points at the next question.

Why build foundations for something that might fail?

Only the ones that are expensive to add later: accounts, roles, the core record, history and keeping customers' data apart. Everything else stays minimal.

Can parts be done by hand?

Yes, and they should be when a person can do it for a few users. You learn the rules before you automate them.

Test the idea that matters first

Tell us about the product and the belief it depends on. We'll show you the smallest build that would test it.

Start a project