Skip to content

MVP development for your first product.

An MVP gives users a first version of your product to try. We choose the main task it needs to support and agree which features can wait. I work remotely with founders in the Netherlands and Aruba, with the schedule agreed before the build.

Start a project

What do you want to test?

An MVP helps you test a specific assumption: whether people will use a product, pay for it or return to it.

We define that question before deciding which features belong in the first version.

If demand is already established, we can instead plan the first release around the needs of your existing customers.

What gets built.

The main user journey, plus the features needed to test it with real users.

The one thing it has to do

We agree what the first version needs and record the remaining ideas for later releases.

Accounts and sign-in

Accounts and sign-in when users need to return or save information. For an interest test, a waiting list may be enough.

Payments

If you need to test willingness to pay, we can include checkout and payment handling in the first version.

Code for further development

A clear data model, common technologies and tests for the important user journeys. Later features may still require changes.

Analytics and error tracking

Analytics and error tracking to help you see how people use the product and where they run into problems.

A plan for the next version

A short handover covering deferred features, decisions made during the build and possible next steps.

What it costs.

This range covers one core user journey to test one assumption. Accounts, design and integrations are agreed in the quote. Complex payment flows or a broader product need a separate estimate.

€5,000 – €12,000

for a focused first release

Excl. VAT. Quoted for an agreed scope.

We agree the scope and quote before building. If new findings change the plan, we discuss the cost and schedule before continuing.

What determines the price

  • The features needed to test your assumption
  • Whether real users need accounts, or a waiting list is enough
  • Whether it takes payments on day one
  • How much design exists before the build starts

How it runs.

I do this work alongside my full-time job, with up to 20 hours a week available for freelance projects. We agree a realistic schedule before starting and can split the work into smaller releases.

First

Cut it down

We define the assumption to test and agree the smallest useful first release.

Early

Clickable, end to end

I build the main user journey so you can try it and gather early feedback.

Every week

Build, review, cut again

You review working software each week. We check requested changes against the purpose of the first release.

Launch

Out, instrumented, documented

We launch with analytics and error tracking, then hand over the code and notes for the next version.

What is and is not in it.

Included

  • Scoping the question and cutting to fit
  • Full-stack build of the core path
  • Accounts and payments where they are in scope
  • Analytics and error tracking
  • Deployment and a real domain
  • A short written v2 path
  • The code, in your repository, from day one

Not included

  • The full product roadmap
  • Native mobile apps, unless scoped in
  • Admin panels for problems you do not have yet
  • Scaling work for traffic that has not arrived
  • Fundraising material, pitch decks or financial modelling

Team experience: Kollaby.

Kollaby was an event collaboration product built in a scrum team, with shared code review and a regular release cadence, and it shipped to both the App Store and Google Play. It has since been delisted and is no longer active.

My contribution included full-stack development and real-time collaboration. The team also handled app-store review and releases.

See selected work

Before we start.

How small is too small?

It needs to let users complete the task you want to test. We use that requirement to decide what stays in the first version.

Will we have to rebuild it if it works?

Some parts may change as you learn. I plan the data model and core code for further development, but no first version can anticipate every future need.

Do you take equity instead of payment?

No, I work on a paid project basis. If the budget is limited, we can discuss a smaller scope.

Can you keep building it after launch?

We can discuss further development after launch, subject to availability. You can also continue with your own team or another developer.

Do you sign an NDA?

Yes, happily, before you tell me anything sensitive.

Tell me about your project.

Tell me what you're working on. I'll tell you how I'd build it, what it would take, and whether I'm the right person for it. No obligation.