Hire Solution Architects: What It Costs and How to Vet Them

What a solution architect actually does, and where the hire goes wrong

A 400-person logistics company came to us replacing a twelve-year-old .NET Framework order system. They had already paid an architect for three months. The deliverable was a 40-slide deck: a Kafka backbone, event sourcing, six microservices, ArgoCD, a service mesh. It was internally coherent and completely detached from the building it was meant to run in. The architect had never opened the legacy database. Two months into the build, the team found a 3,000-line stored procedure driving the pick-pack workflow and a nightly SSIS job pushing a fixed-width file to a customer's SFTP that nobody had documented since 2019. The event-sourced design had no answer for either. That is roughly $180k of design that had to be thrown away.

Here is what the same brief looks like when the architect is good. First two weeks: read the stored procedure line by line, pull actual volumes from the production database instead of taking the CEO's number. Peak turns out to be about 6,000 orders on a Monday, not the "millions of events" in the brief. Write an architecture decision record that says, in writing, we are not buying a message broker for this, Postgres with a transactional outbox and two worker processes carries the load with room to spare and the team already knows how to operate it. Keep the SSIS job alive behind an API facade as a strangler seam so cutover is not a big bang. Ship a C4 context and container diagram, sequence diagrams for the three flows that actually earn money, a non-functional requirements table with p95 latency and recovery targets, and a phase one that goes live in seven weeks.

The job is not drawing. The job is deciding, in the presence of a legacy system, a fixed budget, a team with specific skills, and a vendor API that will absolutely rate-limit you at the worst moment. Hiring goes wrong because this role has the widest gap in software between what a resume claims and what shows up. Everyone senior eventually calls themselves an architect. Very few of them have ever had a design meet production and survive it.

Engagement models: in-house, freelancer, agency, staff augmentation

In-house hire. Works when you have three or more delivery teams, a platform you will run for years, and real arbitration to do between squads, vendors and a security function. Fails badly when you have one product and eight engineers. An architect with nothing to decide will invent governance, review boards and templates to justify the seat, and your engineers will start routing around them.

Freelancer. The right shape for a bounded decision: pick the stack, design the Salesforce and ERP (Enterprise Resource Planning) integration, plan the migration off the on-prem SQL Server. You buy a decision, not a person. The risk is that the reasoning walks out the door with them and six months later nobody can say why there are two queues. Contract for artifacts, not hours: ADRs with rejected options written down, plus a live handover session with the team that inherits it.

Agency. Right when you want the design and the build from one accountable party, so nobody can blame the diagram when the sprint slips. The honest trade-off: an agency architect has a house stack, and house stacks have gravity. Ask them directly which of their recent designs used a technology their own team had to learn from scratch. If the answer is none, price that in.

Staff augmentation. An architect embedded in your team, reporting into your delivery lead. Best fit when you have capable engineers but nobody with the standing to say no to a stakeholder. The trade-off is that it only works if someone internal carries the authority. Drop a contract architect into a company with no decision owner and you get very well-reasoned documents that nothing in the roadmap respects.

What it costs

These are the ranges we see and bill in Digital Heroes delivery. They move with region, domain and how much regulatory exposure the work carries.

• Onshore US and UK contract: roughly $120 to $200 per hour. The top of that band is for people who have carried a payments, healthcare or trading platform through an audit and can hold the room with a CFO.
• Nearshore Latin America and Eastern Europe: roughly $65 to $110 per hour.
• Offshore India and South Asia: roughly $35 to $75 per hour.
• Fractional retainer: most of our clients buy 10 to 20 hours a week rather than 40. Architecture is not a full-time activity on a single product.

If you are comparing against a full-time hire, compare the real number. Base salary is the smallest honest part of it. Employer payroll taxes, health cover, retirement match, equipment, software seats, desk and the internal time spent managing the person push total cost well above base, and 25 to 40 percent over base is the working assumption we use when clients model it with us. Add a recruiter fee if you use one; the clients we have watched run this search paid a fifth to a quarter of first-year base. Then add ramp: on a real legacy estate, an architect is not making decisions you should trust for the first 60 to 90 days, because they have not yet read the stored procedures. A $170k architect is a $220k to $240k first-year commitment before they have shipped a single ADR, and if the fit is wrong you find out at month five.

How to vet a solution architect

Do not run a coding kata. You are not hiring for LeetCode. Test the specific thing that fails in the field: designing under real constraints with incomplete information.

