I'm a product manager. I can't write code — not "I'm rusty," not "I know some Python." I cannot write the code that runs my business.
Six months ago my product made $30.32. This month it made $8,880. I have never paid for a click.
The numbers first
Revenue, straight out of the production database, admin accounts excluded:
| Month | Revenue | Paying customers |
|---|---|---|
| 2026-03 | $30.32 | 3 |
| 2026-04 | $230 | 3 |
| 2026-05 | $460 | 9 |
| 2026-06 | $2,410 | 33 |
| 2026-07 | $6,730 | 63 |
| 2026-08 | $8,880 | 127 |
293x in six months. Trailing 30 days is $9,180 — so no, I haven't crossed $10k/month yet. September probably. I'd rather publish the real number than a rounder one.
On the system side:
- August: 299,668 API calls at a 95.5% success rate
- Excluding content-moderation rejections — a customer's prompt refused upstream, not my system failing — it's 98.9%
- From July to August, volume grew 2.6x (116k → 300k calls) while the success rate went from 93.9% to 98.9%
Volume nearly tripled and stability went up. That last line says more than the success rate on its own.
But a success rate can lie to you — in a minute I'll show you exactly how it lied to me. The number I actually trust: only 20 customers have ever topped up in more than one month, and they account for 70.8% of all revenue I've made. Heavy users renewing month after month is the one stability proof that can't be faked. Nobody keeps paying for an API that isn't good.
The product is apimodels.app: one API key for 182 AI models — image, video, audio, and LLMs — behind a single OpenAI-compatible interface. Every line of it was written by an AI coding agent working under my direction.
How does someone who can't write code run this?
It's the question I get most. The answer has four layers, and the first one matters more than the rest combined.
1. This business has exactly two product cores
Nobody picks a model aggregator because the UI is nice, the feature list is long, or the model catalog is big. They pick you for two reasons: the same model is cheaper here, and you don't fall over.
That's the whole list. Everything else is decoration.
Get the core right and the product follows. That sounds like a truism. The operational meaning is sharper: every hour you have should go into those two things, and you need to know, at all times, whether you're cheating on one of them.
Because they will lie to each other. Here's the time I nearly got away with cheating on "cheaper."
2. Official model channels only — a rule I paid for in customers
Early on I wired up a very cheap upstream for a popular video model. Cheap enough that the margin looked absurd.
Then I noticed something no dashboard flagged: several users tried it once and never came back.
No errors. No failed calls. Every request returned 200.
So I ran the same prompt through the official channel and put the two clips side by side. It was watered down. Almost certainly a lower resolution upscaled and delivered as the higher one — or the cheap tier being passed off as the premium tier.
That upstream wasn't failing. It was substituting. Every request "succeeded," my error rate was immaculate, and my retention was dying.
That's when the rule got written, and it hasn't been broken since: official model channels only. Never a reseller priced far below the market.
If something is cheap in a way that seems impossible, it is guaranteed to be both unstable and quality-compromised. There's no third explanation — somebody has to pay for the GPU, and if it isn't you, it's coming out of what you receive.
So "cheap" as a product core needs restating. It isn't cheapest possible. It's the lowest price at a quality level you have actually verified. Undercut that line and you haven't won a customer — you've rented one for a single call.
And notice which instrument caught it: not the error rate. Retention. Silent quality degradation is invisible to every monitor you have. The only thing that reveals it is whether people come back.
3. Everything built in-house — no open-source gateway
There are several good open-source API gateways. You can be running on one in a day. I used none of them.
The reason is simple: price and stability both live in the same layer of code — the forwarding logic between the customer's request and the upstream model. That layer is exactly what an off-the-shelf gateway occupies.
When a failure lives inside a dependency, your move is to file an issue and wait. When it lives in your own code, you fix it that afternoon. At 300,000 calls a month, the gap between those two response times is the product.
Much slower to start. And the only way to actually control the two things customers are paying for.
As for how the success rate got from 93.9% to 98.9%: every mechanism in this system exists because of a specific production failure. Not one of them was designed up front. "Polishing," in plain language, means something breaks, you understand it, you turn it into a rule that stops it recurring, and then you do that three hundred times. There's no shortcut version — and it happens to be work a non-coder can do.
4. What I own isn't the code. It's defining what counts as evidence.
The most misunderstood part: this is not "the AI writes it and I click deploy."
If that's your loop, you'll ship something that appears to work and quietly does the wrong thing, and you'll hear about it from a customer.
The agent generates. I define what counts as evidence that it works. Four rules, each one written down because breaking it cost me money:
Never deploy automatically. Test locally, show me the result, I say OK, then commit. No exceptions, no "this one's trivial."
"Test it" means test it. Not test-and-then-fix-what-you-found. When I ask for a diagnosis I want the diagnosis — a fix applied before I understand the problem is a fix I can't evaluate.
A deploy succeeded only if the code running on the server equals the version I pushed. Not if the command printed no errors. I lost a full day to a deploy that reported success at every step while the server ran week-old code.
Verify against production data, never against a summary of production data. "I checked and there were no errors" and "here is the query and here are the zero rows" are completely different claims.
None of these require reading code. They require refusing to accept confidence as evidence — which turns out to be a product skill, not an engineering one.
The bottleneck in AI-assisted development was never code generation. It's verification. And verification is exactly the part a non-coding PM can own completely.
Then three things I got wrong
My free tier couldn't afford a single call
New users got $0.10 in signup credit. The video models my content pushed hardest cost between $0.89 and $2.66 per successful call.
A new user signs up, lands on the page my SEO worked hardest to rank, tries the thing that page is about, and gets rejected for insufficient balance. Their first experience of my product is a billing error.
The obvious fix is raising the credit. I almost did. Then I sorted every model by actual per-call spend instead of by how much I liked it, and two things stopped me cold:
-
veo-3.1-fast-fhd: $0.0684 per clip — 1080p, native audio. $0.10 covers it with change. -
gpt-image-2-lite: $0.0078 per image. The same $0.10 buys twelve pictures.
So the free tier was never too small. It was perfectly adequate for a path no new user was ever shown. I'd built a funnel that took strangers by the hand and walked them into the most expensive thing I sell.
A free tier isn't a generosity number. It's the answer to one question: can a brand-new user complete one full happy path with it? If not, you have two levers, and raising the credit is the expensive one.
Never build a product page for a model you can't actually call
To go after a new model's search terms, the instinct is to put the page up first.
But that reads as a claim that you offer it. The API will 400 every time, and the specs and prices can only be invented. Worse — you've fed a false fact to the LLMs, and it gets cemented. By the time you really launch, the version in their heads is still the one you made up.
The right move is an honest placeholder: state plainly it isn't open yet, show how you verified that, promise it the day it launches, and put a working neighboring model in the code sample. Honest pages rank fine, and they leave no debt.
In an era where AI remembers what you said, this only gets more important.
Healthy SEO metrics and a working product are independent
Two of my flagship model pages failed on every single call because of a config error — for ten days, and nobody noticed.
Because the page status was active, it was indexed normally, and Search Console kept right on reporting impressions and clicks. Those metrics measure "the page exists and got crawled." None of them measures "the person who clicked could use it." If GSC is your only dashboard, everything looks great.
This and the watered-down upstream are the same disease: your dashboards will show everything is fine while the product rots. The only cure is finding one metric that can't lie. For me that's retention.
One thing I still haven't gotten right
I've never bought a click. That I can prove.
The only acquisition work I've done is content: 1,204 indexable pages across 7 languages, a page for every model. I believe the traffic comes from search and LLM citations, because it's the only thing I've ever done.
But I have to say this out loud: I can't prove it.
There is no analytics on my site. No Google Analytics, no Plausible, no PostHog. My user table has a registration IP and a timestamp and no source field of any kind.
My largest customer paid $3,000 in August. I do not know how they found me. Not which page, not which query, not which language. I know their invoice total and nothing else.
Install analytics on day one, and add a first-touch source column to your user table on day one. Not because you'll read the dashboard — you won't, for months. Because on the day you finally have revenue worth explaining, the data either exists or it doesn't. It cannot be backfilled. Ever.
It's the biggest mistake I've made, and it's the one that looks least urgent while you're making it.
About apimodels.app
One API key for 182 AI models — image, video, audio, and LLMs — through an OpenAI-compatible interface, with no separate signups or quota applications per vendor.
- Image generation from $0.0078 per image
- 1080p video with native audio from $0.0684 per clip
- 299,668 calls served in August 2026 at a 95.5% success rate
- Official model channels only — no resellers priced far below market
- Interface and docs in English, Chinese, Japanese, Korean, Spanish, Portuguese, and Russian
Every figure here is queried straight from production. Happy to answer anything in the comments.
Top comments (0)