The pitch-deck playbook is not for us
If you've read any of the last decade's startup books, you know the playbook. 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. 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.
1. Pick problems that obviously need solving
The startup-book advice is "find an unsolved problem". The actual advice should be "find an already-solved problem where the existing solutions are bad for a specific audience".
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, Harvest or Clockify 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".
2. Charge money from day one
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.
This does two useful things. It filters the early-signup noise down to people who actually have the problem you're solving (free users will say a product is great; paying users will tell you what's wrong). It also means your cashflow is positive from week one, which changes every subsequent decision.
Sumlo had its first paying user on day four. Eddi had paying 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.
3. Build tools you can explain in one sentence
Most profitable small SaaS products have a one-sentence pitch. "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.
4. Proven tech, proven patterns
The startup-book advice is "find technical advantage". The real advice for most small SaaS: "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 or Postgres (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.
What this philosophy does not promise
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 we're writing this down
Partly because the "build in public" community does a lot of this thinking already and we want to contribute. Partly because every prospective Simplepage client asks some version of "so what's different about how you work?" and 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.