Solutions architect tasks explained from pre sales to delivery

A Solution Architect (SA) is the person who owns “does this solution actually work for this customer and this business?” in the messy middle between product promises and production reality. If you’re picturing someone who only draws boxes and arrows, you’re missing the punchline: an SA is accountable for outcomes, not diagrams. The diagrams just happen to be one of our favorite ways to argue politely.

The role often splits into pre-sales (shape a viable solution, win the deal) and delivery (make it real, reduce risk during implementation). Some organizations combine these; others have separate pre-sales SAs and delivery architects. Maturity matters a lot: in a startup you might write Terraform at 2 a.m.; in a large enterprise you might spend that same 2 a.m. negotiating who owns the firewall rule.

The core loop is consistent across environments: discover constraints and goals, design a solution that fits, and de-risk the plan early with prototypes, estimates, and decision records.

That workflow diagram is the “happy path.” In practice, you’ll loop back whenever you hit a gate like “security says no,” “budget changed,” or “latency target is unrealistic.”

Day-to-day cadence#

Your day is usually a triage exercise: you time-block deep work, then protect it like it’s production data. Expect a rhythm of customer calls (requirements, demos, technical deep dives), internal syncs (sales, product, engineering, security), and focused solo time for designs and docs.

Two habits separate calm SAs from frazzled ones: keep a lightweight risk log (what could break, probability, impact, owner, next action) and track key decisions with short decision records (what we decided, why, alternatives, date). This prevents “we never agreed to that” from becoming a recurring weekly meeting.

When you’re building SA muscles around cloud choices and operational constraints, structured practice on cloud architecture helps and is a solid way to pressure-test your instincts around cost, reliability, and tradeoffs without relying on vendor-specific magic.

With the daily rhythm in mind, it helps to zoom out and see how the same SA muscles get used differently in pre-sales versus delivery.

Pre-sales responsibilities#

Pre-sales is where you earn the right to build. Your job is to qualify whether the opportunity is real, winnable, and deliverable. I usually start by pinning down success criteria in plain language: what outcome the customer will measure, what “done” means, and what would cause them to say “no.” Then we surface constraints early: budget ceilings, compliance boundaries, current-stack realities, and delivery timelines.

Next comes architecture sketching, but it is intentionally lightweight. You’re comparing options, not producing a blueprint. A solid pre-sales whiteboard usually includes two to three viable architectures, the trade-offs that matter to this customer, and the assumptions you are making.

Estimation is the tricky bit. You’re not just sizing effort, you’re bounding uncertainty. I like to separate “must-have scope” from “nice-to-have,” call out integration unknowns, and offer phased delivery that maps value to time. When risk is high, de-risk on purpose: run a small proof of concept to test one assumption, not to build the final product.

Tip: Pre-sales is where vague language sneaks in. If you hear “real-time,” “secure,” or “simple,” ask for a number, a standard, or an example.

Delivery responsibilities#

Delivery is where we convert intent into execution. The SA role shifts from “options and persuasion” to “decisions and follow-through.” Your first responsibility is translating the agreed design into an executable plan: milestones, dependencies, interfaces, and a backlog that engineering can actually pick up. If pre-sales produced a narrative, delivery produces a map.

Day-to-day, you guide implementation without stealing the keyboard. You unblock teams by clarifying requirements, answering edge-case questions, and keeping a running list of decisions. You also protect the system’s quality attributes: security, reliability, performance, and cost. These are rarely solved once. They are maintained through reviews, guardrails, and steady attention.

Change control is the hidden job. Scope will move, timelines will slip, and new stakeholders will appear. You help everyone make explicit trade-offs, ideally with written decisions. When two “reasonable” paths conflict, your value is being the person who can say, “Here’s the risk, here’s the cost, here’s what we gain,” and get alignment.

Important: Delivery SAs fail quietly when they skip governance. A lightweight decision log and a regular risk review prevent “surprise architecture” in week eight.

Stakeholder interaction map#

Stakeholders are not just names on an org chart. They’re moving forces with different incentives. On the customer side, execs want outcomes and risk reduction, product wants scope and speed, and ops wants stability. Internally, sales wants a clear story, engineering wants clarity and autonomy, and legal wants fewer surprises.

The SA sits in the middle, which sounds glamorous until you realize you’re basically an interpreter. Your best tool is predictable touchpoints: when escalations happen, who is consulted, and which decisions require sign-off. Conflict zones are normal: sales versus engineering on timelines, product versus ops on reliability, security versus everyone on “just ship it.” The alignment tactic is to move arguments from opinions to artifacts: acceptance criteria, SLOs, decision records, and phased plans.

Deliverables checklist#

Deliverables are how you scale yourself. They let new people join midstream and still understand why the system looks the way it does. The key is to keep artifacts small, updated, and owned.

A few that consistently pay for themselves: a high-level design for shared context, a low-level design for implementation clarity, and architecture decision records so “why” doesn’t evaporate after the meeting ends. On the ops side, runbooks plus SLIs and SLOs turn reliability from a vibe into something measurable. The cadence matters: a beautiful document that never gets updated is just expensive fiction.

Note: Every artifact should answer “who uses this” and “what decision does it unlock.” If it unlocks nothing, it is probably overhead.

Metrics, KPIs, tools#

SAs get measured indirectly, which can be frustrating. In pre-sales, you’ll feel it through win rate, cycle time, and whether what was promised matches what was delivered. Adoption metrics and customer satisfaction (NPS, renewal signals, referenceability) often reflect how realistic your early framing was.

In delivery, watch defect leakage and rework. If teams keep rebuilding the same component or revisiting fundamental choices, your decision process is too implicit. Architecture-facing metrics are more concrete: SLO attainment, incident frequency, latency percentiles, and cost trends. The win is not “zero incidents.” It’s fewer surprises and faster recovery.

Tooling is intentionally boring. Diagrams, docs, a backlog, and a decision log. Use whatever your org standardizes, but be consistent. The most valuable “tool” is a shared language for risk and trade-offs. When everyone can say, “This increases blast radius,” you’re already ahead.

Pitfalls and 30-60-90 plan#

Common pitfalls are surprisingly human. Overdesigning is a classic: you build a cathedral when the customer needed a cabin. The twin is vague scope: “integrate with X” without defining the data, the workflow, or the failure modes. Two anti-patterns I see often are the hero SA (everything routes through you) and the no-ADR culture (decisions happen, but no one can prove they happened).

For a 30-60-90 plan, start with listening. In the first 30 days, learn the domain, read past postmortems, map stakeholders, and identify where decisions currently get lost. By 60 days, standardize a minimal set of artifacts, establish a risk log, and introduce a predictable review cadence. By 90 days, tie architecture to measurable outcomes: SLOs, cost targets, delivery milestones, and a clear escalation path.

Tip: If you’re unsure what to do next, improve one feedback loop: incidents, customer objections, or delivery delays. Fixing the loop fixes the system.

Final words#

A Solution Architect’s core value is clarity and risk reduction, delivered through good decisions and good communication. In pre-sales, you focus on fit, constraints, a credible story, and estimates that acknowledge uncertainty. In delivery, you focus on execution, governance, non-functional requirements, and explicit trade-offs. Keep your artifacts lightweight but alive, manage stakeholders with predictable touchpoints, and measure outcomes with KPIs that reflect both delivery health and system quality.