The First 100 Customers Course #27: How 7Learnings Sold Consulting Before Software to Reach Its First $1M ARR

TL;DR

7Learnings could not build a predictive-pricing product without a large retailer's data, and a large retailer had no reason to give proprietary data to a company with no product. Co-founder Felix Hoffmann says the team solved the deadlock by selling a consulting project before it had SaaS to sell. The client paid for help implementing its own pricing approach and allowed 7Learnings to use the dataset to build a separate product.

That was only the input wedge. The first paying software customer later came through Hoffmann's old consulting network. A paid A/B pilot reduced the buyer's risk, the first live upload failed, and a later test reportedly produced a 13% profit uplift. Hoffmann says he then closed the first ten customers himself, reaching about $1M in annual recurring revenue through a mix of network, events, speaking, masterclasses, and customer proof. The customer count, ARR, early channel mix, and 13% result are founder-reported, not independently audited.

What you will build

You will build a service-to-software acquisition system with eight outputs: an input-dependency map, a paid service wedge, a rights boundary, a named-account list, a reversible pilot, a failure protocol, a proof asset, and a customer-backed distribution calendar. Each output includes a pass condition and a stop condition.

This is for a B2B founder whose product needs something a serious buyer controls before it can work: historical data, system access, an integration, a regulated workflow, or expert decisions. It is not for a low-ticket product that can learn from public data or self-serve traffic. It also does not justify disguising custom development as a repeatable product.

Case snapshot

Stage	What the sources support	Evidence limit
Cold start	Useful forecasting required a large retailer's proprietary sales data	Founder explanation; no minimum dataset size is public
First contract	Paid consulting plus permission to use data for a separate product	Terms and customer identity are private
Build	Roughly one year to develop forecasting, optimization, and a front end	Approximate founder timeline
First SaaS customer	A retailer connected to Hoffmann's former consulting network	Not necessarily the consulting client; identity undisclosed
Pilot	Paid monthly; roughly half the assortment optimized as an A/B comparison	No fee, duration, sample size, or statistical method disclosed
Failure and repair	First upload priced high-priced products too aggressively; later test reached 13% uplift	Founder-reported; the 13% figure is qualified with “I think”
First milestone	Ten customers and about $1M ARR, all closed by Hoffmann	No independent revenue audit or customer-level distribution
Next channel	E-commerce events, speaking, masterclasses, and customer references	No channel-level lead or conversion totals

The model: trade immediate service for a reusable input

The causal chain is paid service → lawful input access → product build → paid reversible pilot → visible failure → founder repair → measurable proof → customer-backed distribution. The service is useful only because it breaks a specific circular dependency. It gives the buyer value before the product exists and gives the founder a product input that cannot be manufactured internally.

Three contracts sit inside that chain. The service scope says what the client receives now. The rights boundary says what the startup may learn from or reuse. The pilot protocol says what the product may control, how performance is compared, and when the buyer can stop. If those are blurred, the wedge creates legal and delivery debt rather than product evidence.

Step 1: name the input you cannot fake

Hoffmann brought six years of pricing consulting and two years at Zalando, but expertise did not replace production data. A neighborhood shop was too small. 7Learnings needed the sales history, assortment, inventory, and price-response patterns of a substantial retailer to develop a useful forecast.

Create an input-dependency map with five columns: desired customer outcome, input required, current owner, reason they will not share it, and a valuable job you can do before the product exists. Separate a hard dependency from a convenience. “More examples would help” is not a cold start. “The model cannot be tested against the target environment” is.

Pass condition: one input is both necessary for product validity and controlled by a qualified buyer. Stop condition: public, synthetic, or founder-owned data can answer the same learning question safely.

Step 2: sell the smallest service that earns the input

7Learnings did not promise nonexistent software. The first client wanted help implementing its own decision-optimization approach. Consulting could produce that result immediately, and the startup could build its separate forecasting and optimization product from the permitted data.

Write a one-page wedge offer: one buyer, one current decision, one fixed deliverable, one clock, one fee, and one explicit product-learning output. A useful template is: “In N weeks, we will deliver X using your existing process. Separately, subject to the agreed rights, we will learn Y needed to test product Z.” Charge for the delivered service. Free access encourages polite cooperation without proving budget or urgency.

Pass condition: the buyer would pay for the service even if the product never launched. Stop condition: more than half the work is unrelated custom build, or the service has no reusable learning output.

