Why We Give Away the Solution Architecture

At Sodio, we publish the solution architecture before a client signs anything. Here is why that is not a risk, and why it usually makes the engagement better.

The Assumption Behind Keeping Architecture Secret

Most agencies treat the solution design as proprietary. The reasoning goes: if you show the client how it works, they will build it themselves or hand it to a cheaper team. That reasoning is defensible when your value is in knowing something the client does not. It falls apart when your actual value is in executing it correctly.

We have been building custom software, AI pipelines, and blockchain systems since 2016. The consistent pattern is that clients who understand the architecture make faster decisions, write better requirements, and catch problems before they become expensive. Clients who are kept in the dark ask for changes late, often because the system does not behave the way they imagined it would.

Giving away the architecture is not generosity. It is risk management.

What "Giving Away" Actually Means

To be precise about what we share: before a contract is signed, we produce a document that covers the data flow, the key technology choices with justification, the integration points, the estimated infrastructure cost at scale, and the failure modes we have already identified.

This is not a slide deck with boxes and arrows. It includes specific technology choices — for example, whether we are recommending PostgreSQL 16 with pgvector or a dedicated vector store like Qdrant, and why. It includes the latency budget for each service boundary. It names the third-party APIs we depend on and flags the ones with SLA gaps.

What we do not produce at this stage is the code, the detailed data model, or the deployment runbooks. Those require an engagement. The architecture document is the map. The execution is the journey.

Why Specificity Matters Here

A vague architecture is useless to both parties. If we write "use a message queue for async processing," that tells the client nothing and commits us to nothing. If we write "use RabbitMQ 3.13 with a dead-letter exchange per queue, sized for 50,000 messages/day at peak, with a 72-hour retention policy," the client can evaluate whether that matches their compliance requirements. They can also see whether we understand their actual load.

Specificity is where trust is built or lost. Vagueness is where it erodes.

Is There Any Real Risk of Clients Walking Away With It?

Yes. It happens. In eight years, we have had a handful of cases where a client took a detailed architecture document and had it built by a lower-cost team, or handed it to an internal team that was already half-staffed but lacked direction.

Our read on those cases: the client was never going to engage us for execution anyway. The architecture document accelerated a decision that would have been made eventually. The alternative, spending four more weeks in sales conversations, would not have changed the outcome.

The more common outcome is that the document reveals problems the client did not know they had. A financial services company might discover their planned integration with a core banking API does not support the webhook frequency they need. A healthtech product might realise their PHI handling plan would fail a HIPAA technical safeguard review. When we surface that early, we become the team that saved them from a six-month rebuild, not the vendor pitching for budget.

That changes the commercial dynamic entirely.

How Does This Affect What We Build?

There is a discipline that comes with publishing your architecture before the contract is signed. You cannot recommend a technology you do not know how to deploy in production. You cannot propose a microservices split that you cannot justify against the team size and operational complexity. Every choice is visible, so every choice has to be defensible.

This has shaped our internal standards in concrete ways.

We do not recommend Kubernetes for a product with a team of two unless there is a clear operational plan for it. We do not propose a blockchain component unless we can articulate what property of the chain, immutability, decentralised consensus, or programmable settlement, actually solves a problem that a database cannot. We document the assumptions behind our infrastructure cost estimates, including the AWS or GCP pricing tier we used and the date we ran the calculation, because cloud pricing changes and clients should know when our numbers were last validated.

The Feedback Loop

One practical benefit: when clients read the architecture and push back, they often have information we do not. A CTO might flag that their existing data warehouse is on Snowflake, not BigQuery, which changes the ELT design entirely. A compliance officer might note that their data residency requirements rule out a particular CDN. That feedback before the build starts is worth considerably more than the same feedback six weeks into development.

When We Would Not Do This

This approach does not make sense for every engagement type.

Scenario	Our Approach
Short, well-scoped fixed deliverable (e.g. a data migration script)	Standard SOW, no pre-engagement architecture doc
Client is actively shopping across 5+ vendors simultaneously	We produce a lighter technical summary, not the full document
The architecture requires deep domain research we have not yet done	We scope a paid discovery sprint first
Client has an existing team that would consume the doc without us	We have the conversation, but adjust depth accordingly

The full architecture document is most valuable when the engagement is complex, the client has genuine technical capacity to evaluate it, and the decision timeline is long enough to make the upfront investment worthwhile.

Conclusion

If you are evaluating whether to engage Sodio or build something in-house, the architecture document is the right starting point for that conversation. It will show you what we think the system needs to be, which technologies we would choose and why, and where the genuine risks sit.

If you read it and decide to build internally, that is a reasonable outcome. If you read it and want to work with us, you will be starting that engagement with a shared understanding of the system we are building together.

Reach out and ask for a technical discovery call. We will produce the architecture document as part of that process, at no charge, with no obligation.

---

FAQ

Why do you share the architecture before a contract is signed? Because clients who understand what they are building make better decisions throughout the engagement. Misaligned expectations on architecture are the most common cause of expensive late-stage changes. Sharing the design upfront reduces that risk. It also filters out engagements where the fit was never right.

Does this mean anyone can take your architecture and build it elsewhere? Yes, and it happens occasionally. Our assessment is that those clients would not have proceeded with us regardless. The document accelerates their decision. The clients who do engage us after reading it start with a shared technical baseline, which makes the build faster and reduces back-and-forth.

What is actually in the architecture document? Specific technology choices with justification, data flow diagrams, integration points, estimated infrastructure costs tied to a specific pricing tier and date, identified failure modes, and the assumptions underpinning the design. It is not a slide deck. It is a working technical reference.

Do you charge for the architecture document? For straightforward engagements, no. For projects that require significant domain research before we can produce a credible design, we scope a paid discovery sprint. That sprint deliverable includes the architecture document, and the cost is applied against the main engagement if the client proceeds.

Is this the right approach for every type of project? No. For short, well-scoped deliverables, a standard statement of work is more appropriate. For clients who are simultaneously evaluating five or more vendors, we produce a lighter technical summary. The full document is most valuable when the engagement is complex and the client has the technical capacity to evaluate what we have written.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.