How to Build an MVP in Estonia

Write a testable hypothesis

Use a sentence that identifies the customer, the job, the current alternative and the improvement. For example: 'Independent agencies will pay to reconcile supplier invoices faster than their current spreadsheet process.' This is a hypothesis, not a claim that customers already want your product.

List what must be true for the business to work. If the main risk is willingness to pay, an elaborate technical prototype will not resolve it. If the main risk is technical feasibility, a landing-page signup test will not resolve that either. Choose the experiment that addresses the current risk.

Sources: Y Combinator: How to plan an MVP

Choose one end-to-end workflow

Sketch the path from the user's starting situation to the promised result. Keep the steps necessary to complete that path and postpone optional dashboards, extensive settings and integrations that do not affect the test.

For the invoice example, the first workflow could be upload, review, correction and export. A team member may check the result manually if the customer understands this. Describe the service honestly: a human-assisted pilot is not a fully autonomous production system.

• One user role and one primary job.
• A result the customer can evaluate.
• A way to report mistakes and get help.
• An explicit list of features outside the pilot.

Pick the build approach

A manual service tests the value of an outcome quickly. A no-code workflow may be enough for a standard process. Custom software is justified when the experiment depends on behaviour or technology that simpler tools cannot represent.

Before hiring an agency or freelancer, define deliverables, acceptance checks and ownership of the code and accounts. Keep access to the repository, hosting and domain under the company's control. Ask for a deployment and handover plan, not just screenshots of completed screens.

Make the pilot safe to use

Small scope does not excuse careless handling of customer information. Use sample or de-identified data where possible. Decide who can access uploads, how long they are retained and how deletion requests will be handled. Get specialist advice where regulated or sensitive information is involved.

Test the core flow on the devices your pilot customers actually use. Include loading, empty and failure states. A simple product that explains a failed upload is more useful than a polished interface that silently loses work.

Measure behaviour and learning

Define success before reviewing the results. Our suggested pilot sheet records invited users, completed workflows, repeated use, time to first useful result, errors and willingness to pay. Do not report all of these as one 'engagement' number.

Illustrative experiment: five agencies each try one reconciliation task. Continue only if enough users complete the task and want to repeat it at the proposed price. Choose the actual threshold according to the risk and economics of your business; five tests alone do not establish product-market fit.

Finish with a decision

At the review date, compare results with the original hypothesis. Continue, revise the customer or workflow, or stop. Document what you learned even if the experiment failed: it should change the next investment of time.

A useful advisory request includes the customer, workflow sketch, evidence and the decision you cannot yet make. The Estonian Startup Community can be a place to discuss that problem and find peers. Do not build extra features simply to make a demo look larger.