My SEO Strategy as a Solo Developer

I built API Alerts. It’s a notification routing service for developers. I’ve been working on it for a while and it’s at the point where the product is solid but nobody really knows about it. API Alerts 2.0 is about to launch, and I’ve been spending the run-up to it on one question. When it goes live, will anyone find it?

I ran an Ahrefs authority check a few weeks ago. apialerts.com was sitting at 2.9. mononz.com (this site) was at 0. Literally zero. Since then I’ve started working on the fundamentals and apialerts.com has moved to DR 6 with 75 backlinks across 33 linking domains. Not huge numbers in absolute terms, but a meaningful move from a low base in not very long. That’s the starting point for everything below.

I have a small marketing budget, but no investors, so it’s my own money. I’m not willing to spend it yet. Without a clear path to payoff, throwing cash at ads feels like flushing it down the toilet. I don’t have a team either. I have a blog and some spare time between my day job and playing with my cat. I’m also an introvert, so the “post in every Reddit thread, reply to every tweet” grind isn’t really an option for me anyway. So here’s what I’m actually doing.

The problem

I can build things. I’m pretty good at that. What I’m not good at is getting people to find them. I built API Alerts, I built Hooks (a free webhook tester), I built Hapi (API health checks). They all work. They’re all useful. But if nobody knows they exist, it doesn’t really matter.

There’s context behind that. I’ve been making mobile apps for 13 years. App store optimisation I actually understand. Screenshots, keywords, conversion rates on a store page, feature approvals, the whole dance with reviewers. That’s a different wheelhouse though. The App Store and Play Store are closed ecosystems with their own rules and their own gatekeepers. SEO is the open web, and it plays by completely different ones. This is genuinely the first time in my career I’ve sat down and tried to get people to find a website I made rather than an app. A lot of what I’m doing below is me working that out in public.

SEO feels like the only sustainable option for a solo dev. Paid ads cost money I don’t want to spend. Social media is a treadmill. But content that ranks on Google keeps working while I sleep.

What I’m doing

The technical foundation first. Before writing any more content, I wanted the plumbing to be right. I’ve been going through the site and making sure the basics are in place. BreadcrumbList structured data on every page type via shared layouts. Organization JSON-LD on the base layout. Canonical URLs checked and corrected. Redirect rules for every URL that moved during the 2.0 rebuild. IndexNow pings so changes get picked up immediately. Sitemap lastmod dates that actually reflect real changes. None of it glamorous, but the DR move from 2.9 to 6 came almost entirely from this kind of work rather than from new content, and I think that’s telling. Plumbing first, then content on top.

This blog. You’re reading it. I’m writing here on mononz.com about what I’m building, then cross-posting the good stuff to dev.to. The canonical URL points back here so that Google credits mononz.com as the source. dev.to gives me reach and community discovery, mononz.com gets the authority over time.

The honest goal of mononz.com isn’t to become a high traffic site. It probably never will be. The real goal is for individual posts to rank for very specific niche queries, attract exactly the right kind of developer, and have some percentage of them follow the thread to apialerts.com. dev.to’s high domain authority uplifts the mononz.com canonical in Google’s eyes, which makes that niche ranking more achievable than it would be starting cold.

There’s a second benefit to dev.to that’s easy to miss. Developers who read a post there often later Google “API Alerts” directly, and that branded search volume lifts both Google rankings and AI search visibility over time.

Free tools as awareness. Hooks and Hapi aren’t just side projects. If someone searches “free webhook tester” or “api health check tool” and finds one of my tools, they also find API Alerts. They’re top-of-funnel plays that happen to be genuinely useful on their own. Hapi gets 5-10 new users a week organically, which is 20-40 warm leads a month who are already the right audience.

The API Alerts blog. Product-focused content that targets high-intent keywords. Stuff like “how to get CI/CD build notifications” or “monitor GitHub Actions with push alerts.” People searching for those are already looking for a solution. That blog lives at apialerts.com/blog.

Integration docs. Every integration guide on apialerts.com (Slack, Discord, Telegram, GitHub Actions, and so on) is a durable search target with very high intent. Someone Googling “send Slack alert from GitHub Actions” is basically asking to be sold API Alerts. Docs pages consistently outperform founder blog posts for conversion because the person reading them is already trying to do the thing.

