Boring but profitable is the operating philosophy behind Simplepage's SaaS products: bootstrapped, three people, no investors, revenue from day one. Instead of the startup playbook - large TAM, growth at any cost, a Series A then a B - each Simplepage product picks a proven category, serves a specific audience inside it, charges money at launch, and runs on technology that was proven a decade ago. This post argues the four ideas behind that philosophy, and is honest about what it doesn't promise: no 10x growth, no demo-day prestige, no fast exit.
Why doesn't Simplepage follow the startup playbook?
The pitch-deck playbook is not for us. If you've read any of the last decade's startup books, you know it: pick a large TAM, build for the mass market, grow at any cost, burn capital until you find product-market fit, raise a Series A, then a B, and eventually, maybe, exit.
It's a valid playbook. It has produced real companies. It also has a failure rate that's rarely talked about, and a business model that assumes you want to work for investors as much as for customers.
We're not doing that. Simplepage is bootstrapped. Three people, no investors, revenue from day one. Our SaaS products - Sumlo, Eddi, Patch, and the ones in scoping - are not trying to become unicorns. They are trying to become boring but profitable. This is the philosophy: four ideas, each argued.
What problems should a bootstrapped SaaS product solve?
The best problems for a bootstrapped SaaS are already-solved problems where the existing solutions are bad for a specific audience. The startup-book advice is "find an unsolved problem"; the actual advice should be the opposite.
Sumlo doesn't invent timesheet reporting. Timesheet reporting has been around for 30 years. What Sumlo does is solve it specifically for agencies who use Toggl and want a branded PDF client report in 30 seconds. Narrower audience, sharper product.
Eddi doesn't invent AI-assisted CMS editing. It solves it specifically for Umbraco content teams on v13 LTS and v17. If you're on WordPress or Sitecore, Eddi isn't for you, and that's fine.
Patch doesn't invent gardening apps. It solves the gardening-app problem specifically for UK gardeners with UK weather, UK hardiness zones, and 382 UK-relevant crops.
The pattern: each product picks a proven category and serves a specific, identifiable audience inside it. "Identifiable" is the operative word - I can name, with a first name and a business, three people who bought Sumlo in the first week. That's the inverse of "we have a large TAM".
Why charge money from day one?
Charging from day one filters the early-signup noise down to people who actually have the problem you're solving, and it makes your cashflow positive from week one - which changes every subsequent decision. The startup-book advice is "acquire users, monetise later". The real advice: "if you can't charge for it, you're probably building something nobody wants".
Every Simplepage product launches with paid tiers. Free plans exist where they make sense (Eddi's read-only free tier, Patch's freemium model) but there is always a paid tier available at launch, and the goal is a paying customer in the first week. Free users will say a product is great; paying users will tell you what's wrong.
Sumlo had its first paying user on day one. Eddi had pilots before the v1 NuGet package shipped. Patch has a Pro tier on the launch screen. Every product is a business on day one, not a userbase waiting for a business model.
Why should a SaaS product be explainable in one sentence?
A one-sentence pitch is the test of whether you're building one product or two. Most profitable small SaaS products have one: "Turn your Toggl timesheets into branded PDF client reports." "AI chat for your Umbraco backoffice." "A UK gardening companion that tells you what to do today."
If you can't pitch it in one sentence, you're probably building two products and haven't admitted it yet. One-sentence products are easier to market, easier to sell, easier to support, and crucially easier to say no to feature requests against. Every "can you add X?" from a user gets held up against the one-sentence pitch. If it doesn't serve the pitch, it doesn't ship.
This is the hardest discipline in the list. Every feature request sounds reasonable in isolation. Maintaining the one-sentence focus is the single biggest cause of profitability for our products.
Why build on proven technology instead of the cutting edge?
Proven technology is Simplepage's default: the startup-book advice is "find technical advantage", but the real advice for most small SaaS is "use tech that was proven a decade ago, and keep using it until it isn't".
Simplepage products run on:
.NET 10 with ASP.NET Core (same stack as every Umbraco site we've ever built)
SQL Server (boring, documented, understood)
Vanilla CSS with custom properties (no framework, no build step, renders instantly)
Outfit from Google Fonts (free, good, universal)
Plausible for analytics (privacy-friendly, cheap, one script tag)
LemonSqueezy for payments (IoM-friendly, handles global VAT, 5% + 50c)
Cloudflare in front (free tier is generous, CDN and security in one)
None of this is exciting. All of it has been in production at scale for years. Every hour we don't spend debugging cutting-edge tooling (yes, we used the banned word, in quotes, for a reason) is an hour spent shipping product.
We use AI heavily for development. Claude Code writes the boilerplate, we write the architecture. That's the one bet on newer tech in the stack, and we've written about how and why in other posts. Even then, the way we use it is boring - we treat it as a senior assistant, not a replacement. All code is reviewed by our senior developer Simon, it's audited, security tested, tweaked, improved then, and only then, fit for testing.
What does the boring-but-profitable philosophy not promise?
The boring-but-profitable philosophy does not promise growth, prestige, or a fast exit.
It doesn't promise growth. A boring-but-profitable SaaS plateaus naturally. Sumlo will probably cap out at a mid-five-figure ARR per year. Eddi is a different shape, Patch is another. None of them are going to grow 10x year-on-year. That's fine. The portfolio, not the product, is the growth story.
It doesn't promise prestige. You will not be invited to speak at Y Combinator demo day. Your LinkedIn connections who run venture-backed startups will find your approach quaint. Be at peace with that.
It doesn't promise fast exits. These are cashflow businesses, not valuation-chased ones. If your goal is a £50m exit in five years, this playbook is wrong for you. If your goal is a business that pays three salaries, funds the next product, and lets you sleep, the playbook works.
Why write this philosophy down?
Simplepage is writing this down partly because the "build in public" community does a lot of this thinking already and we want to contribute, and partly because every prospective client asks some version of "so what's different about how you work?" - this is the answer.
If the philosophy above resonates - you've got an idea, you've got a specific audience in mind, you want a working product more than a funding round - get in touch. This is the kind of work we're good at, and the kind of client we want.
If this philosophy sounds wrong to you, that's also useful to know. We're probably not the right partner for a venture-scale ambition. That's fine too.