I’ve stopped clapping for those saves. A rescue in the last stretch isn’t really a win. It’s the receipt for a risk the system should have caught a quarter earlier, when there was still time to handle it quietly and without drama.

That’s the uncomfortable part of renewal forecasting. By the time an account lands on a forecast call tagged “commit,” “likely,” or “at-risk,” most of the outcome is already set. The work that determines whether a renewal occurs takes place in the months before anyone opens the spreadsheet. So the forecast doesn’t really predict the renewal. It reports on it a little early and calls that a prediction.

I wrote a while back about why health scores mislead, how they lean on lagging signals that describe what already happened rather than what’s coming. Renewal forecasts have the same flaw, just further down the timeline. They’re the last and most expensive lagging indicator you’ll stare at before the number either lands or it doesn’t.

A quick note on who “you” are here. I’ll keep saying CSM, but read it as “whoever owns the account.” The CSM and AM titles are merging into a single role that manages both the relationship and the number, and once this happens, renewal risk will rest squarely on that person’s desk.

The framework: Continuous Renewal Underwriting (CRU)

The solution isn’t a better forecast. It’s a different job. Stop forecasting renewals and start underwriting them.

An insurer doesn’t gather in a room at year-end to guess whether a policy will pay out. They price the risk continuously and work to bring it down where they can. A renewal is that kind of object. It’s a position you manage every week, not a coin you flip at the buzzer.

CRU has four parts.

1. Underwrite, don’t forecast. A forecast guesses at an outcome you’ve quietly decided to treat as fixed. Underwriting assumes you can still move it. The shift is from reporting a renewal to working one. Every account holds a live risk position, and the goal is to drive that position toward certainty before the date arrives.

2. Name the five risks, then retire them. “At-risk” is a useless label because it never says why. In practice every renewal carries a small, nameable set of risks: whether the customer has realized the value they bought, how deeply your product is wired into their stack, whether your champion is still in seat and still influential, whether a competitor or an in-house build has entered the picture, and whether something commercial is going to get in the way (budget timing, procurement, a pricing change, an old support scar). Each of those is either open or handled. The operating model is a steady campaign to close them out ahead of the date.

3. Score the risk and your confidence separately. Give every account two numbers instead of one. First, a risk level: high, medium, or low. Second, a confidence score from 1 to 10 for how sure you are of that read. Keeping them apart is the whole point. “Medium risk, and I’m highly confident” and “I think this is high risk, but honestly I’m not sure” are very different situations, and a single commit-or-at-risk tag flattens them into the same box. The low-confidence accounts are where the work is. A shaky read is your cue to go pull the evidence (adoption, integration depth, the cadence of champion engagement) until a number you can stand behind shows up. And “they love us” still doesn’t count as evidence: warm accounts churn quietly every quarter when the relationship was real but the product was never load-bearing.

4. The runway starts at onboarding. Renewal risk is lowest when a customer reaches a working, embedded deployment fast. That’s the time-to-architecture idea from an earlier post, viewed from the far end. Every dependency you help a customer build early is risk you won’t have to fight later. By renewal time, a well-onboarded account re-signs about as deliberately as it pays the electricity bill.

Plot those two scores against each other and you get a simple picture of where to spend the week.

The first 120 days do most of the deciding

Most of a renewal is settled in the first 120 days. That window is where a customer forms their real opinion of whether this was a good decision, and that opinion tends to stick.

Year one is more forgiving than people expect. Enterprise software is messy, and almost nobody gets a clean first year: there are product gaps, a rough integration, a support miss or two. None of that is fatal on its own. If you’ve been visibly in the trenches with the customer, working the problems and showing progress, you can usually earn the first renewal even after a bumpy year. Effort buys you grace.

Year two is where the bill comes due. The grace is spent, and the thing that carries the renewal now is whether the customer actually reached value. If they’re still a long way from it heading into year two, the renewal is most likely already lost, whatever the forecast claims in the quarter it falls due. At that point you’re just waiting for the date to confirm what the first 120 days already decided.

One number worth watching: Time-to-Certainty

Forecast accuracy is the wrong headline metric. A more honest one is time-to-certainty: how far ahead of the contract date your confidence on an account climbs into the high end of that 1-to-10 scale and stays there.

Good teams reach that point a full quarter out. If you’re still uncovering real risk inside the renewal quarter itself, your time-to-certainty is effectively negative, and the confidence in the room is theater no matter how loud it gets.

Two ways the forecast lies

The hope forecast. Confidence built on rapport instead of evidence. The QBRs are friendly and the champion takes the call, so the account goes down as commit. Then it lapses and everyone claims to be surprised. Rapport feeds retention, but it doesn’t prove it. A call you can’t tie to a signal is a wish wearing a label.

The eleventh-hour scramble. Risk that only surfaces inside the renewal quarter, once there’s no runway left to do anything but react. This is what breeds the heroic-save culture in the first place. A champion’s departure flagged at 150 days out is a manageable problem. The same departure flagged at 20 days out is a fire drill.

Both come from the same habit: measuring the renewal instead of underwriting it.

The prompts

Three tools to put CRU to work. One sizes up a single account, one audits the whole forecast, and one runs the portfolio on a schedule.

Prompt 1: Renewal Risk Underwriter

You are a Customer Success renewal underwriter. Given the account data below,
produce a renewal risk position — not a gut forecast.

Account data:
- Account name / segment: {name, segment}
- Contract value (ARR): {value}
- Renewal date: {date} (today is {today})
- Value realization: {has the customer hit their stated success criteria? evidence?}
- Architecture depth: {integrations, API usage diversity, workflow dependencies}
- Champion: {role, tenure in seat, recent engagement, any role changes}
- Competitive/build signals: {any competitor or in-house alternative mentioned}
- Commercial context: {budget cycle, procurement notes, pricing changes, past friction}
- Usage trend (90 days): {increasing / flat / declining}

Produce:
1. A risk rating (Open / Retired) for each of the five factors: value realization,
   architecture depth, champion stability, competitive exposure, commercial friction.
2. Two separate scores: a risk level (High / Medium / Low) and a confidence score
   (1-10) for how sure you are of that read. State the specific signal behind each.
   Don't award high confidence to an account whose evidence is thin.
3. Time-to-Certainty: based on the data, how many days before the date can we
   credibly reach certainty? Are we on track?
4. A prioritized runway plan: the top 3 actions to retire the highest open risks first,
   sequenced against the renewal date.

Prompt 2: Forecast Auditor

I'm going to share our current renewal forecast. Stress-test it for the two failure
modes below, the way a skeptical CRO or board member would.

Failure modes to flag:
- The hope forecast: a "commit" or "likely" rating justified by relationship warmth
  rather than usage, adoption, integration, or champion evidence.
- The eleventh-hour scramble: any account whose risk was discovered inside the renewal
  quarter, where there is no longer enough runway to retire it.

Current forecast:
{paste forecast — account, ARR, current rating, renewal date, and the stated reason
for the rating}

For each account:
1. Is the rating evidence-backed or hope-based? Name the missing evidence if hope-based.
2. How much runway remains (days to date), and is it enough to retire any open risk?
3. Assign a risk level (High / Medium / Low) and a confidence score (1-10), and flag
   any high-confidence rating the evidence doesn't support.

Then summarize: total ARR sitting on hope, total ARR you're low-confidence on, total ARR
with no runway left, and the three accounts most likely to become a "surprise" churn.

Agent workflow: Renewal Runway Monitor

You are an AI agent monitoring a portfolio of upcoming renewals. Run weekly. For every
account with a renewal date in the next 180 days, track risk retirement against the clock.

Portfolio data:
{structured account data: name, ARR, renewal date, the five risk factors with current
status, usage trend, last champion contact, support themes}

Checkpoints: 180 / 120 / 90 / 60 days out.

For each account, evaluate:
1. Risk-retirement velocity: are open risks closing fast enough, and is confidence on the
   account climbing toward a level you'd stake the forecast on, by 90 days out? Compare
   this week's status to last week's.
2. Flag any account where an open risk is not being retired at a pace that fits its
   remaining runway. Mark urgency: routine / elevated / critical.
