Code architecture for indie devs

Last few years I have been obessing over software architecture a bit too much. It was a phase. Imposter syndrome kicked in I guess. No matter what I was building, I tried to create extreemly scalable software, that was and would be easy to maintain.

Applying DDD on a codebase of 5k LOC. Springling some Uncle Bob on a codebase of 10k LOC. Codebases build to last. Codebases build to scale. But without users.

As an indie developer speed of development is crucial. When you have not validated product market fit yet, then getting the product out there is the only thing that matters. Code maintainability is not your concern this stage. Making sure you didn’t write the all that code for nothing, is your only concern.

By applying one (or more) of these architectures you by definition make your code more complex. And these (premature) optimizations have prevented me in the past from working on the things I really should be working on: talking to users. I slowed myself down unnecesarily. A big no no. When product market fit is not yet validated - just ignore any theories and write code. And don’t forget to ship it. Once you reach (some) traction, you can always refactor the code. Also, at that point you probably understand much better what the real value of your application is, and what the important bits are - and thus you can refactor your code much more effectively.

After reading about these theories, I learned some much that architecting code is all about reducing the required human resources to develop and maintain a project. Since there is no project to maintain yet, there are no rules regarding architecture either. Just stick to any tech what you know and write. You don’t even have to structure it. It is okay if it is slow, complex or whatever. It this stage it only matters if you can validate product market fit.