MVP development, small on purpose, real from day one.
The shortest path to a real user finishing a real job.
An MVP is not a cheaper version of the product. It is the smallest thing that can be put in front of people and produce an honest answer, which means one journey done properly rather than six done halfway. We build that first release in production, with real accounts, real payments where money is involved, and the code in your repository from the first commit.
The first releases we build
What counts as a minimum version depends entirely on what you are trying to learn. These are the situations we are usually brought into.
Clickable prototype, before any code
Sometimes the fastest way to learn something is a prototype people can click through. It settles the argument about the flow before a line of code exists, and moving a screen at that stage costs minutes rather than days.
- The core flow, screen by screen
- Testable with real users
- Used to settle scope disagreements
- Feeds straight into the build
Founder MVP, first version in market
A new product with no engineering team behind it yet. Everything not central to the idea gets bought rather than built, so the money goes into the part that is actually yours.
- One journey, end to end
- Real signup, billing, and hosting
- Ready-made services for the rest
- Analytics on the question you are asking
Internal MVP replacing a spreadsheet
The spreadsheet that became the system. A first version has a lower bar here because the users are down the hall, so it can ship narrow and grow weekly against real feedback.
- The current process, mapped honestly
- One team live first
- Existing data imported, not retyped
- Widened once the first team stops asking
A new line inside an existing business
An established company testing something adjacent. The constraint is usually integration rather than build: it has to touch the existing systems without waiting on them or destabilising anything.
- Read-only integration first
- Separate deployment from the core system
- Existing identity and access reused
- A clean path to fold in later
A pilot build for one named customer
You have a buyer waiting and a deadline attached to them. Built so the pilot is not a dead end: their configuration is data, not a fork, so customer two does not mean a rewrite.
- Scoped to what the deal requires
- Configuration as data, not a fork
- Deployed and supported for the pilot
- A named path to a second customer
Rebuilding a no-code product that outgrew its tools
The version that proved the idea and is now the ceiling: hitting limits, costing more per user every month, or unable to do the one thing customers keep asking for. Rebuilt without losing what already works.
- The working version treated as the spec
- Users and data migrated intact
- The specific limit that forced the move
- Cutover without a gap in service
How the work runs
Tell us what you need
A short written brief is enough to start: what you are building, the stack it has to live in, and the problem behind it. Someone technical reads it, not a sales rep.
passed when we reply with questions and a proposed shape
Scope and quote
We agree what the first release contains and what it costs before anything is built. Anything we cannot estimate honestly gets scoped on its own rather than padded into the total.
passed when the scope and the quote are agreed
Build in the open
Working software arrives in increments, in your repository, with our commits visible from the first week. Progress is something you can open and run, not a status report.
passed when a real user is doing a real job in it
Iterate, then hand over
What the first release teaches sets the priority for the next one. When you want it in house, documentation and a handover period are part of the engagement rather than an extra.
passed when your team can run it without us
How pricing works
Fixed price per milestone
You approve each milestone and its price before it starts, so the cost is known before the work is rather than after. Milestones are sized to be worth reviewing on their own.
Monthly rate for a dedicated team
A set team at a set monthly cost, with notice rather than a minimum term. Priorities move between sprints without renegotiating anything.
Scoping first, quote after
We work out what it should be with you before quoting it. There is no charge for that conversation and no obligation to go ahead.
Frequently asked questions
How a first release is kept small
Every build ships end to end, from first scope to live deployment and ongoing support.
