The spec was 76 pages.
Content. Flows. Edge cases. Every screen the founders could picture, written down in detail. It was beautiful, thoughtful, ambitious work. They had clearly poured weeks into it.
And it landed on one developer's desk.
One dev. One MVP. One reasonable timeline. And 76 pages of "here is what the product is supposed to be."
If you have ever been the person on either side of that handoff, you already know how it usually ends. The dev opens the file. Scrolls for ten minutes. Closes the laptop. The project never really starts. A month later somebody asks why no demo, and the answer is some version of "we are still aligning on scope."
That is not a developer problem. That is a spec problem. More precisely, it is a shape problem. The spec was the right document for the wrong moment.
This post is the long version of what we did about it, on a project called Happier Hours, when we got handed exactly that situation. Three boring decisions, in a specific order, that turned a 76-page document into something a single developer could actually start building this week.
The setup
Happier Hours is a mobile app concept the founders had been developing for a while before they came to us. They had vision. They had a competent technical partner. They had budget for one full-time developer to ship an MVP.
What they handed us was the content and flow specification, plus some early hi-fi screens, plus the goal: help the dev actually ship a working MVP, on a realistic timeline, without losing the soul of the product.
The brief was good. The founders were sharp. The spec covered every screen, every state, every edge case they could think of. Onboarding, preferences, voting on group activities, follow-up flows, retention, the Right Now tiles, navigation, profiles, settings. All of it.
That is not a bug. That is what happens when smart, ambitious people sit down and write everything they know about a product they care about.
The trouble is the document did not know it was going to be built by one person.
Why a 76-page spec stalls a one-dev team
I want to spend a minute on this because I think most founders misdiagnose it.
When an MVP is not moving, founders usually reach for one of three explanations.
"We do not have enough engineering capacity."
"The developer is not moving fast enough."
"We need to do another round of design before we build."
Sometimes one of those is true. More often, none of them are.
The actual problem is that nobody has drawn a hard line between "this week" and "later." The spec treats every section as equally important, because in the founders' heads, they all are. The voting flow matters. The Right Now tiles matter. The advanced post-outing experience matters. The profile system matters. Onboarding matters. Of course they all matter. They all made it into the spec.
But "all of it matters" and "one person is shipping this" cannot both be true at the same time.
Somebody has to decide what gets built this week, what gets built next month, and what is allowed to be a great idea sitting on a shelf for now.
That is not the developer's job. That is the strategy and design job.
If your developer is "moving slow" on an MVP, before you blame the developer, look at the spec they were handed. The spec is probably a wish list with confidence, not a plan with a horizon.
The three decisions, in order
Here is what we actually did, in the order we did it.
Decision 1: Three named batches
We split the roughly sixty to seventy wireframes into three batches. Not "phases" in a vague Gantt-chart way. Three batches the developer could literally pick up and start.
Batch 1: Core onboarding and preferences. The first ten minutes a user spends in the app. The minimum the user needs to do before any other feature is meaningful. This is what the dev starts with.
Batch 2: Voting, follow-up, and retention. The loop that makes the app actually do something. Once batch one is working, this is the next thing the user encounters.
Batch 3: Navigation, profiles, and polish. The connective tissue. The parts that make it feel finished rather than functional.
That ordering is not random. It mirrors how the user experience layers on top of itself, and it mirrors how the dev can ship one piece, see it work, ship the next piece, see that work, and so on.
The naming matters too. "Batch 1, batch 2, batch 3" gives everybody in the room a shared shorthand. The dev can say "I finished batch one" and the founders know what that means. The founders can ask "where is voting" and the dev can answer "batch two, I am ten days in."
You cannot have that conversation about a 76-page spec. You can have it about three batches.
Decision 2: Phase 3, do not wireframe
This is the decision most teams skip, and it is the one that quietly does the most work.
We took several entire systems and labeled them, in writing, as Phase 3, do not wireframe.
The Right Now tiles. The advanced post-outing experience. A few other features the founders genuinely loved.
We did not delete them. We did not pretend they were not in the spec. We labeled them with a sentence that said roughly "this is Phase 3, we are not designing it now, here is why, here is when we will revisit."
The "here is why" part is what keeps a deferred feature from feeling like a stolen feature. Nobody felt like work was being snuck out. The shelf was visible. The shelf was labeled. The shelf had a date on it.
That is the difference between deferring and quietly killing. Deferring is an explicit, time-boxed decision the founders are part of. Quietly killing is the thing teams do when they cannot bring themselves to have the conversation, and it is the thing that erodes trust the fastest.
There is a quiet emotional dynamic here too. Founders who see one of their favorite features marked "Phase 3" on paper will mourn it for about a day, and then move on. Founders who see one of their favorite features quietly disappear from the build will hold a grudge for months. Same outcome on the timeline. Completely different outcome on the relationship.
Always defer in writing. Always defer with a reason. Always defer with a date.
Decision 3: Developer annotations as part of the deliverable
The third move is the one that looks the least like strategy and is actually the most strategic.
The Figma file did not just show what the screens looked like. It told the dev what to do with them.
Every screen had annotations alongside it. Things like:
- What state is this. Empty, populated, error, loading.
- What triggers the next screen. Tap, swipe, automatic.
- What the API needs to return for this view to render.
- What we are explicitly not handling in v1. Edge cases, race conditions, anything we are accepting as known.
- Where the dev should stop and ask a question instead of guessing.
This is the part most teams skip. They hand off Figma files full of beautiful screens and assume the developer will figure out the rest.
The developer will figure out the rest. They will guess. They will guess wrong half the time, because nobody told them what was intentional and what was decorative. Then the team will spend cycles in review either accepting the dev's guess or asking them to redo work, and somebody will get frustrated.
A wireframe with developer annotations is a contract with reality. A wireframe without annotations is a moodboard.
I am borrowing that framing from a designer I worked with years ago and I keep coming back to it. The job of design, when there is a dev on the other end, is not to inspire. It is to be specific enough that the dev does not have to invent.
What this is really about
I want to step back and name the actual move, because the three decisions above are not the point. They are the symptoms.
The point is this. The job of strategy and UX, when there is a single developer on the other end, is not to add ideas to the pile. The job is to make shipping psychologically possible.
That sentence sounds soft. It is the most operationally useful thing I will write all year.
The developer does not need more inspiration. They have plenty. They have 76 pages of inspiration, on their desk, glaring at them.
The developer needs to know what the next five days look like. The developer needs the boundary between "this week" and "later" to be visible enough that they can pick a screen and start.
The founders do not need more scope on the table. They have plenty. They put it there.
The founders need to feel safe that the stuff they deferred is not getting quietly killed. They need the Phase 3 list to be in writing, in the document, with a reason and a date.
A three-batch plan with an explicit Phase 3 list gives both sides what they actually need.
That is what gets the build moving. Not more brainpower. Not a longer spec. Not another design round. A spec with a horizon.
The four questions before you cut a single feature
We use a short checklist when we are about to defer something the founders care about. It exists so we do not cut features for the wrong reasons.
- Does this feature depend on the loop, or does the loop depend on it? If the core voting/follow-up loop can ship without it, it can be Phase 3.
- What does the user experience lose without it on day one? Specifically. Not "the experience suffers." A specific sentence about what the day-one user does not get.
- Is the founder mourning the idea or mourning the timeline? Different conversations. The first one is a feature conversation. The second one is a hiring conversation.
- What is the date on which we will revisit this? If we cannot answer that, we are not deferring. We are killing.
If a feature survives all four questions, it usually belongs in batch one or batch two. If it fails any of them, it belongs in Phase 3 with a date.
What to do this week, if you are sitting on a fat spec
If you are looking at a spec that is fatter than the team that has to ship it, try this.
Open the doc. Highlight one third of it in one color. That is batch one. That is what the team is doing this month.
Highlight another third in a second color. That is batch two. That is what the team is doing next month.
The last third gets labeled "Phase 3, deferred." Write the sentence. Write the date you will revisit it. Send it to the founders before they have a chance to mourn the parts that moved.
Then go to your design file and ask one question on every screen. "What does the dev do with this on Monday morning?" If the screen does not answer that, the screen is not done yet.
Three batches. Phase 3 in writing. Annotations as part of the file.
That is the whole move. None of it is clever. All of it is uncomfortable, because somebody has to make the call about what does not get built first, and that decision is the one most teams flinch on.
Where this connects
If you want the related reads, two recent ones pair with this directly.
On treating dates as tools rather than commandments, and on how to renegotiate a deadline cleanly: "The bravest thing you can do under a deadline? Move it."
On how a marketing problem usually turns out to be a pipeline problem in disguise: "Your marketing problem is a pipeline problem."
The connective tissue across all three is the same idea. Most of the time the project is not stuck because of capacity. It is stuck because somebody has not made an uncomfortable decision out loud. Moving the date, naming the pipeline gap, drawing the line between "this week" and "Phase 3." Same skill, three different surfaces.
A note for service-firm leaders
If you run a strategy, design, or product firm, this is the move I keep telling my team to lean into.
We get paid to add value. The instinct is to add value by adding ideas. More screens. More flows. More research. More options. That is the easy version of the work.
The harder, more valuable version is to be the team that draws the line. The team that says "here is batch one, here is Phase 3, here is the date we revisit." The team that hands the developer a file they can pick up and start.
That is the work clients remember. Not the seventy-fifth wireframe. The Phase 3 list with a date on it.
If your firm is competing on volume of output, you are in a race you do not want to win. If your firm is competing on shipping discipline, you are in a much smaller, much better field.
The reflection
I will close with the question I have been asking founders and product leaders this month.
If your spec landed on a solo developer's desk tomorrow morning, would it feel like a runway or a brick wall?
Be honest. The answer is almost always "somewhere in between, but closer to brick wall than I want to admit."
That is fine. That is normal. The fix is not more spec. The fix is three batches, a Phase 3 list, and annotations on the file.
That is the move. Go make it this week.
Want the batching worksheet we use with clients to turn fat specs into three-batch shippable plans? Reply to the email or comment "MVP" on the LinkedIn version of this post and I will send it over.
Chykalophia helps founders and product teams get unstuck on exactly this kind of problem: a vision that is bigger than the team that has to ship it. If that sounds like you, let's talk.