The First 100 Customers Course #7: How Wash-Dry-Fold POS Pre-Sold Three External Systems Before Reseller Approval

TL;DR

Wash-Dry-Fold POS did not begin by building a modern SaaS. Founder Brian Henderson first packaged hardware, third-party desktop software, setup, and training for laundromat owners. He says he collected payment from three external buyers before the software vendor had formally approved him as a reseller. For the first 34 external systems, he received the computers at his house, installed the software himself, repacked every unit, and drove it to the post office.

The distinction matters. Trade coverage says three earlier systems operated inside Liberty Laundry, his family's chain. The podcast describes a separate milestone: the first three external pre-sales. Those buyers did not purchase the cloud product that exists today. They paid for a working system assembled from available parts, plus Henderson's rare knowledge of their workflow.

The mechanism was operate the workflow → package the imperfect system → expose it in a trusted niche venue → require payment → fulfil manually → standardise repeated support → build owned software. The warning is equally important: payment before permission is evidence only when the buyer, problem, deliverable, and refund boundary are explicit. It is not permission to sell vaporware.

What you will build

You will build a seven-day paid-evidence sprint for one narrow operational buyer. The outputs are a workflow map, a complete offer assembled from what already exists, a list of 25 qualified accounts, a three-seat pre-sale cohort, a fulfilment checklist, a support ledger, and a clear gate for deciding whether custom software deserves to be built.

Who this is for

Use this when the buyer already spends money or staff time on a recurring workflow, you can deliver a useful result with existing tools, and the founder can personally onboard the first three accounts. It fits vertical SaaS, agent workflows, operational software, and software plus service offers where expertise closes the gap between a generic tool and a finished outcome.

Do not use it for regulated work you are not authorised to perform, promises that depend on an unbuilt core capability, or consumer products where support cannot be scoped. If a failure could stop payroll, expose sensitive data, or damage physical equipment, create a controlled pilot with written limits instead of pretending the product is ready.

Case snapshot

Stage	What happened	Evidence limit
2011–2014	Liberty Laundry grew from one to three stores and exposed multi-site management problems	Founder and company history agree
Internal systems	Three POS systems ran inside the family chain	Not external customer sales
2016	Wash-Dry-Fold POS began serving other laundromat owners	Started as a reseller bundle, not owned SaaS
First external pre-sale	A nearby laundromat owner asked to buy the same system	Buyer unnamed in public sources
Three external pre-sales	One relationship plus two forum responses paid before reseller approval	Founder-reported; no public invoices
First 34 external systems	Henderson configured, repacked, and shipped each unit from home	Founder-reported
2019–2020	Partner integration demand led to an owned cloud rebuild	At least five partner requests; sources differ between five and six
February 2025	1,000th system sold	Independent trade report of company milestone
August 2026	1,300+ systems and seven-figure ARR	Founder-reported; no audited financials

The model: sell the solved workflow before the software

Henderson's advantage was not code. It was accumulated workflow compression. He had managed multiple laundromats, tried unsuitable point-of-sale products, connected scattered tools, spoken at industry events, and trained attendants who sometimes had never used a mouse. When another operator asked for the same setup, he could define the full outcome better than a general software vendor could.

The first offer was therefore a system, not an app: computer, touchscreen, printer, cash drawer, weight scale where needed, software, configuration, training, and someone to call. That bundle reduced the customer's integration risk. It also forced the founder to learn what custom software would eventually need to absorb.

Step 1: earn a workflow before choosing a market

The company began inside an operating business. Henderson saw paper tickets, inconsistent pricing, disconnected payment systems, remote employee management, and the difference between dry-cleaning workflows and wash-dry-fold orders. This is deeper than picking a vertical because a keyword tool shows low competition.

Complete this workflow worksheet before writing an offer:

• Trigger: what event makes the buyer need a better system now?
• Actors: who buys, who uses, and who supports the workflow?
• Objects: which records, devices, files, or approvals move through it?
• Failure: where does money, time, trust, or compliance leak?
• Current stack: which tools already solve 60% of the job?
• Founder edge: what can you configure or teach that a generic vendor cannot?

Pass condition: five operators describe the same trigger, handoff, and failure cost. Stop condition: your insight is only that the industry looks old or that buyers “need AI.”

Step 2: assemble the whole result from available parts

Henderson did not know how to build the final software in 2016. He knew which existing desktop product worked best, which hardware survived a laundromat, and how to train the team. The product gap became a packaging opportunity.

