At a glance
The client
A platform operator building a new multi-tenant transactional product. The company had a clear market thesis and nothing else: no product definition, no requirements, no architecture, and no engineering organization.
The challenge
The hard part was never the individual features. It was that the entire product had to be defined, architected, and built in parallel — inside a regulatory environment that shaped the architecture from day one, for an operator with no existing engineering function to build on.
Underneath that sat four constraints that had to be solved structurally rather than patched later.
No specification to build from
There was a market thesis, not a product. Nothing existed that a team could estimate against, sequence, or start building.
Strict visibility boundaries between tiers
Every account level had to see its own downline and nothing above or beside it — scoped to that account's subtree at query time, not filtered on the way out to the interface.
Accurate position without asking for it
Users needed their financial position correct at any moment without triggering a refresh. That is a push architecture and a settlement model, not a reporting feature bolted on at the end.
Settlement that resolves without either party
Manual reconciliation was the single largest source of dispute in the market. Settlement needed to execute automatically against an agreed outcome, provably, with neither side able to influence it.
What we did
-
Built the capability model before writing code
The product was decomposed into nine top-level domains, then mapped down through features and sub-features to individual functions. That tree became the single reference for scope, sequencing, estimation, and progress.
-
Ran structured requirements elicitation against it
Each requirement was captured with its goal, priority, and separate completion tracking across API, UX, UI, and test — so partial progress stayed visible per layer.
-
Sequenced three delivery phases and fixed their scope
An MVP for the core transactional flow, a second phase adding management depth and reporting, and a third adding live capability and native mobile — each settled before build, not negotiated during it.
-
Made the hierarchy a data model, not a permission check
Tier visibility was pushed into the data access layer, so an account's boundary was enforced when the query resolved. New surfaces inherited it automatically.
-
Integrated live third-party data feeds
External providers were connected through a dedicated integration layer, isolating the platform from provider-side changes and keeping feed latency out of the transactional path.
-
Moved settlement onto automated contracts
A contract generator produced settlement contracts programmatically, with independent audit of the contract code before release. Outcomes resolved against agreed conditions without either counterparty in the loop.
-
Built four client surfaces against one API
Backend, web, desktop, and native mobile were developed in parallel against a single internal API, so behavior stayed consistent across surfaces.
The results
The platform was delivered code-complete across all planned scope. Six account tiers resolve correctly, with each level seeing only its own subtree. Four client surfaces run against a single internal API. Live third-party data flows through a dedicated integration layer, and settlement executes automatically against agreed conditions through audited contracts.
The capability model built at the outset held for the duration of the programme. Scope, sequencing, estimation, and progress tracking all resolved back to the same artifact — unusual on greenfield work of this size, and the main reason the build stayed estimable throughout.
