Most architecture problems I get called in on are not really architecture problems. They are business decisions that got made — or not made — a year earlier, and the codebase is now just where the bill arrives. The team did not pick the wrong technology out of ignorance; usually it picked a reasonable technology against a reasonable set of constraints that nobody wrote down, and then the constraints changed, and nobody owned the consequences.
That is why I treat architecture as a business conversation that happens to have a technical component, rather than the other way around. The interesting question is rarely “which is the better framework”; it is “what does this choice commit us to, at what cost, and how long does that commitment last”.
When it makes sense
- The system has outgrown its founding assumptions. It was built small, for a small team, on a small budget — and it worked. Now the scale, the team count, or the compliance requirements have changed, and every change is a negotiation with the codebase.
- A migration is on the table and the options are fuzzy. Split into microservices, consolidate into a monolith, move to the cloud, stay self-hosted: every option is being argued from tribal knowledge and vendor marketing. You need someone to run the numbers and the trade-offs out in the open. I have recently led exactly this kind of decision — taking Breek.gr from a split frontend/backend architecture towards a monolithic Elixir application — and the honest answer was not the fashionable one.
- You are building something long-lived and want it to stay a liability, not a trap. If the system is going to be in production for a decade, the architecture decision is a decade-long commitment, and it deserves the same rigor as any other long-term business decision.
- The operational side is the product. For some businesses — trading operations, property management, industrial equipment — the surrounding system (data, integrations, the ERP/CRM around it) is as strategic as the core product. Emporoman, the tailor-made ERP/CRM for ISATEK, is an example of the kind of system where “architecture” and “business operations” are one and the same.
What I bring to the table
I have designed and run production systems on both the big-company and the bootstrap end of the spectrum: requirements and system work at Hilti, product systems and microservices at Tectra, full-stack SaaS at Rent21, and a steady stream of open-source software built and maintained by me. I also run my own hybrid cloud — self-hosted object storage, containers, mesh networking, geocoding, and local LLM serving — which means my architectural advice is not theoretical: I live with the operational consequences of self-hosted, frugal, open-source stacks, including their failure modes.
In practice, an engagement covers some or all of the following:
- Architecture assessment. A written diagnosis of what the system is, what it is committing you to, where the commitment has become more expensive than its value, and what the realistic options are — with the trade-offs and their costs made explicit, not implied.
- Migration and evolution planning. Sequencing that keeps the business running while the shape of the system changes: what moves first, what can stay, what must not break, and the observable evidence that each step worked.
- Technology selection done properly. Evaluated against your actual constraints — team skills, budget, data residency, uptime requirements, exit options — instead of against the current year’s trend. I am as happy to tell you a boring established technology is the right one as to tell you the shiny one is.
- Self-hosted and hybrid-cloud strategy. For organizations where data control, cost, or independence from a single vendor matters: what to run on your own infrastructure, what to buy, and the realistic operating cost of each, based on running them rather than on pricing pages.
- Local AI integration. If you want LLM features without shipping your data to a third-party API — or without an API bill that scales with your success — I design and deploy that stack: model selection and quantization for your hardware, serving, and the integration into your product. I have put months into this and run it in production; see how we work and the Elixir Chatbot Alchemy book for the depth behind it.
What an engagement looks like
Architecture work is usually a short, sharp engagement: two to eight weeks, ending with a document the organization can execute on — the assessment, the chosen path, the sequence, and the explicit list of decisions that remain with the team. I am deliberately not the kind of consultant who stays on as a permanent architecture review board; the goal is for the organization to own the system’s shape, with the trade-offs understood, long after I am gone.
Start with a conversation with the system that has started negotiating with you.
