Technical Solution Design
& the Commercial Business Case.
Whether you are answering a solicitation or issuing one, the document that decides the outcome is the solution design — and the business case that proves it is worth funding. We produce both, as one coherent answer.
We work either with bidders competing for enterprise and public-sector work, or for enterprises defining what they should be asking the market for in the first place. The discipline is the same; only the direction of travel changes.
A design an evaluator can score, an architect can challenge and an engineer can build from — with the commercial case that funds it attached to the same architecture.
Each asks a different question.
And each fails for a different reason. A response written as though all four are the same is the most common cause of good solutions scoring badly.
| Type | What is really being asked | What we produce |
|---|---|---|
| RFIRequest for Information | Does a credible answer to this problem exist, and roughly what does it cost? The buyer is shaping a future procurement. | Capability response, options analysis with trade-offs, indicative reference architecture, cost bands rather than prices, early risk view — and language the buyer can lift into the eventual RFP. |
| RFPRequest for Proposal | Show us your whole solution, prove you can deliver it, and price it. The most demanding of the four and the one most often answered generically. | Full technical envelope — target-state architecture, integration and interface design, non-functional and compliance matrices, data and migration approach, delivery and mobilisation plan, transition and support model — with the complete commercial envelope alongside it and win themes mapped to the published evaluation criteria. |
| RFQRequest for Quotation | The specification is fixed. Are you compliant, and what is your price? Won on precision and disqualified on omissions. | Compliance-first response, itemised bill of materials and services, transparent pricing construct, delivery schedule, and an explicit deviations register rather than silent non-compliance. |
| ProposalUnsolicited or negotiated | Nobody asked. You have to create the demand and justify the spend before anyone will consider the technology. | The business case leads: the problem quantified, the opportunity sized, then the solution design, investment case, phased roadmap and commercial construct — written for an executive committee rather than an evaluation panel. |
Anatomy of a response
Most responses treat the commercial envelope as a spreadsheet produced after the technical one, by different people. That is why prices collapse under interrogation. We build both from the same architecture, so every line is traceable to a design decision.
- Business requirement interpretation and traceability
- Target-state solution architecture
- Integration, interface and API design
- Non-functional requirements and compliance matrix
- Security, data residency and privacy position
- Data model, migration and cutover approach
- Delivery, mobilisation and resourcing plan
- Assumptions, dependencies and risk register
- Transition, support and service model
- Declared methodology, framework and standards conformance
- Cost model and itemised bill of services
- Total cost of ownership over the investment horizon
- ROI, payback and benefit realisation logic
- Pricing construct and commercial terms
- Sensitivity analysis and cost-risk provisions
- Optional and value-add scope, priced separately
- Local content and transformation credentials
- Payment milestones tied to delivery evidence
- Commercial assumptions and exclusions
- Certification and compliance evidence where required
Architecture governance · requirement traceability · evaluation-criteria mapping and win themes · a single narrative thread
Working with bidders and with buyers
A response that survives evaluation
You have a deadline, a scoring matrix and a solution that must be both credible and affordable. We supply the architecture depth and commercial modelling most bid teams do not have in-house — and for smaller ICT businesses, could never justify employing.
- Technical envelope authored end to end, or an independent architectural review of yours
- Win themes mapped to the published evaluation criteria, not asserted generically
- Commercial case that holds under clarification questions and price interrogation
- Consortium composition — ecosystem partners assembled behind one submission
- Compliance matrices, deviations register and a defensible assumptions log
A specification worth going to market with
The quality of what you receive is set by the quality of what you asked for. We help you define the requirement, model the investment, and write a solicitation the market can answer precisely.
- Requirement definition and target-state architecture before the market is approached
- Options analysis with honest trade-offs, including the do-nothing case
- Investment case and cost envelope to secure internal funding approval
- Evaluation criteria that actually discriminate between good and plausible responses
- Independent technical evaluation support once responses arrive
You do not have to employ it.
Architecture is the most expensive competency in this industry, and it is usually the reason a capable small business declines a tender it could have delivered.
Engage the competency as and when you need it, on retainer, for the bid in front of you — and stand it down once the response is submitted. For the cost of an occasional engagement, a small ICT company gets what only a large one could previously afford.
A response that is technically defensible under evaluation, commercially credible under scrutiny, and deliverable at the price it was bid — because the people who designed it are the people who will build it.
Declared, not assumed.
Every design we produce states the methodologies, frameworks and standards it was written under, and the ones the delivered solution will conform to. Evaluators score that explicitly. More importantly, a declared framework is what makes a design reviewable by someone who was not in the room.
The applicable set is selected per engagement — the client's own architecture standards and PMO governance always take precedence over ours — and it is written into the response rather than assumed.
| Domain | Applied in our solution designs |
|---|---|
| Enterprise & solution architecture | TOGAF ADM for the architecture process, ArchiMate for modelling, the C4 model for software structure — and the client’s own reference architecture and standards wherever one exists |
| Public sector, South Africa | GWEA (Government-Wide Enterprise Architecture), SITA procurement requirements, PFMA and MFMA obligations, National Treasury regulations, and local-content and B-BBEE evaluation criteria |
| Corporate & IT governance | King IV governance principles and COBIT 2019 for control objectives, decision rights and assurance |
| Delivery methodology | Agile and Scrum, scaled with SAFe where the programme requires it; PRINCE2 or PMBOK-aligned governance where the client’s PMO requires it; stage-gated and hybrid delivery for regulated programmes |
| Service management | ITIL 4 for service design, transition, operational readiness and the support model handed over at go-live |
| Security | ISO/IEC 27001 control alignment, the NIST Cybersecurity Framework, OWASP ASVS and Top 10 for application security, and CIS Benchmarks for platform hardening |
| Privacy & data protection | POPIA and GDPR, ISO/IEC 27701 for privacy information management, with explicit data-residency and cross-border transfer positions |
| AI governance | ISO/IEC 42001 AI management principles — human-in-the-loop control points, decision logging, explainability, bias testing and model evaluation gates |
| Cloud & infrastructure | AWS and Azure Well-Architected Frameworks, landing-zone and hybrid patterns, and FinOps practice for ongoing cost governance |
| Software quality | ISO/IEC 25010 quality characteristics, test-driven development, CI/CD quality gates and defined coverage thresholds |
| Integration & interoperability | OpenAPI 3.x contracts, event-driven integration patterns, ISO 20022 for financial messaging and HL7 FHIR where health data is in scope |
| Accessibility | WCAG 2.2 AA, verified in the build pipeline rather than asserted in the response |
Designing to a standard and holding a certificate against it are different claims, and evaluators know the difference. Our responses state precisely which frameworks the design conforms to, which certifications the delivered solution or a named partner actually holds, and the evidence behind each. We do not let the two blur together in a compliance matrix.
Where do you sit?
Whether you are answering the solicitation or writing it, the fastest route is to tell us which.
I have a bid to answer
An RFI, RFP, RFQ or proposal with a deadline on it. Send us the solicitation and we will tell you honestly whether it is winnable.
StartI cannot employ an architect
An SMME ICT provider that keeps declining work it could deliver. Draw on the competency as and when the bid arrives.
StartI am writing the RFP
Define the requirement, model the investment and write a solicitation the market can actually answer precisely.
StartI built something good
An AI-native product enterprises would buy if they knew it existed. The ecosystem is open, and it is judged on the product.
StartNot sure which?
Send us the solicitation
and the deadline.
We will tell you honestly whether it is winnable, and what it takes. If it is not, we will say so — that answer is worth more than a proposal.