MVP to market
A first version real customers can use, in weeks rather than months.
Most MVPs fail because they try to include too much, and engineering is rarely the cause. Deciding what to build is now the slow part. We make the build fast enough that the discussion about what to include becomes the slowest step, then keep the scope small enough that people can complete a real task in what you launch, instead of clicking through half-finished screens.
Our approach
Week one is the spec, written to the level of detail our tooling can generate from, which is more detail than a normal PRD. After that the build runs in daily increments you can open and click. We deliberately release the least impressive complete path first: one job, done from start to finish, in production. Everything else waits until real usage shows it is needed. Timeline we plan for: 4 to 8 weeks to a public launch.
Other builds
Common questions
Why do most MVPs fail because of scope instead of engineering time?
Because deciding what to build is now the slow part of releasing software. A team that spends its first month arguing about which features belong in version one is spending time on the part that is now genuinely hard, while the part that used to be hard, the implementation, has gotten cheap. A faster build leaves a scope problem in place and only shows it sooner.
What does 'week one is the spec' actually mean in practice?
It means the first week produces a specification detailed enough for our tooling to generate working code from, which is more detail than a normal product requirements document contains. That level of detail is where the real decisions get made: what a user can and cannot do in version one, what counts as done for each screen, and what is explicitly out of scope.
What is the 'least impressive complete path' and why release it first?
It is one job done from start to finish in production, rather than several jobs each half-finished. A user who can complete one real task, however narrow, is a better first release than a set of screens where nothing fully works. Everything beyond that first complete path waits until real usage shows what is needed, instead of being guessed at the start.
How fast can a first version actually reach real customers?
Four to eight weeks to a public launch is the range we scope new work to, not a measured average across past projects, since this describes an engagement pattern rather than a record of past projects. The main factor is usually how quickly the specification can be agreed, since the build itself goes as fast as the AI can generate code once that is settled.
Do we see the product before it launches, or only at the end?
The build runs in daily increments you can open and click, instead of one big reveal at the end of the engagement. That matters most for an MVP specifically, because early usage of an unfinished but working path is the fastest way to find out the spec assumed something customers do not actually want.
What happens to features that get cut from the first version?
They wait until real usage shows they are needed, instead of being built on a guess. Once the first complete path is live, actual customer behavior decides what gets built next, in place of a guess on the roadmap. A feature that seemed essential in planning sometimes turns out to be unused once real people are using the actual first path.
Is a narrow first launch a smaller product or a lower-quality one?
It is narrower, and the quality is the same. The one path that is released is built to work from start to finish in production, evaluated the same way any other Reveneau build is, rather than a rough prototype. The difference from a broader launch is how many jobs a customer can do on day one. The job they can do works as well as in any other build.
How does this pattern differ from a traditional agency MVP sprint?
A traditional agency MVP sprint usually still spends the bulk of its calendar time on implementation, so scope gets fixed early to protect the schedule. Because AI generates the code fast here, the calendar time goes to the specification and to reacting to real usage after the first path is released, rather than to defending an estimate made before any customer used the product.