Layer	First-cohort choice	What you learn
Core capability	Existing software, API, or manual operation	Whether the result is valuable before custom build
Configuration	Founder sets up the workflow	Which defaults repeat
Training	One live onboarding session	Where language and ability break
Support	Named channel and response window	Which failures block value
Boundary	Written exclusions and refund rule	Whether demand survives honest constraints

Output: a one-page offer describing a finished outcome, not a future feature list. Stop condition: the core outcome still depends on software you cannot reliably deliver today.

Step 3: run a three-payment demand probe

The first nearby buyer supplied a credible starting point. Henderson then posted in online forums for laundromat owners to ask whether others wanted the system. Two more paid. Interest did not count; payment did.

Use a restrained probe:

I operate this workflow in [context]. I am opening three paid setups for [narrow buyer]. You receive [complete result] by [date], using [current stack], plus [setup and training]. The price is [amount]. It does not yet include [honest boundary]. If I cannot deliver, you receive [refund rule].

Send it to 25 qualified operators in a place where the problem is already discussed. Do not broaden the promise after objections. Pass condition: three buyers pay under the same scope within 14 days. Stop condition: buyers praise the idea but nobody accepts the price, deadline, and boundary.

Step 4: fulfil manually and measure repetition

The first 34 shipments turned theory into operations. Henderson learned hardware sourcing, interstate sales tax, software installation, packaging, fulfilment, and remote support. None of that looked like a scalable SaaS. All of it revealed the product.

Create one row for every fulfilment action: owner, duration, error risk, customer dependency, and repetition count. Keep an action manual when it changes weekly. Standardise it after three repetitions. Automate it only when the inputs and success condition are stable.

Metric: founder hours to first customer value. Pass condition: cohort three takes at least 30% less time than cohort one without reducing the result. Stop condition: every account requires a different product or unbounded custom work.

Step 5: turn support failures into product defaults

A New Jersey customer did not know how to connect a monitor to a computer. The response was not to blame user sophistication. Wash-Dry-Fold POS moved toward preconfigured all-in-one hardware that could be unpacked, connected, and used remotely. Time to value improved because the system removed a dependency.

For each support issue, choose one action: better qualification, a safer default, a checklist, training, automation, or rejection of the account. Pass condition: the same blocker appears in fewer than 10% of the next cohort. Stop condition: onboarding still succeeds only when the founder takes control of the customer's environment.

Step 6: build owned software only after the pressure repeats

By 2019, the reseller business had hundreds of customers. At least five industry vendors asked for integrations at the Clean Show. Two adjacent companies told Henderson they had spent six figures trying to build their own POS products without a usable result. This was a much stronger build signal than the first three payments alone.

Use a build gate with four required proofs: ten paying accounts, one repeated workflow, three blocked integrations or capabilities, and evidence that owning the capability improves margin, retention, or speed. Wash-Dry-Fold POS rebuilt on Bubble in 2020 and launched late that year. The owned software came after distribution evidence, not before it.

What failed, and what not to copy

• Wrong prior tools: about $12,000 of the family business's money went into POS systems that did not fit. Expertise partly came from expensive mistakes.
• Buyer-sourced hardware: asking customers to assemble the stack created remote support failure. The bundle became more opinionated.
• Premature custom development: an Upwork experience went sideways, while adjacent vendors reported six-figure builds with nothing usable. Payment did not justify immediate code.
• COVID pause: deals fell flat in March 2020. Downtime accelerated the rebuild, but this was circumstance, not a repeatable channel.
• Scope confusion: the first three internal systems, first three external pre-sales, and later cloud subscriptions are different cohorts. Combining them produces a cleaner story and worse evidence.

Your seven-day implementation plan

1. Day 1: shadow or interview five operators and complete the workflow map.
2. Day 2: assemble the complete result from existing tools and manual work.
3. Day 3: define price, delivery date, exclusions, and refund boundary.
4. Day 4: build a list of 25 accounts with visible workflow evidence.
5. Day 5: send the paid three-seat probe and book qualification calls.
6. Day 6: close or reject. Do not change scope to manufacture a yes.
7. Day 7: decide: fulfil, revise once, or stop. No custom build yet.

Continue only when three buyers accept the same result and the founder can deliver it safely. Move toward custom software only after fulfilment data shows the same repeated bottleneck.

