The First 100 Customers Course #9: How Alguna Turned 10 Trust Bets Into a Billing Wedge

TL;DR

Alguna did not have a famous founder network to lend credibility to an unfinished, mission-critical product. Co-founder Aleks Đekić says its first ten customers came from finding companies with a specific gap between what sales promised and what finance could bill, then earning enough trust for those buyers to take a leap of faith. The number is founder-reported, and no source names the ten accounts, prices, or acquisition channels.

The repeatable mechanism was costly workflow gap → narrow problem account → buyer data on the second call → technical scrutiny → forward-deployed build → reusable billing wedge → reputation. Early product engineers joined the commercial process, asked prospects to attack the product's limits, and built dedicated workflows with design partners. The first customer then forced Alguna into invoicing, payment processing, dunning, and retries, work the founders had intended to avoid. Đekić says that unwanted scope became a competitive advantage with finance teams.

The warning matters as much as the result. Alguna spread the product horizontally earlier than the lean-startup playbook recommends. That may be necessary when a buyer outcome crosses several systems, but it can also turn every sales call into a custom roadmap. Copy the proof process. Do not copy unlimited bespoke development.

What you will build

You will build a 30-day trust-replacement sales system for a technical B2B product that touches an important workflow. The outputs are a system-boundary worksheet, a 25-account problem list, a proof plan using real buyer data, a technical scrutiny checklist, a design-partner agreement, a request recurrence ledger, and a reviewable outreach campaign.

Who this is for

Use this when your product asks a buyer to trust a young company with money, data, operations, or another workflow that cannot fail quietly. It fits billing, security, data infrastructure, compliance, developer tools, and vertical SaaS where a generic demo leaves the buyer's biggest risk unanswered.

Do not use it for a lightweight utility a buyer can test alone in minutes. Do not offer forward-deployed engineering when you cannot name the product boundary, record requests, or say no. If each prospect needs a different company, you are running an agency without admitting it.

Case snapshot

Stage	Verified fact	Evidence limit
Before Alguna	Đekić had worked on revenue tooling at Dojo and fragmented product launches at Primer	Founder biography and interview
2023	Alguna joined Y Combinator's S23 batch	YC and independent coverage agree
Discovery	The founders report interviewing more than 100 company leaders	Interviews are not paying customers
First 10	The founder describes an organic, problem-led motion built on trust in the team	No channel mix, dates, prices, or conversion data
Manual work	Product engineers used buyer data, tested edge cases, and built with design partners	Effort and implementation time undisclosed
Product correction	Customer one required invoicing, payments, dunning, and retries	Customer identity and contract value undisclosed
Reuse	The founder says early builds cover about 80% of use cases in the later pipeline	Founder-reported; not a win rate
September 2025	Alguna announced a $4 million seed round	Later context, not proof of first-10 attribution

The model: replace brand trust with proof of control

An established infrastructure vendor sells two products. The visible product performs the job. The invisible product is institutional safety: references, operating history, support capacity, and the belief that the vendor will still exist when something breaks. A startup has almost none of that second product.

Alguna replaced missing institutional safety with a controlled buying process. It started from a painful boundary, brought technical people into the sale, used the prospect's own data, exposed limitations before implementation, and stayed close enough to repair failures. This does not make the purchase safe. It makes the risk visible, testable, and shared.

The loop compounds when bespoke delivery creates reusable product. A hard customer case becomes a primitive. The primitive shortens the next proof. A successful implementation becomes a reference. The reference reduces the next buyer's trust gap. The failure mode is the opposite: every deal creates unique code, the roadmap fragments, delivery slows, and the trust promise collapses under its own cost.

Step 1: choose a system boundary, not a category

Alguna did not begin with the claim that “billing is broken.” It focused on the chasm between the truth in a signed sales contract and the different truth finance could actually invoice. The target buyer was already reconciling a quote, a billing system, payments, accounting, and often a spreadsheet. That coordination tax made the problem urgent enough to consider a young vendor.

Complete this system-boundary worksheet:

• Upstream promise: what one team commits to the customer.
• Downstream execution: what another team must deliver or record.
• Broken handoff: where data, ownership, or timing diverges.
• Current patch: spreadsheet, manual review, copied data, or internal code.
• Failure cost: lost revenue, delayed work, compliance exposure, or churn.
• Change event: the moment that makes replacement unavoidable.

Pass condition: ten interviews describe the same handoff and at least five buyers have paid for a patch in time, software, or headcount. Stop condition: buyers agree that the category is annoying but cannot describe a recent failure or owner.

Step 2: build a problem list before a contact list

