Lead Scorer

The First 100 Customers Course #4: How Peregrine Turned a Design Partner Into a $100,000 Licence

A step-by-step course for earning a first enterprise design partner through account research, manual delivery, proof, and peer referral before scaling sales.

By Miljan @ Lead Scorer 19 min read

TL;DR

Peregrine did not enter its first police department with a finished product. The two founders mapped Bay Area agencies, studied commanders and their past cases, contacted many people, and found one operator willing to let them help. They then worked as free crime analysts inside San Pablo Police Department for 12 to 18 months while turning repeated data work into software.

The first independently documented commercial milestone is concrete: San Pablo approved a one-year Peregrine software licence for $100,000 on 17 December 2018. The same public record says the service kept renewing. The founder says the next city arrived after one police chief recommended Peregrine to another.

The mechanism was account evidence → operator fit → bounded service → embedded work → proof event → paid licence → peer referral. The warning matters as much as the result: free work without access, a proof definition, governance, and a conversion gate is consulting debt, not distribution.

What you will build

You will build a first-enterprise-customer system for a product that is still too early to sell through a polished demo. The output is a 20-account map, five evidence-rich operator dossiers, one bounded design-partner offer, a manual delivery protocol, a proof scorecard, a paid-conversion gate, and a peer-referral request.

Who this is for

Use this when the buyer owns a high-value operational problem, the workflow is hard to understand from the outside, and you can safely perform part of the job manually. It fits vertical SaaS, data infrastructure, security, compliance, operations, and enterprise AI where trust and implementation are part of the product.

Do not use it when free delivery would expose sensitive data without a legal basis, when a mistake could cause material harm, or when the account cannot supply a named operator and a real workflow. Peregrine's category also carries civil-rights and privacy risks. Copy the customer- learning mechanism, not the policing use case, and add the governance required by your market.

Case snapshot

StageWhat happenedEvidence limit
2017Peregrine started with a broad public-sector data thesisFounder-reported; Fortune confirms the origin story
First agencySan Pablo Police Department accepted the founders as design partnersFounder names it as the first agency
12–18 monthsFounders worked cases on site and built software from repeated manual workFounder-reported; the episode title rounds the period to one year
17 Dec. 2018San Pablo approved a one-year software licence for $100,000Primary city record; not proof no other agency paid earlier
Next customerA neighboring city arrived through a chief-to-chief recommendationFounder-reported; city is not named in that claim
First 3–4 yearsGrowth remained slow and word-of-mouth ledNo full customer or channel series
LaterFounder reports a $1m, $3m, $10m ARR progression and about $250,000 current average ACVFounder-reported; dates and audited figures absent
June 2026$250m Series D at a $6.8b valuationIndependently reported by Fortune; not early-channel proof

The model: borrow credibility from the work

An unknown founder asking an enterprise to buy software starts with a credibility deficit. The buyer risks budget, implementation time, security review, and personal reputation. A generic demo does not remove that risk. Peregrine replaced borrowed brand credibility with evidence of preparation and useful work.

Typographic cover highlighting Peregrine's design-partner path to a documented $100,000 licence
Peregrine turned embedded design-partner work into a documented $100,000 software licence.

The sequence compounds only if every stage produces an asset for the next one. Account research produces a relevant approach. Manual work produces workflow knowledge. A proof event produces a buying case. A paid deployment produces a reference. Repeated implementation work produces a product and deployment playbook.

Step 1: choose a market where access creates an advantage

Peregrine's founders already knew that government work was slow and bureaucratic. They still chose it because data fragmentation was severe, the work mattered, and direct access could reveal context that an outside product team would miss. Your first market needs a similar reason to go deep.

Complete this market-access worksheet:

  • Operational job: ______
  • Cost or risk of the current failure: ______
  • Data, workflow, or vocabulary invisible from outside: ______
  • Operator who experiences the problem weekly: ______
  • Safe manual contribution you can make: ______
  • Legal, security, ethical, and permission boundary: ______

Pass condition: access to one real workflow would change what you build. Stop condition: the account is attractive only because its logo would look good.

Step 2: build a 20-account evidence map

The founders did not search for every police chief. They mapped East Bay cities, examined the organization chart, focused on the number two or three, looked for technology orientation, and studied cases each person had handled. The goal was not personalization theatre. It was finding an operator already close to believing the proposed collaboration could help.

