Lead Scorer

The First 100 Customers Course #18: How Accrual Turned Two Design Partners Into 100% Pilot-to-Production

A practical course for turning two complementary enterprise design partners into auditable pilots, layered buyer conviction, and a production decision.

By Miljan @ Lead Scorer 19 min read

TL;DR

Accrual did not choose two friendly design partners who would ask for the same easy demo. Co-founder Cosmin Nicolaescu says its first two customers were H&R Block and Armanino: one brought national scale, governance, and change-management pressure; the other brought the complexity of high-net-worth returns. Those opposite constraints forced one product foundation to become credible.

The founder reports a 100% pilot-to-production conversion rate. The denominator, contract values, and complete customer sequence are not public, so this is not a benchmark. The useful mechanism is borrowed access → complementary forcing functions → transparent iteration → auditable pilot → layered champions → production decision. An introduction opened the room. Evidence earned the rollout.

Typographic cover for the Accrual course highlighting two first design partners and founder-reported 100% pilot-to-production conversion
Accrual paired two early enterprise customers with opposite constraints, then used a structured truth-based pilot to reach a founder-reported 100% production conversion rate.

What you will build

You will build a two-design-partner system for a high-consideration B2B product. The output is not a list of logos. It is a falsifiable learning program: two accounts that stress different reusable constraints, a pilot truth contract, a case matrix, a champion map, weekly evidence reviews, and a written production decision.

By day 30 you should know whether the product can produce a trusted result in one narrow workflow, whether the result survives both constraints, and whether a real buyer will fund deployment. If the answer is no, the same system tells you whether to repair the product, narrow the segment, or stop.

Who this is for, and who should not copy it

Use this course for enterprise SaaS, vertical AI, data infrastructure, compliance, finance, security, or workflow products where the buyer needs proof with real data before changing how people work. It fits a founder who can stay close to delivery and has enough domain credibility to ask for a serious evaluation.

Do not use it to disguise free consulting, to collect sensitive data without a governance plan, or to sell an AI demo whose output is secretly repaired by humans. Do not target two famous companies simply because their logos would help fundraising. If their constraints do not generalise to the same product wedge, you are running two custom projects.

Case snapshot and evidence limits

StageWhat the evidence supportsLimit
October 2024Accrual started after several months of market and idea selectionExact start date is founder-reported
Market discoveryFounders interviewed and shadowed accountants, owners, and workflow operatorsConversation count is undisclosed
First two customersNicolaescu names H&R Block and ArmaninoOrder is not independently verified
WedgeIndividual tax returns exposed scale, security, and high-complexity casesEarly contract scope and price are private
PilotVaried returns and roles, reviewed side by side against final customer workExact sample size is undisclosed
ConversionFounder reports 100% pilot-to-productionDenominator and contract values are not public
Later proofArmanino moved into production across six offices and thousands of returnsMetrics come from an Accrual case study with named customer speakers

Independent trade coverage confirms that Accrual worked closely with H&R Block, Armanino, Creative Planning, and other Top 100 firms before its February 2026 public launch. It also confirms a phased Armanino deployment. That supports the early-customer context, but it does not convert the founder's first-two claim into an audited chronology.

The model: make each customer prove a different part of the same product

A weak design-partner program optimises for encouragement. Both partners resemble the founder, tolerate rough edges, and request features. The result is activity without a buying case. Accrual's stronger pattern was to select a pair whose differences were useful.

H&R Block represented volume, public-company governance, security, and organisational change. Armanino represented intricate returns for high-net-worth clients. Both still shared the same initial job: prepare and review individual tax returns. If the foundation could serve both ends of that constraint range, it had a reason to exist beyond one account.

The pilot then replaced promises with a truth set. Different cases were run through the product, compared against final returns, and investigated when they differed. Operators did not merely rate a demo. They could see what matched, what failed, why it failed, and whether the team corrected the system. That evidence gave champions something credible to carry into a production decision.

Step 1: choose one narrow job before choosing the logos

Accrual's founders began top down. They excluded markets where they lacked obsession or an earned advantage, then looked for regulated workflows with many connected steps, high accuracy requirements, and severe coordination cost. Interviews and shadowing narrowed the first product to individual tax returns.

Complete this worksheet before sourcing any account:

  • Weekly job the operator must complete: ______
  • Current truth set or accepted final output: ______
  • Cost of one wrong result: ______
  • Minimum security and permission boundary: ______
  • Repeated handoffs or tools inside the job: ______
  • One result a buyer can evaluate in 30 days: ______

Pass condition: two accounts can test the same job against different reusable constraints. Stop condition: each account needs a different user, data model, buyer, and final output.

Step 2: recruit a forcing-function pair

