Founders do not need a 200-page specification document, a microservices architecture, or a brand identity system that accounts for every possible future use case. They need something real to put in front of users in the shortest time that allows them to learn whether their hypothesis is correct. The 90-day launchpad we run packages MVP build, brand kit, and first go-to-market experiments into a structure that respects runway and delivers a product that users can actually interact with — not a demo environment that looks like one.
The 90-day structure and why each phase exists
Weeks one through three are problem sharpening, not solution building. The most common failure mode in early-stage product development is building a solution to a problem that is not sharp enough to have a testable hypothesis. We use structured problem definition exercises with the founding team to arrive at a problem statement specific enough to generate a falsifiable prediction: "if we solve X for Y user in Z context, they will do W." Without that, the MVP builds the wrong thing at high speed.
The technical spine is also chosen in weeks one through three, not in sprint one of development. Framework choice, database choice, deployment target, and authentication approach are decisions that are expensive to reverse after the first six weeks of development. We make them deliberately against the known constraints — team familiarity, time to first deploy, likely scale requirements in the first 12 months — rather than defaulting to the team's comfort technology regardless of fit.
Weeks four through ten are building and user testing in alternating cycles of two to three weeks each. The MVP is in real users' hands by week five or six at the latest — not a polished product, but a working one that solves the core hypothesis scenario. Feedback from week-five users changes what gets built in weeks seven through ten in ways that no amount of pre-build planning accurately predicts.
Weeks eleven through thirteen shift to go-to-market experiments: a landing page that communicates the value proposition without the founder pitching it, outreach to target user segments with a consistent message, and pricing smoke tests — either a paywall or a waitlist with willingness-to-pay questions — that reveal whether the value proposition converts. GTM experiments at this stage are cheap to run and produce signal that is worth far more than any market research report.
Scope discipline — what the launchpad explicitly excludes
Microservices are excluded. The operational overhead of a distributed system — service discovery, inter-service communication, distributed tracing, independent deployment pipelines — is a significant engineering cost that delivers no user value at startup scale. A well-structured monolith can be split later if scale requires it; a premature microservices architecture cannot be unbuilt cheaply.
Custom authentication is excluded unless the product concept requires it. Auth0, Clerk, or equivalent managed identity services handle the hard parts of authentication — session management, MFA, social login, token rotation — correctly and with less engineering time than a custom implementation. Security vulnerabilities in custom auth are a company-ending event at any stage; they are particularly hard to defend at the MVP stage when the team is at full sprint.
"AI" as a feature without a labelled outcome is excluded. We do not build AI features whose success cannot be defined — "make the product smarter" is not a definition. If the AI feature has a measurable outcome — "reduce time to complete this task by 30%," "surface the right recommendation for 80% of users" — it is a candidate for the MVP scope. If it does not, it is deferred until the core product has enough usage to generate the data required to build it correctly.
Internationalisation, advanced permissions, and analytics dashboards are deferred unless they are the product. These are features that matter enormously at scale and not at all at MVP. Building them in the launchpad window displaces the core hypothesis features that determine whether there is a product worth scaling.
Brand kit in a sprint — what is enough for launch
A launch brand kit has one job: make the product look intentional and professional enough that target users take it seriously. It does not need to be comprehensive, versatile, or future-proof — those are qualities of a mature brand system, not a launch kit. We build what is needed for the first six months and defer the rest.
The launch kit includes: a primary logo in three variants (full colour, reversed, mark-only), a two-colour palette with accessible combinations documented, one display typeface and one body typeface with size scale, and a set of launch-specific templates (website, pitch deck, email header). This is deliverable in one sprint when the positioning direction is clear.
Positioning workshops run during weeks one through three inform the brand direction at the same time as the product direction. The brand brief that comes from those workshops — what the product stands for, who it is for, what visual references resonate — is the input to brand design. Brand design that happens without a positioning brief produces aesthetic work disconnected from the product story.
First GTM experiments — what to test and what to defer
The landing page is the first and most important GTM experiment. A landing page that communicates the value proposition clearly enough for a target user to understand it without the founder present is a hypothesis test: does the message resonate? A high bounce rate tells you the message does not resonate before you have invested in outreach. A high conversion rate on a waitlist tells you the message does.
Outreach experiments in weeks eleven through thirteen are designed to test distribution channels, not to generate revenue. Which channels produce engaged users rather than one-click-bounce traffic? Which message variants convert better with which audience segments? This data shapes the go-to-market investment after the launchpad, when the product is ready for growth rather than learning.
Pricing smoke tests before a payment integration is built save significant engineering time. A waitlist with a "how much would you pay?" question, or a landing page with a pricing section and a "join waitlist" CTA, reveals willingness-to-pay signal that most founders discover much later and at much higher cost. Pricing that users respond to shapes the product features worth building next.
