Summary
Billing, login, and receiving contact messages: I handed all of them off to outside services. For membership and billing, the only things I keep in my own database are a mapping of who is a member of which plan, and a copy of the subscription and purchase state. I keep that copy because if the site went to the payment service to check the subscription state every time a reader opens a paid article, the display would get slow. When you develop together with AI, the implementation itself can be pushed as far as you like. So the first thing to decide was not what I could build, but what I would not hold myself.
Audience and takeaways
This article is for someone trying to build a service with billing on their own while having an AI agent write much of the code. You can take away how to decide how much personal data to hold yourself and where to start handing it off to outside services, and why deciding that standard up front pays off. It also gives concrete examples: what rule I used to deal with the AI’s habit of confidently writing outdated specifications, and how I split the work so that the AI handles the research into terms and prices while a person makes the decisions that put limits on cost and permissions. This article is a record of practice, based on the process of building this site itself together with AI.
This is a sample: the full text is open for free. Read the full article.