A software architecture consultant who stays for the build
A software architecture consultant helps you decide how your system should be structured – data model, service boundaries, integration points, where state lives – so it can carry the next few years of growth. Most stop at the recommendation. I stay and help your team implement it.
The test of an architecture isn’t the diagram. It’s whether the team can ship on it six months later without asking me.
Why architecture advice so often doesn’t land
The classic architecture assessment ends with a target-state diagram and a list of recommendations. Then the consultant leaves, the team gets pulled back onto features, and the diagram becomes a slide nobody updates. A year later you’re halfway between two designs, which is worse than either.
The fix isn’t a better diagram. It’s sequencing the change into steps small enough to ship alongside product work, and having someone senior in the codebase while the first few land. That’s the part I care about.
What an architecture review covers
A software architecture review starts from the business, not the stack. I want to know what has to be true in 18 months – customers, volume, team size, compliance – and then check the system against it.
- Data model and ownership. Which tables or services own which facts, how tenants are separated, and what’s painful to migrate. See multi-tenant SaaS architecture.
- Boundaries. Where the module and service lines are, whether they match how the team is organized, and where coupling is slowing you down.
- Integration and async work. Queues, webhooks, background jobs, retries and what happens when a third party is down.
- Scaling limits. The first three things that will break under ten times the load, and what it costs to move each one.
- Operability. Deploys, rollbacks, observability, and how hard it is for an on-call engineer to find out what went wrong.
- Cost. Infrastructure spend relative to revenue, and the design choices driving it.
Opinions I’ll probably bring
Good architecture consulting should come with a point of view. You can disagree with mine, but you’ll know where I stand.
- Start with a monolith. For most SaaS teams under 30 engineers, a modular monolith beats microservices on speed, cost and debuggability. I’ve written up the trade-offs in microservices vs monolith.
- PostgreSQL until proven otherwise. It will do more than you think, and every additional datastore is something else to back up, monitor and understand at 3am.
- Make money paths boring. Payments, billing and anything with a ledger get idempotency, an audit trail and reconciliation before they get clever.
- Incremental over big-bang. Replace parts behind stable interfaces – the strangler fig pattern – rather than freezing features for a rewrite.
- Write decisions down. Short architecture decision records, so the next person knows why, not just what.
How an engagement runs
- Intro call. You describe the system and the pressure on it. I tell you honestly if a review will help.
- Two-week sprint. I read the code, talk to the team, map the system as it really is, and ship at least one change that proves the direction – often a seam that later refactoring hangs off.
- Written review. Current state, target state, and a sequenced plan where each step is shippable on its own and delivers value even if you stop there.
- Implementation, if you want it. A fixed number of days a week, working in the pull requests with your engineers until the hard parts are done and the team owns the rest.
Where this experience comes from
I was an early engineer at Yola, where I built the PHP framework, payment platform and core APIs while the product scaled from 10K to 11M users. I architected the backend and payment integrations for BLU Loyalty, serving 9 million users in the UAE, and led architecture at Indiemaker. Before that I co-founded and sold a software studio that delivered 200+ projects across fintech, gaming, e-commerce and big data.
I still build my own products, including Craaft and a programming language, Ecko. That keeps my architecture opinions tested against real code rather than conference talks.
When you don’t need an architecture consultant
If you have a strong staff engineer or CTO who simply lacks time, you may be better off buying them time – a contractor to take feature work off their plate – than bringing in an outside voice. And if the real problem is delivery rather than design, a code audit or an embedded lead will get you further than an architecture review.
Questions
What does a software architecture consultant do?
A software architecture consultant reviews how a system is structured – data, boundaries, integrations, scaling and operations – against where the business needs to go, then recommends and sequences changes. The good ones also help implement those changes so the plan survives contact with the codebase.
What is a software architecture review?
A software architecture review is a structured assessment of an existing system’s design. It identifies risks, scaling limits and coupling problems, and produces a target design plus a plan to get there. It’s most useful before a period of growth, a major feature, or a migration.
Do you work as a freelance software architect on a single project?
Yes, as long as the scope includes some implementation. I don’t do diagram-only engagements because they rarely change anything. A review plus hands-on work with the team on the first steps is the shape I look for.
Will you recommend microservices?
Rarely, and only for a specific reason such as genuinely independent scaling or a separate team that needs to deploy on its own schedule. For most growth-stage SaaS, clear module boundaries inside one deployable get you the benefits at a fraction of the cost.
Is your architecture holding the team back?
Tell me what’s breaking or slowing down. In a two-week sprint I’ll map what you have, ship the first change, and give you a plan you can actually execute.
GMT+2 · Full EU overlap · US East mornings