Short builds aren't about shipping less. They're about finding the expensive question sooner.
A four-week build is not a discount version of a six-month build. It's a different instrument, and its job is to convert open questions into answered ones while the cost of being wrong is still small.
The questions worth targeting are the ones that could invalidate the roadmap. Can the necessary data actually be joined? Can a model perform the required task reliably enough to be useful? Does the workflow survive contact with a real user? Can we reliably tell whether the system's outputs are good enough, and whether they're improving? When RAND studied why AI projects fail, it put the failure rate above 80%, with misunderstanding of the problem to be solved as the most common root cause [1]. Everything else, including polish, scale, and comprehensive coverage, is deferrable by design. Teams that resist that ordering often spend their first quarter hardening a system whose core premise hasn't been tested.
A short build isn't a smaller promise. It's a faster way to find out which promise is worth making.
The goal is evidence, not completeness
A good MVP is a narrow but complete version of the intended product: it accepts a real input, performs a meaningful piece of the workflow, and produces an output someone can evaluate. It may support only one user type, one data source, one carefully chosen scenario, but a real one. This is the lean-startup logic of validated learning over elaborate planning, on a fixed clock [2].
Structurally, we build what agile practitioners call a walking skeleton: instead of partially building every layer, one path runs all the way through — interface, business logic, data integration, model interaction, and output [3]. The result is not broad, but it's deep enough to expose the assumptions hiding between the layers.
One path, all the way through. Not broad, but deep enough to expose the assumptions hiding between the layers.
Week one: define the decision
The first week is largely about refusing ambiguity. "Build an AI assistant" is not yet a useful scope. We need a specific workflow, the people involved, the information entering the system, and the decision or artifact produced at the end.
More importantly, we need to agree on what the MVP is supposed to prove, and aim at the biggest risk first:
- Uncertain data access means reaching the difficult source immediately.
- Model accuracy means representative examples and evaluation criteria before interface work.
- Adoption means real users early enough for their behavior to influence the build.
The output of this phase is a deliberately constrained promise: for these inputs, in this situation, the system will attempt this task, and we will judge it using these criteria.
Week two: make the entire path work
The second week usually produces the first end-to-end version. It may be awkward, the interface plain, some steps still manual. But real information should move through the system, and the result should be inspectable.
This is where many of our most important discoveries happen. An API doesn't expose the fields its documentation suggests. Two databases use incompatible identifiers. A model performs well on simple examples and fails on the cases users care about. Finding these is one of the sprint's main purposes: each discovery replaces an assumption in the roadmap with evidence.
What matters is not whether the system can look convincing once, but whether the workflow works repeatedly under realistic conditions.
The temptation is to hide the awkwardness behind a polished demonstration. That produces a more impressive meeting and a less useful MVP.
Week three: test the premise
Once the complete path exists, attention shifts from construction to evaluation. Real users try the system. Outputs are compared with known examples or reviewed by domain experts. Failures are classified rather than patched indiscriminately: did the system retrieve the wrong information, misinterpret the request, apply the wrong rule, or make a judgment that belongs to a person?
This step earns its week. Microsoft's experimentation platform found that only about a third of well-reasoned product ideas improved the metrics they targeted once tested [4]. Confidence is not a substitute for a test, and for AI systems in particular, a fluent output is not evidence of a working product.
Confidence is not a substitute for a test. A fluent output is not evidence of a working product.
The evaluation doesn't need to be statistically definitive after four weeks; it needs to be concrete enough to support iteration. A small, representative test set with expert review beats a pile of anecdotal successes. By the end of this week, we should know not only how often the MVP works, but how it fails and which failures look tractable.
Week four: turn a prototype into a decision
The final week consolidates what was learned. We fix the problems that prevent meaningful use, make the primary workflow repeatable, document the limitations, and reorganize the backlog around what the sprint revealed.
The handoff includes working software, source code, setup instructions, an architectural outline, evaluation results, known risks, and a recommended path forward. The recommendation may be to continue, to change the workflow or a data source, to narrow the market, or occasionally that the idea shouldn't be pursued in its current form. That outcome can feel disappointing, but it's often the most valuable one: the cost of fixing a fundamental error escalates steeply the later it's found, and four weeks in is a far cheaper place to find it than after launch [5].
What will not be finished
A four-week MVP is generally not a production system: expect gaps in coverage, visual design, monitoring, automated testing, and infrastructure proven under load. Security and privacy should inform the architecture from the start, but formal compliance work usually needs a later phase.
Our OnTarget project illustrates the boundary. The four-week MVP established the core evidence-synthesis workflow; the following twelve weeks added stronger citations, reporting, broader processing capacity, and production hardening. Four weeks can establish the shape and feasibility of a product. It can't compress everything a mature product requires into a single month.
What the client contributes
Speed depends as much on access and decisions as on engineering. The strongest sprints we've run had an engaged client owner who could answer workflow questions, provide representative data, arrange access, and make scope decisions quickly; a three-day delay obtaining credentials is significant in a four-week engagement. The client doesn't need to manage the development process, just to stay in regular contact through someone with the knowledge and authority to resolve ambiguity.
The real deliverable
At the end of four weeks, the most valuable result is not a longer feature list. It's a better-informed decision. The client can see the workflow operating, identify what remains manual or uncertain, understand the largest risks, and estimate the work required to reach production.
The next investment is no longer based primarily on enthusiasm, but on a working system, observed behavior, and evaluation evidence.
That is what a short build is for: not to pretend the finished product can be delivered in four weeks, but to make sure the expensive work that follows is aimed at something worth building.
References
- [1]James Ryseff, Brandon F. De Bruhl, and Sydne J. Newberry, "The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed," RAND Corporation, August 2024. rand.org
- [2]Steve Blank, "Why the Lean Start-Up Changes Everything," Harvard Business Review, May 2013. hbr.org
- [3]Clint Shank, "Start with a Walking Skeleton," in 97 Things Every Software Architect Should Know (O'Reilly, 2009); the pattern is due to Alistair Cockburn. oreilly.com
- [4]Ron Kohavi et al., "Online Experimentation at Microsoft," Third Workshop on Data Mining Case Studies, 2009. stanford.edu
- [5]NASA Johnson Space Center, "Error Cost Escalation Through the Project Life Cycle," NASA Technical Reports Server, 2010. ntrs.nasa.gov