FieldWhat to recordReject when
Account conditionVisible workload, change, failure, deadline, or mandateOnly firmographic fit exists
Operator fitOwns the workflow and can sponsor accessContact is senior but distant from the job
Public evidenceTalk, case, filing, technical post, job, or projectThe message would rely on a compliment
ContributionOne safe result you can help produce manuallyThe only offer is a product demo
GovernanceApproval, data scope, retention, access, audit, and exitThe founder must improvise with sensitive data

Metric: five of 20 accounts must contain a named operator, a dated problem signal, and a credible manual contribution. If fewer qualify, change the segment before enriching more contacts.

Step 3: ask for a working session, not faith in a product

Peregrine had no prescriptive solution. Its approach was to learn how the operator worked and help solve cases. Commander Brian Bubar responded after the founders referenced a specific case he had worked on. Many other people had already said no.

Use this structure:

We studied [specific public workflow or priority]. It appears [documented constraint] makes [owned outcome] harder. We can contribute [bounded manual result] for [short test period]. No platform migration is required. If useful, could we map the workflow with the person who runs it?

The ask is access to a real job, not indefinite free consulting. Pass: the operator provides a workflow, owner, inputs, permission boundary, and test date. Stop: the contact offers only general feedback, asks for speculative development, or cannot approve access.

Step 4: run a governed manual deployment

The founders initially performed the crime-analyst job and wrote software as patterns emerged. That is different from shadowing. They accepted responsibility for a bounded contribution and observed the real files, exceptions, vocabulary, and handoffs.

  1. Write the outcome and explicit non-goals.
  2. Name the operator, approver, data owner, and escalation path.
  3. Limit access, retention, and use before touching customer data.
  4. Perform the workflow manually and log every action, wait, correction, and judgement.
  5. Mark repeated work separately from customer-specific work.
  6. Review evidence weekly with the operator.

A 12-to-18-month free embed is not a default recommendation. Start with two weeks. Extend only when a new period has a named learning objective, the buyer supplies meaningful access, and a commercial decision date exists. Otherwise stop.

Step 5: define the proof event before building

Peregrine's product-market-fit moment was not a feature release. A detective team called the founders into a difficult existing case, their work helped move it forward, and they later served as expert witnesses. The founder treated that operational reliance as proof that the system was useful.

Your proof scorecard needs four lines:

  • Behavior: the operator uses or requests the workflow without a founder reminder.
  • Outcome: a measurable task becomes faster, safer, cheaper, or newly possible.
  • Repeat: the same result appears in at least three comparable jobs.
  • Buying evidence: a budget owner agrees on scope, price, and procurement path.

Pass: all four are visible. Stop: users praise the effort but do not change behavior, repeat the workflow, or open a buying process.

Step 6: convert repeated work into a paid deployment

San Pablo's council record gives the milestone the interview cannot: on 17 December 2018 the city approved $100,000 for one year of software, mobile applications, training, integrations, product development, and support. The bundle matters. The first commercial product was not pure software; it combined software and successful deployment.

Price the smallest complete outcome:

  • licence or recurring access;
  • implementation and data integration;
  • training and adoption owner;
  • support and incident path;
  • renewal measure and review date.

Conversion gate: do not extend the free period unless procurement has an owner, a written next step, and a decision date. A design partner who never confronts price has not validated a market.

Step 7: earn one peer introduction before scaling outbound

The founder says Peregrine's next customer was the city next door because one chief told another chief the team was trustworthy and useful. In a high-trust network, the first successful account is also the first distribution asset.

Ask only after the proof review:

Which peer owns the same workflow and would benefit from seeing the evidence? Would you be comfortable introducing us with the result, the limits, and the work still required?

Track introductions, meetings, accepted pilots, and paid conversions separately. Do not call all word of mouth organic. It compounds because customer success makes a specific recommendation safe.

What failed, and what changed later

Most first approaches still failed. The founders had no brand, product, or proof. Research moved one operator far enough to take the risk; it did not create a high response rate. The company then grew slowly for three or four years. This is a depth strategy, not a fast-volume hack.

Deployment also created a structural limit. Engineers were integrating data instead of building the core product. Peregrine responded by creating integration tooling and a deployment-strategy function. Later, it simplified the message, hired account executives across regions, worked nine-to-twelve-month sales cycles, and prepared deeply for RFPs. Founder-led learning became a playbook only after repeated customer evidence existed.

