You Don't Have a 2.0 Platform Proposal. You Have a Preference.

You know the moment.

You're twelve slides deep into the Platform 2.0 pitch you spent three weekends on. The architecture diagram is beautiful. The shading alone took an hour. And someone senior leans back and asks:

"So what's the actual problem we can't solve on 1.0?"

And you say something. About technical debt. About the codebase being hard to work on. About how the new orchestrator would be "so much cleaner."

And the room does the thing where nobody writes anything down.

I've sat in that silence on both sides of the table. I've been the pitcher whose face went hot. I've also been the senior person asking the question, half-bored, already knowing the answer wouldn't have a single number in it.

What I learned, the expensive way, is that most rejected rewrite pitches aren't wrong about the architecture. They're wrong about the sell. You had a real ceiling. Real friction. And you presented it as a mood instead of a case. So the org said no, it felt personal, and maybe you started interviewing.

That outcome is waste. Good ideas dying of bad packaging might be the most fixable problem in an engineering org.

So this piece has two halves. The first is for the engineer who has to stand up and make the case. The second is for the leader who has to judge it. Both halves run on the same principle: you are a founder pitching a Series A, and engineering hours are the capital. Founders know something internal engineers forget. Investors do fund. Rigorous asks get money all the time. The standard isn't the obstacle. It's the door.

Part 1: For the Engineer

Work the phases top to bottom. If you can't check a box, that's not failure. That's your work plan before you pitch.

Why Your Pitch Dies Before the Second Slide

Three failure modes kill almost every rewrite proposal, and all three are about framing, not engineering.

Tech-first, problem-second. The pitch opens with the runtime, the paradigm, the architecture you read about last week. To the person holding the budget, that reads as resume-first. They care what breaks on Monday if you don't build it.

Vague misery instead of measured pain. "1.0 is legacy." "It's ugly." "It's hard to work on." Every one of those is a feeling wearing technical vocabulary. Feelings are unfalsifiable, which is why they survive in a proposal for months. They're also why nobody signs the check.

Boredom dressed as architecture. This is the one nobody says out loud. Maintaining a stable system is penance. It's the flaky test, the migration script that fails on one team's weird data, the ninth small improvement to the CI queue. Nobody writes a blog post about the ninth small improvement. A rewrite is a green field, and green fields feel like the job you signed up for. Both feelings are legitimate. Only one is a fundable reason.

If you catch yourself in the third one, the honest move is a career conversation, not an architecture proposal.

Phase 0: Before You Write Anything Down

• [ ] Catch yourself first. Am I proposing this because 1.0 has a ceiling, or because maintaining it is boring? Answer honestly, because your audience will figure it out in the first five minutes.
• [ ] Solution or problem? If your pitch opens with the new runtime, flip it. What can't your users do today?
• [ ] Name your customers. Not "the org." Actual teams. Actual workflows. Actual people who open 1.0 every morning. You'll need them for evidence, and later, for quotes.

Be honest with me here. Of the rewrite pitches you've been part of, what fraction were at least 30% boredom? I'll go first. Mine was well past 50%.

Phase 1: Build the Evidence (the part everyone skips)

This phase is the difference between funded and dead. It's also the phase nobody wants to do: a quarter of unglamorous work with no diagram at the end.

• [ ] Put a number on the pain you're claiming. P95 build times. CI queue wait. Flaky test rate. Ticket volume. Time to first commit for a new joiner. "The build is slow" is a feeling. "P95 is 22 minutes and 1,000 engineers run it on every PR" is a funding conversation.
• [ ] Freeze your baseline in writing. The moment you start fixing things, "before" evaporates. Future-you will need it and past-you won't have it.
• [ ] Talk to 5+ actual users of 1.0. Are they complaining about what you think is broken? This one stings. Half the time, the thing that makes maintenance miserable for you is invisible to them, and the thing keeping them up at night isn't on your slide at all.
• [ ] Attempt the incremental fix. For real. Pick the two or three worst offenders and genuinely try to remediate them inside 1.0. Budget a quarter. This is not a stall tactic. It's armor.
• [ ] Record exactly where remediation hit the wall. "We tried X. It moved the metric from 22 to 19 minutes. It can't go lower because of Y baked into 1.0's foundation." That last clause is the most valuable sentence in your entire pitch. It's the difference between "I dislike this code" and "I have measured the shape of the ceiling."
• [ ] If you didn't hit a wall, stop. Genuinely congratulate yourself. You just improved 1.0 cheaply, saved the org two years, and learned the ceiling was made of comfort, not architecture. The playbook worked. Take the win.

Have you ever run this remediation experiment and had it succeed? What did you do next, celebrate or keep pushing for the rewrite anyway? No judgment. I've done both.