Technical signals that matter. Can they read a schema and reason about it, not just draw boxes around it. Do they write architecture decision records in a real format, Nygard style or equivalent, with the options they rejected and why. Do they know the C4 model well enough to separate context, container and component, instead of producing one mega-diagram that mixes domain, deployment topology and vendor logos. Can they turn "it has to be fast" into a p95 latency budget, an RPO and RTO, a concurrency number, a retention policy and a compliance boundary. Do they have opinions on multi-tenant isolation, row-level security versus schema-per-tenant versus database-per-tenant, and can they say which one they picked last and what it cost them. Do they know OIDC from SAML and can they explain service-to-service auth without hand-waving. Can they price their own design in the AWS or Azure calculator to within a sensible margin.

Make the questions specific to the estate you actually have. If you are on legacy .NET and SQL Server, ask what they do with a 3,000-line stored procedure that still runs the business: rewrite it, wrap it, or leave it and put a seam in front. If you are on Postgres, ask when a transactional outbox beats a broker, and what the outbox costs you in write amplification. If you are on AWS, ask them to choose between SQS, EventBridge and MSK for your actual throughput and defend the bill. If you are on Kubernetes, ask what they would put in a Helm chart versus what belongs in a platform they do not own. If your integration surface is Salesforce or an ERP, ask how they handle the vendor's rate limit and what happens to your design when a bulk job blows through it.

Questions to actually ask. "Tell me about a design you shipped that you would build differently now, and be specific about what was wrong." "Walk me through the last time you removed something from an architecture. Who pushed back and how did that go." "Our peak is 6,000 orders a day. Do we need a message broker. Defend either answer." "How do you cut over when the old system and the new one both have to be authoritative for two weeks." "What is the failure mode of the design you just drew when the third-party API is down for four hours." "Who writes the code in this design, and how do they know they built the right thing." The last one separates architects from consultants.

What a good take-home looks like for this role. Give them a redacted version of a real problem you have: three pages of context covering current systems, actual volumes, budget, team skills and compliance, plus one deliberately ambiguous requirement and one hostile constraint, for example a vendor API capped at 5 requests per second or a database that legally cannot leave your premises. Cap it at four to six hours and pay for it. The single strongest signal arrives before the deliverable: a good architect sends you questions first. The deliverable should contain a C4 context and container diagram, one short ADR per major decision including the options rejected, a rough monthly run cost, an NFR table, the top three risks with a plan to retire each, and a phase one that ships in under eight weeks. A weak one hands back a poster of every service in the cloud catalogue, no cost, no rejected options, and no first phase.

Red flags

• The design is the vendor reference architecture with your logo on it. If it maps one to one onto the Well-Architected diagram, they skipped your constraints. Ask instead: "which parts of this do you delete first if the budget drops 40 percent, and what breaks."
• Certifications instead of scars. AWS Solutions Architect Professional, TOGAF and Azure Solutions Architect Expert prove they can study. Ask instead: "what broke in the first 90 days after go-live on your last design, and what did the fix cost."
• They have not touched code in years and cannot review a PR. Ask instead: "when did you last read or write code in this stack, and what did you change." Then hand them a real pull request from your repo and give them 20 minutes. Architects who cannot read your codebase will design for a codebase that does not exist.
• Microservices and Kafka regardless of the numbers. Ask instead: "give me the specific throughput and team-size numbers at which a modular monolith stops working here." If they cannot name a threshold, they are pattern-matching, not designing.
• No opinion on data. They spend an hour on compute and five minutes on the database. Ask instead: "what is the primary key on the order table today, what happens to it during migration, and how do you reconcile a dual-write window."

When to hire this role, and how Digital Heroes staffs it

If you have one product, one team under eight engineers, and a stack you already operate, you do not need a solution architect. You need a senior or staff engineer who owns design and writes code, and you will get better outcomes for less money. Hire a solution architect when you are integrating three or more systems of record, moving off a legacy platform that still runs the business, entering a regulated boundary such as PCI, HIPAA or SOC 2, or arbitrating between teams and vendors who each have a different answer. If the real problem is "deploys are scary and the database falls over on Mondays", that is a platform engineer or a database specialist. If the real problem is "we do not know what to build", that is product, and no diagram will fix it.

How we staff it: a fractional architect at 10 to 20 hours a week for the first 6 to 10 weeks, sitting with the engineers who will build it, not in a separate governance track. Their output is ADRs, a C4 set, an NFR table, a costed run rate and a phased plan we can be held to, with phase one live inside two months. After that they taper to a few hours a week for design reviews and ADR sign-off as reality argues with the plan. Everything they produce, diagrams, decisions, code and infrastructure definitions, is yours from day one under work-for-hire, in your repositories and your cloud accounts, so the design does not leave when the architect does.