Price a micro-SaaS with value and cost in view

Price the offer as one connected system

The number on the pricing page is the last decision, not the first. A workable offer connects what the customer values, how access is packaged, what the customer is prepared to approve, and what the account costs to serve. Change one part and the others may stop making sense.

Part of the offer	Question it must answer	Warning to investigate
Value metric	Which unit grows when the customer receives more of the outcome?	The metric is easy to bill but feels unrelated to value, or the customer cannot predict it before purchase.
Packaging	Which differences belong in separate offers because they reflect distinct needs, risk or service?	Tiers are padded with arbitrary limits or features that make the right choice harder to identify.
Willingness to pay	What will this buyer approve for this problem, in this context, now?	Interest is measured through compliments or free signups while the price remains hypothetical.
Support cost	How much setup, review, recovery and ongoing help does an account require?	A small account consumes founder time that the package neither limits nor pays for.
Price test	Which uncertainty will the next offer or conversation reduce?	Several variables change at once, so a yes or no teaches you little.

Use the value metric to hold the package together

A seat can fit collaborative work. Usage can fit repeated processing. Records, locations, clients or reports may fit products where those units closely track the customer's job. None is universally correct. Check whether the buyer understands the unit, can estimate a normal bill and sees a fair reason for price to rise.

Packaging then decides which customer situations you are willing to serve. Separate offers when access, risk, workflow complexity or support genuinely differs. Do not create tiers merely to imitate a familiar pricing table. If every serious customer needs the same core outcome, a simpler package may produce a clearer conversation.

Evidence worth recording

The price and package shown to the buyer.
Who approved or rejected it, and what they compared it with.
Which limit or service term caused confusion.
The setup and support work the account actually required.

Conclusions to avoid

A single rejection means the price is too high.
A quick acceptance proves the price is optimal.
A competitor's tier should become your tier.
One margin or conversion threshold fits every product and stage.

Run price tests that leave a readable trail

State the uncertainty: price level, metric, package, trial model or service boundary.
Choose a buyer segment and keep the offer stable enough to compare conversations.
Present a real decision with the terms written plainly.
Record acceptance, refusal, delay, objections and support assumptions without treating silence as a verdict.
Change one important variable when practical, then repeat with the next relevant buyer.

Start with the value-metric article if the billing unit is unclear. Move to trial versus paid pilot when the buyer needs experience before committing. Use the cost-model and packaging guides when support or infrastructure makes the offer hard to sustain. Read the price-change material after you can explain what existing customers bought and how the new terms affect them.

Write the next offer before debating the next price

Put the buyer, outcome, value metric, included service, limits, price and decision date on one page. Mark which part is an assumption. After the conversation, record what the buyer accepted, questioned or compared. Review the support work separately from the reaction to the number. That gives the next test a reason to exist.