Skip to content
YourBrief.

YourBrief.io — specimen file

Sample decision briefs

Four complete briefs, exactly as our generator produced them: pricing, M&A, portfolio strategy, and market entry. Each is tailored to a specific decision type.

The decision · filed for: Solo founder

Pricing — Raising our SaaS price from $29 to $79

PricingSolo founderTwo-way door

The decision

The decision: Move your single plan from $29 to $79/month for new customers only (existing 270 grandfathered at $29 for 12 months), versus holding at $29 and betting on volume growth to reach a livable income.

My read: this is a two-way door — treat it as one. Because you're only changing the price for new signups and grandfathering everyone who already pays you, the downside is capped at new signups from the test window. If $79 stalls conversion, you revert the page to $29 (or $49) next week and you've lost a few dozen trials, not a dollar of existing MRR. That is the opposite of a bet-the-company move. Given that, do not over-deliberate — run the price live and read the data. The only genuinely irreversible piece is the grandfather promise; once you tell 270 people "$29 for 12 months," you own that. So the reversible experiment is the new price; the one-way commitment is the grandfather clause, and you should word it carefully (see Next steps).

The strategic fact underneath this: at $8k MRR with growing support load and no team, volume growth is actively hostile to you — every new $29 customer adds support minutes that eat the build time you need to stay competitive with $99 and $149 rivals. Price is the lever that fixes MRR and support load at once.

Read the full brief
Recommended frameworks · filed for: Board of directors

M&A — Acquire vs build: entering the enterprise segment

M&AValuationOne-way door

Recommended frameworks

1. Buy vs. Build Economic Model Apply a total-cost-of-ownership (TCO) comparison. Building enterprise capabilities in-house costs: 2-3 senior engineers × 12 months × fully-loaded cost (~$150k each) = ~$900k in direct costs, plus lost enterprise revenue during the build period. If the two prospects represent $700k ARR and you lose them while building, the real cost of building is $700k in lost ARR + $900k in engineering = $1.6M. The $9M acquisition looks expensive until you factor in the time-to-revenue advantage and the three existing Fortune 500 logos.

2. The Real Options Framework Think of this as buying an option on enterprise growth. SecondLook gives you immediate revenue, SOC 2 Type II (already paid for), three enterprise logos (reducing your sales risk), and a team that already knows enterprise sales. The $9M is not just for revenue — it's for eliminating the 12-month execution risk of building and the risk of losing the $700k in pipeline. The question is: what is that optionality worth to you given your growth rate and runway? At 60% YoY, speed matters more than cost efficiency.

3. The Acquirer’s Dilemma (Valuation Artifacts) At $9M for $1.2M ARR, you're paying a 7.5x multiple. For a company with 60% YoY growth and enterprise traction, that's aggressive BUT not unreasonable if you factor in the strategic premium for: (a) SOC 2 Type II certification, (b) Fortune 500 logos that reduce your enterprise sales cycle, and (c) the two deals worth $700k that close immediately post-acquisition. Run the math: if you keep both $700k deals and add $500k from SecondLook's existing base, you've justified 57% of the purchase price in year one. The rest is strategic premium.

Read the full brief
Key questions · filed for: Executive leadership

Portfolio — Sunsetting the legacy on-prem product line

ExecutiveStrategic accountsContract risk

Key questions to answer before deciding

  1. What are the exact contract end dates for the three on-prem-only strategic accounts, and what are the renewal terms/price sensitivity? If two renew in the next 6 months versus 14 months, your timeline compression changes entirely.

  2. Can the on-prem team be reduced (not eliminated) — e.g., cut from 35% to 15% of engineering through a "security-maintenance-only" release train? This would preserve the strategic accounts while dramatically reducing the drain.

  3. What is the actual NRR lift potential from migrating the on-prem base to cloud? If the three strategic accounts convert at 128% NRR, does the math justify a longer runway even at higher cost?

  4. What does the competitive landscape look like — is on-prem demand collapsing across the market, or is this specific to our product's neglect? If competitors are still selling on-prem successfully, we may be underinvesting rather than the category dying.

  5. What is the contractual obligation exposure if we sunset mid-term? Sales' warning about "poisoning" accounts suggests there may be minimum service terms or implicit renewal expectations that create real liability.

  6. Is there a third path — spin out or sell the on-prem business to a services firm? This would offload the cost while preserving customer relationships (and potentially creating a referral pipeline).

Read the full brief
Decision criteria · filed for: Executive leadership

Market entry — Entering the AI coding-agents market

PositioningValidationCapital efficiency

Decision criteria

