Marketing is harder than building
Notes from a builder finding out that the easy part was the code.
The shift I missed
I shipped OmoiOS. The system worked. The demos were not staged. The PRs were real. Sixty people gave it a star on GitHub. A handful of users ran it for real work and told me it was good.
And nothing changed.
There’s a moment, hard to describe, where you realize that the thing you built being good is not the same as the thing you built being chosen. I’d been engineering against the wrong constraint for a year. Not “is this real software,” which it was, but “can a stranger justify spending an hour figuring out whether to use it,” which they couldn’t.
The flattering version is that I had a marketing problem. The honest version is that I’d treated marketing as something I’d get to after the build, and by the time I got to it, the world had moved. The buyer was buying agents from inside Cursor, not from a guy on GitHub with a Daytona dependency.
Why building got easier
The build cost on software collapsed. Not just for AI agents. For everything. The tools changed faster than the conversation about them.
Claude Code writes my boilerplate faster than I can spec it. Astro builds a static site in thirty minutes that would have taken a week in 2018. Cloudflare Pages gives me a global CDN for free. Modal gives me GPU sandboxes on demand. Postgres is a docker compose line away. I can run a feature through a code review by an LLM faster than I can read it myself.
What used to require a team now requires one person and an opinion. What used to require eight weeks of plumbing now requires a weekend. The leverage curve has bent so far that “I want to build X” is a sentence that ends with a working version of X two days later, not two months.
This is not a complaint. It’s the new baseline. And every other builder who can read documentation is on the same baseline. Which is exactly the problem.
Why marketing got harder
If you can build anything in a weekend, so can everyone else. And every one of them is shipping into the same feeds you’re shipping into.
The attention math doesn’t add up. Twitter has more accounts than ever and less reach per account than ever. Show HN is a coin flip on whether the algorithm gods surface your launch. Reddit has twenty subreddits that might care about your thing and nineteen of them auto-remove anything that looks like self-promotion. LinkedIn rewards consistency more than quality, which means showing up daily for a year before the algorithm trusts you. Newsletters work, but getting the list requires the same channels you’re trying to escape.
And underneath all of it: the trust deficit. Everyone’s drowning in AI-generated content. The default assumption when someone sees a polished landing page from an unknown engineer is that the landing page took ten minutes and the product took ten more. That assumption is right often enough that the people who do real work get caught up in the same suspicion.
The asymmetry is brutal. Building cost: a weekend. Distribution cost: months of patient surface area, and you might still not break through. The bottleneck moved, and most of us were still pointing our effort at the old one.
What I tried with OmoiOS
I ran the standard playbook for an open-source dev tool.
I shipped on GitHub with a clean README, a demo GIF at the top, badges, an Apache 2.0 license, the works. I posted on X with thread breakdowns of the architecture. I wrote release notes. I dropped it on Hacker News (didn’t make the front page) and on the relevant subreddits (auto-removed twice, mildly upvoted once). I made demo videos. I went on a few podcasts.
What I learned from doing all of that:
- Engagement is not adoption. A thread about agent orchestration got me 200 likes and zero real users.
- Stars don’t pay rent. Sixty stars looks like traction in a tweet and means almost nothing for a managed-service business.
- Demo videos are necessary, not sufficient. People watch them, say “cool,” close the tab. They don’t sign up.
- Open source attracts the wrong customer for a SaaS pivot. The people who love “self-hostable” don’t want to pay you to host it.
- Cold inbound from launches is essentially zero. Every real lead came from someone who already knew me from somewhere else.
The full story of the build itself is in Building OmoiOS. What didn’t sink in until later is that the marketing failure wasn’t downstream of the technical work. It was the actual product problem.
The longer game
What I’m doing instead isn’t a different marketing tactic. It’s a different category of work.
I stopped trying to sell a product to strangers. I started selling expertise to companies who already have distribution.
The companies who actually need multi-tenant agent infrastructure are not me. They’re the companies who already have customers asking for agent products. They have the marketing problem solved, in the only way it actually gets solved, which is by having paying customers who already trust them. What they don’t have is the layer underneath their agent product that scales it past tenant one. That’s a real problem with a real budget attached, and it doesn’t require me to convince a stranger of anything they weren’t already trying to do.
The site you’re reading this on is part of that. Not because a personal portfolio is a marketing channel in any traditional sense, but because writing about specific technical problems in public attracts the specific people who have those problems. The conversion rate on a CTO who searches “multi-tenant background agents” and finds a real engineer who has actually shipped that is much higher than the conversion rate on a stranger who saw a tweet.
This isn’t a hack. It’s just acknowledging what works. The companies with distribution are the ones with the budget. The builders who can solve their specific problem are the ones who get the work. Anyone trying to be both the builder and the distribution channel for a horizontal dev tool in 2026 is signing up for a much harder game than they think.
What it means for builders
The standard advice is loud and pretty consistent. People scream about it on social all the time. Distribution is the most important thing. Post daily. Comment constantly. Join the groups. Build an audience. Show up where your buyer is looking, and keep showing up.
The advice isn’t wrong. It’s just hard.
Building an audience means positioning yourself, and positioning yourself at scale mostly works one way: by looking enough like someone the algorithm already trusts that it gives you a shot. The path of least resistance is to copy. Same hooks, same cadence, same hot takes wrapped up the same way. It works. It also drains the part of you that was worth listening to in the first place.
What if that’s not the path you want? You can build a brand for a company instead of a personal brand. Different shape, different tradeoffs. The positioning is the company’s, your job is to be the engineer behind it. That bypasses the part of the conventional advice that asks you to perform yourself online every day. It’s not less work. It’s different work.
Either way: figuring out how to distribute correctly is hard. Most of the developers I know are good at building and bad at distribution. They’ve spent years getting better at the easier of the two problems.
If I were giving advice to a builder right now, I’d say something contrarian. Spend the next year figuring out people. Then go back to figuring out how to code. Coding is great and awesome. Coding is also the cheap part now. The return on understanding how to distribute and how to talk to the people you want to reach is much higher than the return on shipping another side project that nobody sees.
The hard part moved. You can move with it, or you can keep optimizing the part that’s already cheap.
If you’re starting now
If you’re inside of coding right now and reading this, here’s the more concrete version of the advice.
There’s a discipline emerging that doesn’t have a clean name yet. People are starting to call it go-to-market engineering, or GTM engineering. It’s the skill of treating distribution as an engineering problem instead of something that happens after the engineering is done.
GTM engineering work looks like:
- Sending cold emails that don’t get filtered as spam
- Figuring out how to manipulate social media to reach the people you actually want to reach
- Doing outreach to specific people on specific websites
- Making phone calls
- Reaching out to people on LinkedIn
- Getting something sellable in front of a buyer before you’ve spent a year polishing the build
These are the skills that compound across every business you could ever start. They’re also the ones that get most ignored when you’re optimizing for engineering output.
There’s tooling for all of this now. One that’s particularly interesting for LinkedIn outreach is Gojinberry. Tools like it are part of the GTM engineering stack the same way Postgres and Cloudflare are part of the application stack. Get familiar with that stack the way you got familiar with the engineering one.
On what to build: if you’re trying to stay remote, marketing technology is probably the broadest category to point at. The buyers exist, the budgets are large, and the patterns are well-understood enough that you can ship a real product without inventing a new technical category. Build something that’s basically a leaner version of an existing martech tool. You’ll be in a better position than if you tried to build new technology entirely off your own provision.
If you actually want to do hard technology, look at the open calls Y Combinator publishes. They put out lists of spaces where they think there’s real money waiting on a real builder. But each one requires optimizing for something different. You can’t pattern-match across them. You’re picking a specific bet and committing to it.
The principle underneath all of this: navigate to the distribution point before you build, as much as humanly possible. Get good at GTM engineering first. The engineering you already do will be more useful inside that frame than outside of it.