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.
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
| Stage | What happened | Evidence limit |
|---|---|---|
| 2017 | Peregrine started with a broad public-sector data thesis | Founder-reported; Fortune confirms the origin story |
| First agency | San Pablo Police Department accepted the founders as design partners | Founder names it as the first agency |
| 12–18 months | Founders worked cases on site and built software from repeated manual work | Founder-reported; the episode title rounds the period to one year |
| 17 Dec. 2018 | San Pablo approved a one-year software licence for $100,000 | Primary city record; not proof no other agency paid earlier |
| Next customer | A neighboring city arrived through a chief-to-chief recommendation | Founder-reported; city is not named in that claim |
| First 3–4 years | Growth remained slow and word-of-mouth led | No full customer or channel series |
| Later | Founder reports a $1m, $3m, $10m ARR progression and about $250,000 current average ACV | Founder-reported; dates and audited figures absent |
| June 2026 | $250m Series D at a $6.8b valuation | Independently 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.
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.
| Field | What to record | Reject when |
|---|---|---|
| Account condition | Visible workload, change, failure, deadline, or mandate | Only firmographic fit exists |
| Operator fit | Owns the workflow and can sponsor access | Contact is senior but distant from the job |
| Public evidence | Talk, case, filing, technical post, job, or project | The message would rely on a compliment |
| Contribution | One safe result you can help produce manually | The only offer is a product demo |
| Governance | Approval, data scope, retention, access, audit, and exit | The 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.
- Write the outcome and explicit non-goals.
- Name the operator, approver, data owner, and escalation path.
- Limit access, retention, and use before touching customer data.
- Perform the workflow manually and log every action, wait, correction, and judgement.
- Mark repeated work separately from customer-specific work.
- 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.
- Run
$icp-offer-context. Store the workflow, trigger, operator, disqualifiers, safe manual contribution, and claims you may make. - 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. - Use
$daily-vertical-prospectingfor a 20-account list, then$signal-research-dossierfor at least two dated sources per operator. - Keep design-partner, peer-referral, watch, and stop lists separate. Do not blend their conversion rates.
- Run
$contact-discoveryonly for 8+ operators after the credit dry run and human confirmation. - Use
$cold-email-first-touchto draft the bounded working-session ask, then$outreach-qa-audit. Review every message. - 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.