Architecture Is the Decisions That Are Hard to Reverse
Most engineering decisions are cheap. Architecture is the small subset that aren't: the choice of cloud, the data model, the boundary between services, the build-vs-buy on a critical capability, the way you handle multi-tenancy, the call on whether to accept the operational cost of a queue. These decisions get made early, often by whoever is closest to the keyboard, and they're expensive to change later.
The job of architecture consulting is to make the load-bearing decisions deliberately, with the experience of having seen which ones cause pain at scale.
Where We Help
Greenfield system design
You're starting a new product, platform, or major component, and you want the architecture thought through before the team starts building. We design the system, document the components and their responsibilities, choose the technology stack, and write down the trade-offs behind every non-obvious decision. The output is something your engineers can build from and your team can reason about.
Architecture review of existing systems
You have a system that works but is causing trouble: slow to change, painful to operate, expensive to scale. We read the system and the code, document what is actually there (often different from what the team thinks is there), and produce a prioritised remediation plan with effort estimates.
Technology selection and build-vs-buy
The decisions that get made by whoever Googles fastest. Database choice, cloud provider, queue, search, identity, observability stack, payment processor, the SaaS that you're considering replacing with custom code (or vice versa). We bring outside experience to choices that are hard to reverse later.
Re-platforming and rewrite decisions
Few decisions in software are more expensive or more often regretted than a rewrite. We help you decide whether the rewrite is actually warranted, scope it honestly if it is, and design the migration path so the business does not have to stop while it happens. Often the more useful conclusion is that the rewrite is not warranted, and we'll tell you that.
Multi-tenant and SaaS architecture
The specific architectural questions that come up when you build software multiple customers will use: tenant isolation models, data residency, customisation versus configuration, billing, identity, the limits of pooled vs siloed deployments. These are easier to get right at the start than to fix later.
What you get. A written architecture document: diagrams, component descriptions, data model, trade-off rationale, decisions made and decisions deferred. Something your team can build from, argue against, and revise as the system evolves. Not a slide deck.
How We Engage
A typical greenfield architecture engagement runs two to four weeks of focused work; a review of an existing system is usually one to three weeks depending on scope. Standard rate structure.
For larger ongoing work (for example, sustained architectural involvement during a major build) this tends to evolve into a fractional CTO engagement instead, where the architectural responsibility is part of a broader leadership role.
Frequently Asked Questions
What does architecture consulting actually deliver?
A written architecture: a description of the system, components and their responsibilities, the data model, the boundaries between services, the operational characteristics, and the decisions made along with the trade-offs behind them. Done well, it answers the questions your engineers will otherwise have to argue about for months.
When should we engage an architect: before or during a build?
Both moments are useful. Before the build, the cost of getting the architecture wrong is paid in slow progress and rewrites. During a build that is in trouble, the cost is paid in incidents and engineering frustration. Earlier is cheaper, but architecture intervention partway through is one of the highest-leverage things a senior outsider can do.
Do you do greenfield architecture, or also review existing systems?
Both. Greenfield work is designing the system before code is written. Existing-system reviews look at architecture that already exists, identify what is working and what is not, and produce a remediation plan. The latter is often the more valuable engagement.
Can you help us with a re-platforming or major rewrite decision?
Yes. Re-platforming and rewrites are among the most expensive and most often regretted decisions in software. We help you decide whether the rewrite is actually warranted, scope it carefully if it is, and design the migration path so the business does not have to stop while it happens.