The reality of building a SaaS product has shifted. And most founders are building the wrong thing entirely. Not because they build technical shitty products, quite the opposite. They proceed to build the wrong thing, but beautifully, for months, before anyone tells them nobody wanted it.
I’m currently working on a new SaaS product. It’s called Noxtrack. And I want to share a little secret about it with you. I haven’t written a single line of code, I don’t have a document outlining the features, and I haven’t even written down anything.
So what's the deal, I hear you say? Am I procrastinating? Am I telling you a joke?
No, it’s the decision I made.
But before I walk you through this decision, I want to clear the air around SaaS products. They are not dead and I don't think we're anywhere near that point. Like it always has been, it’s evolving. And with the shift of AI, it just became very visible.
What people miss about this shift is that AI didn’t make it harder to survive as a SaaS founder than it was a few years ago. The hard part shifted. Building was always the biggest struggle for anyone, and now it suddenly became a lot easier. What’s hard is the discovery and validation, and acting on it. And most founders skip exactly those parts.
And I do get it. Building feels like progress. It's visible, you can ship it, and you can tell people you have made something. Sitting with a document full of assumptions you're not sure about “validating” feels like doing nothing.
As someone who has advised and mentored founders, I have seen a lot of them waste time building the wrong things. And I've always advised them to validate first. Finding that biggest assumption before you build is the difference between wasting three months and knowing exactly what you're walking into, with a validated plan for how to deal with it.
So for the first time, I'm going to do exactly what I advised other founders to do. And that is what I'm doing right now with Noxtrack. And I'm going to show you how to do it the right way.
Your product is based on an idea, and most ideas fail
Let’s kick things off nice and light. Or, well, with the fact that about 90% of products fail because nobody wanted them, and that the lovely idea you had in the shower this morning statistically belongs in the bin. Sorry, not sorry…
When you have an idea, it doesn't feel like a guess, it feels solid. But it only feels solid because it's untested, built on assumptions, in your reality, rather than on what you know. The moment it meets a real customer, that's when you find out the one you started with is almost never the one that ends up working.
Slack started as a gaming company, YouTube as a video dating site, Instagram as a check-in app. Every one of them had to walk away from their first idea to find the one that worked.
To reach product market fit, you have to test out your ideas in the real world.
What is product market fit?
Product market fit is the point where the market pulls your product out of your hands instead of you having to push it through. It isn't one clever decision, it's what you get from exploring your market, understanding what customers actually need, and validating your assumptions before you commit. And even then it's hard, because a validated problem still needs the right solution. But when you land that, solving a real problem the market actually has, you've reached product market fit.
And here’s the part that should make you nervous. Knowing all of this, founders still pour months into their riskiest assumption.
They build on something they never tested, on “facts” they captured in an AI conversation and never checked against a single real person. They bet their best months on the one belief most likely to sink the whole thing.
Without product market fit, everything else eventually fails too
From the very first decision, and with every feature and every choice after it, product market fit is and should be your highest priority. Without it, everything else will fail too at some point, maybe later, maybe sooner. But you won’t survive.
You can run the most brilliant marketing campaign, hire the best people, ship features faster than anyone. But if nobody actually wants what you built, all of it sinks into a product nobody was waiting for. Marketing gets you attention, not retention. Great hires can’t sell something people don’t need. Speed only gets you to the wrong place faster.
So with everything you do, there’s one goal. Making sure you’re building something people actually need, and that they find it valuable enough to pay for.
How to deal with assumptions, and start validating
Alright, great talk. But how do you find out if you're building the right thing, without building it first? You start with the only thing you actually have before a single line of code: validating your assumptions.
Not all assumptions are equal
We live in a fast world, and you won’t be able to test everything up front. You don’t have to, because not all assumptions are equally risky.
Some are small. If you’re wrong, you shrug and adjust, as long as you keep an eye on them. Others are load-bearing, the ones holding up the whole company. Get one of those wrong and everything above it comes down with it.
So yes, I’d still say place your bets. The only way to know if something really works is to throw it into the real world. But place them carefully. Bet freely on the small stuff, the wording, the flow, the features you can change later. Never place a blind bet on the one assumption the whole thing rests on. Test it, or break it into something smaller you can test.
And if it turns out you’re wrong, good. You found out cheap.
Test the assumption that can kill you
So which one is that? The one your whole idea rests on is almost always the same. Not “would this be cool”, but “is this a problem people genuinely have, right now, in their actual work”. A real problem leaves traces. People are already working around it, patching it, complaining about it. That’s what you’re testing for, evidence that the problem exists without you.
For Noxtrack, that's exactly where I'm pointing. My biggest assumption is that companies are actually struggling with how to use AI responsibly, with the threat of fines hanging over them, enough that it keeps them up at night. That the problem underneath it is real and urgent. And the layer right after that, just as scary, is whether it's urgent enough that they'll pay to solve it instead of filing it under someday. If either of those isn't true, it doesn't matter how well I build the rest.
Test by talking, not building
The cheapest way to test that assumption is to talk, not build. Especially early on, when the assumption is still your biggest risk.
A conversation can tell you your idea is wrong to your face, with no code to hide behind. And I’ll be honest, that feels uncomfortable. But an afternoon of the right conversations can save you three months of building the wrong thing.
The catch is that a good conversation is trickier than it looks.
Most people talk in a way designed to hear yes. They pitch, they explain, they ask “would you use this?” And people are polite, so they say yes, and you walk away flattered and none the wiser. Compliments feel like validation, but they’re just noise. So stay as far away from pitching your product as you can, because the moment you do, people start lying to you.
The fix is to talk about their life, not your idea. Ask what they actually did, not what they think they’d do. Listen more than you talk. You don’t ask “would you pay for this”, you ask “how are you dealing with this today, and what did the last attempt cost you”. What people do with their time and money tells you the truth. What they say about your idea tells you nothing.
For Noxtrack, that means talking to companies about how they handle AI right now, where it bites them, what they’ve already tried, long before I show them anything at all. I’m not looking for people to like the idea. I’m looking for the truth about whether the problem is real, and whether it hurts enough to pay for.
So that’s the shift. Not building faster, but building later, once you actually know what you’re building and for whom. The conversation comes first. The code comes when the code is the only thing left to get wrong.
And as a bonus, these people already know you. So once you’ve actually built something, coming back to them is a lot easier.
Make pivoting your default
Startup mythology loves the lightning strike. You come up with a breakthrough idea, you build the best solution out there, and the company takes off like a rocket. Clean, linear, inevitable.
The reality is much more messy, everyone.
Almost no company is still the idea it started with. The ones that made it changed direction, often more than once, until they landed on something the market actually wanted. And even then, the market is constantly changing.
So if there's one takeaway here, it's this. Pivot early, pivot fast, pivot by default.
The whole point is to change direction while it's still cheap, while it's a conversation and a document, not a codebase and a launch you have to walk back. Being wrong isn't the risk. Being wrong slowly, after you've built everything around it, is.
That's why I refuse to build, I'd rather fail nine times faster
So back to my little secret. I still haven’t written a line of code for Noxtrack. Right now I’m testing the one assumption I can’t afford to be wrong about, whether the problem is real and urgent enough that people will pay to solve it.
I don’t see that as delay. I see it as the most important work I could be doing. Every conversation I have now is a month of building I might save later, or a wrong turn I get to skip entirely.
Chances are the idea doesn't survive. But hear me out: a ninety percent fail rate just means nine no's stand between me and a yes. I can take nine failures. I just have to fail fast.
Most people stop at the first failure. The successful ones are just getting started there.