Lead Scorer implementation: build the paid-evidence loop

Lead Scorer fits the narrow-account research and draft outreach parts of this motion. It cannot prove workflow expertise, charge a buyer, activate a campaign without review, or decide that a risky pilot is safe. Use it to separate discovery from enrichment, preserve evidence, draft a small campaign, and turn objections into better qualification and content.

Phase 1: define the workflow and account universe

Run the icp-offer-context skill. Record the buyer, trigger, current stack, failure cost, disqualifiers, pilot boundary, and proof you may claim. Then find 50 candidate companies through the relevant registry or company-search tools. Keep them in a discovery list. Do not spend contact-enrichment credits yet.

Copyable prompt: Define the ICP for a paid pilot that delivers [result] to [buyer]. Exclude accounts without [workflow trigger] and accounts where [risk boundary] applies. Find 50 companies, attach source evidence, and do not enrich contacts.

Apply icp-scoring-rubric with a 7/10 pre-enrichment threshold. Score problem evidence more heavily than company size. Output: 15–25 accounts with a visible trigger. Stop condition: fewer than ten accounts share the same workflow.

Phase 2: research and spend credits only on keepers

Use signal-research-dossier for the qualified accounts. Require two sourced, dated signals when available: a new location, job opening, workflow complaint, tool migration, or public service change. Run contact-discovery only for accounts that remain above the threshold. Find the operator closest to the workflow and one economic buyer.

Copyable prompt: Research the 20 qualified accounts. Keep only those with current evidence of [trigger]. For the keepers, find one operator and one buyer. Stop before any paid contact lookup if the account lacks evidence.

Credit gate: the human approves the keeper list before email or phone discovery. Output: no more than 25 people across 15 accounts. Stop condition: the personalisation relies on generic company facts instead of workflow evidence.

Phase 3: draft the three-seat probe

Use cold-email-first-touch or ai-authored-campaign to create a draft campaign. Every message must state the narrow result, why this account fits, the paid nature of the pilot, the honest boundary, and one ask. Run outreach-qa-audit before human review. Do not imply that the product already has automation it does not have.

Copyable prompt: Create a draft only. Offer three paid pilot seats for [result] by [date] at [price]. Use the account's verified workflow signal. State that [capability] is manual or excluded. One ask: a 20-minute qualification call. Do not activate or send.

Approval gate: the founder reviews every message, price, claim, and exclusion, then decides outside the agent whether to activate. Pass condition: three buyers pay under one scope. Stop condition: replies demand three different products.

Phase 4: turn objections into the next iteration

Classify replies with reply-triage. Store objections as pricing, trust, timing, missing capability, wrong buyer, or unsafe scope. Feed repeated objections into Content Studio as source material for a workflow explainer, comparison, checklist, or setup guide. If useful content attracts visible engagement, capture those people as a separate signal audience, score them, and require the same qualification and approval gates before outreach.

The loop is small by design: 50 discovered accounts → 15 qualified → at most 25 contacts → three paid seats → one fulfilment ledger. Lead Scorer makes the research and drafting repeatable. The founder remains responsible for the promise, payment, delivery, and decision to build.

Checklist

• One narrow workflow has five consistent operator accounts.
• The first result can be delivered now with existing tools and manual work.
• Price, deadline, exclusions, and refund rules are written.
• Only qualified accounts receive the three-seat probe.
• Payment, not praise, is the demand signal.
• Every fulfilment and support step has a repetition count.
• Customer dependencies are removed through defaults and training.
• Custom software waits for repeated, paid capability pressure.

Sources and limits

The primary source is Startups For the Rest of Us episode 844, audited from the first character to the effective end. Henderson's account of the three external pre-sales and first 34 home-configured systems is retrospective and founder-reported. No public invoices, customer names, or archived forum post were located.

American Coin-Op independently reports the February 2025 sale of system 1,000 and identifies three earlier internal Liberty Laundry systems. The company history, a second founder interview, and an independent Clean Show report support the 2016 start, reseller-to-cloud transition, narrow workflow, and integration demand.

Sources disagree on whether five or six companies requested integrations in 2019, so this course says “at least five.” Company and podcast estimates of the US laundromat count also differ, so no exact market-size claim is used. The 1,300 systems, seven-figure ARR, first 34 shipments, and churn quality remain founder-reported. Later scale validates a durable business; it does not prove that every new founder should copy the hardware model or expect the same result.