How to judge minimum viable offer tools by the jobs they do

No brands are named on this page. Minimum viable offer tools for a first offer should support a promise, a price, and a person doing the work by hand; they need to do four narrow things well and get out of the way.

What follows is those four jobs, the properties that make a tool usable for each, and the one test to run before you commit to anything paid.

Judge categories, not brands: a payment processor or payment link takes payment; a page, document, or form states the terms; a shared folder with a checklist supports manual delivery; and a spreadsheet or plain-text file keeps the log. A payment link passes only if the buyer sees the terms before paying and you can issue a refund yourself; a delivery workflow fails if it requires setup before the first delivery. These are examples of tool categories, not product recommendations.

What to take away

Job one: take money from a stranger

What the tool must let you do. Accept a payment or a deposit from someone who has never met you, on a page they can read before paying, with a receipt that states what they bought. Issue a refund yourself, without asking anyone, on the day you decide to.

What matters more than features. How long the money takes to arrive, and what happens on a dispute. Both are invisible until they matter, and the first sale is the wrong time to learn either.

Disqualifying property. Anything that cannot refund a payment in one action. Being able to refund quickly is what makes selling something unfinished defensible.

Where charges recur, make cancellation as easy as sign-up. The Federal Trade Commission's (FTC) Negative Option Rule may apply to recurring-charge offers, so check its current applicability to your offer. The FTC's information on negative-option offers can help you identify the relevant requirements. Keeping a record of cancellation reasons also preserves evidence about why people leave.

Job two: state the terms

What the tool must let you do. Publish, in one place a buyer sees before paying, what they get, when it arrives, what it costs, and how to get out. A page, a document, a form: the format matters far less than the sequence, which is that the terms come before the payment.

What matters more than features. Whether the terms can be changed after somebody bought under them, and whether you keep a copy of the version each customer actually saw. Keep it. It is one file and it settles disputes.

If money changes hands before delivery, the FTC's Mail, Internet, or Telephone Order Merchandise Rule sets requirements for covered orders when sellers cannot ship within the promised time, including notice to buyers and a prompt refund. That is a reason for the delivery window to live in your terms rather than only in a marketing headline. See the FTC's Mail, Internet, or Telephone Order Merchandise Rule.

Disqualifying property. Anything that puts a disclosure after the payment step, or in a place a buyer would have to go looking for. The point of a disclosure is that it is read, which is what the FTC's * .com Disclosures: How to Make Effective Disclosures in Digital Advertising* guidance addresses: placement, proximity, and prominence rather than mere presence.

Job three: deliver it by hand

Manual delivery is the point, not a stage to be escaped. The tooling should make the manual work reliable, not make it look automatic.

What the tool must let you do. Hold a checklist you can run per customer, keep the working files where you can find them, and record when each step actually happened. A shared folder and a numbered list is a complete implementation of this.

What matters more than features. Whether you can see, in one glance, which customers are mid-delivery and which step each is on. That is the thing that fails at customer number seven.

Disqualifying property. Anything that requires configuring a workflow before the first delivery. You do not know the workflow yet; the first three deliveries are how you find out.

The cut you are making here is real and should be visible to the buyer. Describing the work as done by a person is a stronger claim than most alternatives, and the mistakes around hiding it are covered in the offer mistakes.

Job four: keep the log

What the tool must let you do. Append. That is the entire requirement, and it rules out anything that encourages overwriting.

What matters more than features. That it can be read in a year by somebody who was not there. Plain text ages better than anything else.

Disqualifying property. A structure that forces a reason to be picked from a list. Options do most of the work of answering, and the difference between two refusals with the same label is usually the finding. The full treatment is in the pricing questions.

The lock-in test

Before paying for anything, answer one question: can I export every customer, every term, every payment, and every note to a plain file today, and read it without logging in.

If not, the record is on loan. That matters more here than at any later stage, because the first offer's whole output is evidence, and evidence you cannot take with you is not much of an asset.

What no tool provides

The promise. The price. The person who does the delivery. The willingness to ask somebody for money and hear no.

The specific risk in this period is a fortnight assembling infrastructure for an offer nobody has been asked to buy. It is comfortable, looks like progress, and delays the only thing that produces information.

The sequence that avoids it is in the offer framework, and the argument for keeping the whole thing small is in minimum viable offers.

A useful check: if you have spent more hours on tools than on conversations with potential buyers, the ratio is the finding.

The version that fits on one page

A payment link with a deposit option. A single page stating what they get, when, for how much, and how to stop. A folder per customer with a numbered checklist. One text file, appended, holding every quote, refusal, and delivery note.

That is enough to run a first offer to ten customers, and everything in it exports. What to do with what it produces is the subject of offer testing.

Common questions

Why no product recommendations?

Because they age badly and because the choice does not decide the outcome. The requirements above can be checked against whatever you already have.

Do I need a contract?

You need written terms the buyer saw before paying. Whether that is a contract depends on what you are selling and where, and it is worth asking someone qualified once rather than guessing repeatedly.

Is a landing page builder necessary?

No. A single page of plain text stating the offer, the price, and the terms outperforms most designed pages at this stage, because at this stage the question is whether the offer is wanted, not whether the page converts.

What about invoicing rather than a payment page?

Fine, and often better for business buyers. The requirement is unchanged: terms visible before payment, refund possible in one action, and every quote logged.

When should I move off the one-page version?

When the manual delivery has failed twice for the same structural reason. Not before, because you will automate the version you are about to stop doing.