"Build an app with AI and earn passively" is the most oversold sentence in developer content right now. I have made about $6,400 from AI-built tools over three years, which is a decent side income, not a passive one. Most of that came from one product, and the work was support, not code.
This is the honest version: what I built, what it earned, what it cost, and which model I would pick again.
| Tool | What it does · Built in | Gross revenue · Status |
|---|---|---|
| Hotel rate widget | Embeddable price checker for small travel sites · 3 weeks | $2,900 · Running |
| Itinerary PDF export | Turns a chat into a branded PDF · 10 days | $1,850 · Sold |
| Meeting notes CLI | Local transcription and summary · 2 weeks | $0 · Shut down |
| Trip planner | Conversational planner with booking links · 4 weeks | $1,650 · Running |
Total gross is about $6,400 over three years. Hosting, API calls, and one design tool cost roughly $1,200. The rest was my time, which I value at more than the margin.
What actually sold
The hotel widget. A widget is unglamorous, embeddable, and easy to explain: a small travel site pastes one script tag and gets live rates on their pages.
Three things made it sell:
It solved a buying question, not a writing question. People pay for prices and availability. They rarely pay for a better description.
It had a unit of value. Ten thousand lookups for a flat fee. The buyer could do arithmetic, and so could I.
It failed loudly. When the rate feed was down, the widget said "price unavailable" instead of showing a stale number. Two customers mentioned this as the reason they stayed, which I did not expect.
The itinerary PDF made money once, as an acquisition: a small agency bought it and paid me to hand over the code. That is a real outcome and not a business.
What did not sell
The meeting notes CLI earned nothing, and it took me a while to understand why. The free options were good, the paid options were bundled into tools people already had, and my version's only advantage was that it ran locally. That is a feature, not a product.
The lesson: if the buyer can get 80% of the value for free, the remaining 20% needs to be a workflow, not a checkbox.
The cost nobody lists
Support. Roughly three hours a week at the peak, mostly installation problems. A widget is easy; the site it gets embedded in is not.
API drift. Two rate-feed changes in eighteen months. Each one was a day of work and a round of apologies.
Billing and tax. Stripe is easy. Invoices, refunds, and the one customer who paid twice are not.
Distribution. This is the real cost. Writing the tool took three weeks. Getting the first ten customers took three months, mostly in communities where I was already a member.
"Passive" describes the revenue after month eight. It does not describe months one through seven.
The three models, ranked by fit for a solo developer
1. Usage-based on a boring B2B need. The widget. A buyer with a business reason to pay, a measurable unit, and no expectation of a consumer app. This is the model I would choose every time.
2. One-time sale of the code. The PDF export. Lower ceiling, immediate cash, no support tail. Good if you enjoy building more than operating.
3. Consumer subscription. The one I have not made work. Churn is brutal, support is emotional, and the buyer compares you to free tools. I would need a much sharper niche than "travel planning" to try again.
The travel-specific option most people miss
There is a fourth model that fits small travel tools better than a subscription: take a margin on the transaction instead of charging the user.
If your tool recommends a hotel and the booking completes through a partner, the partner pays a commission or lets you set a markup by country. The user pays the same as they would elsewhere; you earn on conversion rather than on a paywall.
That is the model behind RollingGo's partner program. The MCP server returns a bookingUrl per property, so a small tool can hand off the transaction and still earn on it. Two things make it viable for a solo developer: the API key tier is free with no call cap, so testing costs nothing, and the markup is set on the partner side rather than built into your code.
It is not passive either. Conversion depends on the quality of your recommendation, which depends on the data and the UI. But it aligns the incentive: you get paid when the user actually books, not when they sign up and forget.
If you want to test the model without building a product first, the developer site has the partner flow and the key request. The vendor reports 2,000+ developers and agents connected, which is a useful signal for whether other small builders are trying the same thing.
What I would tell someone starting today
Pick a job with a number in it. "Cheaper hotels" is measurable. "Better travel planning" is not, and you will not know if you shipped.
Charge from day one. Free users do not validate a business, they validate your patience. Ten paying customers at $19 tells you more than a thousand free signups.
Keep the surface small. One widget, one endpoint, one price. Every additional feature doubles the support load and adds a failure mode you have to explain.
Write the cancellation email before launch. If you cannot describe how a customer leaves, you do not understand the product yet.
Do not quit the job. $6,400 over three years is a good reason to keep building and a bad reason to stop earning a salary.
The uncomfortable part
AI made the building cheap. Three years ago the widget was six weeks of work; now it is closer to two, and most of that is the embed logic, not the model.
What did not get cheaper is deciding what to build, finding ten people who will pay, and answering their email when it breaks. Those are the parts that decide whether a tool earns $0 or $6,000, and no model has made them passive.
Top comments (0)