Engineering Practices for Building Production-Ready Software With AI
I’ve been building software professionally for over 10 years. In October 2025, I left my last engineering role to travel through Asia. Since then tools like Claude Code, Codex and others have reached a level where writing code, the bulk of it anyway, stopped being the hard part.
That shift cut the time from idea to working software dramatically. But it came with the cost of more context switching, and a lot more friction trying to stay organised across several tasks at once. It also raised a quieter problem: when code is this easy to generate, it’s easy to end up with something that works today and falls apart in six months. Architecture and long-term quality don’t take care of themselves just because the code came together fast.
So that’s what I started doing: building a real product, slowly, with AI in the loop from day one, and writing down what I’m learning, both about how AI has changed the way software gets built, and about keeping a codebase healthy while it does.
Why Architecture Still Matters When AI Writes Your Code
At some point in my career, I started to appreciate how much difference it made to take care of architectural decisions early. Messy codebases were always more difficult, and less enjoyable to maintain than projects where there was real investment in making sure things grew with proper structure.
Not to say those messy codebases weren’t maintainable. I’ve found plenty of them running fine in production for years. But those were always the codebases people quietly avoided touching as much as possible.
AI brings a different version of this same challenge. People know less and less about their own codebases, which makes sense; I’ve always understood features I wrote myself far better than ones a colleague wrote.
AI can scaffold applications so quickly that creating a product starts to look trivial. But I think that to keep those gains as a product grows, it’s necessary to work under the same principles as traditional software development. A codebase should stay in shape in order to grow, that means making sure we still own our codebases and have a good understanding of what’s been built.
As AI takes on more of the actual typing, I keep finding it more valuable, not less, to get the critical decisions about a system right. Not because AI struggles with syntax, but because my understanding and vision of the system is what guides it.
The bottleneck isn’t writing the code, it’s whether I can keep things coherent fast enough to keep up with how fast they’re being written.
That’s the question I want to use this series to work through, in real time, as the product grows.
What This Series Covers (and Who It’s For)
In this series I aim to document how to build software products from the ground up. It’s a compilation of what I’ve learned over the years and have put into practice repeatedly.
It’s also my own documentation of the newer aspects of this same process with AI development, the things I haven’t mastered yet, but hope to understand better as the product and this series grow.
If you’re a software engineer reading this, I hope some of these concepts translate fairly easily. If, on the other hand, you don’t have prior experience building software before AI, I still hope this gives you a clear guide to the steps involved in building your product, technical things you haven’t considered yet that might save you some headaches down the line.
At the end of the day, this is my own process. Not everything may apply to you, and I’ll most likely be missing important steps along the way. I’ll share as many resources as I can, prompts, workflows, and ideas, whatever I think is useful. If something here helps, take it. If it doesn’t, that’s fine too, this is what worked for me, not a rulebook.
Keonda: A Project Management Tool for Solo Developers and Small Teams
You can see the product live here . Keonda is a project management tool built for solo developers and small teams who want something fast and focused, without the overhead of tools designed for enterprise teams.
What’s Coming Next in This Series
These articles are mostly about the invisible layer: the structure, the patterns, the decisions made before a feature gets written. There will be code, but code isn’t the point. The point is everything around it, how to set up a project so velocity doesn’t decay over time, how to define patterns an AI can replicate consistently, how to think about a product as a system instead of a pile of features.
The scope is deliberately narrow. One person, building one product, from MVP toward something real. Enterprise scale, high-volume architecture, large team coordination, none of that is here.
The first article, “How to Choose Your Tech Stack When AI Can Code in Anything”, is out now.
And if you want to try the thing that’s driving all of this, Keonda is free to use. You can create an account and start managing your own projects. Feedback is welcome and much appreciated.
AI can write the code now. Judgement and product vision still belong to us.
I’m aiming for one article every two weeks. Sign up to the newsletter and follow along.