A good answer to this decision must pass these specific tests:

  1. The 3-Month Demo Test: Can you build a working prototype within 3 months that a security buyer would actually want to see? If not, the vertical play is aspirational, not viable.

  2. The Specificity Test: Can you name the exact security vulnerability category or compliance workflow your agent will automate? "Security and compliance" is too broad. "Finds and explains SQL injection vulnerabilities in PR before merge" is specific enough.

  3. The Pricing Signal Test: Have you talked to at least three potential enterprise buyers about what they would pay? Security tools command premiums — you need to know if your target is $20/seat/month or $200/seat/year.

  4. The Differentiation Test: If Microsoft adds a "security mode" to Copilot tomorrow, what remains of your moat? If the answer is only "we were first," you have no durable advantage. Your deep security expertise must translate into model behavior or workflow integration that is structurally hard for Copilot to replicate.

  5. The Runway Survival Test: Even in your most optimistic revenue scenario, can you extend runway or secure bridge financing to survive the enterprise sales cycle? If not, you need a horizontal or freemium pivot to get to revenue faster.

Read the full brief
Complete sample brief 1 of 4

Raising our SaaS price from $29 to $79

Raise the price from $29/month to $79/month for new customers — or keep it at $29 and try to grow on volume? Solo founder, ~$8k MRR, ~270 customers, competitors at $99 and $149.

Audience: Individual decision-maker
Timeline: Within 1 week
Framing: This is a two-way door.

The decision

The decision: Move your single plan from $29 to $79/month for new customers only (existing 270 grandfathered at $29 for 12 months), versus holding at $29 and betting on volume growth to reach a livable income.

My read: this is a two-way door — treat it as one. Because you're only changing the price for new signups and grandfathering everyone who already pays you, the downside is capped at new signups from the test window. If $79 stalls conversion, you revert the page to $29 (or $49) next week and you've lost a few dozen trials, not a dollar of existing MRR. That is the opposite of a bet-the-company move. Given that, do not over-deliberate — run the price live and read the data. The only genuinely irreversible piece is the grandfather promise; once you tell 270 people "$29 for 12 months," you own that. So the reversible experiment is the new price; the one-way commitment is the grandfather clause, and you should word it carefully (see Next steps).

The strategic fact underneath this: at $8k MRR with growing support load and no team, volume growth is actively hostile to you — every new $29 customer adds support minutes that eat the build time you need to stay competitive with $99 and $149 rivals. Price is the lever that fixes MRR and support load at once.

Key questions to answer before deciding

  1. Is your ~9% trial-to-paid conversion driven by price, or by the product solving the problem? "Nobody has ever complained about price" strongly suggests price isn't the selector — but you don't actually know until $79 is live. What conversion rate at $79 still beats $29 on revenue-per-trial? (Math: at $29 you need ~9% to match what $79 needs at only ~3.3%. Anything above ~3.3% conversion at $79 makes you more money per trial.)
  2. Who are your 270 current customers, and would they have paid $79? Pull the 10-20 most engaged accounts. If they're businesses using this daily to make or save money, your $29 price has been leaving money on the table for a year — which you already suspect.
  3. Where does your marginal support hour go — and does raising price cut the volume that generates it? If most tickets come from low-engagement $29 accounts, $79 filters them out at the top of the funnel. Quantify: how many support hours/week, and how many map to signup volume vs. genuine complexity?
  4. What actually justifies $79 next to competitors at $99 and $149? You're still the cheapest option even at $79. Which one or two capabilities let a prospect say "this does the job for less than the $99 tool"? You need that sentence on the pricing page.
  5. Do you have the runway to absorb a temporary signup dip while you read the experiment? At $8k MRR as your income, a 4-6 week window where new-customer count drops is fine if revenue-per-signup rises. Confirm you can personally tolerate one soft month.
  6. When the grandfather period ends in 12 months, what's the migration plan — and can you already see it? Don't promise "$29 for 12 months" without a rough answer for month 13, or you'll face 270 simultaneous churn decisions.

Recommended frameworks

1. Van Westendorp / "nobody complained" signal. The classic Price Sensitivity read says that if zero customers ever push back on price, you are almost certainly below your optimal price point — complaints only start near the top of the acceptable range. With 270 paying customers and not one price objection, you have strong evidence you're underpriced, which matches your own gut. This framework says: the risk isn't that $79 is too high — it's that even $79 may be conservative next to $99/$149.

2. Value-based pricing vs. competitor anchoring. Your rivals have set the market anchor at $99-$149 for a comparable feature set. At $79 you are deliberately the value option — 20-47% cheaper than the field — which is a defensible, buyer-friendly position rather than a greedy one. Applied here: $79 isn't a 2.7x price grab in the buyer's eyes; it's you finally pricing near the market floor. The story writes itself: "same job, lower price than the $99 tool."

3. Reversible-experiment / expected-value framing. Model it as revenue-per-100-trials. At $29 x 9% = $261/mo of new MRR per 100 trials. At $79 you break even at ~3.3% conversion; realistically you'll land somewhere between 4-7%, i.e. $316-$553/mo per 100 trials — a 20-110% gain — while also signing fewer, higher-intent customers who generate less support. The expected value is strongly positive and the downside is capped by grandfathering. This framework's output: run it.

Decision criteria

