A shortlist in 72 hours, contributing inside two weeks, and a 30-day guarantee if the fit is wrong.
72-hour shortlist · 30-day replacement guarantee · Month-to-month
Solution architecture is genuinely valuable in a narrow set of circumstances and expensive decoration outside them. It is worth being blunt about which you are in before hiring.
You need one when a design spans systems and teams that do not otherwise coordinate — an order process crossing a CRM, an ERP and a warehouse system, each owned by different people with different release cycles. Somebody has to own the interfaces, decide what is synchronous and what is not, and specify what happens when one participant is unavailable. Nobody in a single team is positioned to make those calls.
You do not need one when there is one system and one team building it. That is a technical lead. Hiring an architect to sit above a single delivery team reliably produces documentation nobody reads and a decision layer that slows work down without improving it.
The test we use is simple. If the decisions in front of you are contained within one team, an architect is overhead. If they bind several teams to each other, or are expensive to reverse, that is the job.
The screening question behind all of these: would the teams building this recognise the design as workable?
Specifying failure behaviour, retry safety and reconciliation — not just which system calls which. Where designs actually break.
Whether the teams who have to implement it recognise the design as workable. We ask how they validate that before approval.
Writing down what was chosen, what was rejected and why, so the reasoning survives the people who were in the room.
How recently they have been close to code. Distance from delivery is the most reliable predictor of unbuildable architecture.
Willingness to advise that a technical lead would serve you better. We would rather place nobody than place overhead.
A live conversation in English, every time. The role is persuading teams who do not report to them and were not consulted first.
There are two failure modes here and they look nothing alike.
The first is architecture that cannot be built. A design is produced, presented, approved, and handed to delivery teams. It assumes an interface that does not exist, or a system can respond in a timeframe it cannot, or a team has capacity nobody checked. Teams discover this in week three and start improvising. What ships is a compromise nobody designed, and the document — still the official architecture — no longer describes the system, so the next project is planned against a picture that is wrong.
The second is the absence of architecture where it was needed. Three teams each build a sensible integration for their own use case. Each is defensible. Together they produce four sources of customer data with different update rules, no agreed identifier, and reconciliation that has to happen nightly because nobody owns the interface contract. Nothing failed. There was simply nobody whose job it was to see across all three.
The costly part of the second is that it is discovered late and cannot be fixed cheaply. By the time the reconciliation job is a permanent fixture, unwinding it means changing three systems owned by three teams with three roadmaps — which is exactly the coordination problem an architect existed to prevent.
Senior Developer / Tech Lead (5–8 years). Owns technical decisions inside one system and team. For most single-product work this is the right hire, and it is cheaper.
Solution Architect (8+ years). Owns design across systems and teams. Specifies interface contracts, failure behaviour and non-functional requirements, and stays involved through delivery rather than handing over a document.
Enterprise Architect (10+ years). Works at portfolio level — standards, technology strategy, which platforms the organisation invests in. Different job, further from delivery, and rarely what a team asking for architecture help actually needs.
Integration design across enterprise systems. The most common genuine need. Frequently spans SAP, Salesforce, Dynamics 365 and SharePoint, none of which agree about what a customer is.
Pre-build design. Establishing the shape of a large programme before teams are assigned and decisions get made by default.
Monolith decomposition. Deciding what becomes a service, what stays, and where the data boundaries fall. Easy to get wrong in a way that is very hard to reverse.
Vendor evaluation. Assessing whether a product will actually integrate as claimed, before the contract rather than after.
Alongside infrastructure design. Application architecture and cloud architecture are related and distinct. See cloud architects for the platform side.
Week one. They talk to the teams who will build it before drawing anything. Expect questions about what each system can actually do rather than what its documentation claims, what the release cycles are, and which integrations already exist and are quietly relied upon.
Weeks two to four. Decisions written down with the reasoning and the alternatives that were rejected, in a form somebody can revisit in two years and understand. Interface contracts specified including failure behaviour — what a caller does on timeout, whether a retry is safe, what reconciles the two sides. Expect a diagram, but expect it to be the smallest part of the output.
The warning sign is an architect who has not spoken to a developer by week two. Architecture produced from interviews with managers describes the system as management understands it. The constraints that break designs are known by the people maintaining the code, and they are rarely written down anywhere.
Hiring an architect for a single-team product. The most common mismatch, and it adds a review layer without adding judgement the team lacked. If one team owns the whole thing, promote or hire a technical lead instead.
Accepting an architect who does not stay for delivery. A design handed over at approval is a hypothesis. The valuable part is the fortnight in month three when the assumption turns out to be wrong and somebody adjusts the design rather than letting three teams improvise separately.
Screening on diagrams. Anybody can produce a clean architecture diagram, and the diagram is the artefact, not the work. Ask about a decision they made that turned out badly. Architects who have lived with their choices answer that easily; the ones who move on before consequences arrive usually cannot.
Not asking when they last wrote code. They do not need to be a strong developer, and they do need current contact with how software is built. Someone who has not been near an implementation in a decade will produce designs that are elegant, plausible, and quietly unbuildable.
Rates depend on seniority, systems breadth, and engagement length. Tell us the role and we will give you a firm number.
Tell us the role and we will send a shortlist within 72 hours.
Tell Us the RoleTell us the role. Three to five profiles within 72 hours.