00Services
Solution architecture turns a business problem into a system you can price, build, and defend.
Solution architecture is the design work that comes before a build: what the system must do, where its boundaries sit, which systems it talks to, and what it should cost. Aptixx does this work for leaders who know the problem — and need the solution defined before a budget is committed to the wrong build.
01When to buy design
Cost overruns are designed in before the first line of code.
Most failed software projects were lost at the definition stage: a scope nobody wrote down, an integration nobody tested, a requirement nobody owned. Five situations where the design work pays for itself:
- 01A software budget is about to be committed on a vendor’s estimate that nobody in-house can check.
- 02Three departments describe the same problem three different ways, and each version implies a different system.
- 03An off-the-shelf platform is on the table, and nobody can say which requirements it fails until after it is bought.
- 04The last build stalled mid-project, when the integrations turned out harder than the pitch.
- 05The person who understands the process best is not the person who can specify software.
02What the architecture covers
Risk gets named, priced, and assigned an owner on paper.
Four artifacts define the solution. Together they are precise enough to hand to any competent builder — an internal team, a contractor, or Aptixx.
System boundary & scope
What the system must do, what it deliberately will not do, and what is deferred to a later phase — written down where a vendor, an internal team, or Aptixx can be held to it.
→ A scope you can price and enforce
Data model & roles
The records the business runs on and who may act on each one, specified down to the field. On regulated work that means the governing rule quoted next to the requirement it creates.
→ A schema the argument happens on before the build
Integration map
Every system the workflow touches — ERP, CRM, accounting, file stores, hardware — with whether it exposes an API, a file drop, or nothing, and which connections are expensive.
→ Surprises surface on paper, not on an invoice
Build, buy, or automate
Where an off-the-shelf tool carries the process, where an automation closes the gap, and where a custom build is the only thing that can hold your rules. A custom system is recommended only where it earns its cost.
→ Custom software only where it pays
03The standard
Evidence of the discipline: specifications a regulator could read.
Architecture is judged by what it survives — an audit, a dispute, a change of builder.
On regulated engagements, Aptixx produces regulator-cited, DDL-level build specifications during discovery: the governing rule quoted next to the requirement it creates, taken down to the exact database field that satisfies it. The same discipline scopes bilingual, multi-entity case-management systems for regulated service businesses — entity boundaries, language surfaces, and review trails settled as design decisions rather than discovered as defects.
Two production systems show where that leads. Trazo OS, built under contract for Trazo Global Inc., runs nine operational roles with more than 50 distinct permissions enforced on every endpoint — an access model that was designed, not accreted. The marine survey platform carries its client’s hydrostatic tables, tolerances, and certificate rules as specified behavior, which is why its engine reproduces a previously issued, signed certificate to the cent.
04How it is bought
The design work runs as a fixed-fee discovery sprint.
Solution architecture is delivered through a paid discovery sprint: one to three weeks, a fee fixed in writing before it starts, and every artifact yours to keep.
The sprint ends in the four artifacts above plus a budget band for the build — with the assumptions behind it written down where you can challenge them. If Aptixx builds the system, the sprint fee is credited against the build. If someone else builds it, the specification is written to travel.
See what a discovery sprint delivers →
Deciding not to build is a legitimate outcome, and it costs sprint money instead of project money.
Next step
Bring the problem before the budget is committed.
Twenty minutes on the problem itself: whether it needs a custom system at all, what defining the solution would cover, and what that costs to find out.