A founder I know spent three months chasing a "promising" enterprise deal: weekly calls, a technical deep-dive, a security questionnaire the length of a novella, and a free proof of concept that ate 90 engineering hours. The champion went quiet in week eleven. The deal died in procurement; the only artifact was a well-documented POC nobody paid for and nobody will ever run.

Free pilots feel like momentum. They're usually the opposite. The client has no skin in the game, so the project drifts, and the person absorbing the cost is you. The fix is a paid pilot software engagement: small, fixed-scope, real work that both sides take seriously because both sides put something in.

Here's how to structure one, price one, and spot the deals that were never going to close.

A paid pilot is a 2-to-4-week, fixed-price project that delivers one production-usable workflow for real users, typically priced between $8k and $25k. The buyer caps their downside at a known number and gets working software instead of slideware; the builder gets paid, gets real requirements, and gets the truth about whether this client deserves a bigger commitment. Done right, it's the lowest-risk way for both sides to start.

The Free Pilot Trap

The logic of free sounds generous: reduce friction, prove value, win the deal. In practice, free inverts the risk. Your cost is real, since engineering hours are the most expensive thing a small firm owns, and the client's cost is zero. A zero-cost project competes with everything else on their desk and loses to anything urgent.

There's a quieter second problem: free attracts tire-kickers. Serious buyers have budgets and pain; unserious ones have curiosity and calendar space. A price, even a small one, is the cheapest filter you'll ever buy.

What a Paid Pilot Software Engagement Actually Is

Definition in one breath: two to four weeks, one named workflow, fixed scope, fixed price, and a deliverable running in production for real users on the last day. Not a demo environment. Not a discovery phase with a PDF at the end. Working software, however narrow.

Scope discipline is the whole trick. "One painful workflow" means one: the report that takes a day to assemble by hand, the order-entry screen everyone hates, the reconciliation spreadsheet with a dedicated caretaker. If the client wants three workflows, that's three pilots or one bigger engagement. Pick on purpose.

This pilot sits at the front of the pricing ladder. For the menu of what comes after, see the FDE cost breakdown and the comparison of retainer vs. project structures.

Why Both Sides Win

The buyer's win is capped downside. Instead of approving $150k on faith, they approve $12k and get a working system plus the answer to the only question that matters: can these people actually deliver here, with our data, our constraints, our Denise in accounting. If the answer is no, they learned it for the price of a used car.

For the builder, the win is information plus cash. A paid pilot teaches you more about a client than any sales call: how fast they decide, whether data access takes a day or a month, who blocks things. A client who fights a $10k pilot for six weeks is telling you exactly what the $150k engagement would feel like. Believe them. The pilot fee is a rounding error compared to finding that out in month four of a master services agreement.

Pricing It

Price against value, not hours, but sanity-check against hours so you don't accidentally work for free with an invoice. Illustrative bands: a simple dashboard or workflow pilot lands at $8k to $12k; anything touching a gnarly ERP or multiple data sources lands at $15k to $25k. Below $5k you've priced a favor. Above $30k it's not a pilot anymore; it's a project wearing a pilot's hat.

The sizing rule that keeps everyone honest: find the one workflow that costs the client real pain every week, and anchor the price to a fraction of that pain. Say the spreadsheet caretaker burns a day a week on reconciliation; that's roughly $25k a year of salary, and a $12k fix becomes an easy yes with no spreadsheet model required. For the buyer-side version of this math, budgeting a first engagement walks through it.

The Proposal Template

A pilot proposal fits on two pages. Longer proposals signal that somebody is nervous:

  1. The problem, in their words. One paragraph quoted from your calls, so they know you heard it.
  2. The one workflow. Named, with its current weekly cost.
  3. In scope / out of scope. The out-of-scope list is where trust gets built.
  4. Timeline. Start date, demo date, delivery date, and what you need from them: data access, one decision-maker, 30 minutes a week.
  5. Price. Fixed, with payment terms.
  6. Success criteria. Two or three observable outcomes, not vibes.
  7. What happens next. What a full engagement looks like if the pilot works.

What Happens After

Treat the pilot as a filter, not a funnel. In our illustrative-but-typical experience, 60 to 70 percent of paid pilots convert to a larger engagement; the rest end politely with a working tool and a reference. Both are wins. The failure mode isn't a pilot that doesn't convert. It's a pilot that converts a client you should have filtered out.

On pricing the follow-on: credit the pilot fee against the bigger engagement when the pilot was genuinely exploratory and you want the deal; don't credit it when the pilot delivered standalone value. Both positions are defensible. What's not defensible is deciding mid-conversation.

Red Flags on Both Sides

Buyer red flags about a builder: a proposal with no out-of-scope section, hourly pricing with no cap, and an eagerness to start "next week" without having asked about your data. Builder red flags about a buyer: "we can't pay but the exposure is huge," a decision-maker who won't attend a 30-minute kickoff, and data access described as "complicated" with a laugh.

A paid pilot is how both sides stop guessing. Charge for it, buy it, and let the small truth arrive before the big invoice does.