A good outcome here must pass these specific tests, given that this MRR is your livelihood and your scarcest resource is build time:

  • Revenue-per-trial goes up, not just price. The test passes if $79 delivers more new MRR per 100 trials than $29 did — i.e. conversion stays above ~3.3%. Watch this number, not raw signup count.
  • Support load per new customer flattens or drops. If $79 customers file fewer/higher-quality tickets, you've bought back build time — a second win beyond revenue. If support doesn't ease, revisit onboarding, not price.
  • The pricing page tells a coherent value story. A stranger should understand in 10 seconds why you're $79 and the competitor is $99 — and feel like they're getting the deal.
  • No churn spike among grandfathered customers. The $29 base should stay ~3%/month; if they churn on hearing about a higher public price, your grandfather messaging failed.
  • You can afford the read window. The experiment is only valid if you can watch 4-6 weeks of data without panic-reverting on week one's noise. Pre-commit to a decision date and a sample-size floor (see below).

Sources to consult

No pre-checked sources were provided, so here is a prioritized, specific research plan you can complete in 2-3 days:

  1. Your own funnel analytics (highest priority, do first). Pull the last 3-6 months of trial-to-paid conversion, signup volume by week, and MRR-per-trial. This is your baseline — you can't read the experiment without it.
  2. Your support ticket log. Tag the last ~100 tickets by type and by account engagement level. This tells you whether volume growth or a $29-tier customer profile is what's eating your build time.
  3. The two competitors' pricing and feature pages ($99 and $149). Screenshot exactly what they include at their price. Build a 3-column comparison (them, them, you-at-$79) to find and name your value wedge for the pricing copy.
  4. A 15-minute call or email with 3-5 of your most engaged current customers. Ask what they'd pay if starting today and what job the product does for them. Real willingness-to-pay signal beats any survey.
  5. Search for SaaS pricing-experiment write-ups (e.g., posts from founders who raised price for new customers while grandfathering — Patrick McKenzie / "charge more" essays, ProfitWell/Paddle pricing studies). Use them to sanity-check your read window and grandfather wording, not to make the decision — your data makes the decision.

Next steps

My recommendation: raise the price. Go to $79 for new customers this week and read the experiment. The evidence — zero price complaints, competitors at $99-$149, healthy conversion, support eating your build time — all points the same direction, and the downside is capped. Sequenced for this week:

  1. Today/tomorrow: Pull your conversion + MRR-per-trial baseline and tag 100 support tickets (research steps 1-2). Write down the pre-change numbers so the experiment is readable.
  2. Day 2-3: Build the 3-column competitor comparison and rewrite the pricing page with a one-line value story ("Everything the $99 tools do, for $79"). Set the price to $79 for new signups.
  3. Day 3: Send grandfathered customers a short, warm email: "Public price is going up — because you've been with me, you keep $29/month for the next 12 months." This reduces churn (loss aversion works for you) and seeds goodwill. Word the 12-month clause as a benefit, and avoid promising $29 forever.
  4. Ship it live and set a decision date 4-6 weeks out with a minimum sample (aim for ~150-200 trials before judging). Watch MRR-per-trial and support-per-new-customer, not raw signup count.
  5. Optional hedge if you're nervous: test $49 for one week first, then step to $79 — but honestly, given the $99/$149 anchors, I'd go straight to $79.

Revert or step down only if MRR-per-trial actually falls below your $29 baseline over the full window — not on a quiet first week.

When to escalate