Step 3: make the rights boundary boring and explicit

The key fact in the founder account is permission: the retailer agreed that 7Learnings could use its data to develop another product. The public interview does not expose the actual contract, so it cannot be copied as legal precedent.

Before receiving data, document purpose, fields, access, retention, deletion, security, confidentiality, derived outputs, model use, and what may never be reused. Keep client delivery separate from product assets and obtain qualified legal review. Do not treat anonymization as a magic sentence. If a right matters to the product, it must be understandable to the buyer before transfer.

Pass condition: both sides can explain the boundary in the same words. Stop condition: product viability depends on an implied right, a buried clause, or data you would be uncomfortable naming in the scope.

Step 4: choose the first software buyer by patience and economics

The first paying software customer came from Hoffmann's former consulting network. It was a real retailer with a live pricing problem, not a friendly small company. Hoffmann says the product's economics started around €25M in annual turnover because the approach carried real delivery cost and created more value on a larger revenue base.

Score the first-account shortlist on pain, input quality, economic headroom, executive sponsor, ability to measure, tolerance for imperfection, and reference potential. Warmth is useful only after fit. A close contact without enough data or margin exposure will teach the wrong product.

Pass condition: the account has a costly current problem, the required input, and a sponsor willing to evaluate a bounded test. Stop condition: the only advantage is an introduction.

Step 5: make the risky decision reversible

7Learnings did not ask the retailer to hand over every price. The pilot compared the product on roughly half the assortment with the retailer's existing method on the other half. The buyer could see a result and stop. The pilot was paid with a monthly fee rather than a success fee; Hoffmann argues that success pricing adds complexity and dispute pressure to an already contested test.

Define the unit under control, baseline, observation window, guardrails, rollback owner, success metric, and expansion decision before launch. The split does not need to be 50/50, but it must produce a credible comparison without putting the whole operation at risk.

Pass condition: the buyer can describe the downside, rollback, and expansion decision before signing. Stop condition: success is a vague testimonial, or a bad result cannot be isolated quickly.

Step 6: sell a failure protocol with the pilot

The first upload was a disaster. High-priced products came out too expensive, and e-commerce exposed the mistake within one day. Hoffmann credits a patient customer with a serious problem, but he also says the founder must stay close, explain why the system failed, and work through the repair. A later upload reportedly produced a 13% profit uplift.

Write the red-day protocol before launch: automatic alert, affected scope, rollback time, customer owner, founder call, root-cause note, corrected test, and rule for ending the pilot. Speed without candor burns trust. Candor without a bounded repair plan turns the customer into unpaid QA.

Pass condition: a failed result triggers action within one operating cycle. Stop condition: the founder needs to improvise who tells the buyer or how to reverse the change.

Step 7: turn the result into scheduled customer proof

Once the personal network thinned, events became more important. Hoffmann names e-commerce conferences, speaking slots, and masterclasses. Customer references reduced risk for new buyers, and he recommends putting joint fairs or webinars into the contract rather than merely hoping satisfied customers will refer someone.

Create one proof packet with the initial condition, test boundary, failure, repair, observed result, evidence limit, and buyer quote if approved. Then schedule its use: one relevant event, one educational session, and two reference conversations per quarter. Never turn an uncertain number into a guarantee. Later named stories, including a Google Cloud case study and Otrium's account, support the broader A/B-test approach but do not independently verify the first customer's 13%.

Pass condition: a prospect can inspect what was tested and what remains unknown. Stop condition: the proof omits the failure or borrows a later customer's result.

What failed, and what remains structurally hard

• Initial execution failed: the first live prices were wrong. The reversible pilot and founder response kept the learning recoverable.
• Broad outreach weakened: Hoffmann says cold outreach worked to some extent, then became less effective and risky for a small account universe. The answer was account plans, not more volume.
• Proof creates operations: A/B tests help sales but burden implementation teams with design, evaluation, and explanation. 7Learnings still chooses selectively when a test is necessary.
• Founder-led sales did not end at ten: Hoffmann says he stayed closely involved through roughly the next forty customers. Enterprise judgment remained hard to delegate.

Your seven-day implementation plan

