10 SaaS Mistakes to Avoid: Lessons From Building My Own
10 SaaS mistakes to avoid, from a developer who built his own product: an oversized MVP, underpricing, ignored billing and VAT, and no plan for sales.
Freelance full-stack developer
- Published
- Reading time
- 14 min
In this post8
The SaaS mistakes to avoid are rarely technical. The expensive ones are building too much before anyone has agreed to pay, charging too little, and treating billing, operations and sales as problems for after launch. Here are ten pitfalls and suggestions for avoiding them.
[PLACEHOLDER: Simon confirms that all ten items are mistakes he actually made with Remotefitness and swaps out any that don't apply. Add one sentence on what Remotefitness is and which numbers can be shared.]
I'm a developer, and developers tend to answer every problem with more code. Several of the mistakes below come from exactly that habit, so use the list as a check against your own plan.
The short answer: all ten mistakes at a glance
| # | The mistake | What it costs you | Do this instead |
|---|---|---|---|
| 1 | Building before validating | Months spent on something few will pay for | Talk to customers and get a yes before writing code |
| 2 | An oversized first version | A late launch and expensive pivots | Cut it down to the one job the product does |
| 3 | A target market that's too broad | Vague messaging and slow sales | Pick one niche you can reach directly |
| 4 | Building for scale too early | Complexity with no users to justify it | Keep it simple and scale when the numbers demand it |
| 5 | Underestimating billing and VAT | Weeks lost to subscriptions, invoices and tax rules | Use a billing provider and talk to an accountant early |
| 6 | Leaving onboarding until last | New users drop off on day one | Design the first session as carefully as the core feature |
| 7 | Pricing too low | Thin revenue and the most price-sensitive customers | Price on value and test upward |
| 8 | Expecting the product to sell itself | A launch with no audience | Build a route to customers while you build the product |
| 9 | Underestimating operations and support | Time taken from building and selling | Budget time and money for operations from day one |
| 10 | Measuring too little, too late | Decisions based on gut feeling | Track activation and churn from the first customer |
The table is the overview. Below, I go through each mistake, grouped by when it usually shows up. If you want the full story from idea to a running product, read from idea to SaaS: choices and priorities.
Mistakes before writing any code
1. I started building before validating the idea
It's the classic developer reflex. You get an idea, you can already picture the solution, and you start coding that evening. The trouble is that code can't tell you whether anyone will pay. Only customers can, and every week you build without talking to them is a week you might be heading the wrong way.
This isn't just a hunch. In 2026, CB Insights analyzed 431 VC-backed startups that had shut down and found poor product-market fit (a product that doesn't match a real need in the market) among the causes in 43% of them. Those were funded companies, but the mechanism is the same for a small SaaS.
My advice is to speak to at least ten potential customers before you write any code. Ask how they solve the problem today and what it costs them in time or money. The strongest signal is a pre-payment or a commitment to become a pilot customer at a stated price, not a polite "sounds interesting". I've collected the methods in a guide on how to validate a SaaS idea.
[PLACEHOLDER: Simon's own version. How long did you build Remotefitness before talking to the first potential customers, and what did those conversations show? 30-50 words.]
2. My first version was too big
An MVP (minimum viable product, the simplest version that can be put in front of real customers) exists to test one assumption: that a specific group will pay to have a specific problem solved. It is not a portfolio piece. Even so, plenty of first versions ship with user profiles, reporting, integrations and a large admin panel before a single customer has logged in.
Every extra feature pushes the launch back. It also makes it more expensive to change direction once your first customers tell you what they actually need, and they always do.
Write the one sentence the product has to live up to, for example "a plumber can send a customer a quote in under five minutes". Then cut everything that isn't needed for that sentence and park the rest on a list for later. It's the same discipline I use in my week-by-week MVP development process.
[PLACEHOLDER: Which features were in the first version of Remotefitness that you would hold back today? 30-50 words.]
3. My target market was too broad
"For anyone who ..." is a weak starting point for a SaaS. The broader the audience, the more generic your message, and the harder it is to find the places where your customers gather. You end up competing with large, general-purpose tools on their home turf.
A narrow niche feels limiting, but it makes almost everything easier. You know the words your customers use, which systems they already run, and where to reach them. You can always widen the market once you have a foothold.
A useful test: can you name five specific companies or people in your target market and email them tomorrow? If not, the market is probably too broad, or too hard to reach.
[PLACEHOLDER: Who was the initial target market for Remotefitness, and did it get narrower or broader over time? 20-40 words.]
Mistakes in the product itself
4. I built for 10,000 users before I had 10
Developers love solving tomorrow's problems: microservices, queues, clever caching and an architecture ready for a flood of sign-ups. It feels responsible. In practice it means more code to maintain, more things that can break and slower development, right when you need to change the product quickly.
A mature framework like Laravel on a single server can usually handle far more traffic than a new SaaS sees in its first year. The boring choice tends to be the right one: one database, one codebase and hosting you already know.
That doesn't mean architecture is irrelevant. Some decisions are expensive to undo, such as how each customer's data is kept separate (multi-tenancy) and how roles and permissions work. Spend your thinking time there and leave the rest until the numbers demand it.
[PLACEHOLDER: Did you build anything in Remotefitness too early with scale in mind? What was it, and what did it cost? 20-40 words. Replace this item if it doesn't apply.]
5. I underestimated billing, VAT and invoicing
Taking a card payment is the easy part. Behind it sit subscriptions, trials, mid-cycle upgrades, failed payments, receipts, credit notes, cancellations and tax. Each one is a small task, but together they can take as long as the core product.
VAT is the one that catches European founders out. When you sell to a business with a valid VAT number in another EU country, you usually don't charge VAT yourself, because the customer accounts for it under the reverse charge. Selling to consumers across the EU is different: above the EU's €10,000 threshold for cross-border sales you generally charge VAT at the customer's local rate, and you can report it through a single One Stop Shop (OSS) registration.
Use an established billing provider and don't build your own invoicing engine. If you'd rather not handle VAT at all, a merchant of record (a reseller that sells on your behalf and deals with the tax, such as Paddle) takes it off your plate, usually in exchange for a higher fee. And if you store personal data, GDPR and data processing agreements belong in the same pile of dull but necessary work.
[PLACEHOLDER: How did you handle payments and VAT in Remotefitness, and what took longer than expected? 20-40 words.]
6. Onboarding came last
Onboarding is a new user's first experience of your product, from sign-up to the moment their problem gets solved for the first time. It's often the last thing built, in a rush just before launch. That's backwards. A user who doesn't get the product in their first session rarely comes back, and you never learn why.
Decide what "activated" means for your product, for example creating a first project and inviting a colleague. Then build the shortest path to it: fewer fields at sign-up, sample data instead of an empty screen, and an email that nudges people along if they stall.
The best research tool is also the cheapest. Sit next to three real users, or share a screen with them, and watch them try the product without helping.
[PLACEHOLDER: What did the first onboarding in Remotefitness look like, and what did you change after watching real users try it? 20-40 words.]
Mistakes in pricing and sales
7. I priced too low
A low price feels like a way to lower the risk, because more people say yes. The math is harsh, though. To reach €7,500 in monthly revenue, you need about 500 customers at €15 a month, but only 100 at €75. Each customer costs roughly the same to support and sell to, whatever they pay.
A low price also tends to attract the most price-sensitive customers, who are often the quickest to churn. And it's far easier to give an early customer a discount than to raise prices on your whole existing base later.
Price on what the problem costs the customer today, not on what you'd pay yourself. Start higher than feels comfortable and watch how many people say no because of the price. If nobody says no, you're probably too cheap.
[PLACEHOLDER: How did you set the first price for Remotefitness, and have you changed it since? Only share numbers you're happy to publish. 20-40 words.]
8. I expected the product to sell itself
"If it's good enough, customers will find it" is one of the most common beliefs among technical founders. A new product has no traffic, no reviews and nobody searching for it by name. Without a plan for how customers find you, you launch to an empty room.
Pick one or two channels that suit your audience and start on them while you build: direct outreach, LinkedIn, an industry association or community, content that answers your customers' questions, or partners who already have the customers. The channel doesn't need to scale at first. Early customers usually come from slow, manual work.
My rule of thumb is to spend as much time on sales and marketing as on development, even when that feels wrong to a developer. I've written up how I got the first paying customers separately.
[PLACEHOLDER: What was your plan for finding customers at launch, and what actually worked? 20-40 words.]
Mistakes in running the product
9. I underestimated operations and support
A SaaS isn't finished at launch. It needs security updates, backups that actually get tested, monitoring that alerts you when something breaks, and a plan for failed payments. Then there's support: questions, bug reports and feature requests, all landing in the same inbox and calendar as your development work.
Hosting, transactional email, error tracking and backups are often small amounts on their own, but they bill every month, customers or not. The biggest cost is usually your own time, because every hour spent on operations is an hour not spent building or selling.
Budget for operations from day one. Choose hosting where updates and backups are part of the setup, put error tracking in place before launch, and write standard replies for the questions that keep coming back. I've shared the real monthly cost of running a SaaS in a separate post.
[PLACEHOLDER: Which part of running the product took the most time that you hadn't planned for? 20-40 words.]
10. I measured too little, too late
Early on, there are so few users that measuring anything feels pointless. But that's exactly when each user is most valuable as a source of learning. Without numbers, you don't know whether new users reach the point where the product helps them, or when and why they cancel.
You don't need a big dashboard. Three numbers are enough to start: how many people sign up, how many of them get activated (see mistake 6), and how many cancel each month (churn). Also send everyone who cancels a short email with a single question: what made you stop?
The numbers tell you what is happening. The conversations tell you why. You need both, and they're cheapest to set up before you have many customers.
[PLACEHOLDER: What did you track in Remotefitness from the start, and what do you wish you had tracked earlier? 20-40 words.]
When not to hire a developer (yet)
I build software for a living, so read this section with that in mind. Still, several of the mistakes above get more expensive, not cheaper, when you pay a developer to make them faster.
Hold off on hiring a developer, me included, if:
- you haven't spoken to potential customers yet, or nobody has shown they'll pay
- the idea can be tested with a landing page, a spreadsheet or a manual service where you do by hand what the product would later automate
- an off-the-shelf tool covers most of the need, and your edge is service or sales rather than software
- you don't have the budget to run and market the product for at least a year after launch
A developer is the right investment once the idea is validated, customers are waiting, and the product needs logic, integrations or data handling that an existing tool can't offer. At that point it pays to get the foundations right, so you don't have to rewrite everything when customers arrive.
Next steps: what I would do if I started over today
If I were building a new SaaS tomorrow, I wouldn't start in the code editor. I'd start with the six points below and only open the editor once every one of them was ticked.
Before you build your SaaS
- Ten customer conversations: you understand the problem, what it costs customers, and the words they use for it.
- One sentence: you can describe what version one must do in a single line.
- One niche: you can name five potential customers and contact them tomorrow.
- A tested price: you've tried it on real people, and it's higher than your first instinct.
- One channel: you know where your first 20 customers will come from.
- An operations plan: billing, VAT, backups, monitoring and support are planned, not forgotten.
If you've worked through the list and the product needs building, take a look at how I approach SaaS development for founders and growing businesses. Larger builds start with a paid, fixed-price discovery phase, and you own the code from day one.
Frequently asked questions
How long does it take for a SaaS to become profitable?
For most founders, it takes longer than planned. Subscription revenue grows slowly because each new customer pays a modest monthly amount, while hosting, tools and marketing costs start on day one. Set a budget that can carry the product well past launch, and work towards milestones such as your first ten paying customers rather than a fixed date for profitability.
Can you fix these mistakes after launch?
Most of them, yes. Features, onboarding and marketing can be adjusted continuously, and they should be. The expensive things to change are the foundations: your data model, how customer data is separated, and pricing for existing customers. Spend most of your pre-launch thinking on those decisions and be more relaxed about the rest.
Is it a mistake to build a SaaS as a solo founder?
No, but you have to cover far more than the code. On your own, you build, sell, support and run the product, and sales is the part technical founders most often underestimate. A small, focused product can be run by one person if you automate operations, keep the feature set lean and say no to requests only one customer has made.
Should a non-technical founder learn to code before starting a SaaS?
Usually not. Your time is better spent understanding customers, pricing and distribution, which no developer can do for you. Learn enough to follow technical decisions and ask good questions, and test the idea with no-code tools or a manual service first. Once it's validated, bring in a developer to build the version that has to hold up in production.