Choosing the right API
I tested three different language models over a weekend. The cheapest one produced flat, generic sentences that felt like they came from a form letter. The most expensive gave clean output but cost more per call than I was charging per month. I settled on a mid-tier model that balanced quality and cost well enough to keep margins healthy from the start.
The other thing I learned early was to keep the prompt tight. Long prompts with too many instructions confused the model and produced inconsistent output. I stripped the prompt down to the essential task: the job description, the user's resume, and a single instruction to match the two without removing the person's voice.
The first version was embarrassingly simple
The first version of the product was a single HTML page. One text area for the job description. One for the resume. One button. I hosted it on a five-dollar virtual server and pointed a cheap domain at it. There was no login, no payment wall, no dashboard. Just the form and the output.
I shared the link in three indie maker communities and asked people to try it and tell me what broke. Within forty-eight hours I had thirty-one users who ran multiple sessions each. Two of them emailed me without being prompted, which told me the output was at least good enough to be interesting.
The traffic was small. But it was real. People were returning to the page the next day, which I had not expected at all. I kept the free access open for the first month intentionally, just to see what a regular user actually did with the tool over time.
What early users actually said
I put together a plain email list using a free tier on a basic ESP. Every three days I sent a short note to everyone who had tried the tool and asked one question. Not a survey. Just one question in plain text. What did you end up changing after the tool gave you output?
The answers were more useful than anything I expected. One person said the tool made his work history sound like a job description instead of a personal story. Another said the opening summary always felt too formal. A third said she wanted to lock certain lines and only rewrite the rest. Each piece of feedback pointed to something specific I could address without rebuilding from scratch.
I added a simple lock toggle that let users mark sections as fixed before running the tool. I also softened the default prompt instructions around the summary section. Small changes but they cut the post-output editing time noticeably, at least based on what users told me in follow-up replies.
Adding the subscription
After a month of free usage I added a simple payment layer using a processor that handled the recurring billing without requiring me to write much code. I set one price. One plan. Twelve dollars a month. No annual option. No tiers. No discount codes.
Fourteen people subscribed in the first week. I had expected to explain the pricing or justify it somehow. Instead the people who found the tool useful just paid. The ones who did not want to pay stopped using it, which was completely fine. I was not trying to convert everyone.
What surprised me was how few people asked for a refund. In the first three months I had two refund requests, both in the first week. Both from people who had misunderstood what the tool did. That told me the product description needed a bit more clarity, not the pricing.
The weekly rhythm
The work settled into a rhythm after the second month. Monday I check the API usage logs and watch whether the cost per session is drifting upward. Wednesday I read user notes and update the keyword matching logic if something stands out. Friday I send a short email to the list, not a formal newsletter, just a note about what changed and what I am thinking about next.
I keep a plain text file on my desktop where I log every change I make to the prompt, the page, or the payment flow. Next to each change I write one number: what happened to the session completion rate after I made it. Most changes do nothing. A few move it noticeably. That file is more useful than any analytics dashboard I have tried.
What I would do differently
If I started over I would spend less time on the frontend and more time on the prompt. The HTML page I built on day one still works fine. The prompt has gone through nineteen versions. The prompt is the product. Everything else is the container.
I would also charge from day one. Free usage gave me feedback, but it also brought in users who were never going to pay. The paying users gave better feedback because they had some investment in the outcome. Their notes were shorter, more specific, and easier to act on.
The tool is still small. It does not have a mobile app, an API for third parties, or a team behind it. It has a few hundred subscribers and a cost structure that keeps it profitable without requiring constant attention. That is exactly what I wanted when I started.
I still open the inbox each morning and read the new notes. Some days there is nothing. Other days someone has written a full paragraph about how their session went. I read every one of those. The tool is small and I want to keep it that way. Small things are easier to take care of.
Turn AI Into Extra Income
You don’t need to be a coder to make AI work for you. Subscribe to Mindstream and get 200+ proven ideas showing how real people are using ChatGPT, Midjourney, and other tools to earn on the side.
From small wins to full-on ventures, this guide helps you turn AI skills into real results, without the overwhelm.

