A SaaS company’s business model depends entirely on the IT solution it builds and operates. If the solution is well-made, it supports the business and enables growth. If it’s made poorly, the business starts to struggle.
That struggle shows up in familiar ways:
- outages, overloads, and peak‑time failures that erode customer trust
- runaway infrastructure bills that eat margin
- slow evolution that delays getting new functionality to market
This isn’t bad luck. It’s a structural issue that won’t fix itself.
What causes the problem?
The root cause is a stream of suboptimal, often simply bad, decisions made through the lifecycle of the IT solution.
Under business pressure or through lack of experience, teams pick the quickest path. It buys a short‑term win and hides a long‑term cost. People act tactically; no one holds the strategic line.
In the moment, choices look reasonable: unblock a deal, hit a date, calm an incident. Each one quietly adds long‑term risk that surfaces later. The consequences arrive as outages, rising run costs, and slower change — long after the original decision is forgotten.
From the outside, the fix seems obvious: “Just start making optimal decisions”.
In reality, it isn’t that simple.
Why is making optimal decisions hard?
In a nutshell, every meaningful decision within the lifecycle of a SaaS product is a trade‑off across four forces:
Business
What must be achieved to win the deal, protect margin, satisfy contractual promises, and keep revenue flowing.Domain
What must be respected by the product — processes, rules, compliance obligations, regulatory constraints, and industry expectations.Software
What can be built, tested, and maintained by the current teams and tech stack.Infrastructure
What can support the solution and host the software at scale — with the required capacity, resilience, security, performance, and predictable run cost.
These four forces naturally form two sides of a single scale:
Demand = Business + Domain
Demand is what the business wants and what must be respected.Capability = Software + Infrastructure
Capability is what the engineers can actually build and run.
Every decision within a SaaS product’s lifecycle must keep Demand and Capability in balance. That’s inherently hard — and in most SaaS companies, no one is explicitly accountable for that balance.
Why does no one own the balance?
Even though every decision must balance Demand and Capability, inside most SaaS companies there is no shared understanding of the four forces that define that balance — Business, Domain, Software, and Infrastructure. Because these forces aren’t explicitly named or understood, the need to balance them is invisible. As a result, nobody is assigned to own it.
Instead, each group defends its own priority:
- Leadership pushes new ideas and commercial commitments.
- Sales optimizes for contract wins.
- Product management optimizes for functionality and deadlines.
- Engineering optimizes for shipping code.
- Operations optimizes for stability and keeping production up.
Individually, each of these priorities is rational. Together, they pull the solution apart.
This is the structural gap.
The job of holding Business, Domain, Software, and Infrastructure in balance must belong to a dedicated role.
That role is the Solutions Architect.
What does a Solutions Architect actually do?
A real Solutions Architect (SA) is the business safeguard against self‑inflicted damage.
The SA’s responsibility is to translate business intent into something that the company can actually build, run, and afford — and then defend that shape against erosion.
In practical terms, an effective SA does the following:
- Confirms that what is being promised to a customer can in fact be delivered without destroying future roadmap or operational stability.
- States clearly when a shortcut creates a future liability (technical, contractual, compliance, or cost).
- Describes the viable path: “Yes, this is possible — here is how it must be done so it won’t explode six months from now”.
- Forces explicit trade‑offs and documented decisions instead of silent debt.
The SA keeps Demand and Capability in balance.
The SA provides margin protection, reputational protection, and delivery‑risk control.
How does the SA do this in practice?
To keep a SaaS product running, a solution architect must continually translate business intent into real, tangible value that integrates with what already exists and reliably operates in production—without unexpected costs, disruptions, or deviations from the roadmap.
The SA does this through an ongoing process that looks like this:
- Capture Business intent: understand revenue impact, contractual promises, deadlines, constraints, and success criteria.
- Anchor it in the Domain: map real workflows, compliance, obligations, and rules that cannot be broken.
- Check it against Software capabilities: confirm that it can be built with the current stack, safely, on time, and make visible the debt or risk created.
- Validate it against Infrastructure realtiy: ensure that it can run at scale, securely, cost‑effectively, and with the uptime and cost profile the company is willing to own.
- Negotiate and document the solution shape: define how the solution must look so it is truly buildable and operable, with explicit trade‑offs instead of silent debt.
- Stay through implementation: ensure what gets delivered still matches that agreed shape and has not been quietly degraded into something unstable, unmaintainable, or unprofitable.
This process cannot be reliably split across multiple roles. When it is fragmented, every group protects its own priority, and nobody owns the balance.
Only when a single role owns this process end to end does the balance hold and the product remain viable.
That single accountable role is the Solutions Architect.
Who can play this role?
A real Solutions Architect is rare.
This is not a theoretical strategist.
This is a person who has already lived the consequences of bad decisions across multiple environments and can recognize them before they repeat.
A strong SA typically has:
Business
Direct exposure to commercial pressure. Ideally has acted as a co‑founder, carried responsibility for a product or engagement P&L, or directly supported revenue‑critical deals. Understands money, contract pressure, and margin, not just technology.Domain
Several years inside the actual business domain (energy, finance, logistics, healthcare, etc.). Understands compliance traps and which “minor requirements” are in fact legally or operationally non‑negotiable.Software
Over a decade or even two of building, debugging, and operating production systems in the same languages and frameworks that the IT solution uses. Not “familiar with”, but battle-tested. Has carried on-call responsibility for that stack.Infrastructure
A decade of running workloads on the actual platform in use (specific cloud environment, network model, security posture). Understands scaling limits, cost levers, and real failure modes under load.Motivation
The SA must care that the solution actually fits the business and survives in production — and must be rewarded like someone protecting revenue, margin, and reputation.
This is not a role that can be filled by “a smart engineer with potential in six months”.
This profile is rare.
How can a company get a Solutions Architect?
The realistic way is to bring in a senior Solutions Architect from the market as a dedicated contractor for 12–36 months, depending on the IT solution.
The company must bring in someone who has already seen these failure patterns in multiple environments, already paid the price for getting them wrong, and is motivated to protect the business.
Note that SAs, by nature, don’t stay long at a single company. The judgment this role requires comes from switching products and environments — seeing different business models, domains, stacks, and failure modes. That breadth is hard to accumulate inside one product, so senior SAs tend to rotate to build and maintain the experience the role demands.
Why isn’t there an alternative?
When companies understand what the Solutions Architect actually does, they assume that they can easily cover the capability with a workaround.
What happens in practice is always some variation of the same assumption which is failure by nature:
1. Give it to the CTO
Assumption: the Chief Technology Officer is “the technical one,” so can also do the SA job.
The CTO role is crucial, but it’s an executive function: organization design, budget, hiring, vendor strategy, certifications, board work, and customer engagement. The expertise required for CTO is fundamentally different from that of an SA.
Even if a CTO personally meets the SA bar, they almost never have the time or focus to do deep SA work week in, week out.
Using a CTO as a substitute for an SA usually means neither job is done properly.
2. Cover with multiple people
Assumption: “Senior people together can cover it”.
Companies put Engineers, Operations, Product Management, and Compliance in one room, aim for consensus, and expect the group to collectively “own” decisions.
On paper, this seems to cover Business, Domain, Software, and Infrastructure. In reality, it fails because no single person is accountable for the integrated balance. Each participant protects their own priority, consensus dilutes responsibility, and there is still no owner of the balance in real time.
Shared responsibility becomes no one’s responsibility.
3. Level up an internal employee
Assumption: mentor a strong internal engineer or delivery lead into an SA over time.
This rarely succeeds. Correct judgment in this role comes from years of exposure to different pressures and failures:
- multiple customers,
- multiple business models,
- multiple domains with different regulatory traps,
- multiple technology stacks and scaling problems,
- multiple production outages and cost crises.
A single SaaS company usually cannot generate that breadth fast enough. It isn’t about intelligence; it’s accumulated scar tissue under different conditions.
4. Borrow from a vendor
Assumption: use an architect provided by an implementation partner or service provider.
A vendor architect’s primary loyalty is to their employer’s commercial safety and delivery success — not to SaaS company.
Even if the SA genuinely wants to help, they will always be forced to propose solutions that work for their employer first.
Conclusion
Any SaaS company that operates a live product needs a Solutions Architect.
Without an SA, no one is accountable for keeping Business and Domain expectations aligned with what Software and Infrastructure can actually deliver and run. That’s when costs spike, promises break, and reputation is damaged.
With an SA, that balance is actively protected. The product stays deliverable, operable, and economically viable.
A senior SA is not overhead. It is a required function for any serious SaaS business.
Top comments (0)