My development workflow today looks very different from the one I was using at the beginning of 2025. Back then I had ChatGPT in a browser and WebStorm next to it. I copied files into the conversation, asked for changes, pasted the result back into the IDE and repeated the process until the feature worked.
After understanding MCP, it becomes very tempting to connect everything. GitHub MCP. Database MCP. Documentation MCP. Project management MCP. Maybe another server for deployment, analytics and whatever comes next. Technically, that can be impressive. I am not convinced it is a good way to start every project.
I had seen MCP mentioned everywhere for a while, but for a long time I did not feel that I actually needed it. Then I started wanting AI tools to work with more than just the files in a repository. I wanted access to things such as databases, GitHub and other external systems without building a completely different integration for every AI client.
I used to think about AI development tools mostly in terms of which model was better. Now I find it more useful to think about what kind of work I am trying to do. ChatGPT is still where I like to think.
Once I started using coding agents more seriously, I became very interested in project documentation. If the agent understands the architecture, product rules and important decisions, surely it will make better changes. That is true. But there is an obvious trap: documenting everything because AI might need it someday.
Once a coding agent can inspect an entire repository, the next temptation is to explain everything to it. That is where AGENTS.md becomes useful — and also where it is easy to overdo it. At first I thought of it as a place for all the information an agent might possibly need.
When I first started coding with ChatGPT, the workflow was very literal. I would paste a file, explain the change I wanted, get some code back and then manually copy it into the project. That already saved a lot of time, but it also meant I was doing all of the coordination myself.
It is extremely easy to start using Supabase. Create a project, create a table, copy the URL and key into the app and start writing data. That is enough for a prototype. It is not quite enough for a project I want to keep working on.
Human input is messy. People misspell words, use different forms of the same name, leave out accents, mix languages and enter things that are almost — but not quite — what the application expects. It is tempting to solve all of that by sending every input to an LLM.
SQLite is almost perfect for a small local application. There is no database server to configure, the whole database can live in one file and development is incredibly simple. Then you deploy the app to Vercel. The application may still build successfully, the database file may even exist during deployment, and everything can look fine at first.
For a long time, when I heard “backend”, I imagined a server somewhere running all the time. You deploy an application to it, configure the database connection, keep the process alive and worry about the machine underneath. The more side projects I build, the less often my backend actually looks like that.
Accepting money sounds like the kind of feature where I should build a large billing system. For most small applications, I really do not want to. A payment provider can already handle the difficult parts: card processing, checkout, receipts, taxes in some setups, subscription management and a lot of the security requirements I would rather not implement myself.