Turning a stalled architecture into working software 

A financial-infrastructure company had a strategic platform idea that had been stuck for years, because its engineers were rightly focused on day-to-day delivery. We stepped in as embedded senior architects and took it from concept to a working prototype, without pulling the core team away from their roadmap. 

The challenge 

The company had a clear vision for a new generation of programmable financial infrastructure. It also had a problem familiar to any senior engineering leader: the idea had been sitting for two to three years, and the existing engineering organization was consumed by product and commercial delivery. The co-founder needed a way to move the architecture forward to a point where it could actually be tested, without disrupting the team. 

The technical bar was high. The platform needed to support a design target of roughly 20,000 transactions per second, while staying flexible enough to run a wide range of financial rules and use cases. The initial assumption was that an existing large-scale financial platform could provide the foundation. 

What we did 

We started by evaluating that existing platform objectively rather than force-fitting it. We built experiments around the expected workload and found it was optimized for a different model: relatively complex, longer-running transactions, not the very small, fast, composable rule evaluations the client needed. We recommended building a bespoke architecture instead. 

From there, we became embedded senior architecture support, working with both the co-founder and the CTO to turn a conceptual model into a buildable system. A few of the decisions that mattered: 

• Choosing the right runtime. Although the team knew Go well, we recommended Elixir on the BEAM virtual machine. BEAM provides the actor-based, message-passing concurrency the design depends on natively; rebuilding that model in Go would have added unnecessary platform risk. 

  
  

• Isolation and scale. The architecture separates work into isolated units that own their own state and communicate by message. Within a boundary, operations are ordered consistently; across boundaries, communication is asynchronous. This gives strong data separation, clear security boundaries, and the ability to scale parts of the platform independently. 

  
  

• Fast integration on the hot path. The first prototype called external services directly from the core, which coupled it too tightly. Moving those calls behind REST improved separation but added too much latency. We landed on a sidecar model for low-millisecond paths and WebAssembly components written in Rust for the most performance-sensitive path. Local testing showed microsecond-scale latency for the WebAssembly calls and low-millisecond latency for the sidecar path. 

  
  

• A generic core. Internally, the system works with generic objects and identifiers rather than named financial fields. A configurable mapping layer, built from configuration, APIs and caching, translates between that generic model and the schemas external systems expect. 

  
  

• Prototyping over specification. Instead of a long specification-first process, we worked in fast loops: concept, whiteboard, prototype, documentation, review, iterate. For example, the original plan was a visual, BPMN-style tool for defining behaviour. Prototyping showed it wasn't expressive enough, so the design evolved toward text-based configuration in YAML with injectable executable functions. 

The outcome 

Before we were involved, the architecture was an important but stalled initiative. Today the client has a working prototype, demonstrations across several financial use cases, a platform used in client demos, defined interfaces, architectural documentation for the CTO and engineering team, and a cloud deployment underway for full-scale performance testing. 

The real value wasn't just a better architecture. It was a protected path for a strategic idea to move from stalled concept to working software, while the core engineering team stayed focused on the product customers use today. 

Facing a similar challenge? Get in touch. We'd be glad to talk it through.