Your 30-day implementation plan

  • Days 1–3: choose one workflow and write the governance boundary.
  • Days 4–7: map 20 accounts and five operator dossiers from dated public evidence.
  • Days 8–10: send five service-oriented approaches; record every rejection reason.
  • Days 11–14: scope one two-week manual test with inputs, permissions, outcome, and stop date.
  • Days 15–21: do the job, log repeated work, and review evidence with the operator.
  • Days 22–24: automate only the most repeated safe step.
  • Days 25–27: run the proof scorecard and present the smallest paid deployment.
  • Days 28–30: secure a decision or stop; after a win, ask for one peer introduction.

Lead Scorer implementation

This motion fits Lead Scorer when the target accounts and operators can be identified from public evidence. It does not replace security review, procurement, manual delivery, or founder judgement.

  1. Run $icp-offer-context. Store the workflow, trigger, operator, disqualifiers, safe manual contribution, and claims you may make.
  2. Run $icp-scoring-rubric. Require account fit, operator ownership, dated evidence, and an access path. Set 8–10 to research, 6–7 to watch, and 1–5 to stop.
  3. Use $daily-vertical-prospecting for a 20-account list, then $signal-research-dossier for at least two dated sources per operator.
  4. Keep design-partner, peer-referral, watch, and stop lists separate. Do not blend their conversion rates.
  5. Run $contact-discovery only for 8+ operators after the credit dry run and human confirmation.
  6. Use $cold-email-first-touch to draft the bounded working-session ask, then $outreach-qa-audit. Review every message.
  7. Create only a draft campaign. Human approval and activation remain mandatory; delivery and procurement stay outside the agent.

Copyable prompt: “Build a 1–10 rubric for operators who own [workflow]. An 8+ requires account fit, a dated public priority, evidence the person owns the work, and one safe manual contribution. Return 20 accounts, five dossiers, and separate design-partner, referral, watch, and stop lists. Do not enrich or contact anyone.”

Put every rejection, objection, and manual-work pattern into Content Studio. Turn repeated misconceptions into useful evidence, capture people who engage with that evidence, rescore them, and return only qualified signals to reviewed outreach. The loop is research → manual proof → useful evidence → peer signal → qualified conversation.

Checklist

  • One narrow operational workflow.
  • Twenty accounts, five evidence-rich operators.
  • One bounded contribution, not a generic demo.
  • Written legal, data, ethical, and permission gates.
  • Two-week default test with an explicit stop date.
  • Behavior, outcome, repeat, and buying proof.
  • Paid scope includes deployment work.
  • One peer introduction after verified success.
  • Repeated manual work becomes product or playbook.
  • Every outbound message reviewed by a human.

Sources and limits

The operating story comes from Ben Rudolph's complete interview on The Product Market Fit Show, published 27 July 2026. The locally stored transcript was audited contiguously from character 0 through 49,220.

The San Pablo City Council record independently confirms the December 2018 $100,000 licence and later renewals. Fortune confirms the June 2026 financing and reports the company's current scale claims.

Privacy and governance are not side notes. Axios documented public concerns in a later procurement, while the Brennan Center describes category-level data-fusion risks. These sources do not allege wrongdoing in the first San Pablo deployment; they establish why an access, oversight, and civil-rights gate is necessary.

The interview does not provide an outreach count, early conversion rate, complete customer chronology, or audited ARR series. San Pablo is the first named agency and design partner, but the public record does not establish that it was Peregrine's first paying customer. Reproduce the evidence ladder and its stop conditions, not the later valuation.

Frequently asked questions

Was San Pablo Peregrine's first paying customer?

San Pablo was the first agency and design partner named by co-founder Ben Rudolph. A city record confirms a $100,000 one-year licence approved in December 2018, but it does not prove that no other agency paid Peregrine earlier.

How long did Peregrine work inside the first police department?

Rudolph gives a 12-to-18-month range in the interview and later says 18 months. The episode title rounds this to one year, so this course preserves the founder's fuller range.

What should an early SaaS founder copy?

Copy the sequence: research a narrow account, contact an operator with a documented problem, offer a bounded manual outcome, define a proof event, convert repeated work into product, and ask for one peer introduction. Do not copy the unusually long free engagement without strict gates.

Keep reading