Zero to Public

How to Price a Tiny Product Before You Have Traffic

A practical, operator-first guide to pricing a tiny product before you have traffic, including how to choose a starting price, test demand, avoid undercharging, and adjust with evidence.

2026-07-19 · field notes for public builders

Pricing a tiny product before you have traffic is less about discovering the perfect number and more about choosing a useful starting point. Set a price that reflects the problem’s value, is simple enough to explain, and gives you room to learn from real conversations and purchases.

You do not need thousands of visitors to price a product. You need a clear customer, a painful enough problem, and a willingness to make a specific offer.

Start with the problem, not your costs

Your hosting bill, API usage, design time, and payment fees matter. They help you understand whether the product can be viable. But they should not be the main source of your price.

Customers are not buying your server costs. They are buying a result: fewer hours spent on a task, less uncertainty, more revenue, fewer mistakes, or a small improvement that makes their work easier.

A useful first question is:

> If this product works, what becomes easier, faster, safer, or possible for the customer?

The answer does not need to be dramatic. A tiny product can solve a narrow problem and still be valuable. A tool that saves a consultant an hour every week, helps a team avoid one recurring error, or removes an annoying manual step may deserve a real price.

Choose the customer before choosing the number

The same product can have different prices for different buyers. A personal productivity tool, a freelancer workflow, and an internal business tool may share features but not economics.

Before pricing, write down one primary customer profile:

You are not trying to calculate an objectively correct price. You are trying to understand the range in which a purchase would feel reasonable.

A solo founder selling to hobbyists may need a low-friction one-time purchase. A product used by a business may support a higher recurring price if it becomes part of an ongoing workflow. Neither is automatically better. The important thing is matching the offer to the customer’s context.

Use a simple starting model

When you have no traffic and limited evidence, complexity creates the appearance of rigor without producing much insight. Start with one of three models:

| Product situation | Sensible starting model | Why it works |
|---|---|---|
| Clear, repeatable utility | Monthly subscription | Revenue matches ongoing value and maintenance |
| Narrow tool with a defined outcome | One-time purchase | Easy to understand and buy |
| Service-like product or high-touch workflow | Paid setup or higher tier | Captures implementation and support effort |

For many tiny products, a single paid plan is enough at launch. You can add tiers later when customers show you meaningful differences in usage, support needs, or willingness to pay.

Avoid building a pricing page with five plans before you have learned what customers value. The first version of your pricing is a research instrument, not a permanent monument.

Price for a meaningful decision

A price should be high enough that a purchase tells you something. If everyone says yes instantly, you may have made the decision too easy—or you may simply be talking to exceptionally friendly people.

Likewise, a price that produces no interest is not automatically evidence that the product is too expensive. The problem may be weak positioning, an unclear promise, the wrong audience, or insufficient trust.

Your goal is not to maximize early conversion at any cost. Your goal is to find out whether a specific person will exchange money for a specific result.

That means asking for the sale directly:

> I’m building this for people who need X. It does Y. The price is Z. Would you like to try it?

A real offer creates better information than compliments, waitlist signups, or vague statements such as “I’d probably use that.”

If you are unsure, test a price range

You can test pricing before you have meaningful traffic through direct outreach, small communities, existing relationships, or conversations with potential users. Keep the test narrow and honest.

Show the same product and promise to similar customers at different prices over time, or present two clearly defined packages with different levels of value. Record what happens:

Do not change the price every time someone hesitates. Hesitation is a signal, not a verdict. Look for patterns across several conversations or purchases.

You can also pre-sell a limited first version. Explain exactly what is included, when it will be available, and what early customers are helping shape. A founding price can be useful, but give it a reason and an end point. Permanent “early bird” pricing teaches customers to wait.

Make the offer easier to evaluate

Before lowering your price, improve the information around it. A customer should quickly understand:

Tiny products often fail to sell because the buyer has to do too much interpretation. “AI-powered workflow automation” is less useful than “Turn a client call into a clean project brief in two minutes.”

Specificity makes a price easier to judge. It gives the customer something concrete to compare with their current process.

Watch for the most common pricing mistakes

Starting too low

Low pricing can attract people who are interested in cheap tools rather than people who have the problem. It can also make support uneconomical and create an awkward future increase.

You can offer a discount without making the list price artificially small. A lower founding price is easier to explain than a price you secretly hope to triple later.

Copying competitors blindly

A competitor’s price reflects its audience, product maturity, brand, distribution, and cost structure. Use competitors to understand category expectations, not to outsource your judgment.

Adding features to justify the price

When people resist an offer, founders often add features. That may increase complexity without increasing value. First ask whether the core promise is clear and whether the right customer is seeing it.

Confusing attention with demand

Likes, replies, and compliments are encouraging. They are not purchases. Keep a separate record of attention signals and commitment signals. Payment, a scheduled onboarding call, or a repeated use pattern carries more weight.

Refusing to change the price

Your first price is a hypothesis. If customers consistently describe the product as useful but too limited, consider packaging. If they buy quickly and ask for more, consider raising the price for new customers. If nobody understands why it matters, fix the message before touching the number.

A practical launch checklist

Pricing before traffic is an act of commitment. You are saying who the product is for, what result it creates, and what that result is worth in context. You will revise the number. That is normal. The mistake is waiting for traffic to give you permission to make an offer.

Build the smallest useful product, put a clear price beside it, and let the market answer with behavior.

If you want a practical guide to building and sharing internet projects in public, read or buy *From Zero to Public*. It is for the messy stretch before momentum arrives—the part where you choose the idea, make the first version, find the first users, and keep going where others can see you.

FAQ ### How much should I charge for a tiny product with no traffic? Start with a price that reflects the customer’s likely value, not just your costs. Choose one simple price, make a clear offer, and use real conversations and purchases to adjust it.

Should a tiny product be a subscription or a one-time purchase? Use a subscription when the product provides ongoing value or ongoing costs are meaningful. Use a one-time purchase when it delivers a defined outcome and can be maintained without continuous service.

How can I test pricing without an audience? Talk directly to potential customers, share a specific offer, and ask for a purchase or pre-order. Track payments, objections, and usage rather than relying only on compliments or signups.

What should I do if people say the product is too expensive? Determine whether they object to the price, the product’s value, the audience fit, or the clarity of the offer. Improve the promise and packaging before automatically lowering the price.

Build in public from zero.

From Zero to Public is the operating manual for turning small internet projects into visible, buyable assets.

Get the book