3. For critical flags, recommend the single highest-leverage action to retire the
   blocking risk this week, and whether the CSM should act directly or equip the champion.

Output a one-page briefing: accounts on track, accounts slipping, and the week's must-do
runway actions ranked by ARR-at-risk.

Your turn

Two questions I’m genuinely curious about. What’s the earliest signal that has reliably predicted a churn for you? And what’s the warmest account you’ve ever lost? The renewals nobody saw coming usually hold the best lessons.

And if you’ve built a renewal-risk prompt or workflow that’s working well, send it over. I keep a running collection of what’s actually working from people doing this in technical accounts, and the good ones get shared.

New here? The earlier posts on health scores and on onboarding technical buyers set up a lot of what’s above.

By the time that chapter ended, I was pretty sure we’d built the wrong thing.

The pattern was the same every quarter. The model would forecast more accounts. We’d staff CSMs ahead of them. We’d promote managers to handle the new CSMs. Someone would call a meeting about span of control. Every conversation about “scaling CS” ended at the same place: hire.

What we built was a service organization with “Customer Success” written on the org chart.

Most CS orgs scale this way. It’s the default, and the math gets ugly fast. At $150K fully loaded per CSM, every 50 new accounts is another headcount you have to fund. There’s no point at which the operation gets cheaper, only points at which it gets less obviously broken. Eventually finance does the unit economics, and CS becomes the line item that gets a “growth pause.”

The “revenue era of CS” crowd wants to make this worse. Their fix is to turn CSMs into quota-carrying sellers and let expansion revenue cover the cost of the team. I’ve watched that movie. I know how it ends. Trust erodes, champions stop being candid with you, and your NRR flattens within four quarters.

There’s a different play, and the best CS orgs are already running it.

They aren’t hiring faster. They’ve quietly rebuilt the underlying operation so that one CSM does the work that used to take three. Not by working harder. By moving most of the work somewhere else.

I've written about the operational pieces individually: health scores, QBRs, onboarding, and expansion. This post is the architecture that holds them all together.

The Framework: The CS Operating System

Four layers. Each one absorbs work from the layer above. The job of every CS leader is to push every interaction down the stack to the lowest layer that can still handle it well.

Layer 1: Self-Service Infrastructure

Documentation, in-app guidance, quickstart templates, automated onboarding flows, community forums.

In a well-designed CS operation, this layer handles 60 to 70 percent of customer needs without anyone on your team getting involved. Technical buyers prefer it that way. Engineers don’t want to file a support ticket. They want to find the answer at 2am and keep building.

If your CSMs are answering the same five questions in Slack every week, the problem isn’t your customers. It’s that your docs aren’t where your customers expect to find them.

Layer 2: Automated Signal and Response

Event-driven workflows that detect state changes and trigger the right action.

A customer’s deployment velocity drops for two weeks running. Your system flags the state transition, pushes an in-app message with the right resource, and adds the account to a CSM review queue. The CSM only sees the account once a real human decision is required.

This is where the state-based model from the first post stops being a reporting tool and starts running things. The state transitions are the events. The events fire the workflows. CSMs stop spending Mondays manually scanning a portfolio for things that have changed since Friday.

Layer 3: AI-Augmented CSM

Agents that handle research, prep, drafting, and analysis.

A CSM should walk into Monday with a briefing already in their inbox: priority accounts for the week, prep notes for every scheduled meeting, accounts that haven’t been touched in a while, product releases mapped to specific customers in their portfolio. They shouldn’t be spending the first three hours of the week gathering context they’ll only use once.

Good AI augmentation doesn’t try to replace what the CSM is best at. It clears out the work that gets in the way of doing it.

Layer 4: Human-Led Strategic

The 20 percent of interactions that drive 80 percent of the outcome.

Executive alignment. Expansion strategy. Real renewal negotiations. Champion development. Architecture reviews where you’re being asked to commit to a customer’s direction. Complex technical problem-solving that no agent is going to handle credibly anytime soon.

This is what CSMs should actually be spending their week on. Everything else belongs in a layer below it.

Two Ways CS Leaders Get This Wrong

Failure Mode 1: Headcount Theater

You scale CS by adding bodies. The KPI on the leadership dashboard is “headcount per X accounts” rather than “outcomes per CSM.” Every operational gap becomes a hiring requisition. The org chart fills out faster than the retention numbers move, and by the time someone in finance models the cost per retained dollar, you’ve already overhired by twenty percent.

Failure Mode 2: AI Sprawl

The opposite trap, and the one I see more often now. Teams scatter prompts and automations across the org with no architecture behind any of it. Five CSMs are running five different ChatGPT prompts. Two managers built competing dashboards. Nobody actually knows what’s automated, what’s manual, and what was supposed to be automated but broke six weeks ago.

The leadership view is “CS is using AI.” The operational reality is that CSMs are doing more work than before, just with more tabs open.

The Layer Cake fixes both. It tells you what belongs where, and it tells you what work to push down next.

The Prompt Library

Prompt 1: CS Coverage Model Analyzer

Analyze our current CS team structure and identify opportunities to shift
work from human-led to systemized layers.

Current state:
- Number of CSMs: {N}
- Average book of business per CSM: {accounts}
- Current CSM time allocation (estimate %):
  - Onboarding: {%}
  - Recurring check-ins: {%}
  - Renewal management: {%}
  - Escalation handling: {%}
  - Strategic/expansion conversations: {%}
  - Internal coordination: {%}
  - Admin/data entry: {%}

For each activity, recommend:
1. Which layer it belongs in (Self-Service, Automated, AI-Augmented,
   Human-Led Strategic)
2. What it would take to move it down one layer
3. Estimated time savings per CSM per week
4. Implementation complexity (low/medium/high)

Calculate the projected effective book of business per CSM after
systemization, and flag the top 3 highest-ROI moves.

Prompt 2: Automation Opportunity Scorer

Review the following list of recurring CS tasks and score each for
automation potential.

Tasks:
{list of tasks}

