How to Sell Software as a Service: Start With a Pilot

Why it matters

Getting someone to pay before you build is useful evidence. The difficult question is what that payment proves. A buyer might be funding a custom solution, purchasing your expertise, or testing something they could eventually subscribe to. Those are different businesses, even when the first invoice looks similar.

In this video, Bgo says he studied more than a thousand developers and found that they sold before building. The supplied material does not include an inspectable dataset, selection criteria, or a comparison with unsuccessful founders. I would treat that claim as the author's account of a pattern rather than research establishing a reliable route to wealth.

What interests me is the practical experiment underneath the claim: replace vague enthusiasm with a specific commercial commitment. My addition would be to measure delivery effort and renewal behavior from the beginning. A first payment can justify a small project. Building a subscription business takes evidence that the same offer can serve independent customers at a sustainable cost.

Key points

• 0:33 Bgo introduces selling before development as the common pattern. A workable version requires being explicit about what exists today, what remains to be built, and what the customer is purchasing.
• 1:39 Coding becomes a way to avoid commercial rejection. The useful diagnostic is whether another feature addresses something a buyer actually requested or merely postpones asking for a decision.
• 2:43 The author recommends looking for an existing budget by investigating previous attempts to solve the problem. Past spending is a promising lead, but approval authority and the ability to switch still need checking.
• 3:50 The pitch centers on an outcome, a deadline, and a price. Applying that advice requires an observable result and a shared way to assess whether it happened.
• 4:22 Bgo describes a guarantee as inexpensive when the developer knows how to deliver. That overlooks the cost of refunds, unrecoverable working hours, and dependencies outside the developer's control.
• 4:56 Three customers buying the same offer, or $15,000 in monthly recurring revenue, are proposed as commitment thresholds. I would use them as prompts for closer evaluation; neither number establishes repeatability on its own.
• 5:31 The video places greater investment in acquisition after the initial sales signal. Before increasing outreach, I would also check delivery margins, ongoing usage, and whether customers have a reason to renew.

How to apply

How to sell software as a service through a paid pilot

Start with a narrow workflow that happens often enough to observe during a short engagement. Consider a hypothetical wholesaler whose staff manually compare incoming purchase orders with records in an internal system. Your initial offer could cover one order format, one location, and two weeks of operation.

That gives the buyer something concrete to evaluate. It also gives you a chance to discover the actual delivery workload before designing a platform around assumptions.

1. Investigate the most recent incident

Speak with both the person doing the work and the person who can approve spending. Ask about the last time the problem occurred:

• Who had to intervene, and how long did it take?
• What happened because the task was delayed or performed incorrectly?
• What have you already tried or purchased?
• Who could approve a pilot, and when could it begin?

Ask to walk through an example using synthetic data or an appropriate demonstration sample. Look for exceptions: missing fields, duplicate orders, and decisions that depend on someone's unwritten knowledge.

Existing spending is evidence worth investigating, but the absence of a software bill does not automatically eliminate an opportunity. Staff time may be the current workaround. You still need to establish urgency and willingness to pay. Also distinguish capacity from cash savings: freeing five hours creates available time, while reducing expenses requires an actual change in spending.

2. Define an acceptance test before quoting

Write a one-page scope covering the workflow, transaction volume, required access, customer responsibilities, and evaluation method. Explain which components already exist and which you will develop during the pilot.

For the wholesaler, the deliverable might compare one purchase-order format with an export from the internal system, then flag discrepancies for human review. The acceptance test could compare the assisted process with manual checking on a sample agreed in advance.

This is easier to evaluate than promising to transform operations or increase revenue. It also makes hidden dependencies visible. Does the export exist? Are the required fields present? Can the customer provide authorized access?

Do a short feasibility check before committing to a deadline. Selling before building does not require quoting an unfamiliar integration without investigating whether the necessary access is available.

3. Put a limit on delivery effort

Use a simple cost model. In an illustrative $1,500 pilot, 15 hours valued internally at $60 plus $100 in infrastructure leave $500 before taxes, sales effort, and other expenses. If delivery expands to 25 hours, those hours and infrastructure alone cost $1,600.

The point is to decide how much effort the experiment can absorb and notice when the scope exceeds that allowance. Track meetings, onboarding, troubleshooting, and support alongside development. Work without a commit still consumes your capacity.

If you offer a refund, define the acceptance criteria and keep the potential refund available. Your time and supplier bills remain costs even if the customer gets their money back. Choose a commitment you can absorb while learning how to deliver the offer.

4. Separate the first service from the subscription

The guide linked in the video description currently describes itself as being for engineers willing to start with a service. That is useful context for the video's SaaS framing: a customer paying for custom implementation may be validating a consulting offer first.

Separate implementation work from ongoing operation in your proposal and your records. If there is a monthly fee, explain the continuing work it covers, such as recurring processing, hosting, monitoring, or support within stated limits.

Payment installments on a finished project do not establish recurring demand. For a subscription, investigate what continues to provide value after setup and why the customer would keep paying. The renewal conversation is part of the experiment.

5. Compare independent buyers

Keep a small evidence log:

| Evidence | What to record | |---|---| | Purchase | Who approved it and why they acted now | | Delivery | Working hours, external costs, and exceptions | | Reuse | Components that worked unchanged for another buyer | | Continuation | Usage after onboarding and the renewal decision |

Try offering the same narrowly defined result to another independent company before investing in a broader platform. Notice whether the promised outcome stays consistent or each sale requires a different system.

Three customers can provide useful learning, especially when they purchase similar work at comparable prices. Three unrelated custom projects tell you something else: you may have demand for your development services, with product repeatability still unproven.

I would increase investment when delivery becomes predictable and customers demonstrate a continuing reason to pay. That is a more useful milestone than reaching a revenue number while every new account adds another bespoke workload.