Define two columns. Partner A should expose scale, throughput, permissions, or change management. Partner B should expose complexity, edge cases, expert judgement, or integration depth. Neither is “better.” Together they bound the product.

FieldPartner APartner B
Shared job____________
Primary constraintScaleComplexity
Truth owner____________
Security owner____________
Production sponsor____________
Decision date____________

A warm introduction is acceptable. Accrual benefited from an investor network and the founders' Stripe and Brex histories. Record that advantage honestly. Then qualify the account exactly as you would a stranger. Prestige without workflow access produces a press quote, not product evidence.

Step 3: write a truth contract before the demo

Nicolaescu repeatedly emphasises truthfulness: say what works, what does not, what the team will build, and what it will not. In AI software this matters because a polished demonstration can hide retries, human repair, missing context, or cherry-picked output.

Your one-page truth contract should name:

  1. The job and the accepted reference output.
  2. The cases included and excluded.
  3. Every manual intervention and who performs it.
  4. What the product may do with customer data.
  5. How errors, missing context, and nondeterministic results are recorded.
  6. The success threshold and the production decision date.

Pass: the buyer agrees to evaluate the real system with real work. Stop: success depends on hiding the work required to make the output look correct.

Step 4: size the pilot between anecdote and chaos

Accrual describes two common failures. A tiny pilot finishes quickly but leaves the buyer asking for another trial because too little was tested. A huge pilot includes hundreds of cases and dozens of people, which spreads attention so thin that nobody learns why a result succeeded or failed.

Build a case matrix instead. Choose three complexity bands, two user roles, one normal workflow, and one meaningful edge case per band. The exact count depends on the job. Stop adding volume when another case repeats evidence you already have. Add a case only when it tests a new failure mode.

Checkpoint: every included case must answer a named risk. If a case cannot change a product or production decision, remove it.

Step 5: compare every result with the customer's truth

Accrual reviewed pilot returns one by one beside the firm's final version. If outputs matched, the team moved on. If they differed, it traced the cause: product error, missing document, missing context, or a legitimate judgement difference. This is stronger than asking users whether the product feels useful.

Create one evidence row per case:

  • Case and complexity band.
  • Reference output and owner.
  • Product output on the first honest run.
  • Difference, cause, severity, and recoverability.
  • Manual minutes and founder intervention.
  • Fix shipped and result on the next comparable case.

Pass: severe errors fall, repeated cases require less intervention, and the buyer trusts the comparison method. Stop: the team changes the scoring rule after seeing a bad result.

Step 6: build a champion stack, not one executive sponsor

A CEO can authorise evaluation but often cannot judge daily workflow. Accrual sought a practice leader who could make the service-line decision, a technology or security owner who could unblock integration, and managers or senior managers who still performed the work.

Your minimum stack is one economic sponsor, one technical or governance owner, and two hands-on operators. Meet weekly with the operators. Review risks with the technical owner. Keep the sponsor focused on evidence, scope, and the decision date. If one person holds every role, the deployment is fragile even when that person is enthusiastic.

Step 7: make production a separate product

A passing pilot answers whether the system can produce a trusted result. Production asks whether the organisation can use it repeatedly. Accrual's later implementation material separates these stages: scope offices and clients, clean data four to six weeks early, configure permissions, train by role, designate four or five local champions per office, create support channels, and review outcomes after the season.

Write the production plan before the pilot ends. Include volume, included teams, exclusions, data readiness, integrations, training, support, incident ownership, commercial terms, and the first review date. A successful pilot without this plan is still a research project.

Step 8: accept expansion pull only after the wedge works

Accrual's paying customers later asked about business returns, audit, client accounting services, and engagement letters. This is useful because the requests came after the original problem produced value. It differs from a prospect saying, “build one more feature and then I might buy.”

Decision rule: log every adjacent request, but build it only when the original workflow is paid, used, and repeatable; at least two customers own the same adjacent problem; and the extension reuses the existing context, permissions, and product foundation.

What failed, or would have failed

  • Vision without evidence: necessary before the product existed, insufficient for production.
  • CEO-only sponsorship: authority without enough workflow detail to evaluate the tool.
  • Tiny pilots: fast, but too narrow to create conviction.
  • Huge pilots: broad, but engagement and causal learning become diluted.
  • Hidden human repair: creates a result the production system cannot reproduce.
  • Point-solution drift: an easy feature may not build the shared context required by the wedge.

The podcast does not identify a failed acquisition channel, outreach count, or close rate. Do not turn these pilot-design failures into a story about cold outbound, content, or events. That evidence is not present.

