The real cost isn't visibility
We used to think the real cost of not having a developer portal, or a strong developer experience, was invisibility, being missing from the market, and losing ground to competitors when it comes to being chosen and integrated with. But the equation turns out to be completely different.
In some cases, you're already in the market by law. Institutions like banks, or national payment solutions, exist regardless of anything else. And if you're a TPP (third-party provider) or a fintech app, you're required to connect with them, whether or not they have a developer portal.
So the real problem isn't visibility. The problem is time, the time these institutions waste on manual operations that could take minutes instead.
The story that sums it all up
Through our work and projects across different markets, we've run into the same situation, in different shapes, more than once.
A national or licensed payment institution, by virtue of its position, you're required to connect with it as a service provider. But the entire technical integration process is manual. There's no ready sandbox. No auto-onboarding. You send an email, wait for a reply, and after weeks (sometimes months) you get access to a test environment. Then, once you're done and ready to move to production, you start from zero again.
A second, entirely manual process. Paperwork, emails, follow-ups. Sometimes the email gets lost, or the reply takes weeks to come back. And through all of that time, you're not building value. You're waiting.
Three real manual costs
If we break down the pain, it comes down to three core points.
- Documentation. Who keeps it updated? How do you make sure it actually matches the API that's running in production? And how does it reach the other party, through an email with an outdated file attached?
- Onboarding. Every step needs a human replying to a human. There's no self-service path.
- Security. How are API keys delivered? By email? Is that secure enough, especially for sensitive or critical APIs?
Now there's an added challenge: AI
Large companies are preparing their documentation in a completely different way, ready to be read directly by AI, not just by humans. This is known through formats like llms.txt, built specifically for AI agents and AI-assisted coding tools.
According to a 2026 study, 85% of developers use AI tools while coding, and traditional HTML documentation wastes a large share of a tool's token budget just navigating and formatting, before it even reaches the actual API information. The llms.txt format cuts that token usage by more than 90%.
In other words, an institution that hasn't solved the basic documentation problem is actually behind twice over — once on the fundamentals, and once on this entirely new wave.
Note: Falling behind on documentation doesn't just cost you human developers anymore. It costs you AI agents too.
It's not just an external problem
What's surprising is that this pain isn't limited to external partners. We've seen the exact same problem inside large institutions — a bank and a telecom company — except this time, the problem is internal.
The middleware team inside these institutions has no internal developer portal for its own developers or internal channels. All the documentation was manual internally too. Same disease, different patient.
A recent study found that engineering teams without a central internal developer portal lose an average of four hours per engineer, per week, searching for internal APIs, services, and documentation — about 200 hours a year, per engineer. And onboarding a new engineer takes about three weeks when documentation is scattered across different tools.
What the right solution actually looks like
The solution here has two parts, and we don't like to merge them together.
The first part is an internal developer portal. It gives internal developers organized access to internal APIs, with a clear API catalogue. The most important point: the documentation isn't written manually, it's pulled directly from the services actually running in production. So when the API changes, the documentation updates itself.
The second part is an external, or partner, developer portal. This is a broader topic, with a full partner ecosystem, onboarding, and its own implementation, we'll cover it in a separate article soon.
Here, we just want to establish that this part exists, and that it's different from the internal part, each needs its own solution. It's about Developer Experience, not just a Developer Portal.
But let us be precise on one last point, because it matters: having a developer portal doesn't automatically mean you've solved the problem.
We've seen large institutions that technically have a portal, but it's really just a checklist item, a few HTML pages, a list of APIs, and that's it. No interactive documentation, no sandbox, no clear onboarding path.
The result: the institution spent time and effort on something that exists in name only, without delivering the real value it was supposed to. Because the question isn't "do we have a portal", it's "what kind of experience are we giving developers." That's the real difference between a Developer Portal as a feature, and Developer Experience as a strategy.
The bottom line
An institution that decides to invest in a real developer portal, internal and external — gains time, reduces security risk, and prepares itself for the coming AI wave.
An institution that keeps postponing that decision will keep paying the price quietly, week after week, email after email.
Sources
- API Docs for AI Agents: llms.txt Guide, buildwithfern.com
- Reducing Time-to-Hello-World for Enterprise Partners, buildwithfern.com
- Wasl — Digitinary's Open Banking / API platform
