Lead Scorer

The SaaS Distribution Course #6: How Notch Grew ARR 12x After Its Original Market Said No

A practical course on Notch's enterprise distribution system: reject education-heavy markets, map relationship paths, qualify paid POCs, prove generic requirements, and expand from production evidence.

By Miljan @ Lead Scorer 20 min read

TL;DR

Notch says its annual recurring revenue grew 12x in 12 months. The starting and ending ARR are not public, so treat that as a company and lead-investor reported milestone, not an audited result. The reusable lesson is the distribution sequence underneath it.

Notch first sold insurance for creators and digital assets. People called the idea clever, but the founder says buyers did not feel enough urgent pain. The team later turned an internal AI operations tool into enterprise software, moved from e-commerce toward regulated financial services, used relationships to reach dream accounts, and converted serious opportunities through business-owned proofs of concept. One late-entry POC became a contract worth a little more than $1 million per year, according to the founder.

The system is market-pull gate → operator proof → relationship access → paid POC → generic requirements → production evidence → vertical expansion. The warning is equally important: a logo, technical champion, or impressive demo is not a distribution system. Without budget, a business owner, success criteria, and a route to a contract, a POC is unpaid product theatre.

Typographic cover for The SaaS Distribution Course number 6, highlighting Notch's company-reported 12x ARR growth after its original market said no.
Notch's documented sequence moved from a demand-light insurance offer to an existing-budget AI wedge, relationship-led account access, qualified enterprise proof, and a narrow regulated-industry position. The 12x ARR milestone is company and investor reported.

What you will build

You will build five operating assets: a market-pull scorecard, a 25-account relationship map, a POC qualification sheet, a generic-versus-custom evidence ledger, and a production-reference gate. Together they answer one question: should you invest scarce founder and engineering time in this account, or stop before enthusiasm becomes bespoke work?

Use this system if

  • your product sells to an enterprise with a measurable operational workflow;
  • several people influence access, evaluation, security, budget, and deployment;
  • a buyer needs proof before signing a meaningful contract;
  • the same product requirements can recur across a narrow vertical.

Do not use it if

  • a user can evaluate and buy the product safely in a self-serve session;
  • you cannot define the cost, risk, or budget attached to the workflow;
  • every account needs a different product architecture;
  • your proof would touch sensitive data without governance and written permission.

Verified case snapshot

StageEvidenceLimit
2021Notch began as a specialty insurer for digital assetsCompany history and independent profiles agree on the origin
July 2022TechCrunch reported creator-account hack insurance approved in five U.S. statesThe founder later says the product reached 47 states
2023The team converted an internal policyholder-service system into enterprise AI softwareThe precise pivot month is not public
Lean rebuildThe founder says Notch kept two engineers, had $2M left, and burned $10K-$20K per monthFounder-reported, not audited
Enterprise proofA late-entry POC became a contract slightly above $1M per yearThe customer is unnamed and the contract is founder-reported
March 2026Notch reported 12x ARR growth in 12 months and raised a $30M Series AGrowth is company/investor reported; funding is independently corroborated
Current positionInsurance, financial services, telecom, and other regulated operationsNo public channel attribution or customer ledger

The model: every stage must earn the next commitment

Notch's story can be misread as “pivot into AI, then ride the wave.” That removes the hard work. AI created interest, but interest did not choose the customer, open the account, qualify the test, survive security, or prove that the product could repeat.

Each stage created an asset required by the next. Operating an insurer created domain evidence. A workflow with obvious labor economics created budget. Relationships created access. A paid, business-owned POC created buying evidence. Generic requirements created repeatability. Production created credibility for the next regulated account.

This is the central decision rule: do not advance an account because the conversation feels warm; advance it only when the buyer contributes a harder commitment. That commitment can be an owner, data, budget, security time, a success metric, or a contract path. Compliments are not a stage.

Step 1: reject markets that require you to manufacture urgency

In the podcast, Rafael Broshi says the original insurance product sounded ingenious but did not solve enough urgent pain. The team had completed real regulatory work. That competence did not create demand.

Score a candidate market from zero to two on each question:

  1. Is a named operator accountable for the workflow today?
  2. Is there an existing budget, headcount, loss, or compliance exposure?
  3. Did a recent technology, regulation, or cost change increase urgency?
  4. Can the buyer measure a result inside 90 days?
  5. Are buyers already evaluating alternatives?

Pass condition: at least eight out of ten, including an owner and present budget. Stop condition: the pitch begins with a long explanation of why the problem should matter. Education can support distribution; it cannot replace buying pressure.

Step 2: choose one budgeted workflow, not a fashionable category

Notch considered AI for sales, marketing, and customer support. The team chose customer operations because it had operated that workflow and could express the value through staffing, availability, accuracy, and service quality. It first sold into e-commerce, then narrowed toward insurance and financial services where auditability, deployment control, and traceability were harder requirements.