For each task, evaluate:
- Frequency (how often does this happen?)
- Consistency (is the process the same each time?)
- Judgment required (does this need human intuition?)
- Data availability (do we have the inputs needed to automate?)
- Customer impact if automated poorly (what's the blast radius?)

Score each 1-5 on automation readiness. Recommend the top 5 to automate
first, ranked by highest time savings with lowest risk. For each
recommendation, specify which Layer Cake layer it should move to and
what infrastructure is required.

Agent Workflow: Weekly CSM Briefing Generator

You are an AI agent supporting a CSM. Every Monday morning, generate a
briefing for the week ahead.

Inputs:
- Account portfolio data: {structured data}
- Calendar for the week: {meetings}
- Recent support tickets: {tickets}
- Product changelog: {recent releases}
- Any flagged state transitions from the previous week: {transitions}

Generate a briefing that includes:
1. Top 3 priority accounts this week and why
2. Prep notes for each scheduled meeting (key context, recommended
   talking points, technical anchors per the customer's stack)
3. Accounts with no scheduled touchpoint that need attention
4. New product releases relevant to specific accounts in the portfolio
5. Suggested time blocks for proactive outreach vs. reactive work

Keep it scannable. No more than 1 page. No filler.

The One Metric That Matters

The number I’d track instead of headcount-to-account ratio is what I think of as effective book of business. It’s the number of accounts a single CSM can manage well, measured by the outcome data that actually matters: gross retention, net retention, time-to-architecture, expansion rate.

Most CS orgs run at 20 to 30 accounts per CSM. With a working version of the Layer Cake in place, the same CSM can manage 60 to 80 without a meaningful drop in retention or expansion for non-strategic accounts. That delta is what an AI-native CS operation actually looks like in practice.

If your effective book has been flat for two years, your stack isn’t compounding. You’ve added tools, not leverage.

It sounds progressive. It sounds like alignment. And it’s quietly destroying the one thing that makes CS effective.

Trust.

The moment a customer perceives their CSM as a salesperson, the relationship changes fundamentally. Technical buyers are especially attuned to this. Engineers have been burned by vendor relationships that prioritized extraction over value. They can smell a pitch from three slides away, and once they do, you’ve lost something you can’t get back.

But here’s the part nobody says out loud: the best CS orgs drive more expansion revenue than sales-led models, not less. They just do it differently.

The Problem With Sales-Led Expansion

The standard playbook goes like this: CSM has a good relationship with the customer, so CSM should leverage that relationship to drive upsells. QBR becomes the venue for the pitch. Renewal becomes the forcing function for the expansion conversation.

This logic is backwards.

You’re converting a trust asset into a transaction, and you can only do that once. The champion, who used to be candid about what was broken, now hedges because they know the CSM has a number to hit. The engineering lead who used to pull you into architecture discussions stops inviting you because the last three conversations ended with a pricing conversation.

The revenue shows up short-term. The trust doesn’t come back.

I’ve watched this scenario play out at dozens of companies. The teams that grafted sales motions onto CS relationships saw an initial bump in expansion revenue followed by a slow, steady decline in NRR. Teams that took a different approach, one rooted in technical depth, consistently outperformed.

The Framework: Architecture-Led Expansion (ALE)

Expansion in technical products follows a predictable pattern: deeper integration leads to more use cases, more use cases lead to more users, more users create more value, and more value creates natural commercial expansion.

Your job is to accelerate that progression. Not to pitch upgrades.

ALE has four components:

1. Map the Whitespace Architecturally

Most expansion conversations start with "What else can we sell them?” ALE starts with "What does their full technical environment look like, and where else could our product add value they haven’t considered?”

This is a fundamentally different lens. You’re not looking at your product catalog and matching features to a customer. You’re looking at their architecture and identifying gaps where your product is the natural solution. The difference is subtle but critical: one feels like selling, the other feels like consulting.

At GitHub, the CSMs who drove the most expansion revenue were the ones who could diagram a customer’s entire development workflow and identify the friction points our platform could eliminate. They never pitched. They solved problems that happened to require additional capabilities.

2. Plant Seeds Through Problem-Solving

When a customer raises a challenge in a TVR or a support interaction, solve it. And if the solution naturally involves capabilities beyond their current plan, demonstrate rather than sell.

“We actually have a way to handle that” is the most powerful expansion sentence in CS. It positions the capability as a solution to their problem, not a product you’re pushing. The customer experiences it as help, not a pitch.

The key word is “naturally”. If you’re contorting every support interaction into an upsell opportunity, you’re doing sales-led expansion with extra steps. ALE only works when the connection between their problem and the additional capability is genuine.

3. Enable the Champion to Sell Internally

Your technical champion already believes in the product. They don’t need to be convinced. They need ammunition.

The Champion Enablement Package is the most underused tool in CS. Instead of you selling to their leadership, you equip your champion to make the case internally. This works for three reasons:

• Credibility: An internal advocate is more trusted than an external vendor.

• Context: They know the political landscape, the budget cycles, and the objections.

• Ownership: When they champion the expansion, they own the outcome, which means they’re invested in making it successful.

You have to build the package around their narrative, not yours. Architecture diagrams should show the current vs. proposed state. Three talking points framed around their business priorities. They fill in a simple ROI framework with their own numbers. Anticipate objections with suggested responses. Map a timeline to their budget cycle.

Every component should be something they can present as their analysis, not something that looks like it came from your marketing team.

4. Trigger-Based Expansion Conversations

Certain technical milestones naturally create expansion opportunities. Hitting usage thresholds. Completing initial integration. Adding a new team. Architectural reviews. Production deployments that change the scope of the implementation.

Consider incorporating these triggers into your operating model rather than depending on CSM intuition or renewal timelines.

The distinction between vanity signals and real expansion signals is critical. A green health score tells you the customer is happy. Expansion signals tell you they’re ready. Most CS teams only instrument the first metric. ALE requires you to instrument both.

The Two Failure Modes

Failure Mode 1: Stealth Sales

This scenario is where a CS team adopts ALE language but keeps running a sales-led motion underneath. The CSM “maps the whitespace,” but the whitespace map is really just a territory plan. They “enable the champion,” but the enablement package is a sales deck with the logo removed.

Technical buyers see through the charade immediately. If your champion enablement package has your product name in the header and your competitive positioning in the talking points, it’s not enablement. It’s a brochure.

The test: Could your champion present this material without mentioning your company name and have it still be valuable? If not, it’s not enablement.

Failure Mode 2: Passive Waiting

The opposite failure. The CS team is so afraid of being perceived as sales that they never proactively surface expansion opportunities. They wait for the customer to ask. They wait for renewal. They wait for the champion to figure out on their own that more capabilities exist.

ALE isn’t passive. It’s proactive problem-solving that creates natural pull. You’re solving problems, demonstrating capabilities, and equipping champions. The expansion conversation is a consequence of excellent technical partnership, not an agenda item you’re avoiding.

The One Metric That Matters

If you adopt ALE, the metric you track changes.

Sales-led expansion tracks expansion revenue per CSM, which is a number that incentivizes CSMs to push. ALE tracks champion-initiated expansion rate, the percentage of expansion deals where the customer reached out first or the champion drove the internal business case.

A healthy ALE motion should produce a champion-initiated rate above 60%. If most of your expansion is still CSM-initiated, you haven’t shifted the model, you’ve just relabeled it.

The Prompt Library

Two prompts and one agent workflow to operationalize ALE in your CS org.

Prompt 1: Whitespace Analyzer

Analyze this customer's current product usage and technical environment to identify expansion opportunities that are architecturally natural — not forced upsells.

Current state:
- Products/modules currently using: {list}
- Current usage volume and trends: {data}
- Known technical environment: {stack}
- Teams currently using the product: {teams}
- Integrations in place: {integrations}
- Problems they've raised in the last 6 months: {support themes}

Identify:
1. Adjacent use cases where the product could solve problems they're currently handling with other tools or manual processes
2. Teams or departments that would benefit but aren't currently using the product
3. Technical milestones they're approaching that naturally create expansion conversations
4. The single highest-probability expansion opportunity and a recommended approach that feels helpful, not salesy

Prompt 2: Champion Enablement Package Builder

My technical champion at {customer_name} wants to expand our product to {new use case/team/capability}. They need to make an internal business case to their leadership.

Context:
- Champion's role: {title}
- Current deployment: {what they're using today}
- Proposed expansion: {what they want to add}
- Their leadership's likely concerns: {concerns}
- Budget cycle timing: {when}

Create a champion enablement package:
1. A one-page architecture diagram description showing current state vs. proposed state
2. Three talking points framed around their business priorities (not our product features)
3. A simple ROI framework they can fill in with their own numbers
4. Anticipated objections and suggested responses
5. A recommended timeline that aligns with their budget cycle

Agent Workflow: Expansion Signal Monitor

You are monitoring a portfolio of accounts for natural expansion signals. Review the following data weekly and flag accounts showing expansion readiness.

Portfolio data:
{structured account data including usage, support, engagement}

Expansion signals to detect:
- Usage approaching tier thresholds (>80% of current plan)
- New teams or users being added organically
- Support questions about capabilities not in their current plan
- Integration with new tools that suggest evolving use cases
- Champion promotions or role changes that increase their influence
- Positive references to the product in external channels

For each flagged account, specify:
1. Which signal(s) triggered the flag
2. Recommended expansion conversation approach
3. Timing recommendation (act now vs. nurture)
4. Whether to engage directly or equip the champion

This is Post 4 of a 5-part series: Rebuilding Customer Success. Next up: the scaling problem nobody wants to talk about and why the answer isn’t more headcount.

If these frameworks and prompts are useful, subscribe for the final post and the complete prompt library that comes with it.

Engineers would rather not be trained. They want to solve their problem. They’ve already read your docs. They Googled your API. They probably found a GitHub thread where someone had the same edge case they’re worried about. What’s standing between them and production isn’t knowledge. It’s friction.

The fastest path to value isn’t a webinar series. It’s removing every obstacle between the customer’s intent and their first meaningful outcome.

The best onboarding for technical products doesn’t look like customer success. It looks like developer experience design.

The Framework: Time-to-Architecture (TTA)

Stop measuring time-to-value. It’s vague, difficult to define, and almost impossible to benchmark consistently. Replace it with time-to-architecture: the elapsed time between contract signing and the customer having your product embedded in their production architecture in a way that would be painful to remove.

TTA is a real number. It’s measurable. And it predicts retention far better than any satisfaction survey.

Four principles:

1. Outcome-first onboarding: Start with "What are you trying to accomplish?" not “here’s how our product works.” Most CSMs start onboarding by walking through feature menus. Technical buyers tune out immediately. Map their stated goal to the fastest implementation path before you touch a single slide.

2. Progressive complexity: Get them to a working integration in hours, not weeks. One integration that works in production is worth more than a 12-module training course that ends with “now let’s schedule the kickoff.” Think about how the best developer tools work: Stripe's accepting a payment in 5 minutes, Twilio’s first SMS, and Vercel’s first deploy. The entire UX is designed around the moment of first success. Your onboarding should be no different.

3. Architecture anchors: Deliberately help customers integrate in ways that create healthy dependencies. Not lock-in for its own sake, but genuine architectural value that makes your product load-bearing. An integration that sits on the edge of someone’s stack is easy to remove. One that sits in the middle of their data pipeline is not. Guide them toward the middle.

4. Self-service with instrumentation: Let technical users move at their own pace. Forcing them into a CSM-led process every step of the way is friction, not service. Build docs, quick starts, and templates that make self-direction the path of least resistance, but instrument the journey so you know when someone is stuck, stalled, or going down an implementation dead end.

Why CSMs Keep Getting Onboarding Wrong

There are two failure modes I see frequently.

The first is feature tourism. The CSM walks the customer through every part of the product in the first few sessions, covering things the customer won’t need for six months. By the time they actually need something, they’ve forgotten the walkthrough. Meanwhile, you've missed the opportunity when they're most eager to act quickly.

The second is milestone theater. The onboarding plan has 14 steps, each marked complete when the customer sits through a meeting. But meeting attendance isn’t progress. The only milestone that matters is whether this thing is in production. Everything else is a process.

The underlying problem in both cases is that the onboarding is designed around the vendor’s comfort, not the customer’s intent. CSMs want a structured sequence they can report on. Engineers want to ship something.

What TTA Changes

When you organize onboarding around time-to-architecture, a few things shift.

First, kickoff calls change. Instead of “let’s review the onboarding timeline,” the first call is, "What does your production architecture look like today, and where does our product fit?” That’s a conversation technical buyers actually want to have.

Second, success milestones become real signals. “Completed module 3” tells you nothing. “First API call in production” tells you a lot. “Product embedded in two workflows” tells you you’re probably going to retain this account.

Thirdly, CSM time is allocated to the edges. A significant portion of onboarding effort is often directed towards customers who are likely to understand it on their own. TTA instrumentation shows you who’s actually stuck so you can deploy human attention where it changes the outcome, not where it provides the appearance of service.

The Prompt Library

Prompt 1: Onboarding Path Generator

A new customer just signed. Based on their profile, design a personalized onboarding path optimized for minimum time-to-architecture.

Customer profile:
- Company size: {size}
- Technical maturity: {low/medium/high}
- Primary use case: {use case}
- Existing tech stack: {tools and platforms}
- Decision maker role: {title}
- Implementation team: {who's doing the work}
- Success criteria stated during sales: {criteria}

Generate:
1. The single fastest path to a working production integration (target: under 2 weeks)
2. Three milestone checkpoints with specific observable signals that confirm progress
3. Potential friction points based on their stack and maturity level
4. Recommended self-service resources to send before the kickoff call
5. Questions to ask in the kickoff that a traditional onboarding script would miss

Prompt 2: Onboarding Friction Detector

Review the following onboarding data for customers who started in the last 90 days. Identify where TTA is breaking down.

Onboarding data:
{structured data: customer, start date, current milestone, days at each stage, support tickets opened, CSM touchpoints}

Analyze:
1. Which stage has the longest average dwell time?
2. Are there segments (by company size, use case, or stack) that consistently stall?
3. What support ticket patterns emerge during onboarding?
4. Which customers reached production integration fastest — what did they have in common?

Recommend 3 specific changes to the onboarding process that would reduce average time-to-architecture.

One Metric to Add This Week

If you’re not tracking TTA today, start with a proxy: days from contract signed to first production API call (or equivalent for your product). Pull the last 90 days of new customers. Segment by company size and technical maturity. Find the outliers (the customers who got there fast) and figure out what they had in common.

That pattern is your new onboarding template.

This is the third post in a series on rebuilding Customer Success for technical products. If you missed the first one, start here: Your Health Score Is a Horoscope. Subscribe at michaelpgoetz.substack.com if you’re building CS for people who build software.

Think about what you’re actually asking your champion to do. They had to block an hour on their calendar. They probably had to pull in their boss or a peer. And now they’re sitting through 45 minutes of “here’s your adoption data” that they could have pulled from a dashboard in 30 seconds. You’re not providing value. You’re consuming their political capital to justify your own existence.

Technical buyers feel this harder than anyone. Engineers evaluate vendor relationships on two criteria: do you respect my time, and do you make me smarter? A QBR that reads back their own data fails both tests. Every single time.

This is the second post in a series on rebuilding Customer Success for technical products. Same format as last time: challenge something the industry treats as settled, offer a framework to replace it, and hand you the prompts to operationalize it this week.

The Problem: 60 Minutes of Nothing

Here’s what a standard QBR typically looks like.

Slide 1: company logos and “partnership overview.”

Slide 2: usage metrics with a green arrow pointing up.

Slide 3: support ticket summary.

Slide 4: NPS score.

Slide 5: “roadmap preview” that’s really just a marketing slide from the last product launch.

Slide 6: “open discussion” where everyone checks their phone.

Your champion sat through all of that and walked away with nothing they didn’t already know. Worse, they now have to justify to their boss why that meeting was worth the time. If they can’t, they stop accepting the invite. And you just lost your most important access point into the account.

Here’s what really happens after a bad QBR: your champion starts declining meetings. Not because they’re unhappy with the product, but because you’ve trained them to expect that every interaction with your team is a waste of time. That’s a self-inflicted wound.

The irony is that most CS teams treat QBR attendance as a health metric. “They showed up, so the relationship is fine.” No. They showed up because they felt obligated. The moment they stop feeling that obligation, you’ve already lost.

The Framework: The Technical Value Review (TVR)

I think the fix for these sorts of QBRs is to kill the format entirely and replace it with something designed for how technical buyers actually think.

Let’s call it the Technical Value Review. Here’s what makes it different.

No slides up front. Use a shared working document that both sides can edit. Send it to the customer 48 hours before the meeting. Let them add context, correct assumptions, and flag what they actually want to talk about. By the time you sit down together, half the meeting’s work is already done.

No usage reviews. They have dashboards. They know their numbers. If you’re spending meeting time reviewing data they already have, you’re telling them you have nothing better to offer. Stop it.

Three sections only. Everything in the document fits into one of three buckets:

1. Architecture Alignment. How has their technical environment changed since last time? New services, new teams, infrastructure shifts, reorgs. And given those changes, how should their use of your product evolve? This is the conversation that positions you as a technical partner instead of a vendor. You’re thinking about their architecture, not your renewal.

2. Roadmap Intersection. No one really wants a product marketing pitch. What customers really want is a specific mapping of what’s coming on your roadmap to their stated priorities. “You told us last quarter that observability across your microservices fleet is a priority. Here’s what we’re shipping in Q3 that directly addresses that. And here’s what we need your input on before we finalize the design.” That’s a conversation worth having.

3. Risk and Technical Debt. What’s fragile in their current implementation? What would you recommend they invest in before it becomes a support ticket? This is the section that builds trust faster than anything else in CS. You’re proactively telling them where the problems are, before they find out themselves.

30 minutes max. If you can’t deliver value in 30 minutes with a pre-shared doc and three focused sections, more time is not the answer. Better preparation is.

Why This Works for Technical Buyers

The TVR format works because it matches how engineers already operate. They read docs before meetings. They want the pre-read to be substantive, not a teaser. They hate slides. They evaluate people based on technical depth, not polish.

When you show up to a TVR and say “we noticed your API call patterns shifted last month, and given your migration to Kubernetes, here’s how we’d recommend restructuring the integration,” you just proved three things: you understand their architecture, you’re paying attention to how they use the product, and you have an opinion about how they should evolve. That’s a relationship. A slide deck with a green usage arrow is not.

The other thing the TVR does is shift the power dynamic. A QBR is something you do to the customer. A TVR is something you do with them. The shared doc means they have agency. The architecture section means they’re bringing knowledge to the table too. The roadmap section means their input actually shapes what gets built. They leave the meeting feeling like a partner, not a captive audience.

The Prompt Library

Three prompts to start running TVRs this week. Same drill as last time: pull data from your systems, fill in the brackets, and run them.

Prompt 1: TVR Prep Document Generator

Use this to build the shared working doc you’ll send to the customer 48 hours before the meeting.

You are preparing a Technical Value Review document for a meeting
with {customer_name}. Using the data below, create a concise shared
working document (not slides) with three sections.

Customer context:
- Industry: {industry}
- Primary use case: {use case}
- Technical environment: {stack details}
- Recent changes in their environment: {any known changes}
- Your product's recent releases relevant to them: {releases}
- Known implementation risks or technical debt: {risks}
- Their stated priorities for this quarter: {priorities}

Format the document as a collaborative working doc with:
1. Architecture Alignment (what's changed, what should evolve)
2. Roadmap Intersection (what's coming that matters to them,
   questions to ask)
3. Risk & Technical Debt (what to address proactively)

Keep it under 2 pages. Use technical language appropriate for an
engineering audience. No marketing speak.

Try this: Run it for your most important renewal this quarter. Send the output to the customer as a shared doc and ask them to add their context before the meeting. Watch what happens when they show up having already engaged with the material.

Prompt 2: QBR-to-TVR Converter

Already have a QBR deck built? Don’t start over. Feed it to this prompt and let it strip out the filler.

I have a traditional QBR deck that I need to transform into a
Technical Value Review format. Below is the content from my current
QBR slides.

Current QBR content:
{paste slide content}

Remove all usage metric reviews, NPS references, and relationship
management filler. Extract the genuinely valuable insights and
restructure them into the TVR format:
1. Architecture Alignment
2. Roadmap Intersection
3. Risk & Technical Debt

Flag any content from the original QBR that has no place in a TVR
and explain why it was cut.

Try this: Take the last QBR deck you delivered. Paste the content in. The prompt will tell you exactly how much of your current format is filler versus substance. Most teams find it’s about 70/30 in the wrong direction.

Prompt 3: Post-TVR Action Item Synthesizer

The meeting’s done. Now turn your notes into an action plan within 2 hours.

Here are my notes from a Technical Value Review meeting with
{customer_name}.

Meeting notes:
{paste notes}

Generate:
1. A summary email to send to the customer within 2 hours (concise,
   action-oriented, no fluff)
2. Internal action items categorized by: CSM follow-up, Product
   feedback to log, Engineering/support escalation
3. Any state transition signals detected during the conversation
   (refer to the state-based model: Onboarding, Expanding,
   Steady-State, At-Risk, Recovering)

Try this: Use it after your next customer meeting. The state transition detection in item 3 connects back to the framework from the first post in this series. You’re not just taking notes. You’re feeding the system.

The Bottom Line

The QBR was designed for a world where customers couldn’t access their own data and the CSM was the only window into how the account was doing. That world doesn’t exist anymore. Your customers have dashboards. They have product analytics. They don’t need you to tell them what they already know.

What they need is someone who understands their architecture, has an opinion about where it should go, and is willing to flag risks before they become problems. That’s a Technical Value Review. It’s shorter, sharper, and it actually makes your champion look good instead of wasting their time.

Kill the deck. Share a doc.

This is the second post in a series on rebuilding Customer Success for technical products. If you missed the first one, start here: Your Health Score Is a Horoscope. Subscribe at michaelpgoetz.substack.com if you’re building CS for people who build software.

Health scores are the horoscope of Customer Success. Vague enough to feel true. Updated too slowly to be useful. And they exist mostly to make the person reading them feel like they understand something they don’t.

This is the first post in a series where I’m going to challenge things the CS industry treats as settled, offer a framework I’d actually use, and hand you the prompt library or agent workflow to put it into practice. No theory without tooling. Here we go.

The Problem: Performative Dashboards

You know how these things get built. Take a handful of inputs (NPS, support ticket volume, login frequency, maybe a CSM gut-feel rating), throw some weights on them that somebody argued about in a meeting, and produce a composite number. Green, yellow, red. Board deck looks great.

Now ask a CSM what they’re supposed to do when an account turns yellow. You’ll get a shrug. Or worse, they’ll send a check-in email. The score told them something changed but not what, not why, and definitely not what to do about it. It’s a summary of stuff that already happened pretending to be a prediction.

But here’s the part that really gets me. The deeper failure isn’t that the score is wrong. It’s that the score trains your team to manage numbers instead of managing customers. CSMs figure out how to game the inputs. Leadership starts trusting the dashboard more than the people closest to the accounts. And the signals that actually predict churn (deployment logs, API call patterns, the day a champion updates their LinkedIn) those never make it into the model. Too hard to quantify. Too messy to weight.

I’ve watched a team spend months arguing about whether NPS should be 15% or 20% of the composite score. While that was happening, a strategic account quietly ripped out the integration because their internal champion left and nobody noticed. Health score was green the whole time.

The Framework: Signal-Based Customer State Detection

The answer isn’t a better health score. It’s scrapping the whole concept.

Replace it with a state machine. Customers aren’t a number on a 0-100 scale. They’re in one of a handful of states at any given time:

• Onboarding: Still implementing, clock is ticking on time-to-value

• Expanding: Rolling out to new teams, adding integrations, usage climbing

• Steady-State: Stable, not growing, not shrinking. Coasting.

• At-Risk: Usage declining, integrations getting pulled, champion gone quiet

• Recovering: You’ve intervened, re-engagement is underway

The thing that matters isn’t the state itself. It’s the transitions. When a customer moves from Expanding to Steady-State, that means something. When they slide from Steady-State to At-Risk, that’s not a yellow dashboard. That’s a fire drill with a specific playbook attached to it.

Three ideas make this actually work in practice:

1. Flip from lagging to leading indicators.

Most health scores are built on data that tells you what already happened. NPS is how someone felt last quarter. Ticket volume is what already broke. You need the stuff that tells you where the account is headed: deployment velocity, feature adoption curves, how deep the integration goes, how often the champion is engaging. Forward-looking, not rearview mirror.

2. Trigger playbooks off state transitions, not score changes.

“Score dropped from 82 to 71” is meaningless. Nobody knows what to do with that. But “this account just moved from Expanding to Steady-State”? Now you’ve got something. Schedule an architecture review. Find the next expansion use case. Get back in front of the exec sponsor. That’s a to-do list, not a guessing game.

3. Treat technical depth as your best retention signal.

This one’s specific to technical products, and it’s the hill I’ll die on. The best predictor of whether a customer stays isn’t their satisfaction score. It’s how tangled up your product is in their architecture. Count the integration points. I like to call them “retention anchors”. Look at API call diversity. Figure out how many of their internal tools depend on yours. A customer running 15 integrations with 4 internal tools built on your API? They’re not leaving. I don’t care what their NPS is. A customer with one shallow integration and a great NPS? They’re one executive decision away from rip-and-replace.

The Prompt Library

OK, so how do you actually start doing this? Here are three prompts you can run this week against real customer data. They work with Claude, ChatGPT, whatever you’ve got. Pull structured data from your CRM, product analytics, and support system, and feed it in.

Prompt 1: Customer State Classifier

This one replaces your health score for a single account.

You are a Customer Success analyst specializing in technical B2B SaaS.
Given the following customer data, classify this customer into one of
these operational states: [Onboarding, Expanding, Steady-State,
At-Risk, Recovering].

Customer data:
- Account age: {months}
- Product usage trend (last 90 days): {increasing/flat/declining}
- Features activated vs. available: {ratio}
- Support ticket trend: {increasing/flat/declining}
- Last executive sponsor contact: {days ago}
- Recent integration/API changes: {description}
- Contract renewal date: {date}

Classify the state and explain which signals were most determinative.
Then recommend the top 3 actions the CSM should take this week,
specific to the detected state.

Try this: Run it on your top 20 accounts and compare to what your current health score says. I’d bet money at least 3 accounts come back in a different state than your dashboard shows.

Prompt 2: State Transition Detector (Weekly Batch)

This is your new Monday morning portfolio review.

You are reviewing a portfolio of {N} accounts. For each account below,
compare their current signals to their signals from 30 days ago.
Identify any accounts that have shifted operational states.

For each state transition detected:
1. Name the transition (e.g., "Expanding → Steady-State")
2. Identify the 2-3 signals that drove the change
3. Flag urgency: routine, elevated, or critical
4. Recommend the specific playbook to execute

Account data:
{structured account data with current and 30-day-prior snapshots}

Try this: Use it to replace your weekly health score review. Instead of everyone staring at a dashboard trying to figure out what the numbers mean, you walk in with a ranked list of state transitions and a playbook for each one. The meeting goes from interpretation to execution.

Prompt 3: Health Score Audit

Run this once to find out where your current model is lying to you.

I'm going to share our current health score model. Analyze it for
the following failure modes:
- Lagging indicator dependency (signals that tell you what already
  happened)
- Vanity signal inclusion (metrics that feel important but don't
  predict outcomes)
- Missing technical depth signals
- Weighting that obscures rather than clarifies

Current health score model:
{paste your model: inputs, weights, thresholds, and any logic}

Provide a redesigned scoring approach using state-based detection
instead of composite scoring. Map each of our current inputs to
either: a state classification signal, a transition trigger, or
"remove: does not predict outcomes."

Try this: Paste your actual health score model in. Inputs, weights, thresholds, all of it. You’ll find out which signals actually predict outcomes, which ones are vanity metrics making you feel good, and how to restructure around state detection. Do it before your next QBR.

The Bottom Line

Health scores were built for a world where CS was an account management function and the main event was a quarterly business review. If you’re running CS for a technical product, where your customers are engineers, your value lives in their architecture, and retention comes down to integration depth, you need something that thinks in states and transitions, not weighted averages.

Kill the horoscope. Build a state machine.

This is the first post in a series on rebuilding Customer Success for technical products. Next up: why your QBR format is optimized for the wrong audience. Subscribe at michaelpgoetz.substack.com if you’re building CS for people who build software.

It’s been 9 months since I’ve published here. A lot has changed.

When I started this Substack, I was building a startup with AI tools and writing about that experience. Since then, I’ve taken on the SVP of Customer Success role at Drata, and the thing I’ve been thinking about most isn’t how to build software — it’s how to rebuild the way we run Customer Success for technical products.

Here’s what this publication is now:

I’m writing for CS leaders at technical SaaS companies. The ones whose customers are engineers, whose retention depends on architectural depth, and who are tired of frameworks designed for a different buyer.

Every post follows the same format: a challenge to something the CS industry treats as settled, an opinionated framework to replace it, and a prompt library or AI agent workflow you can run against real customer data that week.

Look out for the first post tomorrow. “Your Health Score Is a Horoscope” is focused on why composite health scores are performative dashboards and what to build instead.

If this new direction isn’t your thing, no hard feelings, unsubscribe link is below. If it is, I’m glad you’re here.

— Michael

Last week, Amazon quietly launched something called Kiro. Most people saw "another AI coding tool" and moved on. I almost did too.

But something in their launch post caught my eye: they weren't selling speed. They were selling thinking.

After five weeks of vibecoding my way through RallyCamp, shipping features fast but accumulating technical debt faster, this hit different. So I signed up, played around with it for a few hours, and discovered something that changed how I use Claude Code.

Here's the thing: you don't need Kiro to use their best idea.

What Kiro Actually Does

Kiro forces you to build in a specific order:

1. Requirements first (what problem are you solving?)

2. Design second (how will you solve it?)

3. Tasks third (what's the step-by-step plan?)

4. Code last (now execute the plan)

If you try to skip ahead, it literally won't let you. The AI refuses to write code until you've thought through the problem.

My first reaction: "This is going to slow me down."

My second reaction, after trying it: "Holy shit, this is exactly what I've been missing."

The Pattern Hidden in Plain Sight

Here's what fascinated me: Kiro uses Claude under the hood. The same Claude I've been using in Claude Code. The same Claude that's been happily building whatever half-baked idea I throw at it.

The difference wasn't the AI. It was the workflow.

So I did what any reasonable person would do. I tried to replicate Kiro's pattern directly in Claude Code.

My First Experiment

I had just run a codebase review on RallyCamp and discovered something horrifying: I had copy-pasted authentication code across 8 different API routes. Eight! The same security-critical code, duplicated everywhere.

Instead of my usual approach ("hey Claude, fix this mess"), I tried the Kiro way.

Step 1: Requirements

Create a requirements.md file for fixing code duplication issues. I have auth code copied 8+ times, validation error handling in 15+ places, and the same patterns repeated everywhere. Focus on why this is a problem and what the solution needs to achieve.

What came back surprised me. Instead of jumping to refactoring, Claude asked questions:

• What happens when you need to fix a security bug in the auth code?

• How many places could you miss?

• What's the blast radius if you get it wrong?

We went back and forth for 10 minutes. By the end, I had a requirements doc that clearly explained WHY this wasn't just about clean code, it was about security and maintainability.

Step 2: Design

Based on requirements.md, create a design.md file for the refactoring. 
Include the new architecture, where shared code will live, and how 
we'll migrate without breaking existing features. No code yet.

This is where it got interesting. Because Claude had the requirements context, the design actually addressed real risks. It suggested things like:

• Creating a phased rollout (security-critical auth first)

• Building comprehensive tests before touching anything

• Setting up feature flags for gradual migration

Stuff I would've learned the hard way after breaking production.

Step 3: Tasks

Break down design.md into specific implementation tasks in tasks.md. Phase 1 should be security-critical auth code. Each task should be independently testable. Order by risk and dependencies.

Now I had a roadmap. Not just "refactor everything" but a three-week plan:

• Week 1: Extract auth middleware, test exhaustively, migrate routes

• Week 2: Create validation handlers and unified API client

• Week 3: Extract shared schemas and utility functions

Step 4: Actually Build

Execute task 1 from tasks.md: Create lib/api/auth.ts with 
requireAuth() middleware. Reference the duplicated code patterns 
from the codebase review.

The code that came out was different. Better. It knew exactly what patterns to extract and why.

Why This Changes Everything

Remember my post about technical debt? About how AI builds code optimized for different constraints than yours?

This fixes that.

When you give AI the full context (requirements, design, architecture) it builds code optimized for YOUR constraints. Your security requirements. Your maintenance needs.

The auth refactoring? It touched 8 critical files. Zero bugs. Zero downtime. That's never happened with my "just fix it" approach.

Even better: the refactoring actually reduced the codebase by 1000+ lines. Turns out when AI understands the full picture, it doesn't just move code around, it finds better patterns.

The Real Magic: Thinking Time

Here's what I realized: The value isn't in the documents. It's in the thinking that happens while creating them.

When I'm writing requirements, I'm not just listing features. I'm discovering edge cases. When I'm writing design docs, I'm not just planning architecture. I'm spotting problems before they're expensive.

The AI helps with this thinking. It asks questions I don't think to ask. It spots patterns I miss. It's like pair programming, but for product design.

My Current Workflow

I still use Claude Code for everything. I just use it differently:

Monday: Think through the week's features. Create requirement docs for each.

Tuesday: Turn requirements into designs. Let Claude challenge my assumptions.

Wednesday-Thursday: Execute tasks. The actual coding is the easy part now.

Friday: Ship with confidence.

I'm building at the same speed, but with 90% fewer "oh shit" moments.

But Here's the Catch

This approach has one major downside: it's addictive.

Once you experience building with clarity (ie. knowing exactly what you're making and why) it's hard to go back to chaos mode. Even for quick experiments, I find myself writing mini-specs.

Last week, I spent 20 minutes spec'ing out a feature that would've taken 10 minutes to build directly. The feature took another 15 minutes to build with the spec.

Total time: 35 minutes instead of 10. But you know what I didn't spend time on? Debugging. Fixing edge cases. Rebuilding it when users complained.

You Don't Need Kiro for This

Look, Kiro seems cool. The interface is slick, the workflow is smooth, and having guardrails built-in is nice.

But you don't need it.

You just need discipline to think before you build. And if you're using Claude Code like me, you can start right now:

# Start a new feature the right way
claude "I want to add [feature description]. 
Let's start by creating a requirements doc. 
Ask me questions until you understand the problem space, 
then write requirements.md"

That's it. That's the secret. Make the AI think with you before it codes for you.

The Unexpected Benefit

Remember my "47 ChatGPT chats" problem? This solves that too.

Now I have one chat per feature, but it contains the complete journey: requirements → design → tasks → code. When I need to modify something weeks later, the context is all there. The thinking is documented.

My codebase has become self-documenting. Not through code comments, but through the thoughts that created the code.

What This Really Means

We're at a weird moment in software development. AI can build almost anything we can describe. The bottleneck isn't coding speed anymore, it's thinking speed.

The teams that win won't be the ones with the best prompts or the fastest AI. They'll be the ones who think before they build.

Kiro gets this. That's why they built an entire IDE around making you think first. But you can get the same benefit with any AI tool. You just have to choose to slow down in the right places.

Your Move

This week, try building one feature the Kiro way:

1. Requirements (what problem?)

2. Design (what solution?)

3. Tasks (what steps?)

4. Code (execute the plan)

Use whatever AI tool you prefer. The tool doesn't matter. The order does.

And if you're already using Claude Code, steal my prompts above. They work.

P.S. - That auth refactoring? Not only did it eliminate security risks, it made adding new API routes 10x faster. Now it's just requireAuth() instead of 50 lines of copy-paste. Sometimes thinking first pays compound interest.

The Reality Check

I’ve been a bit absent writing the last few weeks. That’s because I ran into something nobody mentions in the "build with AI" tutorials: shipping is just the beginning.

My prompt chain had worked beautifully. I'd gone from idea to working app in four weeks. The code looked clean, the features worked, and I was feeling pretty confident about this whole AI-assisted development thing.

Then I decided to add in some functionality to manage the waitlist for users.

And that's when I discovered technical debt I never saw coming.

The Illusion of Clean Code

Here's what AI-generated code looks like when it's fresh: organized file structure, descriptive function names, helpful comments throughout. It feels professional because AI is really good at making things look professional.

But looking professional and being maintainable are two very different things.

The first time I needed to modify a feature based on user feedback, I realized I was debugging code I didn't actually understand. Sure, I could read it. But reading code and understanding the architectural decisions behind it? Completely different skills.

The Hidden Costs of "Fast" Development

When you build with AI, you're essentially inheriting someone else's codebase from day one. Except that "someone else" is a system that makes decisions differently than you would.

AI optimizes for getting the feature working. You optimize for getting the feature working and being able to change it later when users inevitably want something slightly different.

This creates four types of technical debt that traditional coding tutorials never prepare you for:

1. The Black Box Problem

AI creates functions that work perfectly for the exact use case you described. But when you need to modify them, you realize they're doing multiple things at once in ways you wouldn't have architected yourself.

2. The Over-Engineering Trap

AI tends to build for scale and edge cases you don't need yet. My simple app ended up with enterprise-level complexity for features that could have been much simpler.

3. The Dependency Web

AI is great at leveraging existing libraries. Sometimes too great. What starts as a simple request can end up pulling in multiple dependencies that you'll need to maintain and debug.

4. The Context Gap

This is the big one. AI builds exactly what you describe, not what you mean. The nuances of your specific use case—the business logic that makes your app unique—often get lost in translation.

What Debugging Actually Looks Like

Debugging AI-generated code follows a predictable pattern:

First, you think it'll be a quick fix. The error message seems straightforward enough.

Then you realize the "simple" feature is connected to three other systems in ways that aren't immediately obvious.

Then you spend more time understanding the existing code than it would have taken to write the feature from scratch.

Finally, you either patch around the issue (creating more technical debt) or rewrite the section entirely.

The problem isn't that AI writes bad code. It's that AI writes code optimized for different constraints than yours.

The Two-Part Solution

After working through this with RallyCamp, I've developed an approach that actually works:

Part 1: The 80/20 Strategy

Let AI handle the first 80%—the boilerplate, standard implementations, and common patterns every app needs. But plan to rewrite the last 20% yourself: the business-specific logic that makes your app unique.

This gives you the speed benefits of AI without losing understanding of your core functionality.

Part 2: The Documentation Requirement

After AI generates any significant code, I run it through this prompt:

"Explain this code like I'm going to maintain it for the next two years. What does each major function do? What are the key dependencies? What assumptions are built into this logic? What would break if I needed to modify [specific functionality]?"

This creates a maintenance roadmap before you need it, not after something breaks.

The Real ROI

Was building RallyCamp with AI worth it? Absolutely. But not for the reasons I expected.

AI didn't eliminate technical complexity—it shifted when I dealt with it. Instead of spending weeks learning to code before building anything, I spent time learning to debug and refactor after shipping something real.

The value wasn't avoiding technical challenges. It was facing the right technical challenges with real user feedback driving the decisions.

What I'd Do Differently

Starting over, here's what I'd change:

1. Build one feature completely (including understanding and documentation) before moving to the next

2. Set debugging time limits—if I can't understand and fix an AI-generated issue in a reasonable time, I rewrite that section

3. Plan for iteration from day one—assume every feature will need modification based on user feedback

4. Document architectural decisions as I go, not after something breaks

The Mindset Shift

The biggest insight isn't about code—it's about expectations.

AI doesn't eliminate technical complexity. It relocates it from "learning to build" to "learning to maintain." Both are valuable skills, but they're different skills.

The founders who succeed with AI won't be the ones with the perfect prompts. They'll be the ones who plan for technical debt as a natural part of the process.

Because when your users need a feature modified, and they're waiting for the fix, the quality of your prompts matters less than your ability to understand and change the code that's already running.

Building with AI? I'd love to hear what technical debt you've discovered. Reply and let me know what surprised you most about maintaining AI-generated code.

ChatGPT Hell

You know that feeling when you have so many browser tabs open that the favicons disappear and you're just looking at a wall of gray rectangles? That was me four weeks ago, except worse. I had 47 ChatGPT chats open. Forty. Seven.

Each one was a different conversation thread about RallyCamp, my camping app idea. One tab for database design. Another for user authentication. Three separate ones just for different approaches to the scheduling system. I'd hop between them like a caffeinated squirrel, copying bits from one conversation, pasting into another, trying to remember which tab had that brilliant insight about Scout leader workflows.

11 PM, One Reddit Link

It was 11pm on a Tuesday when everything changed. I was scrolling Reddit, specifically r/vibecoding, when I found a thread titled "This is how I build & launch apps (using AI), even faster than before."

The thoughtfulness of the approach just blew me away. And it made a ton of sense to me. I had been treating ChatGPT like a better Google search, trying to learn all of the various roles and context myself. This approach was changing me from a do-it-all-yourself quasi-developer to an AI boss, something that was much more relatable to my recent real life work.

The commenter had linked to their workflow, but honestly, it was overwhelming. Pages and pages of complex prompts with variables and conditionals. I almost closed the tab, but something made me try a simpler version.

The 12-Word Prompt Factory

I opened a fresh ChatGPT window. Just one. And I started with the most basic prompt I could think of:

What are the top 5 most in-demand consumer topics for outdoor recreation apps?

Nothing fancy. No complex instructions. Just a question. But here's where it got interesting. Instead of diving straight into features or code, I took the AI's response and fed it into a second prompt:

Based on these market opportunities, give me 10 app ideas for Scout camping coordination.

Then I took the best idea from that list and wrote my third prompt. And this is where I almost fell out of my chair, because it was literally just seven words:

Create a product requirements doc for this app

Seven words. That's it. And ChatGPT spit out a comprehensive PRD that was better than anything I'd cobbled together across my 47 tabs.

Why Sequence Beats Complexity

But here's the thing. Those simple prompts worked because they were in sequence. Each one built on the last. The market research informed the ideation. The ideation informed the requirements. It was like... well, like a factory line.

Over the next few days, I refined this approach. My prompts got a bit more sophisticated, sure. But the core insight remained the same. Instead of having 47 conversations about 47 different aspects of my app, I had one conversation that flowed from market validation all the way to working code.

The first three prompts in my chain became the foundation for everything:

First, I'd validate the market. Not with some generic "is this a good idea?" question, but by researching actual consumer spending patterns and market trends. This kept me from building something nobody wanted.

Second, I'd generate technically feasible ideas based on that research. Not pie-in-the-sky features, but actual MVPs I could build with AI assistance.

Third, I'd refine the winning idea into a proper product strategy. Not just features, but user personas, go-to-market plans, the works.

What used to take me days of jumping between tabs now took hours in a single, focused session. More importantly, each output was connected. The technical architecture actually matched the product requirements. The product requirements actually matched the market opportunity.

Shipping RallyCamp in Four Weeks

Last week, I shipped the beta of RallyCamp. We've got a few friendly Scout leaders testing it since we are hitting prime camping season. All from a system that started with seven words and a Reddit post at 11pm.

The crazy part? My prompts are still pretty simple. Sure, they've evolved from those first seven words, but they're not the complex monstrosities I thought I needed. They're just clear, sequential instructions that build on each other.

I've been refining these prompts with each project iteration, and I've decided to share them. Not because they're perfect, but because they work. And because I remember staring at those 47 chats thinking there had to be a better way.

Steal My First Three Prompts

This week, I'm sharing the first three prompts in my chain. The ones that take you from "I have an idea" to "I have a validated product strategy." They're the foundation everything else builds on.

Next week, I'll share the prompts that turn that strategy into an actual technical plan. The week after that, the ones that generate working code.

But it all starts with these three. The same three that helped me go from 47 tabs of chaos to shipping actual software in four weeks.

We've been using AI wrong. Not because we need more complex prompts or better models. But because we've been treating each conversation like it exists in isolation, when what we really need is a system.

A chain where each link strengthens the next.

So yeah, that Reddit thread really did change everything. Not because it gave me the perfect prompts, but because it showed me that the perfect prompt doesn't exist. What exists is the perfect sequence. The right questions in the right order.

And it all started with closing 47 chats and opening just one.

P.S. If you want to try the prompts yourself, grab them here. Start with just the first one. See what market opportunity resonates with you. Then feed that into the second prompt. Then the third. Don't overthink it. The magic isn't in any individual prompt. It's in the chain.

The Before State

Five weeks ago, I'd just left GitHub after 4.5 years building Customer Success teams. My last serious coding attempt was basic Python for AWS automation—four years ago. I was that manager who understood how software worked but couldn't build it anymore.

Then I saw someone on Reddit mention they'd built an entire SaaS in a weekend using "vibecoding."

My first thought: "I’m not putting my data in there." My second thought: "...but surely I could figure out a better way?"

Week 1: The Gateway Drug

I started safe with Lovable. No code to write, just describe what you want. My prompt was ambitious for someone who'd been managing, not making:

"Create an interactive journey mapping tool that includes collaboration features, AI driven analysis and recommendations."

Five minutes. That's all it took.

I stared at my screen. This wasn't a mockup or wireframe. Forms worked. Buttons clicked. Data persisted. It even recommended next steps: "Connect Supabase for user accounts and data persistence."

What the hell is Supabase? Didn't matter. There was a button. I clicked it.

Suddenly I had authentication, a database, API endpoints—infrastructure that would've taken me weeks to set up properly. Working. In fifteen minutes total.

I actually said "holy shit" out loud. Then I immediately went upstairs to my wife’s home office: "I just built this thing in like 15 minutes and it mostly works. This is pretty transformational."

The weirdest part? After building my dream CS tool in 15 minutes, I realized... I didn't actually want to run a journey mapping company. When building becomes this easy, you can afford to be picky.

Week 2: Down the Rabbit Hole

If Lovable was gateway drug, ChatGPT Plus was the hard stuff. I bought the annual subscription (first of many AI subscriptions I'd impulse buy).

New idea: Website builder for local small businesses! ChatGPT turned interviewer:

• "What's your initial budget?"

• "Uh... zero dollars please?"

• "What's your technical differentiation?"

• "I... hmm."

It produced a beautiful business plan. Projected Year 1 loss: $19,000. Year 2 profit: $4,000 on a $100k investment.

The AI had just talked me out of my own startup idea. That's when I realized—AI isn't just a building tool. It's a thinking partner that doesn't care about your feelings.

Week 3: The Pivot That Stuck

"Fine," I told ChatGPT. "You tell ME what to build."

I fed it my background: AWS, GitHub, Customer Success, Cub Scout leader planning our annual campout (currently drowning in spreadsheets and SignUpGenius links).

It suggested five ideas. Number 5 caught my eye: "Outdoor Trip Planning & Community App."

"Surely someone's built this for Scouts?" I asked.

ChatGPT's research: "There's a significant gap in the market for group camping coordination specifically designed for youth organizations."

Three prompts later, I had:

• Market analysis

• Competitive landscape

• Revenue projections

• Even a name: CampSync (later RallyCamp)

But here's where everything shifted. Instead of stopping at the business plan, I kept going:

"Create a product requirements doc for this app" "Now create a visual style guide" "Show me the user flow for trip creation" "Write the API schema"

Each prompt built on the last. I wasn't just brainstorming anymore—I was systematically building a company.

Week 4: From Prompts to Patterns

The mess was real. I had 47 ChatGPT chats in a giant list. Projects in Replit, Cursor, and Lovable. Notes scattered across three apps.

That's when I found the Reddit thread that changed everything for me. Some anonymous genius had posted their prompt sequence for going from idea to PRD to code. The comments were gold:

"I use this flow: Business validation → PRD → API design → Schema → Frontend components" "Pro tip: Make AI write the prompts for the next stage" "I version control my prompts like code"

Wait. Version control... for prompts?

I spent two days organizing. Built templates. Created a system. Suddenly I wasn't just using AI. I was building a machine that built products.

Week 5: The Metamorphosis

This week started different. Monday morning, I:

1. Woke up to Claude Code having completed a complete overhaul of the tests for my authentication system

2. Asked Gemini to help me improve my prompts for the next feature I’m planning to implement

3. Drafted my content strategy to help build some awareness for RallyCamp

4. Built a new feature before lunch

The Uncomfortable Truth

Here's what nobody's talking about: We're speedrunning the entire startup journey. What used to take months now takes weeks. What took weeks now takes hours.

Traditional path: Idea → 6 months → MVP → 12 months → Revenue My path: Idea → 6 hours → Prototype → 5 weeks → MVP launch

This isn't because I'm special. I'm a mediocre coder who bought the right tools at the right time. The game changed, and most people don't know it yet.

In six months, everyone will be "vibecoding." The arbitrage opportunity is right now.

What Actually Happened

I didn't learn to code. I learned to think in systems and let AI handle the implementation. I didn't become technical. I became a non-engineer who can ship production code.

Most importantly: I stopped consuming and started creating. Every day, I wake up with the power to build anything I can describe.

Your Move

I'm documenting everything. Every prompt, every failure, every breakthrough. Not because I'm an expert, but because I'm five weeks ahead of you and the view from here is insane.

Next week: The exact prompt sequences that collapsed six months of work into six weeks. Including the Reddit thread that started it all.

But honestly? You don't need to wait. Open ChatGPT right now and type: "I want to build an app that solves [your actual problem]. Help me create a one-page business plan to validate this idea."

See you on the other side.

This Week's Download: "From Zero to Shipping: My 5-Week Prompt Evolution"

• My first terrible prompts

• The Reddit-inspired templates that changed everything

• Current prompt chains for business → product → code

• What I wish I'd known on Day 1

Drop a comment: What bad startup idea could AI talk you out of in 10 minutes?

P.S. - I've built two other entire apps during these five weeks. Killed them both. When building is this fast, you can afford to fail. More on that next time.