Phase 2: Write the Brief (2 pages, hard cap)

Two pages. Not twenty.

The constraint is the feature. If the case is real, two pages is plenty. If it's not, twenty won't save it.

• [ ] Page 1, the case against 1.0. Quantified bottlenecks. Attempted remediation, with the numbers. The ceiling named precisely. "The per-tenant permission model in 1.0's core structurally cannot express our new org's access needs" is a ceiling. "The code is messy" is a mood. Funders can engage with a ceiling. A mood just leaves them guessing at your motives.
• [ ] Page 1, why now. What breaks or degrades over the next 12 to 18 months if nothing changes? What is the org unable to ship while trapped in 1.0's paradigm? Opportunity cost is the line item leaders respond to. They think in trade-offs by default.
• [ ] Page 2, three to five non-negotiable tenets. The rules you won't trade away under schedule pressure. "Sub-minute local feedback loop." "Zero custom abstractions where a standard exists."
• [ ] Page 2, what 2.0 explicitly is not. An out-of-scope list. Scope creep doesn't start big. It starts with one reasonable-sounding "while we're in here anyway."
• [ ] Page 2, target metrics with numbers. "PR build: 22 min to 4 min." Not "improve developer experience." Unfalsifiable goals are how projects drift for two years without anyone being able to say they missed.
• [ ] Page 2, the migration plan. How does 1.0 traffic move over while product work continues? If the answer is "we'll figure it out later," stop. Later is where rewrites go to die. Look up the strangler fig pattern. If you can't name your version of it, you're not ready to pitch.
• [ ] Page 2, the sunset plan for 1.0. What has to be true, by roughly when, for 1.0 to be turned off? Two platforms running in parallel indefinitely is a permanent tax with a friendly name.
• [ ] Page 2, the kill switch. What condition, checked at a named milestone, ends 2.0 if it's not tracking? This is the most trust-building paragraph you can write. You're pre-committing to your own accountability. Almost nobody does it. You'll be the exception in the room.

If you cut your current (or hypothetical) pitch to two pages tomorrow, what's the first thing you'd cut, and what would you discover was load-bearing?

Phase 3: Pre-flight Before You Present

• [ ] Survive the ambush question. "What did we measure on 1.0, what did we try, and where did remediation hit a wall?" Cold, from memory, in the first 30 seconds of Q&A. If you need to open your laptop for that, you didn't do Phase 1.
• [ ] Strike every unfalsifiable sentence. "Legacy." "Modern." "Best practice." "Clean." Each gets replaced with a number or a named constraint. One exception: the new runtime may appear as a consequence of the brief, never as a reason for it.
• [ ] Pass the stranger test. A peer engineer two teams over, not your manager's boss, follows the whole brief without knowing your codebase. If it only convinces people who already agree with you, you wrote a loyalty check, not a case.
• [ ] Make a small ask. A pilot with one named team and a timebox, not a two-year commitment. Funders fund experiments that have exits. The kill switch is what makes the small ask credible instead of naive.

The kill switch sounds like career suicide. "Here's the condition under which you should shut down my project." Have you ever written one? Did anyone hold you to it? And be honest: would you trust a pitch more if it included one?

Phase 4: After the Meeting

• [ ] If funded, never go dark. Every 2.0 milestone ships something a 1.0 user can feel. Pilot teams quietly routing around you in month three is the failure signal nobody puts on a dashboard.
• [ ] If funded, defend the sunset date with your life. 2.0 will run late. It always runs late. The first time it does, the sunset date slips and never comes back. Two platforms forever was the exact failure your brief existed to prevent.
• [ ] If rejected, get the specific box you couldn't check. Not a vibe. A box. "Come back with remediation numbers" is a yes with extra steps. Go run Phase 1. "This is a staffing conversation" means they saw the boredom you didn't, and now you both know.

Part 2: For the Leader

Now the mirror. If you're the staff engineer, the EM, the director who receives these pitches, most of your job is spotting which proposals are real in the first ten minutes. Here's what separates them, and how to run the conversation so you don't destroy the person who brought you a good idea.

What to Look For

• A measured baseline. If they can't tell you what 1.0 costs today in numbers, they haven't done the work. Build times, MTTR, onboarding days, ticket volume. Any of them, measured.
• Evidence of attempted remediation. This is the single strongest signal. Someone who tried to fix 1.0, failed, and can show you where the wall was has already saved you from funding a rewrite you didn't need. That person is your ally.
• A named ceiling. Not "it's messy," but "the per-tenant model in the core structurally cannot do X." A ceiling is a specific architectural constraint that no amount of incremental work removes. If they can name it, they've thought past their own preferences.
• A migration plan with a shape. How does traffic move while product ships? The strangler fig, a shadow read, a dual-write with a cutover. If the answer is "later," there is no plan.
• A kill switch. The proposal should say what would make them walk away. A team willing to name its own failure condition is a team you can trust with a pilot.
• A small, timeboxed ask. A pilot with one named team and a date, not an open-ended multi-year commitment. Experiments have exits. Programs don't.
• Boredom admitted, at least to themselves. The best senior engineers will tell you, if you ask directly, how much of this is the work getting stale.