Đekić says the early team approached companies with specific problems connecting sales and finance. The transcript does not disclose whether those conversations came from cold outbound, referrals, the YC launch, or another source. That gap prevents a channel recipe, but it sharpens the targeting lesson: account evidence must precede message volume.

Create a 25-account list. Give each account one observable trigger: a new usage-based product, multiple pricing models, a move upmarket, a billing migration, a finance hire, or public evidence of manual reconciliation. Add the likely workflow owner, the current stack, the handoff at risk, and the source URL. Separate evidence from inference.

Metric: accounts with a dated trigger and named owner. Pass: 20 of 25 have both. Stop: you are relying on industry and headcount alone. A narrow list with a weak problem signal is still a broad list.

Step 3: sell the scrutiny process

Trust was Alguna's central objection. Buyers were asking whether the young company could control revenue infrastructure and whether it would survive. The team answered operationally. Product engineers joined early. Around the second call, the prospect's own data entered the conversation. Prospects were invited to push edge cases rather than admire a sandbox.

Use a four-part proof plan:

1. Critical workflow: one end-to-end job the buyer must complete.
2. Hostile cases: five edge cases most likely to break the promise.
3. Exit criteria: observable outputs that must match the buyer's system.
4. Failure protocol: owner, response path, rollback, and data handling.

Ask: “Which three cases would make you regret buying this after implementation?” Put those cases into the proof before discussing a broad roadmap. Pass condition: the economic, technical, and operational owners agree on the same exit criteria. Stop condition: the buyer wants production responsibility but will not provide representative data or an owner.

Step 4: forward-deploy with a productization ledger

Alguna's early customers participated as design partners. Engineers built dedicated product with them, close to a forward-deployed model. This level of service is useful only if it buys reusable knowledge. Keep a ledger for every request with the customer job, workaround, frequency, adjacent accounts, implementation cost, maintenance owner, and product decision.

Classify each request:

• Primitive: a reusable capability inside the core boundary.
• Connector: an integration needed by several accounts.
• Configuration: customer-specific data expressed without unique code.
• Service: valuable work that should remain manual and explicitly priced.
• Distraction: a request that serves one logo but weakens the product.

Productize when: the same job appears in three qualified accounts, fits the system boundary, and reduces future proof or delivery time. Do not productize when: the only argument is deal size or founder anxiety. Review the ledger weekly with sales and engineering together.

Step 5: test whether the unwanted adjacency completes the outcome

Alguna initially intended not to touch payments, invoicing, dunning, or retries. The first customer needed those jobs because the existing provider could not handle the workflow. Building them extended the product, but also completed the path from contract to cash. Đekić says finance teams later valued that end-to-end control.

Use a boundary-change gate before accepting a similar request. Does the adjacency complete the same buyer outcome? Have two other qualified accounts shown the same break? Can the capability be built as a primitive or configuration? Does ownership remain clear? Will it improve the next proof instead of only saving the current deal?

Pass condition: four yes answers and one named owner. Stop condition: the request introduces a new buyer, new data model, and new operating promise at once. That is a second product, not a wedge.

What failed and what did not

The admitted mistake was premature horizontal scope. Alguna did not follow the usual advice to solve one small feature and expand later. The founders believed the customer outcome required an end-to-end foundation, but Đekić also says the product spread too thin. Treat that as a tradeoff, not founder mythology.

The second limit was structural. Nobody wakes up wanting to replace billing. A buyer often waits for a pricing change, reconciliation failure, or scaling event. Reputation can make Alguna the trusted option when that event arrives, but it cannot manufacture timing. The transcript mentions later inbound and discovery through LLMs without quantifying them or connecting them to the first ten customers.

Finally, the evidence does not show self-serve growth, a repeatable conversion rate, or channel economics. The system here is a way to earn and learn from the first difficult buyers. It is not a claim that bespoke delivery scales unchanged to 100 customers.

Your 30-day implementation plan

Days	Work	Required output	Gate
1-4	Run ten system-boundary interviews	One repeated handoff, owners, current patch, failure cost	Five buyers paid a coordination tax
5-8	Research 25 triggered accounts	Problem list with dated sources and named owners	20 accounts have both trigger and owner
9-12	Contact the first ten accounts manually	One observation, one problem hypothesis, one proof ask per account	Three buyers share representative data
13-18	Run technical scrutiny	Five hostile cases, exit criteria, failure protocol	One buyer accepts a design-partner scope
19-25	Deliver with the request ledger	Working outcome plus primitive/configuration/service decisions	Buyer completes the critical workflow
26-30	Find recurrence and request a reference	Second proof using the reusable primitive; factual reference	Proof time falls or stop expanding scope

