You don’t need microservices… yet

Have you ever heard about Conway’s Law? As I’ve learned, this law states that the architecture of a system mirrors how the company communicates between different parts of the organisation. Apparently it was studied through and through and found true! The most fascinating part is that it works both ways: you can influence either of the systems and see the change reflected in the other. Clear up air between two teams and watch them uncover and fix bugs between their deployments sort of magic! Such a powerful realisation, isn’t it? And so I thought how can I apply it to my passion project - Hounty, a chore management app I’m building in my free time? Kept it simple, silly? I’ve made significant progress, but it’s been so hard to get through these final 10%! And from the comments to my posts I’ve learned that others tried to build something similar but got stuck at various architectural stages. I myself attempted to rewrite everything from scratch over and over again even before the core functionality was there. But in the light of Conway’s law the reason why it happens became clearer - I think it stems from a misconception of how excellence should look like in software development. What surprised me the most is that I’m well aware of the pitfalls of premature optimisation and unnecessary complexity. I’ve been preaching the “simple is the new smart” for several years now! I’ve kept my team from overly complicated solutions and led gradual massive transition initiatives more than once! And yet I got stuck in a loop of endless perfectionism with a much simpler project - and being a sole contributor leads me to a refreshing understanding that this is a direct result of my mistake. But what did I get wrong? Don’t place all your eggs in one basket? Along with preaching simplicity I’ve been a huge advocate for modular structures: it worked perfectly in so many projects I was part of! Clear scope of every folder allows to share ownership easier, the structure represents the teams that are handling it and I was absolutely certain that this setup is great a starter point of any project! And of course I must be proactive and make sure that I don’t have to completely redo the architecture when the system needs to scale up really quickly! Of course I’m aware that you don’t start with Kubernetes right away (as the joke goes you gotta wait till you get 7 concurrent users), but I still fell in the trap of “monolith is bad”. Now I didn’t deploy Hounty in microservices, but I tried to keep the code structure decoupled to be able to do it easier when the time comes. Because I’m an expert, okay?! I don’t build no monoliths! Do you want to build a monolith? Well, as per Conway’s law I absolutely should build a monolith. Just drop files in one folder, deploy it somewhere quick and get it out in the hands of real users to get data. Not because I’m cutting corners or accumulating tech debt, but because at this stage of the project that is how technical excellence looks like. I was trying to force modularity on a system held by a solo developer and it felt… lonely. Because my changes to the architecture demanded changes to the organisational structure and that’s not possible at the moment. Tech debt? I think the biggest misconception was my understanding of technical debt: I used to think that it’s misalignment between current system and industry standards or best practices, but now I believe that it’s misalignment between system and supporting organisation. Ultimately, we want our software to do what it’s supposed to do at any given time and we want to make sure that developers working with this software can do it with the least amount of friction. And there’s no gold standard: there are patterns that one can apply in a specific situation. For example, a Strangler Fig pattern - that allows to wrap a system to decouple it bit by bit when the time comes. For Hounty I’ve built a system on Supabase with a Deno BFF layer. Most of the logic is in the database layer right now and it took me a while to accept that: I didn’t see that I’ve already went above and beyond by building a BFF layer that allows me to swap any part of underlying system without rewriting the app. The system as it is right now meets my security and scalability standards. It’s not just good enough: it’s perfect for this stage. It’s not done till it’s out I was planning to release Hounty in beta, but users below 13 can’t participate in TestFlight or install unpublished Play Store apps without giving up all parenting controls, so I have to finish the app and polish user experience to be able to pass app review before I can release. And I’ll tell you all about the “90% ready” fallacy in my future posts if you’d like

May 10, 2025 - 08:54

Have you ever heard about Conway’s Law? As I’ve learned, this law states that the architecture of a system mirrors how the company communicates between different parts of the organisation. Apparently it was studied through and through and found true!

The most fascinating part is that it works both ways: you can influence either of the systems and see the change reflected in the other. Clear up air between two teams and watch them uncover and fix bugs between their deployments sort of magic!

Such a powerful realisation, isn’t it? And so I thought how can I apply it to my passion project - Hounty, a chore management app I’m building in my free time?

Kept it simple, silly?

I’ve made significant progress, but it’s been so hard to get through these final 10%! And from the comments to my posts I’ve learned that others tried to build something similar but got stuck at various architectural stages. I myself attempted to rewrite everything from scratch over and over again even before the core functionality was there.

But in the light of Conway’s law the reason why it happens became clearer - I think it stems from a misconception of how excellence should look like in software development.

What surprised me the most is that I’m well aware of the pitfalls of premature optimisation and unnecessary complexity.

I’ve been preaching the “simple is the new smart” for several years now! I’ve kept my team from overly complicated solutions and led gradual massive transition initiatives more than once! And yet I got stuck in a loop of endless perfectionism with a much simpler project - and being a sole contributor leads me to a refreshing understanding that this is a direct result of my mistake. But what did I get wrong?

Don’t place all your eggs in one basket?

Along with preaching simplicity I’ve been a huge advocate for modular structures: it worked perfectly in so many projects I was part of! Clear scope of every folder allows to share ownership easier, the structure represents the teams that are handling it and I was absolutely certain that this setup is great a starter point of any project!

And of course I must be proactive and make sure that I don’t have to completely redo the architecture when the system needs to scale up really quickly! Of course I’m aware that you don’t start with Kubernetes right away (as the joke goes you gotta wait till you get 7 concurrent users), but I still fell in the trap of “monolith is bad”.

Now I didn’t deploy Hounty in microservices, but I tried to keep the code structure decoupled to be able to do it easier when the time comes. Because I’m an expert, okay?! I don’t build no monoliths!

Do you want to build a monolith?

Well, as per Conway’s law I absolutely should build a monolith. Just drop files in one folder, deploy it somewhere quick and get it out in the hands of real users to get data.

Not because I’m cutting corners or accumulating tech debt, but because at this stage of the project that is how technical excellence looks like.

I was trying to force modularity on a system held by a solo developer and it felt… lonely. Because my changes to the architecture demanded changes to the organisational structure and that’s not possible at the moment.

Tech debt?

I think the biggest misconception was my understanding of technical debt: I used to think that it’s misalignment between current system and industry standards or best practices, but now I believe that it’s misalignment between system and supporting organisation.

Ultimately, we want our software to do what it’s supposed to do at any given time and we want to make sure that developers working with this software can do it with the least amount of friction.

And there’s no gold standard: there are patterns that one can apply in a specific situation. For example, a Strangler Fig pattern - that allows to wrap a system to decouple it bit by bit when the time comes.

For Hounty I’ve built a system on Supabase with a Deno BFF layer. Most of the logic is in the database layer right now and it took me a while to accept that: I didn’t see that I’ve already went above and beyond by building a BFF layer that allows me to swap any part of underlying system without rewriting the app.

The system as it is right now meets my security and scalability standards. It’s not just good enough: it’s perfect for this stage.

It’s not done till it’s out

I was planning to release Hounty in beta, but users below 13 can’t participate in TestFlight or install unpublished Play Store apps without giving up all parenting controls, so I have to finish the app and polish user experience to be able to pass app review before I can release.

And I’ll tell you all about the “90% ready” fallacy in my future posts if you’d like