How we ship products in twelve weeks instead of twelve months

This is not a brag. It is the only honest way to build a startup product, and most teams have forgotten how to do it.

Here is the method, in the order we did it.

Week one: the framework, not the features

Most teams start with a feature list. We started with a framework — the conceptual spine that every later decision would hang from.

For Instinct, that was the six-instinct model. A claim about how dogs work: every dog has a weighted mix of six core instincts (Scent, Chase, Herd, Retrieve, Dig, Solve), and a good enrichment app is one that profiles the mix and serves work calibrated to it.

This took about a week of thinking, reading, arguing, and writing. No Figma. No code. No user interviews. Just senior people working out the underlying model.

This is the highest-leverage week of the entire build. Everything that comes later — the onboarding flow, the activity library, the recommendation logic, the marketing copy, the AI prompts — flows from the framework. Get the framework wrong and you spend twelve weeks building on a faulty foundation. Get it right and every subsequent decision has a clear answer.

Most product teams skip this step. They go straight from “here’s the idea” to “here’s the wireframe,” which means every wireframe meeting becomes a debate about first principles that should have been settled in week one. By month four, the team is still relitigating the same conceptual questions.

A week of framework work saves a quarter of build time. Always.

Week two: brand and information architecture, in parallel

By week two, we had the framework. Now we needed two things, and they had to happen at the same time: a brand, and the IA of the product.

The brand decisions were small but consequential. Position Instinct as a performance app for dogs, not a cutesy pet-tech product. Visual references: Strava, Whoop, Nike Training Club. Dark mode. Bold display type. Real photography of working dogs doing work. We made these decisions in about three days. The wordmark took an afternoon.

In parallel, the IA work was about turning the six-instinct framework into a navigable product. What does the home screen show? How does the user understand their dog’s profile? Where does an activity live? How does progress get represented? We sketched this on paper, then in low-fidelity Figma, then pressure-tested it internally before showing it to a single user.

Doing brand and IA in parallel is non-obvious but right. They constrain each other in useful ways. The brand says “this is a serious performance app” — that constrains the IA to look like Strava, not BarkBox. The IA says “the user needs to see their dog’s instinct profile and today’s activity above the fold” — that constrains the brand to a dense, structured layout, not a sparse marketing one. Each discipline shapes the other from day one.

If you do brand first and then IA, you end up redoing the brand. If you do IA first and then brand, you end up redoing the IA. Doing them in parallel sounds risky and is actually faster.

Weeks three to four: prototype, then test

By week three, we had a clickable prototype in Figma. Not a full design system. Not every screen. The five or six screens that defined the product: onboarding, the daily drive, an activity, the profile, the progress view.

Week four, we tested it. With real dog owners, on real phones, watching them try to use it. We caught about a dozen issues — some minor (button labels, icon choices), some structural (the way the daily drive related to the profile was confusing). We fixed the structural ones immediately and noted the minor ones for later.

The thing most teams get wrong about prototype testing is they wait too long to do it. They want the prototype to be “ready” first. By the time it is ready, it is too late to change it cheaply. Test the rough version. Take the embarrassment. The information you get back is worth ten times what the polished prototype would have produced a month later.

We tested again at week eight, and again at week eleven. Three rounds of testing in twelve weeks, each round shorter than the last as the issues got smaller. The final round was a formal validation study with ten participants, the kind of thing investors like to see, but the real testing had been the rough rounds in weeks four and eight.

Weeks five to ten: build, with content as a parallel track

This is the long stretch. Six weeks of build. React Native, Expo, TypeScript, Supabase, the standard modern stack. Nothing exotic. The choice of stack matters less than people think; what matters is that you’ve used it before and you can move fast in it.

Two things made the build fast.

First, scope discipline. We had a list of roughly forty features that could exist in the app. We shipped twelve. The other twenty-eight were either deferred to a v2 list or killed entirely. Every fortnight, we reviewed the list and cut another two or three things. The MVP shipped with: onboarding, a daily drive, an activity execution flow with a timer, completion with rating and notes, an explore tab, a progress view, and a profile. That’s it. No social features. No community. No video library. No marketplace. No gamification beyond a simple streak counter.

Second, content as a parallel track. While the build was happening, we were also writing the activity library. 144 activities, three tiers, six instincts. Every activity to a strict template: title, hook, equipment, three-step instructions, walk-equivalent rating, “Why this works” note. We wrote a 63-item equipment glossary. We did this in parallel with the build, not after it, because content is the thing that takes longest to do well and is the most commonly underestimated.

If we had treated content as a post-build task, we would have shipped a beautiful empty app. Content has to be in the critical path from week one.

Week eleven: AI integration, done last and lightly

We integrated the Claude API in week eleven, near the end of the build. This was deliberate.

The AI integration on Instinct does one thing: it generates a personalised “Why this works” panel for each activity, using a structured prompt that takes the user’s specific dog (breed, instinct profile, behaviour signals) and the activity context. It is useful, it is differentiated, and it is small. It is not a chatbot. It is not a generative coach. It is one feature that uses the API.

Most teams get AI integration wrong by making it the centre of the product. We did the opposite. We built the product, and then added a single AI feature where it earned its keep. Cost-controlled with caching, with a graceful fallback if the API is unavailable. About four days of work, total.

The lesson is general. AI is most useful as a feature inside a well-designed product, not as the product itself. Treat it as one tool in the toolkit, not the reason for the toolkit.

Week twelve: launch, and the launch debt

Week twelve was the App Store submission, the marketing site going live, and the hundred small things that come up in the last week of any project. Privacy policy. Terms. App Store metadata. Screenshots. Compliance review. The things you forget about until you have to ship.

We shipped with what we called “launch debt” — a list of about thirty issues we knew about and had decided to live with. Not bugs. Things we’d do differently if we had another month. The decision to ship with launch debt is one of the most important and least-discussed parts of moving fast. The alternative is to keep polishing forever, which means never shipping. Launch debt is the cost of being in market.

You pay it down in the weeks after launch. Some of it you never pay down because users don’t care about it.

The principles, made explicit

If you wanted to compress the method into principles, they would be these.

Frame before you build. A week of conceptual work saves a quarter of build time. The framework is not optional. It is the most leveraged thing you do.

Run disciplines in parallel, not in sequence. Brand and IA together. Build and content together. Most agencies sequence these because it makes invoicing simpler. Sequencing makes building slower.

Test the rough version, not the polished one. Three rounds of cheap testing in twelve weeks beats one round of expensive testing at the end.

Cut features ruthlessly, every fortnight. The shipped MVP should have a third of the features the team thought it needed. The other two thirds were the team avoiding decisions.

Treat content as critical path. Content takes longer than you think and matters more than you think. It cannot be a post-build task.

Add AI lightly. One small AI feature done well is worth ten ambitious ones half-built.

Ship with launch debt. The decision to ship is the decision to live with imperfection. There is no version of fast that doesn’t include this.

The point

There is nothing in the twelve-week method that requires unusual talent or special tools. It requires the willingness to commit, the discipline to cut, and the experience to know which corners can be cut without breaking the product.

It is not the only way to build. It is the way that respects a founder’s runway, their sanity, and their need to be in market before they run out of money. For an early-stage company, that is most of what matters.

The question is not whether you can build a product in twelve weeks. The question is whether you can resist the industrial pressure to take twelve months instead.