
Last year I had what I thought was a brilliant SaaS idea. A niche project management tool for wedding planners. I'd done the customer interviews, joined the Facebook groups, lurked in the subreddits. The pain point was real. People were using spreadsheets and WhatsApp groups to coordinate events worth tens of thousands of euros. Surely they'd pay for something better.
I was about three days from opening my code editor when a friend — a serial founder who'd burned through two failed products before finding one that worked — asked me a question that stopped me cold:
"What are your unit economics?"
I didn't have an answer. Not even a rough one. I had enthusiasm, a vague pricing notion ("maybe twenty euros a month?"), and zero understanding of whether the numbers would ever work. So before writing a single line of code, I spent a weekend doing nothing but running numbers through free online calculators. What I found changed my entire approach — and probably saved me six months of wasted development time.
This is the process I now use for every idea, and it's the process I recommend to every founder who asks.
Every founder overestimates their addressable market. It's practically a law of nature. You see a big number — "the global wedding industry is worth three hundred billion dollars" — and you unconsciously assume that some meaningful fraction of that number is available to you. It isn't.
Your serviceable addressable market (SAM) is a tiny slice of the total
addressable market (TAM), and your serviceable obtainable market (SOM) is a tiny slice of that. For my wedding planner tool, the calculation went something like this:
Total number of wedding planners in my target markets (Netherlands, Belgium, Germany): roughly twelve thousand, based on industry association data and LinkedIn searches. Percentage likely to adopt a digital tool: maybe forty percent based on analogous adoption rates in similar professional niches. Percentage I could realistically acquire in the first two years with a small marketing budget: perhaps five percent of the adoptable market.
That gives me a realistic customer base of about two hundred and forty planners. At twenty euros per month, that's fifty-seven thousand six hundred euros in annual recurring revenue. Which sounds reasonable until you subtract hosting costs, payment processing fees, customer support time, and the opportunity cost of a year of development.
I ran these numbers through a simple revenue projection calculator. Input: average revenue per user, estimated customer count, monthly churn rate, and growth rate. Output: a month-by-month revenue projection that made it painfully clear that twenty euros per month wasn't going to work. I needed either a much larger market, a much higher price point, or a fundamentally different monetization approach.
This took me about fifteen minutes. Fifteen minutes that saved me from building a product with a structural revenue problem baked into its DNA.
After the market sizing reality check, I recalculated with higher price points. Forty euros per month. Sixty. Eighty. At each level, I used a break-even calculator to figure out how many customers I'd need to cover my estimated costs.
The exercise revealed something counterintuitive: the problem wasn't price sensitivity. Wedding planners regularly spend hundreds of euros on software (CRM, accounting, design tools). The problem was that my feature set didn't justify a price point high enough to make the unit economics work.
This is where many founders go wrong. They set their price based on what "feels right" or what competitors charge, without ever calculating what they need to charge for the business to be viable. These are completely different questions, and treating them as the same one is a recipe for building a product that acquires customers efficiently and loses money on every single one.
The calculation itself is straightforward. Your price needs to cover: direct costs per customer (hosting, payment processing, support time), a proportional share of fixed costs (development, marketing, overhead), and enough surplus to actually generate profit and fund growth. A pricing calculator that accounts for these components will give you a minimum viable price — the floor below which your business cannot sustain itself regardless of how many customers you acquire.
If your minimum viable price is above what customers will pay, you don't have a pricing problem. You have a business model problem. Better to discover that with a calculator than with your savings account.
Churn is the silent killer of SaaS businesses, and most founders dramatically underestimate its impact because they think about it in linear terms. "Five percent monthly churn doesn't sound that bad — I'm losing one out of twenty customers per month."
But churn compounds. At five percent monthly churn, you lose forty-six percent of your customer base in a year. To maintain flat revenue — not grow, just maintain — you need to replace nearly half your customers every twelve months. To actually grow, you need to acquire enough new customers to replace the churned ones and add net new revenue on top.
I used a churn impact calculator to model several scenarios, and the results were sobering. At three percent monthly churn with my projected acquisition rate, it would take fourteen months to reach breakeven. At five percent, I'd never reach breakeven because the churn would outpace acquisition. At two percent — an aggressive target for a new product — I'd break even in nine months.
This single calculation shaped my entire product strategy. Instead of building a broad feature set that might generate moderate engagement, I focused on building deep functionality around the specific workflows that would make the product indispensable — the kind of features that create daily habits and make switching costs high enough to suppress churn below that critical two percent threshold.
If you're bootstrapping, your runway is determined by your savings and your burn rate. If you're funded, it's determined by your raise and your burn rate. Either way, it's a number, and that number defines every decision you make.
I calculated my runway using a simple burn rate calculator. Monthly costs: hosting (initially minimal, maybe forty euros), payment processing (percentage-based, scales with revenue), a contractor for design work (eight hundred euros per month for three months), marketing budget (five hundred euros per month), and my own living expenses if I was working on this full-time.
Total monthly burn: approximately twenty-two hundred euros during development, dropping to about fifteen hundred after the design contractor finished. With twelve thousand euros in dedicated savings for this project, I had roughly six to seven months of runway before I'd need the product generating meaningful revenue or I'd need to go back to consulting.
Six months. That number influenced everything — the scope of the MVP, the marketing timeline, the feature prioritization. Without it, I'd have been making those decisions based on optimism rather than arithmetic.
Here's a pattern I see constantly in indie hacker communities: someone builds a product, launches it, gets some initial traction from their personal network and Product Hunt, and then discovers that acquiring customers through paid channels costs three times more than their annual revenue per customer.
Customer acquisition cost (CAC) is not something you can calculate precisely before launch. But you can — and should — estimate it based on industry benchmarks and basic channel economics. If you're planning to use Google Ads, you can estimate your cost per click for relevant keywords, multiply by an expected conversion rate, and get a rough CAC figure. For content marketing, you can estimate the cost of producing and promoting content against a realistic organic traffic projection.
I ran these estimates through a CAC calculator and immediately identified a problem. My target keyword ("wedding planning software") had a cost per click that would produce a CAC of approximately one hundred and sixty euros. At forty euros per month with a projected twelve-month average customer lifetime, my lifetime value was four hundred and eighty euros. An LTV-to-CAC ratio of three-to-one is generally considered healthy. Mine was right at that threshold — before accounting for any of the costs that eat into LTV.
This calculation prompted me to pivot my acquisition strategy entirely. Instead of paid search, I built a content-first approach targeting long-tail keywords with lower competition and higher intent. The CAC was lower, but more importantly, the exercise of calculating it forced me to think seriously about acquisition before I had a product to acquire customers for.
None of the calculations I've described require specialized software. Every single one can be performed with free online tools that take minutes to use. Revenue projections, break-even analysis, churn modeling, burn rate calculation, LTV estimation — all of these are available as browser-based calculators that require nothing more than entering your numbers and reading the output.
What's notable about the current landscape of online calculation tools is how comprehensive it's become. It's not just the English-language ecosystem — I discovered GratisRekenmachine while looking for Dutch-language financial calculators during my market research phase (my target market included the Netherlands), and was struck by how extensive the coverage was: financial calculators, business tools, mathematical utilities, all structured for quick answers to specific questions.
The point isn't any single tool. The point is that the barrier to doing rigorous numerical validation of a business idea has dropped to essentially zero. There's no excuse for not running the numbers anymore. The tools are free, they're instant, and they might save you from building something the math says can't work.
After a weekend of calculations, I didn't build the wedding planner tool. The numbers didn't work at the price point the market would bear, the addressable market was too small for low-touch SaaS, and the CAC for the primary acquisition channel was too high relative to LTV.
Instead, I used the same calculation process to evaluate three other ideas I'd been sitting on. One of them — a scheduling tool for freelance consultants — had dramatically better unit economics. Larger addressable market, lower churn (because scheduling is a daily-use feature), and a natural expansion path from individual to team plans that improved LTV without proportionally increasing CAC.
I built that instead. It reached ramen profitability in four months, which was two months ahead of the runway calculation's breakeven projection. Not because I got lucky — because the calculations told me to build something where the math worked before I started.
Let me distill this into a repeatable framework. Before you write code, open a browser and run these five calculations:
Calculation 1 — Realistic Revenue Ceiling
Multiply your serviceable obtainable market by your planned price point. If this number doesn't excite you, neither will your revenue.
Calculation 2 — Break-Even Volume
Divide your estimated fixed costs by your per-unit contribution margin. This tells you how many customers you need before you stop losing money. If the number seems unreachable in your first year, reconsider.
Calculation 3 — Churn-Adjusted Growth
Model your customer base over twelve months with realistic churn and acquisition rates. If churn outpaces acquisition, no amount of product improvement will save you — the model is structurally broken.
Calculation 4 — Runway to Breakeven
Divide your available capital by your monthly burn rate. If your runway is shorter than the time to breakeven from Calculation 2, you have a funding problem that needs to be solved before you start building.
Calculation 5 — LTV to CAC Ratio
Estimate your customer lifetime value and your customer acquisition cost for your primary channel. If the ratio is below three-to-one, your acquisition strategy needs rethinking.
How accurate are these pre-launch calculations?
They're directionally accurate, which is what matters. You're not building a financial model — you're testing whether the fundamental economics of your idea are plausible. If the numbers don't work with optimistic assumptions, they definitely won't work with realistic ones.
What if I don't know my churn rate before I've launched?
Use industry benchmarks. SaaS businesses serving SMBs typically see three to seven percent monthly churn. Consumer products tend to be higher. Enterprise is lower. Start with a benchmark and update it with real data as soon as you have it.
Should I use a spreadsheet instead of online calculators?
For the initial validation pass, calculators are faster and force you to focus on the key inputs without getting lost in formatting cells and building formulas. Once your idea passes initial validation and you need to model complex scenarios, a spreadsheet becomes more appropriate.
What if the numbers are borderline — not clearly good or clearly bad?
Borderline numbers should be treated as bad numbers. Your pre-launch estimates are almost certainly optimistic — everyone's are. If the math barely works under optimistic assumptions, it won't work under realistic conditions.
How long should this validation process take?
A weekend is enough for the initial pass. The calculations themselves take minutes each. The time goes into researching your inputs — market size, competitive pricing, channel costs. Don't let this become a procrastination tool; the goal is a quick sanity check, not a comprehensive business plan.
The most expensive mistake in the indie hacker world isn't building the wrong feature or choosing the wrong tech stack. It's building a product whose fundamental economics don't work. And the tragedy is that this mistake is almost always identifiable before you write your first line of code — if you bother to run the numbers.
Free online calculators have made "bothering" trivially easy. The calculations that would have taken an MBA student an afternoon now take anyone with a browser fifteen minutes. The question isn't whether you have access to the tools. The question is whether you're willing to let the math override your enthusiasm.
In my experience, the founders who succeed aren't the ones with the best ideas or the most technical skill. They're the ones who do the math first and build second. And they're the ones who kill ideas that don't work numerically, no matter how exciting those ideas feel.
Run the numbers. Let them tell you what to build. Your future self — the one who isn't burned out and broke from spending six months on a structurally unprofitable product — will thank you.