Lead Scorer implementation: reproduce the research and drafting loop

Lead Scorer fits the account-research and reviewable outreach parts of this motion. It cannot run technical implementation, guarantee trust, or decide which customer request belongs in the product. Keep discovery interviews, proof criteria, and boundary decisions with the founder and product engineer.

1. Store the product boundary and scoring rule

Use the icp-offer-context and icp-scoring-rubric skills. Define the product, the broken handoff, mandatory trigger, allowed buyer roles, disqualifiers, evidence you can claim, and the threshold for contact discovery. Through the MCP, use create_product, create_list, and the scoring configuration workflow. Keep a separate list for each trigger so a pricing migration is not mixed with a general finance audience.

Copyable prompt: Create a 1-10 rubric for companies where sales contracts and finance billing diverge. Make a dated change event mandatory. Reject accounts with no named workflow owner or no evidence of a manual patch. Do not enrich contacts yet.

2. Research cheaply before spending credits

Use signal-research-dossier to collect two dated signals per company. Create or attach records to the correct list, then load unscored leads with get_leads_pending_scoring and persist decisions with submit_lead_score. Score the problem evidence before profile or contact enrichment. A practical gate is 8/10 plus the mandatory trigger. Reject weak accounts instead of lowering the threshold to fill a campaign.

Output: 20 scored accounts with source URLs, five rejected examples, and one sentence explaining every score. Stop: fewer than ten accounts pass from the first 25. Return to the system boundary or choose a better trigger.

3. Enrich only the shortlist

For passing leads, run enrich_leads with dry_run: true first. Review the estimate and require human confirmation above the platform's credit threshold. Submit the full qualified shortlist once, then poll get_lead_enrichment_run; do not loop one lead at a time. Use find_lead_contact_info only after fit and role are confirmed, again estimating before spending.

Output: ten reachable economic or workflow owners with evidence intact. Stop: the role is guessed, the trigger is stale, or contact cost is being used to compensate for poor qualification.

4. Create reviewable proof invitations

Use cold-email-first-touch and outreach-qa-audit. Create a draft with create_campaign, add only the qualified leads, retrieve context through get_campaign_authoring_context, and persist one specific message per lead with write_campaign_drafts. The ask is not “book a demo.” Ask to test one observed handoff using representative data and pre-agreed failure cases.

Copyable prompt: For each lead, cite one verified change event and the exact sales-to-finance handoff it may stress. Draft under 120 words. Ask for a 20-minute workflow review and permission to test one hostile case. Make no savings, implementation-time, or customer-count claim.

Every draft remains in needs review. A human checks the source, relevance, promise, and ask. Campaign activation and sending stay in the web UI and are not agent decisions.

5. Turn objections into the next evidence asset

Use reply-triage to classify replies as timing, wrong owner, trust, technical limit, or no fit. Keep “not now” separate from “not this.” Feed repeated trust objections into a proof checklist or source-backed Content Studio note. Feed technical limits into the productization ledger, not directly into the roadmap. Where a useful post attracts relevant operators, a later create_audience_source can capture and prequalify those engagers, but only after the content has earned real engagement.

Pass condition: the next batch has stronger evidence, a narrower ask, or a faster proof because of the replies. Stop condition: objections merely trigger more copy variants while the product risk stays unanswered.

Checklist

• Choose one expensive handoff, not a broad software category.
• Require a dated trigger and a named workflow owner before enrichment.
• Use buyer data early enough to expose edge cases before implementation.
• Define hostile cases, exit criteria, and failure protocol in writing.
• Keep a recurrence ledger for every customer request.
• Productize after repeated jobs, not after one exciting logo.
• Ask for a factual reference only after the critical workflow succeeds.
• Keep enrichment, drafting, campaign activation, and scope changes behind human gates.

Sources and limits

The core evidence is Aleks Đekić's July 2026 interview on The AI Revolution Show. The public episode description independently exposes chapters for the first ten customers and the unexpected first-customer product request. Alguna's Y Combinator profile confirms the S23 launch, founders, prior experience, and more than 100 discovery interviews. A contemporaneous launch post records unquantified demo demand.

FinTech Futures independently confirms the 2023 founding context and $4 million 2025 seed. Alguna's funding announcement, current documentation, and current homepage show the later product and customer surface. They do not prove who the first customers were or which channel found them.

Treat the first-ten count, the roughly 80% reuse claim, and the competitive-advantage assessment as founder-reported. The sources do not disclose account identities, contract values, first-ten dates, outreach volume, conversion, ARR, CAC, sales-cycle length, retention, or churn. This course therefore teaches the documented trust and delivery mechanism, not an invented path to exactly 100 customers.