Use case pages. Slightly different from integration docs and worth treating as their own thing. Where integration pages answer “how do I connect tool X to API Alerts”, use case pages answer “how do I get notified when thing Y happens”. Same audience, different search intent. The first batch I’m writing for launch covers CI/CD failures, product analytics signals, payment and revenue events, and cron job failures. Each one maps to a real persona and names the actual tools a developer would reach for to implement it. The idea is to catch a query class that integration docs alone will miss.

Compare pages. I was originally going to skip these entirely. Old advice (including my own earlier notes) said don’t build compare pages at low domain authority because you won’t rank against the incumbents anyway. The authority move changed the maths enough that a small, careful compare bucket now makes sense as part of the 2.0 launch. The plan is upgrade-path and parallel-tool compares only. Tools my audience genuinely uses now and could grow out of, framed as “we start where they stop” rather than “they are worse”. No head-on competitor compares at launch. Those are a different and harder game that I’m happy to leave for month three or later once the tonal calibration can happen without launch-deadline pressure.

Directory listings and integrations. This one I underestimated early on. Getting listed on high domain authority platforms like RapidAPI (DR 82), AlternativeTO, and Product Hunt gives you permanent backlinks from trusted domains that actually move your own authority. More importantly they’re platforms with their own discovery, where developers actively browse for tools. A listing on RapidAPI is a backlink AND a potential customer channel.

The same logic applies to integration marketplaces. Getting API Alerts listed on the Zapier marketplace means being discoverable by a completely different audience, people who are already looking for notification and automation tools. These aren’t SEO plays in the traditional sense, they’re visibility plays that happen to help SEO too.

dev.to and Indie Hackers. Cross-posting from here when a post fits those audiences. The dev.to community is great for reach and the domain authority doesn’t hurt.

Twitter/X. I have @api_alerts set up. I’m holding the launch announcement there for the API Alerts 2.0 release. A lot of the distribution strategy is staged around that launch.

What I’m not doing

I’m not doing outreach or guest posting. I’m not buying backlinks. I’m not running keyword research spreadsheets either. What I do instead is simpler. Before any post I ask what exact phrase a stressed developer would actually type into Google, and I write the post to answer that phrase. That’s query-first writing without the process overhead. I’d rather spend my time building things and writing about them than maintaining spreadsheets.

Not all channels are equal

If I’m being honest about the funnel, the channels in this post don’t pull equal weight. Free tools, integration docs, use case pages, and the API Alerts product blog are the top tier for conversion. That’s where people land already trying to solve a problem. Compare pages, directory listings, and dev.to cross-posts are middle tier. Reach and authority plays that happen to help rankings. mononz.com (this blog) and X are the lower tier for direct conversion, but they matter for founder trust and brand recognition. Someone finds a niche post here, follows the thread to apialerts.com, and by the time they’re deciding to sign up they’ve already seen my reasoning.

That tiering tells me where to spend my time. Docs, use cases, and free tools get the most. Personal blog gets consistent but not excessive. X gets the launch moment.

The bigger picture

Everything I’m doing feeds into a single launch moment, API Alerts 2.0. The technical foundation, the content, the directory listings, the Zapier integration, the compare bucket, the free tools with CTAs pointing at the new features. It’s all staged to go live around the same time. SEO is a long game but a product launch is a short game, and I’m trying to play both at once.

The theory is that by the time 2.0 launches, the content has had some time to index, the backlinks are in place, and the distribution channels are ready. Whether that works in practice is something I’ll know soon.

Will it work?

I genuinely don’t know. Domain authority of 0 is humbling. Getting apialerts.com from 2.9 to 6 in a few weeks is encouraging but small in absolute terms, and it came from the easy wins. The next increments will almost certainly be harder. But it was always going to start low and the only way to change that is to start publishing and see what happens.

My friend has a personal blog and one of his posts ranks 3rd on Google for a specific Swift query. He didn’t write it for SEO. He wrote about something he knew deeply, and it happened to be something other developers were actively searching for. That’s not luck. That’s expertise meeting search intent, and it’s exactly what I’m trying to do on purpose with every post. Write about real stuff I know, publish it consistently, and make sure each post answers a question a real developer would actually ask.

Check back after the 2.0 launch and I’ll let you know how it went.