What Not to Look For

• Framework and runtime names as justification. Those are consequences of a decision, never reasons for one.
• The word "legacy," "modern," or "best practice" carrying the argument. Each one is a substitute for a number. Count them. If they're load-bearing, the pitch is hollow.
• A twenty-page design document. Length is camouflage. The case that survives a hard two-page limit is the case that survives a budget review.
• A two-year, open-ended commitment. No exit, no funding. You're being asked to hand over headcount with no kill criteria, and that's the deal you should decline.
• A pitch that only convinces people who already agree. Test it on someone outside the group. If it only lands with insiders, that's not a case. That's a compliment.
• Ego dressed as urgency. "We have to do this now" without a reason why now is a negotiating tactic, not an argument.

The Three Questions That Do All the Work

You don't need a scoring rubric. You need three questions, asked in order, and the discipline to listen to the answers.

1. What did we measure on 1.0? Numbers, not adjectives. If they can't answer, the rest is moot.
2. What did we try, and where did it hit a wall? This one separates the engineer who did the work from the engineer who skipped to the fun part.
3. What would make you walk away? A team that can name its own kill condition is a team you can trust with real money. A team that can't is asking for an open tab.

A real proposal answers all three without flinching. A preference folds on the first one. And notice it's the same ambush question from Part 1, turned around. What did we measure, what did we try, where did remediation hit a wall. Ten seconds, and you know which pile you're holding.

How to Say No Without Losing the Engineer

The no is where most leaders destroy value. A flat no reads as distrust, and your best principal engineer hears "your judgment isn't welcome here." That's how you lose them, not to a competitor, but to apathy.

So make the no specific. "Come back with remediation numbers" is a no with a door in it. "Show me the ceiling named precisely and I'll fund a pilot" is another. Name the exact thing that would change your mind, in writing, and mean it. You are rejecting a proposal, not a person. The goal is that they leave the room annoyed at the standard, not at you.

The worst outcome isn't a rejected rewrite. It's a rejected rewrite that costs you the engineer, because the next pitch they make is a resignation letter.

How to Say Yes Without Losing the Platform

Approving is not the finish line. It's the start of the part that actually goes wrong.

A yes should carry conditions, and they should be the same conditions you'd want as an investor: a named owner, a timebox, a pilot team, a sunset date for 1.0, and a kill switch you intend to honor. Put the sunset date in the same document as the funding, or it doesn't exist. Every rewrite I've watched turn into two permanently staffed platforms got there because the yes had no exit clause.

You are not handing over belief. You are handing over capital with terms. Leaders who say yes with terms get a working 2.0 or an early, cheap lesson. Leaders who say yes without them get a decade of maintenance.

The Honest Caveats

This playbook can't replace judgment, on either side of the table.

Sometimes the ceiling is obvious on day one, and "exhaust remediation first" burns a quarter proving what everybody already knew. That quarter is the price of being legible to people who aren't you. Worth paying? Usually. Not always.

And the brief buys you a hearing, not a pass. A rigorous no on a real proposal is a good outcome. You learned cheap. The thing that kills careers and platforms is the slow, unexamined yes.

The people cost is real too. Asking a principal engineer for a business case can land as "we don't trust you," and once it lands that way you're not having an architecture conversation anymore, you're having a retention one. I've had that go well and go badly, and the difference was never the rigor of the framework. It was whether the engineer believed I wanted their idea to succeed.

The One-Line Version

If you can't fill two pages with measured pain, attempted fixes, a named ceiling, a migration plan, and a kill switch, you don't have a 2.0 platform proposal. You have a preference.

Over to You

The questions are scattered through this thing. Pick whichever one stings and tell me where I'm wrong:

1. Boredom audit: what fraction of the rewrite pitches you've lived through were at least 30% boredom?
2. The remediation experiment: ever run it and had it succeed? What did you do next?
3. The two-page cut: what's the first thing you'd cut from your pitch, and what would turn out to be load-bearing?
4. The kill switch: would you trust a proposal more if it pre-committed to its own shutdown condition?
5. Rejections: which no was right, the one that saved you or the vibes-no that let the platform rot?
6. Leaders: what's the best rewrite pitch you've ever rejected, and did you later regret it?

My hot take: the kill switch is the most underrated paragraph in the entire brief, and I have seen exactly one pitch besides my own ever include it. Change my mind, or show me yours.