Building Financial Systems from the Inside Out

A lot of financial software is built from the outside in: someone takes a list of requirements, picks a stack, writes the code, and hands it over. It works, and it fits what the desk needs today. It just tends to be static: each requirement becomes a feature, built for the need in front of it rather than where the desk is heading.

Building from the inside out means starting somewhere else. It starts with the people who use the system: what they're trying to do, why, and where they're heading next. The architecture comes from that, and the code comes last.

After years of building full systems alongside traders, portfolio managers and operations teams, we've seen what happens when that first step gets skipped, and what becomes possible when it doesn't.

The Gap

It's a pattern we've seen many times. A team of highly skilled engineers sits down with traders, portfolio managers and operations, the desk, and writes down the requirements as they describe them. Then come the usual questions: what else do you need, and how soon do you want it?

Often, without meaning to, the team steers. "Our current system doesn't handle that situation. It would be a big expansion." The conversation turns into a negotiation, and the focus can drift toward the simpler task rather than the right one.

It happens the other way too. Sometimes a trader explains exactly what to build, precise and well thought through, and the team builds it without fully understanding why. Later they come back asking for more. What they described was enough complexity for now, not the whole picture. But the system was architected for the clear-cut version, "this is what we need, and that's it," rather than for where they were heading.

Then there's what happens after the meeting. Even strong engineering teams tend to regroup, agree briefly on who's doing what, and get started, usually under pressure to deliver. Often there's little time set aside for architecting or for questioning the ask further.

Some engineers do message the traders as they build and realise something doesn't add up. Many don't, and work from assumptions instead, which may or may not be right. The measure of done becomes closing the ticket on the task board. So when the trader comes back with feedback, it can feel like an interruption rather than part of the work.

At the other end are deeply thorough engineers, often excellent at system design. They hear a requirement and go away to architect it in great detail, sometimes before fully understanding what the user is after.

For most internal finance systems, requests and products, the best way to get at that is to put something in front of the user early. Build something they can give feedback on, fast, and let their workflow shape what comes next. That usually works better than months of upfront design followed by a long build.

The exception is when the code itself is the product. In a high-frequency trading engine, how each line is written matters a great deal, and that level of care is the job. For most systems the desk relies on, though, early feedback usually matters more than polished code.

None of this comes down to skill or effort. In every one of these cases, the code was rarely the issue. The gap was in translation: hearing what the desk said, but not always what it meant.

What Inside Out Looks Like

It starts with a conversation, and it has to go both ways.

Listen, and ask them to show you. Traders know what they want. They have a vision. Ask them to show it to you, in Excel, on a whiteboard or on paper, whatever works for them.

Understand the why. While they're showing you, ask why. What's the benefit? Why don't the existing tools do the job?

Connect the dots. Where is this trader going with it? Is this all they want, or is there something more complex behind it? Ask, even if the answer is "Not yet, but eventually we'd want to..." That answer matters. It means you can architect with expansion or modification in mind across the parts of the system that will need it. When the next set of features arrives, whether it matches that original vision or it has drifted, you can still build it.

This is what lets us build modular, iterative systems: easy to modify and expand, and most importantly, something tangible in their hands fast. An MVP they can react to. Traders value developers who stay engaged.

Then architect. Architecture still matters, of course, and that's where our engineering skill comes in. Things start taking shape in your head while you're still talking to the trader, so you naturally begin asking feature questions that affect the architecture. That's important, and it's worth being open with them about it.

After the conversation, someone needs to sit down and think it through as an engineer, alone or as a team. An hour is often enough. That session will raise more questions. So go back to the trader: message them, call them, sketch mock-ups or UX flows, or draw diagrams if there's no visual component. They'll understand, and they'll enjoy the conversation. Then you're both clear on what you're building together, your questions are answered, and you can finish the architecture.

Sometimes it takes more than one round of questions. But spending a few hours on that, instead of jumping straight into code, saves you and your trader time and effort, and it builds trust.

Then build. This is the fun part. In the old days, you'd put on some music or a TV show in the background and just code away. Today you're more likely to prompt an AI and review its work, which is maybe a little less fun than digging through documentation or asking a colleague. Either way, writing the code is no longer where most of the effort goes. Knowing what to build, and building it so it can grow, is where experience makes the difference.

What That Looks Like in Practice

This is how we work on every engagement. We're usually the ones sitting with the traders and having these conversations. We've grown into this role over the years: teams put us in front of the desk, and we take ownership of that relationship from the first conversation onwards. It's the part of the job we enjoy most.

The conversation doesn't stop once the architecture is in place. While we build, we share screenshots and short videos as features take shape, check the data with the desk as we go, and set up test channels or accounts they can try before anything is released. Once a feature is live, we check in to see how it's working, whether it needs changes and whether anything is broken, and we turn those around quickly.

We build it together, so nothing arrives as a surprise. Our users tell us they feel heard, and they can trust that what reaches them has been reviewed, tested and guided by engineers. We use AI throughout, but what makes the difference is the part it can't do for the desk: understanding the why, connecting the dots, and architecting and engineering for where they're heading, as senior developers who have spent years building products and systems for fintech. That's the gap we fill, and it's one AI can't fill on its own.

The same approach scales to large greenfield work. We recently wrote a product blueprint for a client's new AI-first platform, roughly a six-month build across many microservices. It took about 20 hours and a few conversations with the client, and covered everything from prioritised requirements and key screens to the full architecture and milestones. Our questions got the client more engaged in the process, thinking through things they hadn't considered before and bringing research of their own. Now we share a clear vision.

With that in place, the build runs smoothly. We give the AI the milestones and task-specific guidance, and review what it writes.

The Experience Behind It

We've seen these patterns from our first years to our most recent projects, with every type of user: traders, portfolio managers, operations, and people outside finance entirely.

We've worked directly with users since the beginning of our careers, building full systems end to end: databases, backend services, APIs, background jobs, and the UI and UX on top. In the cases where our part was only a portion of the system, such as the backend or the frontend, we made a point of understanding the whole thing so we could ask the right questions.

Working that closely with users, you see their frustration or their joy when you release something or talk it through with them. So why not make sure they always feel supported? The desk drives the business, and we see our role as supporting it. That's always been how we like to work.

We're organised, and we think things through. That's what we bring to every project.

Why It Matters

When you work with us, you get people who listen first, ask the questions that shape the system, and think through the whole system before building. That thinking takes hours, not weeks, so you still get something tangible quickly, built so it can grow with you, and people who stay in the conversation the whole way.

The code matters, but it's rarely the hardest part. The real work is understanding the people it's for. We speak trader and engineer.