Every venture and client engagement draws from the same set of reference architectures. Nothing here is theoretical — each pattern names the systems it currently runs, and what it costs to operate.
Because the architecture is not the moat — the judgement about which one fits your constraints is. Publishing the patterns shortens the first three conversations.
If one of these already describes your problem, say so and we can skip straight to the trade-offs.
8
Published patterns
3
Ventures running them
6
Layers covered
0
Untested in production
The patterns
Eight references, in production.
Filter by the layer you are working at. Each pattern lists where it runs today and the trade-off it makes.
hub
Platform3 ventures
Venture platform core
The shared foundation a new venture inherits on day one — multi-region AWS accounts provisioned from templates, a delivery pipeline, observability, and a security baseline. A venture team writes product code in week one instead of infrastructure.
Use it when
checkStanding up a new product with no existing estate
checkSeveral products need the same operational floor
checkA small team has to ship without a platform group
The trade-off
Opinionated by design. A venture that genuinely needs a different data or identity model pays to opt out, and occasionally that cost is real.
Baseline account and tooling overhead, before any product workload.
smart_toy
Applied AIProduction
Shared agent tool registry
One capability registry called by both the interface and the model. Each tool is defined once with its schema and permissions, so the action a user triggers is the identical implementation the agent invokes — and every agent call lands in the audit timeline.
Use it when
checkAn agent needs to act, not just summarise
checkAgent and UI capabilities must not drift apart
checkAgent actions need to be auditable after the fact
The trade-off
Every capability now carries schema and permission overhead, which slows down adding a one-off feature that only humans will ever use.
Per-invocation model cost dominates; the registry itself is negligible.
swap_horiz
MigrationRepeatable
Zero-downtime cutover
Traffic shadowing, then dual writes with nightly reconciliation, then progressive read shifting, then a short write cutover with reverse replication left armed for a full business cycle. The cutover hour is the least interesting part of the plan.
Use it when
checkA maintenance window is commercially unacceptable
checkThe source system's behaviour is not fully documented
checkRollback must be provable, not asserted
The trade-off
Most of the budget goes on rehearsal rather than the move, and you pay for duplicate infrastructure through the hold period.
Duplicate running cost for the rehearsal and hold window, typically 4–8 weeks.
account_tree
IntegrationProduction
Event-driven integration mesh
An asynchronous event backbone replacing point-to-point integrations between services and SaaS systems. Producers publish, consumers subscribe, and an upstream failure stops being an outage for everything downstream of it.
Use it when
checkMore than a handful of systems need to stay in sync
checkPoint-to-point integrations have become the bottleneck
checkFailures in one system must not cascade
The trade-off
Debugging becomes distributed. Without tracing and a dead-letter discipline in place from the start, this pattern makes incidents harder, not easier.
Billed per event and per state transition; predictable and usually small.
wifi_off
ClientProduction
Offline-first with reconciliation
The device holds the working set, writes locally, and reconciles on reconnect with deterministic conflict resolution. Built for venues, market stalls, and branches where connectivity fails exactly when the transaction matters.
Use it when
checkUsers work where connectivity is unreliable
checkA failed write means a lost sale or a queue at the door
checkTwo devices may act on the same record concurrently
The trade-off
Conflict resolution rules are business decisions, not technical ones, and getting them agreed takes longer than building the sync.
Sync traffic only; the local tier costs nothing to run.
safety_divider
PlatformProduction
Multi-tenant isolation
Row, schema, or account-level tenant separation chosen against the compliance posture your buyers will demand, with metering and entitlements enforced at the data layer rather than in application code.
Use it when
checkBuilding a product to sell rather than operate internally
checkTenants have differing regulatory requirements
checkUsage has to be accurate enough to bill from
The trade-off
The isolation model is the hardest thing to change later. Choosing account-level early costs more to operate; choosing row-level can block an enterprise deal.
Rises with isolation strength — per-tenant accounts cost meaningfully more.
lock
SecurityProduction
Residency-first data architecture
Region-pinned storage and processing treated as an architectural constraint rather than a configuration flag, with least-privilege access, encryption by default, and immutable audit logging designed in from the first schema.
Use it when
checkData cannot legally leave a jurisdiction
checkAn auditor will eventually ask where records live
checkHandling beneficiary, health, or financial records
The trade-off
Multi-region features get harder and some managed services come off the table, which can mean building what you would rather have bought.
Region duplication where residency requires it; otherwise standard.
call_split
MigrationRepeatable
Strangler fig decomposition
A routing and event seam introduced in front of the monolith, then one bounded context extracted at a time behind a flag. The monolith shrinks continuously and is never switched off in a single move.
Use it when
checkA rewrite would take longer than the business will wait
checkThe monolith's behaviour is only partly understood
checkEach step needs to be independently reversible
The trade-off
You run two systems for months and pay the integration tax throughout. Teams that lose discipline here end up with a permanent hybrid.
Duplicate running cost across the extraction period.
How to read these
A pattern is a starting point, not an answer.
Each of these has been wrong for at least one project. The value is in knowing which constraint pushes you off the default — and that is what discovery is for.
At least once. The trade-off note on each one is the part worth reading twice.
savings
Run cost is part of the design
We model the operating bill before the build, not after the first invoice.
handshake
Handover is assumed
Each pattern ships with runbooks, because your team ends up operating it.
history
These change
Patterns are revised when production teaches us something. Dates are on the walkthrough.
Walk one through with us
Bring the constraint, we will bring the diagram.
An architect will walk any of these through against your estate — where it holds, where it breaks, and what it costs at your volumes. No charge for the conversation.
