The trapped workflow
Almost every multi-asset and wealth firm runs critical processes on workbooks, notebooks, and undocumented scripts. Fifteen-tab models, nested macros, Python notebooks held together by a single analyst’s working memory. The CIO’s monthly risk numbers come out of them. The COO’s audit team has flagged them. The analyst is interviewing elsewhere.
This is not a failure of sophistication. The workbook persists because it is the only tool that matches the speed at which investment decisions get made. The view changes after a meeting with the strategist. The factor decomposition gets revised after a client briefing. The constraint set evolves in response to a regulatory consultation. By the time a project manager has the second draft of the requirements document, the requirement has moved.
The cost of accepting fragility is paid later, in audit findings, in onboarding time for new analysts, and in the risk concentration around a single person who knows where the bodies are buried.
Why the alternatives have not solved this
The three established options each fail in a recognisable way.
Tier-one consultancies deliver institutional-grade output but at six-figure cost and six-month timelines. The economics only work for transformation programmes, not for the dozens of smaller workflow tools each firm actually needs. The project team is itself the cost: project manager, business analyst, coder, tester, each adding queue time as work moves between them.
Internal IT has the domain context but a twelve-month backlog and competing regulatory priorities. The desk-level tool sits behind core systems work for years.
Low-code and no-code platforms get to a prototype quickly but stall at around seventy per cent of production-quality. The last thirty per cent, around scale, security, error handling, integration, audit trails, requires conventional engineering and is where most low-code projects quietly become maintenance liabilities.
The trade-off has been real. Move at desk speed and accept fragility. Move at institutional speed and accept that by the time the platform ships, the question has changed.
What has actually changed
Two things, simultaneously.
AI-assisted development has collapsed the time cost of writing production-quality software. What used to take a developer a week now takes a day, with comparable test coverage and documentation, when the person at the keyboard knows what good looks like.
Agentic AI has changed what gets preserved from a build. The architectural decisions, the prompts and patterns, the repository structure, all of it can be captured as a first-class deliverable. The next developer, or the next AI agent, can pick the system up without the original builder in the room.
Neither of these matter in isolation. Together, they change the economics of bespoke front-office software.
The Domain-Native Builder
A traditional project team needs five roles: project manager, business analyst, coder, tester, and (later) maintainer. Each handoff between them was always where time and fidelity disappeared. The business analyst’s understanding of the user is not quite what the developer reads from the spec, which is not quite what the tester validates against. Requirements documentation iterated by necessity, each revision trying to close that gap.
AI-native development collapses the technical roles. The agent codes and tests under direction. The remaining question is who directs it.
Generic developers, even with AI assistance, still need a business analyst between them and the user. The translation layer survives because the domain context is missing.
The Domain-Native Builder removes that layer too. The person at the keyboard has lived inside the workflow. Twenty-five years as a CFA charterholder on multi-asset desks, in portfolio construction, risk and attribution. They are the business analyst, the coder, the tester, and the user-advocate, simultaneously. The agent is the development team. The user is one conversation away.
This is not a faster version of the old model. It is a different model.
What domain-native means in practice
Three things distinguish a domain-native build from a generic AI-assisted one.
Specification by conversation, not document. The first meeting is a working session, not a requirements gathering. The builder already knows what a risk attribution table looks like, what a factor exposure constraint is, how an HHI penalty behaves in an optimisation. The user describes the workflow; the prototype appears in days, not weeks.
Engineering judgement embedded in the build. When an optimisation should be convex, it is. When a number should be desmoothed before being regressed, it is. The decisions are made silently in the code by someone who has built these systems before. There is no review meeting to argue the maths.
Institutional-grade output as the default. Test coverage, observability, documentation, error handling, all built in. Not because the methodology demands it, but because the person knows what failure modes a buy-side desk actually encounters.
Built to be inherited
Every system we build is delivered with its full design context. Source code, documentation, architectural decisions, repository structure, and the agent instructions that produced institutional-grade output. The client’s own team can extend the system using their own AI tools.
This inverts a default assumption in enterprise software. The traditional model is that the vendor retains the knowledge and the client rents access to it. The domain-native model lets the client take the knowledge with them.
Support becomes a choice, not a dependency.
Who this is for
Domain-Native Builders are not the right model for every problem. Core platform replacements are still better served by traditional integrators or internal teams.
The model fits where the trade-off has been most painful: front-office workflows that matter to the desk but never make it up the IT priority queue. Portfolio optimisation tools. Risk dashboards. Scenario engines. Reporting platforms. Pitch and proposal systems. Tools that need to be built well, built quickly, and owned by the team that uses them.
If that is the kind of problem you are sitting on, we should talk.