The old bottleneck is gone. Notice what it exposed.
For a long time, the hard part of banking software was building it at all. Cores are unforgiving, integrations are brittle, and a new workflow was a quarter of engineering before anyone could see it work. That constraint is lifting, fast. At Black Flag we have been shipping production software with AI agents for three years, so this is not theoretical for us. GitHub logged close to a billion commits in 2025. Listings for "forward-deployed engineers" rose roughly 800% in the first nine months of the year. The cost of turning an idea into working software has fallen through the floor.
If you run a platform, that sounds like good news. It is not, at least not automatically. Cheap software does not solve your problem. It moves it. When anyone can generate a rough version of almost anything in a week, feasibility stops being the thing that separates the winners. Something else does.
Automating what you already do is the easy half
Every platform team I talk to reaches for AI the same way first: to automate what they already do. Support tickets, onboarding, documentation, internal reporting, the reconciliation nobody wanted to staff. This is real work and worth doing. But be honest about what it is. It is defense. It makes your existing operation cheaper and a little faster. It protects the base. It does not grow the platform.
Growth is the other half, and it is harder. Growth means net-new products, workflows, and use cases sitting on top of your platform that partners will actually pay for. This is where most platforms stall, for two reasons that have nothing to do with whether AI is good enough.
The trap: you can't build your way out with your own hands
The first reason is structural. If you are a platform, your partners are your distribution. The moment you start building the vertical apps your partners build, you compete with the ecosystem that sells you. Platforms that forget this cannibalize the exact relationships that make them valuable. So the instinct to "just build it ourselves" is usually the wrong one, even when you technically could.
The second reason is capacity. Your best engineers are heads-down building and hardening the platform itself, as they should be. Demand for new applications on top of it is real and growing, but nobody has the hands. Your partners know what they want built. You know what your platform can do. And the work of connecting those two things sits in a gap that neither side has the people to close.
What actually changed is the economics, in both directions
Two costs flipped at the same time, and this is the part worth sitting with.
The cost for a partner to adopt something new dropped, because a credible, working prototype now takes days instead of a quarter. And the cost for you to prove a new product to that partner dropped in exactly the same way. Switching costs, on both sides of the table, are lower than they have ever been.
So the bottleneck moves. It moves from generation to qualification. The question is no longer "can this be built?" Assume it can. The questions that decide who wins are harder: what deserves to get built, which ideas are worth trusting with real financial data and real customers, and who can put a working version in front of a partner fast enough to turn a conversation into a signed deal.
The scarce layer is a person, not a model
This is the case for forward-deployed engineers, and it is not a new idea. Palantir built the model more than a decade ago, for customers who could not tell you what they needed until they saw it running inside their own messy environment. The role went quiet for a while. AI brought it back and made it the whole game. OpenAI, Anthropic, Ramp, and Cursor are all hiring for it now, because deploying AI into a real business runs into exactly the problem Palantir faced: the value is discovered in the field, not at headquarters.
For a banking or fintech platform, the forward-deployed builder is the missing layer. Not more features. Not better docs. A person who can sit between what your platform already does and what a specific partner actually needs, and ship a working, trustworthy version of it before the interest cools. Someone accountable end to end, where the same person who scopes it on Monday is the one who answers when it touches production.
How to decide what to build
Speed on its own is a liability in this industry. In banking, trust is the product, and a fast way to ship the wrong thing is just a fast way to lose the account. The discipline that makes forward-deployed building safe is the same discipline that makes it valuable.
Separate the rules from the judgment. Automate the mechanical steps, and keep a human in the loop wherever being wrong is expensive, which in finance is most places money moves. Start where the pain is both expensive and repetitive, and make every build reusable, so the first connector seeds the second instead of becoming throwaway work. Make it explainable, because a platform that ships a black box into a regulated relationship has spent trust it cannot easily earn back.
The platforms that win the next few years will not be the ones with the longest feature list. They will be the ones that can look at a partner's need and, within days, put something real, working, and trustworthy in front of them. That is a hiring decision and an operating decision. It is a layer, and right now most platforms don't have it.
Software is cheap. The people who can turn your platform into products your partners will actually buy are not. If you run a banking or fintech platform and you are sitting on more demand than your team has hands to build, that gap is your opportunity, not your problem. Spend two days with us and we will help you find the first thing worth building. We call it a Foundation Sprint.
