Why most SaaS advice doesn't apply - it was written when engineering was the hard part

Read almost any canonical piece of SaaS advice and count how long it takes to reach an assumption that is not true of you. Usually it is the first paragraph. Get to product-market fit quickly, because you do not yet know who your customer is. Launch a free tier, because nobody has heard of you. Instrument the funnel and optimise it, because the only way to learn what people want is to watch thousands of strangers decline to buy.

Every one of those is sound advice for the company it was written for. Following it as a specialist business costs you twice over: you spend money and years acquiring something you already had, and you write down to nothing the advantages you actually hold, because the playbook has no line for them. Nobody sets out to do this. It happens because the advice is confident, abundant and free, and because there is very little written for the position you are actually in.

In this blog, Elliott Prince, Managing Director at Ferrous Labs, explains why the standard SaaS playbook was written for constraints that no longer hold, what replaced them, and why the advantages that matter now are ones a specialist business has been accumulating for years without ever counting them.

The playbook was written when building was the hard part

For most of the past two decades the binding constraint on a software business was engineering. Turning an idea into something a customer could log into took a team, the better part of a year, and a great deal of money before a single pound came back. Everything in the playbook follows from that one fact. Raise capital, because you must pay engineers long before you have revenue. Hire hard, because headcount is throughput. Ship fast and grow at any cost, because your protection was simply being far enough ahead that a competitor's year-long build never caught you.

Distribution was the second constraint, and it was the one you could solve with money. If you could reach enough people often enough, some of them converted, and the whole apparatus of growth marketing exists to make that arithmetic work at scale. It was hard, but it was tractable, and it was buyable. Which is why so much of the canon is about acquisition: it was the part you could actually do something about once the product existed.

So what is actually scarce now?

Building software has not become easy, but it has become dramatically less expensive relative to everything else, and the ratio is what matters. In the 2025 Stack Overflow Developer Survey, 84% of developers were using or planning to use AI tools, up from 76% the year before, and 52% said those tools had improved their productivity.

I would be careful about over-reading that. The same survey found more developers distrust the accuracy of what these tools produce than trust it, 45.7% against 32.7%, which matches the experience of anyone who has actually shipped with them: the first draft arrives in minutes and the last ten per cent still takes the judgement of somebody who knows what they are looking at. Engineering has not become free, and it has certainly not become reliable. It has simply stopped being the thing that decides who wins.

Three things have taken its place. The first is market access: knowing precisely who has the problem, being able to reach them this week, and being someone they already take calls from. The second is data, which is the same argument I would make about why generic tools fail specialists in the first place - a model is dependable only where it has seen enough of the real thing, and the real thing sits in your client files rather than on the public internet. The third is expertise, by which I mean the accumulated judgement about what a good answer looks like in your field, which is what turns a capable model into a product somebody trusts.

Distribution has not stopped mattering, and anyone who tells you otherwise is selling something. But it has moved down the list, and the three above it are things that cannot be bought at any price by a competitor who does not already have them.

Three tactics for buying what you already have

Read the familiar growth tactics with that in mind and they stop looking like laws of nature. Each is a mechanism for manufacturing market access from nothing, which is an excellent idea if you have none and a waste of effort if you do.

Freemium is a way of letting strangers try your product without anybody having to talk to them, because talking to them individually does not scale when you need a hundred thousand of them. You do not need a hundred thousand. You may well need forty companies, and you can name most of them. Worse, a limited free version actively misleads a professional buyer: they cannot evaluate whether something fits a critical workflow while half of it is switched off, so the free tier answers a question they were not asking.

Growth hacking is a collection of techniques for extracting attention from people who have no particular reason to give it to you. Professionals are unusually resistant to it, partly because they are marketed at constantly and partly because in most expert fields the cost of picking the wrong tool is carried personally. What convinces them is a colleague they respect saying it worked, which is slower, less measurable, and far more durable.

Viral loops ask users to market on your behalf in exchange for status or access. Professionals do recommend tools to each other, constantly, and word of mouth is genuinely how software spreads in expert fields. But that is not a loop you can engineer, and it is not a moat either, because it works exactly as well for whoever arrives second. The thing that protects you is further down: the data and the encoded judgement, which is where we came in.

Dustin had the hard part done before we met him

The standard playbook opens by telling you to establish credibility before you build anything. For an established consultancy that instruction is not merely unnecessary, it is backwards. You have been establishing credibility for years, with the only people whose opinion affects whether this works, and the task is to recognise it rather than to go and manufacture some.

We built TrustOS with Dustin C. Lawrence at MissionCTRL, turning his Brand Effect methodology into a platform that scores trust across five stakeholder groups and the three drivers underneath it. The case study puts the situation plainly: the thinking was not the challenge, because the methodology had been battle-tested across dozens of client engagements. The challenge was turning a consultancy methodology into a scalable product.

Look at what that handed us. Market access, because Dustin knew exactly which organisations had the problem and could reach them. Expertise, in the form of a framework that already broke an abstract idea into components somebody could act on. And data: we validated the scoring engine against real engagement data from MissionCTRL's existing client base, iterating on the model until its output matched the nuance of Dustin's own manual analysis. There is no version of that where a well-funded stranger catches up by moving faster, because the years of engagements are the asset, and they take years.

Stop competing on the thing you are worst at

None of this makes building a product easy, and I would not pretend the advantages above remove the risk. You will not out-ship a venture-funded team, you will not out-spend one on acquisition, and if the contest is decided on either of those you lose it. The useful part is that nobody is obliging you to enter that contest.

So start by writing down what you already hold that a well-resourced generalist would need years to acquire: the client relationships, the archive of completed work, the judgement about what a good output looks like, the standing that gets a meeting accepted. Most businesses find that list longer and more specific than they expected, and rather more interesting than a competitor analysis. Then take the next piece of SaaS advice that crosses your desk and ask which of those three scarce things it takes for granted you are missing. Most of the canon assumes all three.

The playbook is not wrong, it is just answering a question that was settled some time ago, for a company that is not yours. The businesses that will own the software in specialist markets are not the ones who learned to move fast. They are the ones who worked out that what they had been accumulating all along had become the scarce part.