Complete this worksheet:

  • Operator: ______
  • Weekly workflow: ______
  • Current annual cost or exposure: ______
  • Budget owner: ______
  • Trigger in the next 6-12 months: ______
  • Result measurable in 90 days: ______
  • Governance boundary: ______

Pass: five target accounts share the owner, trigger, measurement, and deployment constraint. Stop: the accounts share an industry label but not a buying process.

Step 3: map relationship paths into 25 dream accounts

Broshi's enterprise-access advice is direct: use investor, employee, friend, and family networks, then keep building connections at several levels. An executive introduction can create air cover. It cannot substitute for the working owner who supplies requirements and lives with the result.

For each account, map four roles:

RoleJobEvidence required
Executive sponsorMakes the problem importantPublic priority or warm path
Business ownerOwns outcome and budgetWorkflow, baseline, decision authority
Technical ownerValidates architecture and dataIntegration and security constraints
OperatorUses or receives the resultCurrent behavior and exception cases

Ask every helpful person for one specific path, not a general endorsement: “Who owns [workflow] at [account], and would you introduce us around [documented trigger]?”

Threshold: ten of 25 accounts need a documented trigger, named business owner, and at least one credible path. If fewer pass, change the account set before paying for contact data or sending broad outreach.

Step 4: qualify the POC before engineers begin

Notch learned this through a failed pseudo-POC. A technical contact supplied documents and liked the capabilities, but there was no business need behind the exercise. The work looked like enterprise progress until the evaluation ended without a buying process.

A real POC has all eight fields:

  1. business owner and executive sponsor;
  2. one bounded production-relevant use case;
  3. approved data and governance rules;
  4. current baseline;
  5. three to five measurable success criteria;
  6. budget or paid evaluation fee;
  7. decision date and procurement path;
  8. written next step if the proof passes.

The founder uses $50,000 as an example of pricing a serious POC. That is not a disclosed Notch price and not a universal benchmark. The rule is to charge enough that the buyer allocates real attention and both sides can define what is being purchased.

Pass: eight of eight fields, signed by the business owner. Stop: a technical team wants to “see what is possible” without budget, baseline, or a route after success.

Step 5: prove a product, not your willingness to become a dev shop

The decisive Notch POC tested thousands of cases and required multiple fixed versions. The team entered late and worked through a weekend, but Broshi says it won through requirements that applied across regulated organizations: accuracy under complexity, audit trails, deployment controls, and production readiness.

Maintain two columns during every proof:

  • Generic: a requirement expected in at least three accounts in the chosen segment.
  • Specific: code, data transformation, or workflow unique to this buyer.

Pass condition: at least 70% of engineering time improves the reusable product, and two other qualified accounts recognize the same requirement. Stop condition: customer-specific work dominates two consecutive sprints without a separately priced service boundary.

Step 6: turn production evidence into a narrow vertical position

A won POC is not the finish. Enterprise production adds SLAs, security reviews, incident paths, support capacity, and penalties. Broshi calls winning the contract the easiest part of working with an enterprise. The distribution asset appears when the deployment becomes evidence another account can trust.

Create a reusable proof packet:

  • buyer problem and baseline;
  • test design and governance boundary;
  • generic requirements passed;
  • result, limits, and exceptions;
  • production operating model;
  • approved reference language;
  • next account with the same constraints.

Expansion gate: two production accounts share the same owner, workflow, generic requirements, and buying path. Only then add account volume or an adjacent workflow.

What failed, and why

Market education failed structurally. The original insurance offer required Notch to create urgency around a new category. Regulatory execution could not solve weak demand.

The pseudo-POC failed procedurally. A technical contact evaluated documents, but there was no business owner, budget, or commercial next step. The test was real; the opportunity was not.

The logo ladder is premature timing. Founders often assume they must win smaller brands before approaching dream accounts. Broshi argues that one enterprise with urgent pain may work with a startup while 90 others will not. The useful filter is present need and willingness to commit, not company size alone.

Customization is a structural limit. Speed helps a startup enter an enterprise, but unlimited customization can hide the absence of a product. Separate reusable requirements from paid services before one large customer controls the roadmap.

Your 30-day implementation plan

  • Days 1-3: score three markets for owner, budget, trigger, measurability, and active evaluation.
  • Days 4-6: choose one workflow and write the governance boundary.
  • Days 7-10: build 25 account rows and map four buying roles.
  • Days 11-14: find two dated signals and one relationship path for the ten best accounts.
  • Days 15-18: run discovery with business and technical owners; do not promise a POC yet.
  • Days 19-21: complete the eight-field POC sheet with one qualified account.
  • Days 22-24: price the proof and agree on success, decision, and production path.
  • Days 25-27: design the generic-versus-specific ledger and data controls.
  • Days 28-30: start only after the gate passes; otherwise record the missing commitment and stop.