Get outside help (a pricing-experienced advisor, a fractional growth person, or a peer founder who's done this) if you see these specific signals:

  • Conversion at $79 craters below ~3% AND stays there past a 150+ trial sample — that contradicts your "no one complains about price" evidence and means something structural (positioning, wrong buyer, product gap) is off. Don't just keep dropping price alone; get a second read.
  • Grandfathered customers start churning after the price email — that's a messaging/trust failure, and since those 270 accounts are your income, treat any spike above your ~3% baseline as an emergency worth a conversation.
  • You can't articulate the $79-vs-$99 value story after building the comparison — if the wedge isn't there, the real decision isn't price, it's product/positioning, and that's worth expert input before you touch pricing.
  • The soft month threatens rent. If a temporary signup dip genuinely endangers your personal finances, the issue is runway, not pricing — talk to someone about a buffer before running the experiment, because a founder who can't wait out the read window will misread it.

Generated by YourBrief.io. Not financial, legal, or medical advice. Validate with primary research.

Every brief excerpted above is published here in full — nothing is cherry-picked. Expand the other 3:

Complete sample brief 2 of 4 — click to expand
Acquire vs build: entering the enterprise segment

Acquire SecondLook — a 12-person competitor with an enterprise-ready product and $1.2M ARR, asking $9M — or build enterprise capabilities in-house over the next 12 months?

Read the full brief

Audience: Board of directors
Timeline: Within 1 week
Framing: This is a one-way door.

The decision

The decision: Acquire SecondLook, a 12-person competitor with $1.2M ARR and enterprise-ready product, for $9M — or build the missing enterprise capabilities (SSO, audit logs, SOC 2 Type II, compliance certifications) in-house over the next 12 months.

Reversibility read: You called this a one-way door, and I agree — with one nuance. A $9M acquisition from your $18M cash position (50% of your runway) is strategically irreversible in the sense that it commits a massive portion of your dry powder to a single bet. If the integration fails or the revenue doesn't materialize, you cannot easily unwind this. However, you can structure the deal with earnout components or an asset-purchase structure to create some optionality. The board split actually reinforces this: a divided board on a one-way door decision means the decision carries both execution risk AND governance risk.

My read: This is NOT a pure build-vs-buy economic question. It is a growth-dilemma question. You have 30 months of runway, two enterprise deals worth $700k ARR on the line, and a board split. The real question is whether you can afford to lose those two deals while you build — and whether the $9M price tag is justified by those two deals alone (which would be a 12.9x multiple on day one). The answer likely depends on whether SecondLook's three Fortune 500 logos represent $1.2M in contracted revenue or just pilots that haven't converted.

Key questions to answer before deciding

  1. What is the actual revenue composition of SecondLook's $1.2M ARR? Specifically: What portion is pilot/POC revenue vs. contracted annual recurring revenue? Do the three Fortune 500 logos represent meaningful ARR or just logos that haven't converted to material revenue? This determines whether you're buying $1.2M of real revenue or $1.2M of aspirational pipeline.

  2. What is the technical debt and architecture of SecondLook's product? Will your team spend 6 months just cleaning up their codebase, or does their enterprise-readiness extend to code quality and scalability? If their product is a legacy Rails app held together with duct tape, the integration burden eats your runway.

  3. What are the employment terms of the SecondLook founding team? Are they staying for 2 years post-acquisition, or is this a talent acquisition where they walk away after the check clears? A "tired founding team" often means founders ready to exit — which destroys value in an integration.

  4. Can you structure the $9M with meaningful earnout components? If you can tie 30-40% of the price to retention of their customers and team, you create a two-way door. If the sellers demand all-cash at close, you own the full risk.

  5. Will the two enterprise prospects worth $700k actually close if you acquire SecondLook? Have they explicitly said "we'll sign if you have SecondLook's capabilities," or are you assuming? Get a verbal or written commitment before you pay $9M.

  6. What does your engineering capacity look like over the next 12 months? If your current team is at capacity on core product work, building enterprise features in-house may take 18 months, not 12. What is the opportunity cost of diverting engineers from the core product to compliance work?

Recommended frameworks

1. Buy vs. Build Economic Model Apply a total-cost-of-ownership (TCO) comparison. Building enterprise capabilities in-house costs: 2-3 senior engineers × 12 months × fully-loaded cost (~$150k each) = ~$900k in direct costs, plus lost enterprise revenue during the build period. If the two prospects represent $700k ARR and you lose them while building, the real cost of building is $700k in lost ARR + $900k in engineering = $1.6M. The $9M acquisition looks expensive until you factor in the time-to-revenue advantage and the three existing Fortune 500 logos.

2. The Real Options Framework Think of this as buying an option on enterprise growth. SecondLook gives you immediate revenue, SOC 2 Type II (already paid for), three enterprise logos (reducing your sales risk), and a team that already knows enterprise sales. The $9M is not just for revenue — it's for eliminating the 12-month execution risk of building and the risk of losing the $700k in pipeline. The question is: what is that optionality worth to you given your growth rate and runway? At 60% YoY, speed matters more than cost efficiency.

3. The Acquirer’s Dilemma (Valuation Artifacts) At $9M for $1.2M ARR, you're paying a 7.5x multiple. For a company with 60% YoY growth and enterprise traction, that's aggressive BUT not unreasonable if you factor in the strategic premium for: (a) SOC 2 Type II certification, (b) Fortune 500 logos that reduce your enterprise sales cycle, and (c) the two deals worth $700k that close immediately post-acquisition. Run the math: if you keep both $700k deals and add $500k from SecondLook's existing base, you've justified 57% of the purchase price in year one. The rest is strategic premium.

Decision criteria

A good answer to this decision must pass these five tests:

  1. Revenue certainty test: Can you verify that SecondLook's $1.2M ARR is contracted, not pilot-based? If it's mostly POCs, the multiple is meaningless. Require access to their CRM and customer contracts.

  2. Retention test: Do their customers stay post-acquisition? Request their net revenue retention (NRR) metric. If it's below 100%, you're buying a shrinking business.

  3. Integration feasibility test: Can your team absorb 12 new people and a legacy codebase without derailing your current 60% growth trajectory? If your engineering leads say integration takes 6 months, that's 6 months of diverted focus.

  4. Funding adequacy test: After the $9M spend, do you still have 18+ months of runway? $9M leaves you with $9M in the bank. At your current growth rate, you may need to raise again within 12-15 months. The board needs to understand this dilution risk.

  5. Board alignment test: A split board on a one-way door decision is a red flag. Either get the dissenting board members to articulate their specific concerns and address them, or structure the deal so it can be undone (earnout, milestone-based payments). A 3-2 split on a $9M bet is a governance risk, not just a strategic one.

Sources to consult

Given the one-week timeline and no pre-checked sources, here is your prioritized research plan:

  1. SecondLook's actual financials and customer contracts — Request their Stripe/charge records, customer agreements, and NRR data. This is non-negotiable. If they won't provide this in due diligence, walk away.

  2. Reference calls with SecondLook's three Fortune 500 customers — Ask: "Would you expand your usage if SecondLook added [feature]?" and "What's your renewal intent?" This validates whether their logos are sticky.

  3. Technical due diligence on SecondLook's codebase — Have your CTO review their architecture, security practices, and code quality. A SOC 2 Type II certification is not the same as a well-architected product.

  4. Legal review of SecondLook's IP and customer contracts — Are there any exclusive licensing issues? Do their customer contracts have change-of-control clauses that could trigger churn?

  5. Benchmark comparable SaaS acquisitions — Research acquisitions in the $5-15M range in the product-analytics space over the last 24 months. What multiples did they pay? What integration successes/failures occurred? See if you can find a16z or SaaS Capital benchmarks on small-ticket M&A.

  6. Competitive intelligence on your two enterprise prospects — Are they genuinely comparing you to SecondLook, or is this a negotiating tactic? If they've already seen SecondLook's demo, they may be arbitrage-ing your urgency.

Next steps

Given the one-week timeline and board presentation, here is what you should do this week:

  1. Day 1-2: Demand data or walk. Tell SecondLook's founders you need full financial data, customer contracts, and NRR by Wednesday, or the deal is off. A reluctant seller on due diligence is a warning sign.

  2. Day 2-3: Call the two $700k prospects directly. Ask: "If we acquire SecondLook, can we count on signing by end of Q1?" Get a verbal or email commitment. This is your tiebreaker.

  3. Day 3-4: Run the integration scenario with your CTO. Model what happens if 4 of your 12 engineers go on integration for 6 months. Does your core product roadmap slip? If yes, factor that into the $9M cost.

  4. Day 4-5: Present to the board with a recommendation. Given the urgency, I recommend you propose a structured deal: $5.5M at close + $3.5M earnout over 18 months tied to customer retention and team retention. This gives you a two-way door. If the sellers refuse, the answer is no — at that price, you need the protection.

  5. Alternative: Go build. If you can't get the data you need or the price isn't right, go build. Hire two senior engineers with compliance backgrounds, accelerate your roadmap to Q2 (not Q3), and offer the two prospects a preview program. The cost of building is ~$1.2M over 12 months. The risk of overpaying by $8M is worse than the risk of missing Q2.

When to escalate

Stop and get expert help (investment banker, M&A counsel, or external advisor) if any of these signals appear:

  1. SecondLook refuses or delays financial due diligence. If they won't show you contracts, NRR, or cohort data, they are hiding something. Walk.

  2. The founding team plans to exit immediately. If the "tired founding team" means they're leaving after the check clears, you're buying code, not a business. No deal.

  3. Your two $700k prospects are stalling or are revealed to be negotiating with 3+ vendors. If they're not committed, the strategic rationale for $9M collapses.

  4. The integration planning reveals 6+ months of diverted engineering. If your CTO says the core product stalls, the board needs to understand the growth trade-off before proceeding.

  5. The board split cannot be resolved. If you cannot get to a 4-1 or 5-0 vote after addressing specific concerns, proceed with extreme caution. A divided board on a one-way door is how you get a failed integration and a CEO replacement in 18 months.

  6. Runway falls below 12 months post-acquisition. If the $9M leaves you with less than 12 months of runway, you are making a desperation bet. You should not do this deal if it forces a fundraise within 12 months at a potentially down round.

Generated by YourBrief.io. Not financial, legal, or medical advice. Validate with primary research.

Complete sample brief 3 of 4 — click to expand
Sunsetting the legacy on-prem product line

Sunset the on-prem offering — 22% of revenue, declining 15% YoY — to focus the company on the cloud platform, or keep maintaining both?

Read the full brief

Audience: Executive leadership
Timeline: Within 1 week
Framing: This is a two-way door.

The decision

The core question: Should we sunset our legacy on-prem offering ($4.8M, 22% of revenue, declining 15% YoY) to focus the entire company on the cloud platform, or continue maintaining both?

My reversibility read: This is a one-way door, not two-way.

Your heuristic says two-way door, but I disagree given the specifics. Killing the on-prem product mid-contract for three strategic accounts with renewals in 14 months is a decision that likely cannot be undone — those relationships, once poisoned, don't come back easily. The $4.8M revenue is replaceable if cloud conversion works; the strategic account relationships may not be. You should apply one-way-door rigor: this decision needs a definitive answer, but you need to protect against the irreversible damage path. The two-way-door framing only applies if you consider a staged transition (e.g., 12-18 month sunset with committed support) rather than an abrupt kill date.

Key questions to answer before deciding

  1. What are the exact contract end dates for the three on-prem-only strategic accounts, and what are the renewal terms/price sensitivity? If two renew in the next 6 months versus 14 months, your timeline compression changes entirely.

  2. Can the on-prem team be reduced (not eliminated) — e.g., cut from 35% to 15% of engineering through a "security-maintenance-only" release train? This would preserve the strategic accounts while dramatically reducing the drain.

  3. What is the actual NRR lift potential from migrating the on-prem base to cloud? If the three strategic accounts convert at 128% NRR, does the math justify a longer runway even at higher cost?

  4. What does the competitive landscape look like — is on-prem demand collapsing across the market, or is this specific to our product's neglect? If competitors are still selling on-prem successfully, we may be underinvesting rather than the category dying.

  5. What is the contractual obligation exposure if we sunset mid-term? Sales' warning about "poisoning" accounts suggests there may be minimum service terms or implicit renewal expectations that create real liability.

  6. Is there a third path — spin out or sell the on-prem business to a services firm? This would offload the cost while preserving customer relationships (and potentially creating a referral pipeline).

Recommended frameworks

1. The Rigorous Decision Matrix ( Bezos-style) — Weight each option (sunset vs. maintain vs. hybrid) against: revenue impact, strategic account risk, engineering capacity unlock, and competitive positioning. Assign probability-weighted outcomes. For your case: sunset scores well on engineering unlock (+35% capacity) but poorly on strategic account risk (-high probability of losing 2 of 3 accounts). Maintain scores opposite. A hybrid (12-month maintenance mode) scores moderately on all four.

2. The Reverse-Bias Test — Ask: "If I were newly appointed CEO tomorrow and didn't have legacy emotional attachment to either product, what would I do?" For on-prem: declining 15% YoY, 35% engineering for 22% revenue, accelerating churn. The objective answer leans toward exit — but the strategic account concentration creates tail risk that changes the calculus.

3. Options Generation (not just binary) — You're framing this as sunset-or-keep, but the real answer is likely option three: shrink to maintenance mode. What would a 'minimum viable on-prem' look like? Single release train per year, only critical security patches, dedicated but lean support (not bespoke), with explicit migration incentives for the three strategic accounts.

Decision criteria

A good answer must pass these tests:

  1. Does not lose the three strategic accounts in the next 18 months — Any path that triggers premature departure fails. Sales' warning is a real signal, not FUD.

  2. Frees at least 15% of engineering capacity — The 35% allocation is unsustainable if cloud is the future. A valid path must unlock meaningful resources.

  3. Has a clear 24-month financial projection — Either: (a) on-prem revenue declines to $0 with cloud conversion compensating, or (b) on-prem stabilizes at reduced cost with positive margin.

  4. Provides a migration path for on-prem customers — Not just "we're shutting down" — there must be an explicit cloud offer with pricing/terms that make migration attractive (not punitive).

  5. Executive team alignment — Given the timeline (1 week), the decision criteria must be explicit enough that the leadership team can actually decide, not punt to a committee.

Sources to consult

Research plan (since no pre-checked sources provided):

  1. Contract analysis — Pull the exact renewal dates and contract language for the three on-prem strategic accounts. Understand minimum terms, early-termination clauses, and any contractual service-level commitments. Why: This determines your actual flexibility and liability.

  2. Financial modeling — Build a 3-scenario model (sunset, maintain, hybrid) with: on-prem revenue trajectory (apply the 15% YoY decline), cloud conversion rates from on-prem base, engineering cost allocation, and margin impact. Why: You need hard numbers to present to exec leadership in one week.

  3. Sales intelligence — Interview the account reps for the three strategic on-prem accounts. Get specific: What would they do if we announced sunset? What would it take to migrate them? Is there a competitive incumbent waiting if we exit? Why: Sales' warning is a hypothesis — validate or invalidate it with evidence.

  4. Engineering capacity data — Quantify what the 35% engineering allocation actually covers. How much is net-new feature work vs. bug fixes vs. security patches vs. bespoke customer work? Why: You may find that 20% of that 35% is unnecessary if you shrink the scope.

  5. Market research — Check if competitors (e.g., [relevant competitors based on your product category]) still sell on-prem. Are enterprise customers broadly abandoning on-prem, or is this a company-specific issue? Why: Determines if you're exiting a dying market or creating a self-fulfilling prophecy.

  6. Customer success data — What has been the actual experience of on-prem customers who have churned? Is it product-related (we stopped innovating) or category-related (they moved to cloud regardless)? Why: Informs whether migration incentives would work.

Next steps

This week's concrete actions:

  1. Monday: Request contract data for the three strategic on-prem accounts — exact renewal dates, terms, and any termination clauses. This is the single most important data point.

  2. Tuesday: Commission the engineering lead to model a "maintenance mode" on-prem scenario — what does it look like to reduce from 35% to 12-15% of engineering with a single annual release train and only critical patches?

  3. Wednesday: Conduct 30-minute interviews with the three strategic account reps. Script: "If we announced a 12-month sunset with a cloud migration offer, what would [account] likely do?"

  4. Thursday: Build the 3-scenario financial model with your FP&A partner. Bring to exec meeting.

  5. Friday: Exec leadership decision meeting.

My provisional recommendation: Do NOT do an abrupt sunset. The strategic account risk is too high and the timeline too compressed. Instead, propose a 12-18 month phased transition: (a) immediately reduce on-prem engineering to maintenance mode, (b) initiate migration conversations with the three strategic accounts with a compelling cloud offer, (c) set a public end-of-support date 18 months out, (d) measure conversion rate at 6 months and adjust. This unlocks engineering capacity, protects relationships, and gives you optionality.

When to escalate

Escalate immediately if any of these become true:

  1. Any of the three strategic accounts signal they will not renew under any sunset scenario — This means the risk is not manageable; you need board-level or special-situation expertise.

  2. Engineering cannot deliver a viable maintenance-mode scope — If they say "we can't go below 30% without compromising security compliance," the cost calculus changes fundamentally.

  3. Legal flags significant early-termination liability — If sunsetting triggers penalty clauses that exceed the revenue benefit, you need counsel.

  4. Cloud pipeline data deteriorates — If the 128% NRR or cloud growth slows, the math for "invest in cloud and exit on-prem" breaks down. You need to see Q3 pipeline before committing.

  5. Two or more execs disagree strongly — Given the 1-week timeline, if you don't have near-consensus by Thursday, escalate to the CEO for a deciding vote. This is a one-way-door decision — it needs clear ownership and cannot be committee-ed to death.

Generated by YourBrief.io. Not financial, legal, or medical advice. Validate with primary research.

Complete sample brief 4 of 4 — click to expand
Entering the AI coding-agents market

Build a vertical AI coding agent for security & compliance testing, or compete horizontally against Copilot and Cursor?

Read the full brief

Audience: Executive leadership
Timeline: Within 1 week
Framing: This is a one-way door.

The decision

The decision: Whether to build a vertical AI coding agent focused on security and compliance testing, or compete horizontally against Copilot and Cursor in the general AI coding assistant market.

My reversibility read: This is correctly characterized as a one-way door — but with a caveat. Given your 6-month runway, the decision is effectively one-way because you lack the capital to iterate across positioning after committing engineering resources. A horizontal play requires competing on code completion quality and IDE integration against teams with 100+ engineers and years of iteration. A vertical play requires deep security domain expertise and enterprise sales cycles. You cannot do both with six engineers and six months of fuel. Choose the lane where your existing expertise creates the largest leverage multiplier.

Key questions to answer before deciding

  1. Do you have explicit inbound enterprise interest, or just expressed frustration from developers using general tools? The difference between "people complain about security gaps" and "security leaders are actively evaluating solutions" determines whether you have a market or a hypothesis.

  2. Can you name 10 specific compliance frameworks your target buyers must satisfy? If you cannot articulate which specific audits (SOC2, HIPAA, PCI-DSS, FedRAMP) your tool would help pass — not just mention — you do not yet have vertical differentiation.

  3. What is your team's existing codebase and demos that prove security-agent feasibility? With six months of runway, you need more than domain knowledge. You need a working prototype that security buyers can see to validate willingness-to-pay.

  4. Do you have any enterprise sales capability or channel partners? Vertical plays in security require landing enterprise accounts, which have 6-12 month sales cycles. Your six-month runway may not survive the sales cycle even if the product works.

  5. What specific security tasks does Copilot fail at that your tool would solve? Generic "it doesn't handle security well" is insufficient. Identify the specific vulnerability classes, scanning gaps, or compliance workflows where a specialized tool would demonstrably outperform.

  6. If you chose vertical, could you survive 12 months without revenue? Enterprise security sales will likely exceed your runway. You need a clear plan for bridge financing or a different revenue model (developer-seat licensing vs. enterprise contracts).

Recommended frameworks

1. The Bear Hug Framework (Vertical vs. Horizontal)

Apply: Horizontal plays require winning on breadth — matching Copilot's code completion quality across all languages and contexts, then adding one differentiator. Your six engineers cannot out-iterate Microsoft's investment. Vertical plays require winning on depth — being 10x better at a specific task than a generalist. Your security backgrounds mean you understand what security teams actually need in their workflow. The question: Can you identify one security workflow (e.g., finding OWASP Top 10 vulnerabilities in PRs, generating compliance evidence) where your tool would be unmistakably superior within 3 months? If yes, vertical. If you can only say "we're better at security generally," that's horizontal with a marketing claim.

2. The Mom Test (Customer Validation)

Apply: Before building, you need to answer: Has a specific security leader (not a developer) explicitly said they would pay for this? Have you shown them even a mockup? The "enterprise buyers keep asking" signal is weak — it could mean one buyer at a conference mentioned it. You need three specific personas (e.g., CISO, DevSecOps lead, compliance officer) who have told you their current pain point in enough detail that you could build a demo for them tomorrow.

3. Runway-Adjusted Strategy (Capital Efficiency)

Apply: With six months of runway, you have approximately 3-4 months of product-building time before you need either revenue or a lead. A vertical security play likely requires enterprise sales (longer cycles), but could command higher prices. A horizontal play could find faster developer adoption but faces brutal competition. Your constraint is not which market is larger — it's which market you can actually monetize within your capital timeline.

Decision criteria

A good answer to this decision must pass these specific tests:

  1. The 3-Month Demo Test: Can you build a working prototype within 3 months that a security buyer would actually want to see? If not, the vertical play is aspirational, not viable.

  2. The Specificity Test: Can you name the exact security vulnerability category or compliance workflow your agent will automate? "Security and compliance" is too broad. "Finds and explains SQL injection vulnerabilities in PR before merge" is specific enough.

  3. The Pricing Signal Test: Have you talked to at least three potential enterprise buyers about what they would pay? Security tools command premiums — you need to know if your target is $20/seat/month or $200/seat/year.

  4. The Differentiation Test: If Microsoft adds a "security mode" to Copilot tomorrow, what remains of your moat? If the answer is only "we were first," you have no durable advantage. Your deep security expertise must translate into model behavior or workflow integration that is structurally hard for Copilot to replicate.

  5. The Runway Survival Test: Even in your most optimistic revenue scenario, can you extend runway or secure bridge financing to survive the enterprise sales cycle? If not, you need a horizontal or freemium pivot to get to revenue faster.

Sources to consult

Research Plan (Priority Order):

  1. Interview 5-8 security engineers/devs at enterprises (not startup developers) to validate: Do they actually want an AI coding agent for security, or do they use separate static analysis tools (Snyk, Semgrep, Checkmarx)? What would make them switch? Use the Mom Test — ask about specific frustrations with current workflows.

  2. Analyze Copilot and Cursor's current security capabilities — review their documentation, changelogs, and community feedback. Identify the specific security gaps your vertical play would address. If their roadmap shows they're already closing those gaps, your timing may be off.

  3. Map the competitive landscape for security-specific devtools — who else is building in this space? LangChain has security agents, Snyk has AI features, new startups are emerging. List the top 5 competitors and their positioning.

  4. Talk to 2-3 enterprise security buyers about procurement: What does their vendor evaluation process look like? How long from "interested" to "contract signed"? This directly impacts your runway math.

  5. Review YC/WGE portfolio companies that have taken vertical vs. horizontal positioning in devtools — what worked, what ran out of runway, and why?

Next steps

Execute within 7 days:

  1. Day 1-2: Identify and reach out to 5 security engineers/devs at mid-to-large enterprises. Conduct 15-minute calls using the Mom Test framework. Document specific pain points, not general frustrations.

  2. Day 3-4: Draft a one-page product concept for the vertical play — specify exactly what the agent does (e.g., "reviews PRs for OWASP Top 10 and generates compliance evidence"). Show this to your interview subjects and gauge reaction.

  3. Day 5: Run the numbers. If vertical: what price point, what sales cycle, do you need bridge financing? If horizontal: what is your specific differentiation against Copilot, and can you win on any dimension with 6 engineers?

  4. Day 6-7: Make the call. The recommendation based on your constraints: Vertical is the only viable path — your team of 6 with deep security backgrounds cannot out-compete Microsoft on general code completion, but you can own a specific security workflow if you can validate buyer interest and build a demo within 3 months. The horizontal play is effectively a death march against well-funded incumbents.

When to escalate

Escalate immediately if:

  1. You cannot find 3 enterprise security buyers willing to talk within one week — this signals the market may not exist yet or you're not reaching the right personas.

  2. Your technical founders cannot agree on the core agent architecture — if your team is split on whether the vertical approach is technically feasible, you need an external technical advisor before committing runway.

  3. No clear path to revenue appears possible within 9-12 months (including bridge financing) — you should pause and explore grant funding (NSF, SBIR), accelerator programs, or a services pivot that generates cash flow while you build.

  4. A well-funded competitor announces a security-specific AI coding agent — if Microsoft, Anthropic, or a well-funded startup (e.g., a $50M+ raise) launches in your exact niche, your positioning becomes significantly harder.

  5. Any buyer signals they would wait for Copilot to add the feature rather than pay for a specialized tool — this means you may be building a feature, not a product.

Generated by YourBrief.io. Not financial, legal, or medical advice. Validate with primary research.

Ready to get your own brief?

Submit your topic and get a structured, actionable brief within 24 hours — usually much faster.

Get your first brief for $1 (first 20 only)