You Never Built a Growth Engine

You built the thing. It works. You put it on the internet, told the people you know, and waited for the part where strangers start showing up. That part never arrived. The site gets four visits a day, two of them yours, and you have rewritten the homepage headline three times looking for the sentence that unlocks it.

I’ve written before that the most common reason a SaaS has zero users is that the founder never understood the problem from the inside. That’s still the first thing I look for. The second one is more mechanical, and it explains the products built by people who did understand the problem: nobody ever built the machine that brings people to it.

You built software. Then you launched it, which is an event, onto a website, which is a place. Neither of those is a system, and a business that grows runs on systems.

The silence is the evidence

Founders read a quiet launch as an absence of information. It’s a measurement, and a fairly precise one.

If nothing is happening, no part of your business is currently causing a stranger to encounter your product. That’s a stronger statement than “the marketing isn’t working yet,” and it’s usually the accurate one. There is no marketing to work. There’s a thing you made and a URL where it lives.

A growth engine is the set of repeatable actions that put your product in front of people who have never heard of you. Repeatable is the load-bearing word. Posting your launch somewhere busy and getting 400 visitors in an afternoon is a spike. Spikes are worth something, mostly because they show you what the thing looks like switched on. The engine is whatever brings those 400 people back on a Tuesday in November when you aren’t doing anything special.

There are only a few engines

Every founder I talk to about this expects a long menu. The list is short:

Content and search. You publish things people are already looking for, and they find you months later. Slow to start, cheap to run, and it compounds. The specific difficulty is that you cannot tell whether it’s working for the first three or four months, which is exactly how long most people give it.

Social. You show up where your buyers already are and become a person they recognize. Fast feedback, and it stops the day you stop. The difficulty is that it demands a voice, and posting as a company logo reads as advertising to everyone who sees it.

Other people’s audiences. Press, podcasts, newsletters, communities, partnerships. Somebody with 8,000 readers who trust them mentions you, and you borrow that trust for a day. The difficulty is that it’s a pitching job, and being ignored 20 times in a row is its own skill.

Referrals. Existing users bring new ones, either because you asked or because the product makes it natural. Cheapest traffic there is, and it requires users, which is why it can’t be first.

Direct outreach. You find the 200 people who have this problem and contact them individually. Unfashionable, unscalable, and the fastest way to get your first ten customers and learn what they actually want.

Paid ads sit outside that list on purpose. Ads buy traffic, which is a real and sometimes correct thing to do. They don’t build an engine, because the traffic stops the moment the card stops.

Starting out, the answer is usually to run all of them, badly, at the same time. You don’t yet know which one fits your product, your market, or you, and there is no way to reason your way to the answer from a chair. Run all five for a season, then keep the two that showed a pulse.

Build it the way you build software

Here’s the reframe this whole post exists for. People who are good at building things are frequently terrible at promoting them, and the reason is almost never laziness. It’s that promotion looks like a personality trait rather than a discipline, and builders have no interest in performing a personality.

So stop treating it as one. Promoting is building. Same rigor, same instrumentation, same debugging loop.

You would never ship a feature by doing it once by hand and hoping. Give the growth work the same treatment you’d give a service you were putting into production:

• Spec it. What does this channel do, for whom, and what does a working version look like in 90 days? Write it down, because the version in your head will quietly rewrite itself to match whatever happens.
• Build the system, not the instance. One blog post is an instance. A topic queue, a template, a publishing schedule and a place to keep drafts is the system. The system is what survives a bad week.
• Instrument it. Analytics you trust, tagged links, and a named conversion event. If you can’t see a channel, you’re running it blind and you’ll keep it or kill it based on vibes.
• Review on a schedule. Same as you’d read error rates. Pick a day, look at the numbers, write one sentence about what changed.
• Change one thing at a time. For the same reason you don’t ship six refactors in one commit.

If you can architect a system that keeps running when you aren’t looking at it, you can build a growth engine. It’s the same skill pointed at a different problem.

It also needs the same slot in your week that the software gets. Not the leftover hour on Friday when the real work is done. Growth work put last is growth work that doesn’t happen, and the calendar is where you’ll find out whether you actually believe any of this.

The first thing that moves is traffic

Not sales. Not revenue. Traffic.

This is the part founders resist, because traffic feels like a vanity number and revenue feels like the real one. Revenue is the real one. It’s also the last thing to move, and if you wait for it to tell you whether a channel works, you’ll wait past the point where the information would have been useful.

So here’s the unglamorous test. Open your analytics, set it to the last 90 days, and look at daily visitors. Two questions:

Does it have shape, or is it a flatline? A line that sits at the same 12 or 20 or 60 visitors a day, weekends included, holidays included, is usually not an audience. That’s the background hum of the internet: crawlers, scrapers, uptime monitors, security scanners, your own deploys. Real human traffic is lumpy. It drops on Saturday, it spikes when you publish something, it has a shape that corresponds to things you did.

Where is the number coming from? Direct, search, referral, social. If 90% is direct and you haven’t been telling people about it, “direct” is where your analytics puts traffic it can’t attribute, and much of it isn’t people.

Your traffic number is probably wrong

I’ll use this site, because it’s the example I’m allowed to be blunt about.

Over 90 days this summer, Google Search Console reported that 1123interactive.com received 38,566 impressions at an average position of 5.8. Position 5.8 is the middle of page one. On its face, that’s a property doing fine and failing to convert.

Then I classified every query before aggregating anything, which is a thing almost nobody does. What was left:

	As reported	After classification
Impressions (90 days)	38,566	947
Average position	5.8	40.1
Clicks	0	0

95.7% of it was a single broken bot. Since June, something with an unfilled template variable has been firing the literal string {{0 - domain}} saas or not into Google, with my domain in the slot, thousands of times. My site ranks first for that phrase, because of course it does. No human has ever typed it.

The honest read of this property is 947 real impressions at position 40, which is page four, and zero clicks. That’s a much worse number and a much more useful one. The 5.8 would have had me optimizing titles to fix a click-through problem that doesn’t exist.

The same overstatement happens at the server. Cloudflare’s dashboard counts requests at the edge, and the edge sees everything: bots, scrapers, preflight checks, the lot. Modern analytics tools filter known bots before they count, which is why the same site can look busy in one tab and empty in the other. The lower number is the one to plan with.

Two questions, before you build anything

There are two, and most technical founders can answer the first one in exhaustive detail:

1. How am I going to build this?
2. How am I going to get people to it?

The second question usually gets “post it on Reddit” or “we’ll do some SEO,” which are answers of the same quality as “I’ll write some code” would be to the first. If you’d be embarrassed to ship a technical plan that vague, hold the growth plan to the standard you already have.

Ask them at the same time, before the first commit. The answer to the second one sometimes changes what you build.

Nothing about this is passive

Passive income is vanishingly rare, and I’m not sure it was ever real at any meaningful scale. Every version of it I’ve looked at closely turned out to be a business somebody works at, or an asset somebody bought with money from a business they worked at.

If you’re building something that serves people, the work doesn’t stop. The engine needs feeding. That sounds like bad news and it’s the opposite: it means the outcome is downstream of effort you control, rather than of a launch that either catches or doesn’t.

The absence of users is rarely a mystery. It’s usually the correct output of a system nobody built.