Lead Scorer implementation: build the account system before outreach

This implementation fits narrow enterprise SaaS where public signals and relationship paths can identify accounts with an active workflow. It does not fit when the market-pull score is weak or the product still needs a different architecture for every prospect.

Phase 1: define the gate

Run $icp-offer-context with the operator, workflow, current cost, trigger, generic requirements, governance boundary, and claims you may make. Then run $icp-scoring-rubric. An 8-10 account needs fit, a dated trigger, a named business owner, measurable value, and a plausible relationship path. Scores 6-7 go to watch. Scores 1-5 stop.

Copyable prompt: “Create a 1-10 rubric for enterprises that own [workflow]. An 8+ requires a dated trigger, named business owner, measurable 90-day value, regulated deployment fit, and one credible access path. Return disqualifiers and the evidence required for every point.”

Pass: two operators score the same five accounts within one point. Do not source leads while the rubric produces inconsistent results.

Phase 2: separate account paths

Use $daily-vertical-prospecting for a 25-account set and $signal-research-dossier for two dated sources per account. Keep four lists: relationship path, signal-led cold, active POC, and stop. Never combine their reply or conversion rates.

Record the executive sponsor, business owner, technical owner, operator, trigger, evidence URL, relationship source, and missing commitment. Use create_audience_source only when a relevant event, expert post, or public conversation reveals a real audience. Engagement alone is not pain.

Credit gate: run contact discovery or enrichment only for 8+ accounts. Use a dry run, review estimated credits, then confirm the keepers. A large unqualified list makes this motion worse.

Phase 3: draft the account-specific ask

Run $contact-discovery for the named owners, then $cold-email-first-touch for the cold segment. For warm paths, draft an introduction request that names the workflow and trigger. Create only a draft campaign, preserve list separation, and run $outreach-qa-audit. Every message needs human review before any activation or send.

Copyable ask: “We saw [dated trigger] and believe it affects [owned workflow]. Before discussing a POC, could we validate the current baseline, owner, constraints, and decision path? If there is no active project or measurable outcome, we will stop.”

Pass: the buyer introduces the business owner and shares a baseline or decision process. Stop: the reply offers only a generic innovation conversation.

Phase 4: make objections compound

Classify every reply with $reply-triage: no pain, wrong owner, no budget, timing, security, proof design, or custom requirement. Put repeated objections and sanitized proof into Content Studio. Useful evidence can attract new signal audiences, but those people return to the same score before outreach.

Lead Scorer can organize research, scoring, enrichment, draft creation, and feedback. It cannot invent market pull, approve sensitive data use, declare a POC successful, activate a campaign, or replace the founder's judgement. Human approval remains mandatory at contact-credit, campaign, POC, and production gates.

Saveable checklist

  • One workflow with a named owner and present budget.
  • Five accounts sharing the same trigger and buying process.
  • Twenty-five accounts mapped across four buying roles.
  • Separate relationship, cold, POC, and stop lists.
  • Eight required POC fields before engineering begins.
  • At least 70% of proof work improves the reusable product.
  • Two production accounts before scaling the vertical.
  • Human approval before credits, outreach, POC data, and production.

Sources and limits

The main source is Rafael Broshi on A Product Market Fit Show, published 3 August 2026. The complete local transcript was audited in eight adjacent windows from character 0 to 54,523.

Notch's Series A announcement and Headline's investment announcement report the 12x ARR milestone. Ynet and Calcalist independently corroborate the funding, founders, company origin, and current vertical focus, but repeat the growth figure as a company claim.

TechCrunch's 2022 report confirms the original creator-insurance product and five-state availability at that date. The founder later says the product reached 47 states; both can be true at different points. The episode gives no complete customer chronology, channel attribution, POC win rate, CAC, gross margin, retention, NRR, payback period, or audited ARR. Copy the gates and evidence system, not the undisclosed economics.

Frequently asked questions

Did Notch publicly disclose its ARR?

No. Notch and its lead investor reported 12x ARR growth over 12 months, but neither the starting nor ending ARR is public and the figure is not independently audited.

What makes an enterprise POC real?

A real POC has a business owner, budget, a defined use case, test data, measurable success criteria, a decision date, and an agreed path after success. A technical demo without those elements is product evaluation, not a buying process.

Did Notch grow by doing custom development for one insurer?

The founder argues the opposite. The decisive POC tested generic regulated-enterprise requirements such as accuracy, auditability, on-premise deployment, and scale. The unnamed contract and its repeatability remain founder-reported.

Does the $30 million Series A prove the distribution system worked?

No. Independent reporting corroborates the funding round, but financing is context rather than channel evidence. The useful evidence is the sequence from market-pull selection to qualified proof and production deployment.

Keep reading