PERSPECTIVES
WRITTEN OCCASIONALLY.
We publish when we have something specific to say. Each piece carries an original artefact — a decision matrix, a reference architecture or a checklist — and at least one stated limitation.
- PIECES
- Six
- CADENCE
- Occasional, not scheduled
- REVIEWED
- Annually
02 / Articles
React Native or Flutter: a decision framework by product type
A framework for choosing a mobile stack against product characteristics rather than benchmark numbers.
Offline-first mobile architecture: patterns and failure modes
How to design a data layer that assumes the network is absent, and what breaks when you retrofit it.
Choosing a chain for a payments product: XRPL against EVM networks
Settlement speed, cost and finality compared against the requirements of a payments system.
Deploying computer vision on constrained hardware
Quantisation, pruning and architecture selection against real mid-range device profiles.
Smart contract audit: a pre-deployment checklist
What to verify before mainnet, sequenced so remediation still has time to happen.
Multi-tenant SaaS architecture: isolation models and their trade-offs
Three isolation models compared against customer size, regulatory exposure and operating cost.
03 / Editorial standard
THREE RULES.
One original artefact
Every piece carries something you can use — a matrix, an architecture, a checklist — not a summary of other people’s writing.
At least one stated limitation
Where the approach does not apply, said plainly. A recommendation without a boundary is marketing.
Reviewed annually
Dated honestly, revisited each year, and withdrawn when it stops being true.
Close
Engagements begin with a conversation about the constraint, not the specification.