vosetu.

MVP & Produktentdeckung

Instead of waiting months for the perfect product, we build the version that carries the core value fastest, test it with real users and grow it as we learn. Intuition from 46 products is in play from day one.

Mit einem Experten sprechen

We turn an idea into a working product by the shortest path

Waiting months for the 'perfect' product usually means burning the budget without ever testing the idea. We do the opposite: we build the version that carries the core value fastest, test it with real users and grow it as we learn. Narrowing scope isn't shrinking the idea — it's finding which piece actually settles the decision.

In this work we trust pattern, not guesswork. As a team that has built 46 sector products from scratch, we've repeatedly seen which feature is essential on day one and which arrives in month six; that instinct is on the table from the first meeting. From prototype to working code, from working code to real user feedback, every step moves on a weekly rhythm.

  • Intuition from 46 products
  • Weekly iteration rhythm
  • Validation with real users
  • A technical foundation ready to scale

The discovery phase: the cheapest step before code

01

What the discovery phase is

A short, intense round of work before any code is written: stakeholder interviews, mapping the idea and any existing process, prioritizing scope, an initial technical feasibility note. The goal is to pin down 'what are we building' to a clear answer — before development starts, not after.

  • Stakeholder interviews and a process map
  • Scope & priority clarity (must/should/could)
  • An initial technical feasibility note
02

Why we start with discovery

Changing a diagram takes a day; changing written code takes weeks. Skip discovery and scope grows mid-development, and the budget and timeline estimate drifts from reality. A short discovery round catches a wrong assumption before it gets expensive; the remaining development time runs on a plan, not a guess.

  • No code is written before scope is clear
  • A wrong assumption is caught before it gets expensive
  • The budget and timeline estimate becomes realistic

Who works on the discovery and MVP team

A small, focused team; every role produces a concrete deliverable — not a meeting note, but a document that drives a decision.

Business analyst (BA)

Extracts the need and the existing process together with stakeholders, and writes scope and priority down.

UX/UI designer

Turns the flow into a clickable prototype; it's tested with real users there first, screen by screen.

Tech Lead

Makes the architecture and technology choices, and lays out technical feasibility and a realistic time estimate.

Project manager

Coordinates scope, timeline and deliveries; keeps the weekly rhythm on track without drifting.

Weeks 1-3: from discovery to a deliverable plan

01

Week 1 — Interviews & current state

Input: stakeholder interviews, review of any existing process/system. Output: a problem statement and a first scope draft.

02

Week 2 — Scope & prototype

Input: a priority workshop (must/should/could). Output: a clickable prototype and a settled feature list.

03

Week 3 — Technical plan & estimate

Input: first user feedback on the prototype. Output: an architecture draft, technology choice, a time and budget estimate.

How we build the MVP

01

We narrow the scope

We determine the smallest feature set that carries the core value; the 'nice to have' list waits for the next iteration.

02

We move from prototype to code

Real development starts from the approved prototype; the target is a working flow, not a screen.

03

We build the core

Authentication, the core data model and the main flow are built first — everything else sits on that foundation.

04

We test with real users

The early version is opened to the target user; feedback is collected not as a note but as input for the next iteration.

05

We launch and grow by learning

The MVP goes live; the next step rests on observation, not guesswork, thanks to usage data.

What ships as standard in every MVP delivery

Requirement analysis and a written scope document
A clickable prototype (Figma)
A working MVP — web or mobile
Early user testing and a feedback report
A layered architecture ready to scale
Basic monitoring/analytics setup
A short go-live training session
A prioritized recommendation list for the next iteration

3 gains the MVP approach brings

Speed

Weeks, not months; the idea turns into a testable reality by the shortest path.

Risk reduction

Before a large investment, the assumption is tested with real users and real data.

Decision clarity

The next step reflects an objective decision backed by usage data, not a feeling.

2 – 10 hafta
From idea to working MVP
46
Sector products behind us
22
Industry verticals
.NET 9
Modern core stack

The technology we build on

Prototype
  • Figma
Fast core
  • .NET 9
  • Next.js
  • Flutter
Method
  • Lean scope
  • Weekly iteration
Testing
  • User testing rounds

Frequently asked

How many weeks does an MVP take?

It depends on scope; the general range is 2-10 weeks. After we clarify scope in the discovery round, we give you a specific timeline and estimate — a written plan, not a vague range.

Can we skip discovery and start development directly?

If scope is already clear and written down, yes, we can move straight to development. But our experience shows a few days of discovery cost far less than scope that grows mid-development.

Do you keep growing the product after the MVP?

Yes. The MVP is a start, not an end; a prioritized roadmap emerges from usage data, and if you want we continue development with the same team under SLA maintenance or new sprint cycles.

Our idea is very early-stage — does it need to be ready?

No. That's exactly what the discovery workshop is for: clarifying a half-formed idea through stakeholder interviews, prioritizing it and turning it into a scope ready to test.

Let's get your idea ready to test, together

We'll listen to your scope, target users and timeline and map out where to start, together. The first conversation is non-binding.