Most people say SEO takes 6-9 months to start delivering results.
In our case, it started making money in the first weeks.
Within 90 days, we grew MRR by 2.5X without an in-house team.
We didn't use SEO to get traffic. We used it to get customers.
Here's exactly how we implemented a Product-Led SEO strategy, and it became the main acquisition channel.
Starting point: No engine, no trust, rising pain
The two technical co-founders got to about $2.3k MRR by doing things that don't scale, mostly reaching out to their internal network.
The CTO had written a short series of tutorials and shared them on Hacker News. The other founder raised $1.2M.
But there was no repeatable acquisition engine, no trust signals, the product was hard to understand for many, and the storytelling was basically a copycat from a small competitor.
Meanwhile, web data extraction was getting harder, more unreliable, and more expensive. Cloudflare sits in front of about 1/5 of websites and even offers a free tier, making bot shields accessible to everyone.
Automated traffic surpassed human activity (51%) in 2024, which means the internet is increasingly built to detect and block bots.
That's the gap we filled. Our job wasn't "publishing content". It was turning that pain into a repeatable acquisition engine while owning everything from messaging to product experience.
Intent-first SEO: Pick topics where failure is likely
We didn't try to educate the market into wanting a web scraping API. We replaced an existing behavior: developers already search for DIY fixes when scraping breaks.
Yes, many developers don't control a budget. But bottom-up still works when the product delivers fast and can be tried for free. The key is catching them at the must-have moment, not when the problem is mild.
The biggest question wasn't "How do we get traffic?".
It was: "How do we reach developers at the exact moment they experience the pain we solve?"
Truth is, paying for the data extraction tool wasn't justified when scraping most websites. It did when trying to access popular sites where valuable data lives and developers get blocked. And that happens more often with some verticals. For instance, 82.3% of visitors to e-commerce product pages are bots.
So the insight was simple: high-value targets correlate with stronger bot defenses, which means DIY approaches fail more often.
We started with a domain rating of 27/100, so we needed topics that didn't require high authority to win, and that could monetize directly.
So we defined the "aha moment" as this:
A developer tries open-source or a free solution on sites that block bots. They fail. Then we introduce why it didn't work (or what else is required) and why our product is the natural next step.
This is why the typical "SEO takes months" narrative didn't apply. We weren't chasing broad awareness keywords. We were chasing pain.
Prioritize keywords with a smart scoring model that focuses on revenue
In the first week, we reviewed competitors (direct solutions, alternatives, SEO players), had customer development discussions with the CEO, and gathered examples to justify our strategy.
Then we used a qualification framework with four angles:
- Pain distance: how close the search intent is to "This is not working and I need a solution".
- Product-keyword fit: Does the intent naturally lead to our paid product as the next step?
- ICP fit: Are these the people we want to attract?
- Competitiveness: Can this rank fast given competition, authority, and distribution? We wanted quick wins. Pain distance in product-led SEO was the biggest signal early on because the domain is full of topics that get traffic but don't convert.
A simple ladder:
- More pain: avoid getting blocked while web scraping
- Less pain: pagination with beautiful soup 4
- Even less pain: click link with playwright
So we wrote articles for people searching for how to solve the problem with open-source tools.
In other words: in the build-vs-buy dilemma, we chose the Build path. Because it was easier to rank for a small site with limited reputation, and because it set up the failure moment that makes the product feel inevitable.
The "Failure Moment" framework to drive signups and customers
We made our first million dollars in recurrent revenue with a $50 website. No CMS, no fancy stack.
Developers ignore anything that looks salesy, so we mostly wrote tutorials because that ultimately led to the product.
For example:
Pattern A: You got blocked (visual proof), now what?
You got blocked. The website detected your bot.
You can try rotating IPs, premium proxies, rotating UAs, etc. But these are partial fixes. Advanced systems like Cloudflare can still easily detect you. So what can you do? (...).
It fulfills the DIY instinct (developers like building), then focuses on the outcome with a paid solution.
Pattern B: Do-It-Yourself worked, but it won't scale.
Nice, you randomized your user-agent.
However, this only works for a small number of requests because (...).
Let's see an example of a reliable approach to bypass anti-bot measures at scale without (...).
It reframes the decision from "free vs. paid" to "maintenance vs. outcome".
Since this method has no name (as far as we know), we personally call it the Failure Moment framework, where we bridge open-source solutions with a paid one.
This is the framework:
- Let the reader make progress with open-source software alone (search intent alignment).
- Trigger or predict failure on real targets (blocking, CAPTCHAs, empty HTML, 403, etc.). Sometimes as a step, others as a section, but always connecting them.
- Explain why "single fixes" don't hold (user-agent alone, proxies alone, even combinations still fragile at scale or for some target sites).
- Offer the production path (a single API call, reliable output).
- Prove it by showing real output (not marketing claims).
- Handhold the first success (UI playground → copy code → integrate).
This is why SEO monetized fast: we didn't rely on persuasion. We relied on the moment the reader already wanted a solution.
What we tested to improve conversion
Ranking was only half the job. The other half was delivering what searchers actually wanted, and converting technical readers without sounding promotional.
For example, we complemented the in-article promotion with soft touches (a CTA near the beginning and part of the conclusion). Repetition beats originality.
We also had to keep credibility with advanced users while still converting beginners. Because if we wrote only for experts, we'd lose most of the revenue. If we wrote only for beginners, we'd lose serious tickets. The solution was to atomize tutorial steps by defining micro-wins, and write like a helpful engineer: clear instructions, minimal fluff, and a fast path to results (time-to-value).
Also, we managed a cross-functional perspective (broader than blog posts) to align with the customer journey, even when assets are traditionally owned by different teams:
- Developer documentation: If we mention JavaScript rendering in a tutorial, the API documentation must explain it.
- Product UX/UI: If we create tutorials for C#, the language must exist in the product UI.
- Website conversion optimization and landing pages: Capabilities must be scannable in the homepage and menu because devs scan for specific terms, and assume you don't have what you don't mention.
Finally, bold promises helped when they were instantly verifiable. "Scrape any web page" converted because readers could test it in the UI on their target URL and then integrate it into code. They didn't need to trust the claim because they could verify it.
Note: We created and ran a data-backed experimentation pipeline that went far beyond what's written here.
Building credibility from scratch: Uncopiable content and high-quality standards
The website had no reputation, not even an online review, and no time to "build trust slowly". So we built trust the only way we knew would work in this market: prove we can solve the hardest technical problems people were actively searching for.
Our early trust hack was uncopiable content.
We hired hackers to address hardcore challenges and turned that into articles. Some of that content hit the front page of Hacker News and got distributed by cybersecurity influencers.
But it wasn't scalable. That content is time-consuming end-to-end, and very few people can write it. So we treated it as an early growth lever, not the core scalable model.
So we were building a scalable engine in parallel.
Now, the uncomfortable truth: hiring niche technical writers was a big challenge.
When we looked for developers who can write (both words and code) and have experience in the industry, it looked easy: good portfolios, some domain expertise.
In reality, quality was wildly unreliable and didn't meet our high standards.
A pattern we noticed: many freelancers show samples that were heavily shaped by editorials, meanwhile they actually deliver what we call "bullet writing", i.e. content that reads like an endless list, not a tutorial that teaches, builds trust, and converts.
We ended up testing 50+ technical writers until we found great ones. In the process, we developed a very specific process to hire, communicate and train the right external people in highly technical and more niche industries.
Our goal was to reach 10 articles per month, and we reached that with high-quality and high-converting content, while maintaining consistent standards.
What actually made quality predictable: Documentation
Even when working with external writers, some best practices that work are:
Tip #1: Don't assign what you can't picture.
If you can't imagine the article in 99% detail, don't assign it to a writer.
Tip #2: Content briefs have to be near blueprints.
Early on, we spent 1–2 hours per content brief and got feedback from internal stakeholders. But that was a key pillar to generate customers, and the process sped up over time.
The costly alternative would have been: endless article revisions, pasted-in product pitches, weak linking, and published content that gets views but no revenue.
The brief defined the structure, the steps inside each section, and how to bridge into the product in deep detail.
Tip #3: Guidelines and checklist per role.
We implemented role-specific guidelines on the go, updated with good and bad examples, and respected them with an interactive checklist. The goal was to set clear expectations and consistent execution.
That's how we turned unpredictable writer output into a repeatable publishing standard.
We've generated over $8M with SEO for engineer-oriented companies, so if you want help, drop me a message on LinkedIn or schedule a strategy call.