Ninety-six hours is a delivery window, not a universal promise
A large product cannot be compressed into four days by typing faster. Architecture, unknown requirements, integrations, compliance, content, testing and stakeholder decisions still take time. Pretending otherwise transfers risk into poor security, brittle code and unfinished behavior.
A 96-hour MVP works when the project has a narrow objective and the major uncertainties have already been removed. The goal is a working first release that proves one useful workflow—not a miniature version of every feature the eventual product might contain.
What is usually suitable
Suitable projects share a useful property: their success can be stated in one or two sentences and verified by using the release. An internal team can create and manage a defined record. A client can submit and track a request. An operator can see one dashboard assembled from an existing source. A website can publish approved content across a known set of pages.
Existing infrastructure and APIs can accelerate delivery, provided their access and behavior are already understood. An AI integration using an established model API may fit if the data boundary, prompt task, output format and human review step are defined. Training a custom model does not fit the same window.
- Focused internal tools and CRUD workflows
- Dashboards over accessible data
- Corporate websites and landing pages with ready content
- Client portals with one defined journey
- Focused SaaS prototypes
- Bounded automations and existing-model AI integrations
What is not suitable
The wrong projects contain unresolved systems rather than a bounded first workflow. A large enterprise migration depends on data quality, change management and several owners. A marketplace combines two-sided product behavior, trust, payments and operations. A regulated platform needs evidence, review and controls that cannot be reduced to a coding sprint.
Undefined ideas are also poor candidates. If the first two days would be spent deciding who the user is and what problem the product solves, the project needs discovery before a delivery clock. Speed is valuable after the important decisions have been made, not as a substitute for making them.
- Large enterprise or data migrations
- Undefined product concepts
- Highly regulated platforms
- Complex marketplaces
- Custom model training
- Multi-system transformations
- Work blocked by third-party approvals
The clock starts after readiness
Assessment happens before the build window. We confirm technical fit, reduce the scope to one coherent release, identify dependencies and decide what ‘working’ means. Required accounts, API credentials, brand assets, approved copy and decision-makers must be available. Third-party review queues—such as app-store approval—sit outside the 96 hours.
The resulting scope is explicit about what is included and excluded. That protects quality. The team can choose a simple architecture, establish the data model and security boundary, build the primary flow, validate it against acceptance criteria and deliver a deployable release with known next steps.
Speed comes from decisions, not shortcuts
Disciplined scope reduces coordination and rework. Reusing dependable platform capabilities reduces undifferentiated engineering. Clear acceptance criteria concentrate testing on the release’s real promise. None of those choices require abandoning validation, identity controls or a maintainable structure.
The first release should create evidence. Users can handle the real workflow, the team can observe where it succeeds or fails and the next investment can be based on behavior rather than assumptions. That is the purpose of the 96-hour proposition: a technically suitable project, made ready in advance, moved into reality with focused engineering.
The 96 hours begin when scope, feasibility, access, requirements and assets are ready—not when the first idea is mentioned.