Your 30-day implementation plan

  1. Days 1–3: choose one job, truth set, risk boundary, and 30-day result.
  2. Days 4–6: define complementary scale and complexity constraints.
  3. Days 7–10: score 30 accounts and select five candidates for each constraint.
  4. Days 11–13: secure two workflow conversations through trusted or evidence-led access.
  5. Days 14–15: sign the truth contract and case matrix.
  6. Days 16–22: run honest cases, compare outputs, and ship only repeated fixes.
  7. Days 23–25: review evidence with operators, security, and the sponsor.
  8. Days 26–27: present production scope, exclusions, support, and price.
  9. Days 28–30: receive a production decision, narrow and retest once, or stop.

Lead Scorer implementation: build the pair without wasting credits

This implementation fits a narrow enterprise motion where account research and qualification matter more than list volume. It does not validate the product, run the pilot, or approve outreach. The founder remains responsible for the truth contract, data permissions, production threshold, and every send.

Phase 1: encode the job and two constraints

Run $icp-offer-context with the shared job, buyer, trigger, disqualifiers, allowed proof, security boundary, and manual contribution. Then run $icp-scoring-rubric. Use create_product and create_scoring_config only after reviewing the draft context. An 8–10 account needs workflow fit, a dated reason to change, an accessible truth owner, a production sponsor, and one of the two chosen constraints. Scores 6–7 go to watch. Scores 1–5 stop.

Copyable prompt: “Build a 1–10 rubric for companies that own [job]. Separate scale-forcing and complexity-forcing accounts. An 8+ requires a dated trigger, a named workflow owner, an accepted truth set, and a credible production path. Return disqualifiers before leads.”

Phase 2: source and research two separate lists

Use $daily-vertical-prospecting for a bounded company set and $signal-research-dossier for two dated sources per account. Keep “scale design partner” and “complexity design partner” as separate lists so one constraint does not dominate. Pull candidates with get_leads_pending_scoring and save reviewed scores through submit_lead_score. If fewer than five of 30 accounts score 8+, change the segment or trigger before buying contact data.

Output: ten qualified accounts, each with a workflow owner, sponsor hypothesis, technical owner, trigger, truth-set evidence, primary constraint, and source links. Stop when the dossier is based on job title alone.

Phase 3: enrich only the keepers and draft the access ask

Run $contact-discovery only on reviewed 8–10 leads. Start enrich_leads and find_lead_contact_info with a dry run, inspect the credit cost, and confirm only the people you intend to approach. Use $cold-email-first-touch for a single request: access to map the workflow and define an evaluation, not a generic product demo.

Copyable ask: “We are testing [bounded result] for [job]. Your [dated constraint] would test [scale or complexity] without changing the workflow scope. We will disclose manual work and compare every output with your accepted result. Could we map the cases, owners, and stop conditions in 25 minutes?”

Phase 4: create drafts, keep approval human, learn from objections

Create only a draft campaign with create_campaign. Load real context through get_campaign_authoring_context, persist specific messages through write_campaign_drafts, and run $deliverability-preflight plus $outreach-qa-audit. A person reviews every message and controls activation. The agent must not send, approve, or spend beyond a confirmed credit gate.

Classify replies as no workflow, no urgency, no trust, no access, governance risk, or wrong constraint. Store repeated objections and useful evidence in Content Studio. Turn them into a practical guide, then use visible engagement as a new signal audience and rescore it. The loop is account evidence → reviewed access ask → pilot objection → useful content → new qualified signal. Lead Scorer accelerates the research and drafting loop; it does not manufacture production proof.

Saveable checklist

  • One shared job and accepted truth set.
  • Two partners with complementary reusable constraints.
  • Warm access recorded as an advantage, not proof.
  • Every manual intervention disclosed.
  • Case matrix tests risks, not arbitrary volume.
  • One sponsor, one governance owner, two hands-on operators.
  • Production scope written before the pilot ends.
  • Adjacent requests wait for paid, repeated use.
  • Human approval before enrichment spend and outreach activation.

Sources and limits

“First two customers” and “100% pilot-to-production” remain founder-reported. The rate's denominator, deal values, exact introduction chain, outreach volume, CAC, and sales-cycle length are undisclosed. Armanino's later production results do not prove H&R Block's results. Copy the evidence architecture and stop conditions, not the logos or the headline percentage.

Frequently asked questions

Were H&R Block and Armanino really Accrual's first two customers?

Co-founder Cosmin Nicolaescu names them as the first two customers in the podcast. Independent trade coverage confirms both were early deployments, but no public contract ledger proves their exact order, so the claim remains founder-reported.

Did Accrual convert every pilot into production?

Nicolaescu and the podcast description report a 100% pilot-to-production conversion rate. The denominator and contract values are not public. Treat the rate as a founder-reported outcome, not a universal benchmark.

What can a small SaaS founder copy without Accrual's network?

Copy the forcing-function pair, truth set, narrow pilot scope, layered champion map, and written production gate. Do not copy the prestige logos or assume a warm introduction substitutes for execution.

Keep reading