A side project that’s ready to charge money runs into a strange gap: the product exists, the code works, but there’s no actual pricing page to send someone to. Building one inside your app means touching whatever framework it’s built in, wiring up navigation, and probably fighting your own component library for something that’s really just three cards and some text.
This covers what a pricing page needs to actually convert, and why it doesn’t need to live inside your app to do that.
Why pricing pages are worth building separately
A pricing page gets shared more than almost any other page on a small product’s site — in tweets, in Slack messages, in “hey is this worth it” DMs from someone considering signing up. That means it needs to load fast, work without an account, and stand on its own without the rest of your app’s navigation around it. Building it as a standalone page rather than a route inside your authenticated app achieves all three by default.
It also means you can iterate on pricing without a deploy. Testing a different price point or plan structure becomes a content edit instead of a code change and a release — which matters more than it sounds, because pricing is one of the things indie makers change the most in the first few months after launch.
What actually needs to be on the page
- Clear tiers, if you have more than one. Two or three plans, not five — more options at this stage usually means more hesitation, not more revenue.
- What’s actually included, specific enough that someone can tell the tiers apart without guessing.
- The price itself, unambiguous. “$9/month, billed monthly” beats a price with an asterisk pointing to fine print.
- A single clear call to action per tier — “Start free trial” or “Get started,” not three competing buttons.
Keeping it separate from your app’s code
The case for building this outside your main codebase is the same as for any other marketing-facing page: it shouldn’t depend on your app being up, your auth system working, or your deploy pipeline finishing to load. Carrd is a reasonable fit here — pricing tables, clear typography, and a page that loads in under a second, without pulling in your app’s entire dependency tree for three pricing cards.
Structuring tiers people can actually compare
Name tiers by who they’re for, not just a tier number
“Starter,” “Pro,” and “Team” tell a visitor which one is meant for them. “Tier 1,” “Tier 2,” “Tier 3” makes them do that work themselves, and some visitors won’t bother.
Highlight one plan, not all three equally
A visually emphasized “most popular” tier reduces decision fatigue — most people default to whichever option is presented as the sensible middle choice, and giving them that signal speeds up the decision rather than manipulating it.
Answer the obvious objections nearby
A short FAQ section below the pricing table — can I cancel anytime, is there a free trial, what happens if I exceed a limit — clears the most common hesitations without needing a live chat widget standing by.
What to avoid
Skip false urgency (“price increases in 48 hours” on a page that’s been live for months) — it’s a well-known pattern at this point and erodes trust with exactly the technical audience most side projects are trying to reach. Skip hiding the actual price behind a “contact us” for anything except genuine enterprise tiers; for a self-serve product, an unclear price reads as more expensive than it probably is.
Handling currency and regional pricing
If you have customers outside your home market, decide early whether to show one price globally or adjust by region. Showing a single USD price to everyone is the simplest approach and the right default for most small products — regional pricing adds real complexity (currency conversion, tax handling, arbitrage between regions) that’s rarely worth solving before you have meaningful international volume. A clear note like “prices in USD” avoids ambiguity without committing to a system you don’t need yet.
Testing and updating it
Because the page lives outside your app’s release cycle, testing a new price or a reworded tier is a five-minute edit instead of a pull request. That’s worth using — pricing pages benefit more from iteration than almost any other page on a site, and the friction of a full deploy is often the real reason it never gets revisited after launch.
Quick checklist
- Stick to two or three tiers, named for who they’re for.
- State the price plainly — no fine print asterisks doing the real explaining.
- Give each tier one clear call to action, not several competing ones.
- Address common objections in a short FAQ below the table.
- Keep the page separate from your app so pricing changes don’t require a deploy.
A pricing page’s only job is helping someone decide quickly. Simple, fast, and honest about the price beats polished and complicated every time.
Tested firsthand