1. Day 1: complete the input-dependency map and reject fake dependencies.
2. Day 2: write the paid wedge offer and its standalone customer outcome.
3. Day 3: draft the data and rights questions for qualified legal review.
4. Day 4: score 20 accounts on fit, input, patience, economics, and proof value.
5. Day 5: design the reversible pilot, baseline, rollback, and failure protocol.
6. Day 6: draft five account-specific conversation openers for the top accounts.
7. Day 7: run two founder conversations and update the offer from objections.

The week's output is not a campaign blast. It is one sellable service, one lawful learning path, one ranked account list, and one pilot that a serious buyer can safely reject or accept.

Lead Scorer implementation

Lead Scorer fits the named-account work around this motion. It does not negotiate data rights, run the pricing system, or substitute for the founder in a failed pilot. Use the MCP from Codex or Claude to make research and drafting repeatable while preserving the human gates.

Phase 1: define the narrow account universe

Use the icp-offer-context skill to store the minimum company scale, geography, retail model, data requirement, sponsor role, exclusion rules, and claims you may make. Then use daily-vertical-prospecting for one narrowly defined retail segment. Keep consulting prospects, software-pilot prospects, and later proof-event prospects in separate lists.

Define an ICP for a paid data-access service that may lead to a software pilot. Require a buyer with the necessary operating data, measurable economic pain, and authority to approve a bounded test. Disqualify small datasets, unclear rights, and accounts seeking generic custom development.

Pass condition: the list contains 20 named accounts that meet the hard input and economics gates. Stop condition: company size is being used as a proxy for data availability without evidence.

Phase 2: score before spending enrichment credits

Use icp-scoring-rubric to weight input availability, pain, measurable baseline, sponsor access, implementation capacity, and reference potential. Require a score of at least 8/10 for contact enrichment. Then use signal-research-dossier to require two dated, sourced signals per keeper: a pricing, inventory, margin, or transformation trigger and evidence of the relevant operator. Skip honestly when the evidence is absent.

Score these accounts for the consulting-before-software wedge. Do not enrich below 8/10. For each keeper, document two dated signals, the likely data owner, current workaround, measurable downside, and the safest first ask. Mark every inference.

Only then run contact-discovery for the small set about to be contacted. The credit gate is a human approval point: confirm the count and cost before discovering emails or phone numbers.

Phase 3: draft conversations, not promises

Use cold-email-first-touch for one message per lead. The ask is a conversation about the observed decision and input constraint, not permission to ingest data and not a promise of uplift. Run outreach-qa-audit and rewrite any draft below threshold. The founder reviews every source, claim, recipient, and ask before any campaign is activated or sent.

Draft a first touch under 150 words using only the dossier's verified signals. Name the current decision, ask how it is measured today, and propose a short scoping call. Do not claim a 13% result, imply an existing customer relationship, or ask for data in the email.

Pass condition: every message survives source review and makes one small ask. Stop condition: the copy presents the service as finished software or turns another customer's outcome into a forecast.

Phase 4: turn objections into the next proof asset

Use reply-triage to classify responses as interested, timing, wrong person, objection, or no. Pause rather than automate around resistance. Repeated objections about data rights, test safety, pricing, or implementation become sourced Content Studio briefs. Publish a useful protocol or worksheet, then use signal-audiences to capture and score people who visibly engage. That creates the customer-backed education loop without pretending the agent can close an enterprise deal.

Checklist

• The product has one necessary buyer-controlled input.
• The service produces value without pretending software exists.
• Rights, security, retention, and deletion are explicit.
• The first software account qualifies on economics and patience, not warmth alone.
• The pilot is paid, measurable, reversible, and bounded.
• The failure protocol exists before launch.
• The proof asset includes the failed first result and evidence limits.
• Customer participation is scheduled, permissioned, and never assumed.
• Broad outreach stops before it exhausts the named account universe.
• No agent activates, spends credits, or sends without human review.

Sources and limits

The early chronology comes from The SaaS Podcast episode 494. Its Apple Podcasts listing confirms publication and framing but is not independent evidence. The consulting terms, first customer, ten-customer count, $1M ARR, 13% uplift, and channel sequence remain founder-reported.

Later evidence shows the company and method persisted without validating the first-ten attribution. Google Cloud reports a named customer result and use of A/B testing. Startbase independently reports 7Learnings' 2025 Series B of more than €10M and names later customers. The company announcement supplies the primary financing account. Hoffmann's current claim of about $5M booked ARR, 40 customers, and 60 employees is not independently audited and is not used as the course promise.