Humanizely is an AI-text detector and humanizer. The visible product is simple: paste text, see whether it reads as machine-written, then rewrite it in a tone that sounds human. The part that took the longest to get right is everything around that loop — plans, billing, entitlements and support.
This is not a growth story. It is a list of the operational decisions I would make again, and the ones I would change.
Detection is the easy part to demo
A detector can be demonstrated in an afternoon. You paste text, get a score, show a few highlighted sentences. The demo convinces people that the product exists.
The hard questions start after that. What does the score mean? Which sentences caused it? If the user rewrites the text, does the score move for the right reason? A number without an explanation is not useful, so the detector shows sentence-level reasoning rather than a single opaque percentage.
The humanizer has a similar constraint. It must preserve meaning, citations and numbers. A rewrite that quietly changes a date or a citation is worse than no rewrite at all. Most of the engineering effort goes into keeping those invariants while changing the tone.
Plans are product decisions, not pricing tables
Humanizely has four plans: Free, Writer, Author and Studio. It would be easy to treat them as limits in a database. They are really promises about who the product is for.
A free plan has to be useful enough to demonstrate the product, but not so generous that it replaces a paid plan. A writer’s needs differ from an academic’s, and a studio may care about volume and team workflow rather than individual features. Each plan changes what the interface emphasises, not just how many words you can process.
The mistake I see in side projects is adding a plan because a pricing page looks empty. Every plan creates a support surface, a billing edge case and a set of expectations. Fewer, clearer plans are easier to run.
Billing and entitlements are two systems
Paddle handles payments and tax. RevenueCat handles entitlements. They solve different problems, and treating them as one system causes bugs.
A payment can succeed while an entitlement fails to update. A subscription can be cancelled but remain active until the end of the period. A refund can arrive days after the user has already consumed the feature. The product needs a source of truth for access that is separate from the checkout event.
The rule I use: never grant access directly from a client-side checkout callback. The entitlement service is the authority. The client asks what the user can do; it does not decide.
Support is part of the product
A paid product generates email. Some of it is bugs, some is confusion about plans, and some is a person who needs the tool to work for a deadline. The response is part of the experience, especially for a small product with no support team.
Two habits help. First, keep a short internal note for every recurring question and turn it into help text or a better empty state. Second, answer with a specific next step rather than a promise to look into it. “Try this, then reply with the text you used” is more useful than “we’re investigating.”
I also keep billing conversations out of the product interface where possible. A user who is worried about a charge does not want to hunt through settings; a direct email link is faster and less frustrating.
What I would change
I would instrument the first paid conversion earlier. Not to optimise a funnel, but to understand which feature made the product worth paying for. Without that, plan design is guesswork.
I would also write the cancellation and refund flows before launching the checkout. They are the least glamorous screens and the ones most likely to be missing when a real customer needs them.
The part that matters
Running a paid product solo means the demo, the billing system, the help text and the support inbox are all the same job. The product is not the detector or the humanizer alone. It is whether a person can trust the result, pay without confusion and get help when something breaks.
That is less exciting than shipping a feature. It is also what separates a product from a prototype.
