Code Was Always Cheap (Part 2)

After my last post, a lot of people agreed with one point.

Building is no longer the bottleneck.

I also remembered something I had read years ago. I could not find the exact interview again, so I will not pretend I remember it word for word. I vaguely remember a founder saying that in the early days, they would spend a few days building and then deliberately spend time getting people to use the product.

I think it was Twitter, but I could not find the source anymore.

Either way, the idea is what matters, not who said it.

Today, thousands of developers can finish in a weekend what used to take months. AI agents write boilerplate, generate tests, fix bugs, and even make decent UI. The product that would have been stuck at 90 percent forever now actually ships.

Then comes the awkward silence. Nobody signs up. Nobody shares it. Nobody talks about it.

So we shrug and say, code is cheap now.

I do not think that is the lesson.

Read Paul Graham’s Do Things that Don’t Scale

If you have never read Paul Graham’s essay Do Things that Don’t Scale, read it. It was written more than a decade ago, and almost every word still applies.

One part has always stuck with me. He compares a startup to an engine that has to be cranked by hand before it starts running on its own. You do not gently tap the engine and hope it comes alive. You apply an unreasonable amount of force until it finally catches.

That force is usually marketing. Not ads, not a few LinkedIn posts, not making an Instagram page and hoping the algorithm blesses you.

Real marketing is talking to customers, finding communities, cold emailing, writing content, asking for feedback, and helping people one by one. It is doing things that do not scale until something finally starts moving.

Every product needs a different kind of crank. Your job is to figure out what that is.

We made the same mistake

In my last post, I talked about the ERP startup I worked on during covid. During the lockdowns, we built a multi-vendor marketplace for local businesses. The logic sounded reasonable at the time. Physical stores were closed, shop owners needed an online presence, and customers could not go outside. Surely this was the perfect moment.

The engineering team worked hard. We kept adding features, improved onboarding, fixed bugs, built dashboards, and kept shipping. The application lasted about a year before it got shut down because there were not enough users.

Only later did I realize what our marketing actually looked like. There was a public launch event with a local politician unveiling the app, a few social media posts, and company social pages that were brand new with almost no audience. That was it.

Meanwhile the engineering team, me included, kept building feature after feature, believing the next release would somehow make people appear.

They did not.

AI solved one problem

Now it is 2026. Agentic coding tools have changed how we build software. Developers who used to have five abandoned repos now have five deployed products. Ideas do not stay in Notion anymore. They are live, on the App Store, on the Play Store, on Product Hunt, on GitHub. They are everywhere.

That is genuinely great.

But what happens after deployment? That is where I see people getting stuck. They launch, they wait, and nothing happens. Then they move on to the next idea.

Six months later someone asks, what happened to that product? The answer is usually something like: well, code is cheap now.

No. The code was never the problem.

The internet is full of invisible products

Most products do not fail because they are technically bad. They fail because almost nobody knows they exist. The internet is full of useful software with ten users, not because the developers were lazy or the idea was bad, but because distribution is hard, attention is expensive, trust takes time, and nobody wakes up hoping to discover your side project.

People already have habits. They already have alternatives. They already have twenty tabs open. Your product has to earn a place among all of that.

Marketing is part of building

I think developers, myself included, have been trained to treat marketing as something separate. Engineering builds the product, marketing markets it. But if you are building a side project, you do not get that split. You are both.

Shipping code is only half the work. The other half is making people care. That probably means writing, recording videos, posting updates, replying to comments, sending cold emails, talking to potential customers directly, and showing your work long before it feels ready.

Yes, some of it feels awkward. Most of us would rather spend three more hours refactoring than publish one LinkedIn post.

But that is exactly why so many good products quietly disappear.

If you want your side project to take off

Spend as much energy getting people to notice it as you spend building it. Write about the problems you are solving. Share what you are learning. Show the behind the scenes work. Talk to users one by one. Ask for feedback. Go where your users already are instead of waiting for them to come to you.

The code is already done. Now you have to earn the attention.

Otherwise your product ends up exactly like millions of other projects. A few thousand lines of good code, sitting quietly somewhere in the vast sea of the internet.