Guide
How to price your first offer without guessing forever
Pricing becomes easier when the offer, scope, customer, and buying moment are concrete.
Updated · Authored by Stefan Stoll · Maintained by Stefan Stoll and Wesley Lin
Overview
A practical path from idea to signal.
The first price is a learning tool. It should be tied to a specific result, a manageable scope, and a buying conversation that tells you what the market believes.
Visual field guide
A first price needs three inspectable parts
A number becomes defensible when it covers delivery, relates to credible alternatives, and buys a clearly bounded scope.
- Delivery floorDirect costs + delivery time + current fees + a real risk buffer.
- Value referenceThe buyer's credible alternatives, current workaround, and evidenced effort or outcome.
- Scope boundaryDeliverables, timeline, revisions, usage, support, and exclusions.
At a glance
Illustrative first-price worksheets: replace every input
| Offer | Floor calculation | Value reference | Scope boundary |
|---|---|---|---|
| Landing-page service | 8 hours × 50 units + 50 costs and fees + 50 buffer = 500-unit floor | The buyer's credible DIY and service alternatives | One page, one revision, analytics setup, two-week handoff |
| Template bundle | 480-unit creation and update target ÷ 40 assumed sales = 12 units before per-sale fees | Setup time and quality compared with free substitutes | Named formats, license, updates, support, and refund terms |
| Small-software pilot | 10 hours × 60 units + 100 infrastructure and support + 100 buffer = 800-unit floor | The measured workflow cost or effort, without promised savings | Users, usage, integrations, onboarding, support, and cancellation |
Quick answers
Practical answers for the next decision.
How do I price a first offer for a new business idea?
Foundable helps price a first offer by choosing a specific buyer, naming the paid outcome, packaging a clear scope, anchoring price to value or alternatives, reducing risk, and asking for a concrete payment decision.
Method and scope
This is a Foundable editorial decision aid, not a market-price estimator. For each offer, calculate a delivery floor, write down the buyer's credible alternatives as a value reference, and bind the number to explicit scope. The table uses invented currency units and round numbers so the arithmetic is inspectable; replace every input with your own costs, time, fee schedule, risk tolerance, buyer evidence, and terms before quoting a price.
Set the floor, value reference, and scope
Start with a delivery floor: direct costs, estimated delivery and support time at your minimum acceptable rate, payment or platform fees, and a buffer for the risks you are actually taking. Payment fees vary by provider, method, country, and plan, so use the current terms for the account you will actually use instead of hard-coding a generic percentage. Next, compare the offer with the buyer's current workaround, alternatives, time saved, risk reduced, or outcome gained; that is a value reference, not permission to claim every dollar of value. Finally, define what the price buys: deliverables, timeline, revisions, usage or access limits, support, and exclusions. A price below the floor is unsustainable, a price with no value logic is hard to defend, and a price with vague scope is an unlimited promise.
Service example: price a bounded package
For a landing-page service, the package might include one page, one revision round, analytics setup, and a launch handoff within two weeks. Build the floor from delivery hours and direct costs, compare the package with the buyer's slower do-it-yourself path and credible service alternatives, then quote one fixed price for that exact scope. Charge separately for extra pages, copy research, ongoing experiments, or additional revisions so the first sale cannot silently expand.
Digital-product example: price saved effort, not file count
For a template or guide bundle, direct delivery costs may be small, but the floor still includes payment fees, expected support and refunds, and a reasonable recovery of creation and update work. Define the user, job, included formats, update policy, license, and support before testing the price. Compare the saved setup time and quality of the result with free substitutes. Use a real introductory price only when its end condition is stated; do not manufacture urgency with a permanent fake discount.
Small-software example: bound usage and support
For a small tool that automates one recurring workflow, include infrastructure, support, billing fees, and maintenance in the floor. Anchor value to the specific time, error, or outside-service cost the workflow may reduce, without promising savings you have not measured. Define users, usage, integrations, onboarding, support, and cancellation. A paid pilot can test the workflow and service load before you choose a monthly or annual subscription.
Use buyer response to change one variable
A yes, deposit, invoice approval, checkout start, specific objection, or silence is pricing evidence only in context. If buyers understand the value but resist scope, tighten the package; if they want the outcome but lack trust, improve proof or reduce first-step risk; if delivery would lose money, raise the floor or redesign the work. Test one change at a time so you can tell whether the buyer, value story, scope, or number moved the response.
Limitations and corrections
The worksheet does not estimate willingness to pay, market size, profit, taxes, regulatory obligations, or the price a specific buyer will accept. Illustrative arithmetic is not a quote, benchmark, financial forecast, or promise of savings. Validate assumptions through actual buying conversations and qualified accounting, tax, legal, or industry advice where needed. Send factual corrections through Foundable's contact page; material corrections require source review and a new substantive update date.
What you leave with
Useful outputs, not another vague plan.
Workflow
How to run it in Foundable.
Clarify the result
Ask Ted to describe what the buyer receives and why it is worth paying for.
Choose the first package
Define scope, timeline, price, risk reversal, and what happens after purchase.
Make the ask
Create the sales copy, call script, or checkout path and test it with real buyers.
Iterate from buyer response
Use objections and conversions to tighten the package and price.