Business process outsourcing renewals this year come with a new slide. The provider is no longer just proposing people and a service level; they are proposing a platform, usually low-code, on which your processes will be rebuilt during transition. It is presented as a modernisation story. It is really a question about ownership, and the answer determines what you are holding in five years when the contract ends.
For twenty years you rented the people and the provider owned the process. Low-code lets you own the process and rent the people — which is a better deal only if you are prepared to be the one who maintains it
That is the whole trade. Everything below is detail about how to take it deliberately rather than by accident.
What actually changed
In the traditional model, the process definition lived in the provider's environment: their workflow tooling, their standard operating procedures, their training material, their team's accumulated habit. When you moved provider, you rebuilt all of it, which is why transition costs made switching mostly theoretical. Low-code platforms make the process definition a portable artefact. The forms, the routing, the approval matrix and the validation rules exist as configuration in a system that can be licensed by either party. That is the genuinely significant shift — not that applications get built faster, which is the part the demonstrations emphasise.
Three commercial shapes
Provider builds on the provider's platform. Fastest, cheapest in year one, and the lock-in is total — arguably greater than the old model, because now the dependency is documented in configuration you cannot export. Provider builds on your platform. Slower to start, you hold the licence and the artefacts, the provider charges more because their reusable assets do not apply. This is the shape most mid-market organisations should want and rarely ask for. You build, the provider staffs. Maximum control, requires internal capability that most back offices do not currently have, and only makes sense where the process is a genuine differentiator. Choose by expected process stability, not by cost per hour. A process that will be materially different in two years belongs on their platform; one that will still be recognisable in ten belongs on yours.
| Arrangement | Control and exit question |
|---|---|
| Provider builds on its platform | What configuration and definitions can the client export and reuse? |
| Provider builds on the client's platform | Does the client hold the licence and maintain usable artefacts? |
| Client builds, provider staffs | Can the client sustain design, maintenance and process ownership? |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
The maintenance liability nobody prices
Low-code makes building cheap, which means requests multiply. Eighteen months after a successful start, a typical organisation has somewhere between forty and eighty small applications, no list of which ones matter, and three that touch payroll which nobody has looked at since the person who built them changed roles. The cost is not the licence. It is that every one of those applications is a dependency with no owner, no test, and no retirement date. Start the register on day one: what it does, who owns it, what it touches, when it is next reviewed, and under what condition it gets switched off. A retirement policy sounds pessimistic at the start of a programme and is the only thing that keeps the estate honest by year three.
Where it genuinely wins
Processes that are mostly forms, routing and approvals, and that change every few quarters. Short-lived processes with a defined end — a two-year regulatory programme, a post-acquisition parallel run. And the enormous middle ground between what the ERP does and what somebody currently maintains in a spreadsheet, which in most organisations is where the real operational risk lives.
Where it fails
High-volume transaction processing, where per-transaction platform economics turn against you at exactly the point the process becomes important. Complex integration logic, which ends up as unreadable configuration rather than code. Anything requiring a real software development lifecycle for regulatory reasons. And anything where performance matters, because tuning options are limited by design. There is also the citizen developer claim, which deserves a plain response. In every successful deployment worth studying, the good applications were built by two or three people who had become, in practice, developers — they thought about data models, error states and versioning. The platform lowered the barrier; it did not remove the discipline.
Exit is the clause that decides everything
Three questions, asked before signature rather than at renewal. Can the process definitions be exported in a form that means something outside the platform? Does the logic depend on proprietary functions that have no equivalent anywhere else? And whose name is on the licence — because a client-owned artefact on a provider-held licence is not client-owned in any way that matters when the relationship ends badly.
Practical Guidance for Low-Code Back Office Strategy
- Decide platform ownership before scoping, not during transition.
- Hold the licence yourself wherever the process will outlive the contract.
- Start an application register on day one, with named owners.
- Set a retirement policy and enforce it at each review.
- Keep high-volume transaction processing off the platform.
- Export process definitions into your own source control regularly.
- Price local connectors separately and ask who maintains them.
- Test the exit path once, for real, during the first year.
The Regional Angle
The first thing that decides feasibility here is connectors, and it is consistently underestimated. Platform vendors advertise libraries of hundreds of pre-built integrations, and the list covers the systems a European or North American buyer expects — major enterprise suites, the large cloud services, common finance tools. It does not cover the interfaces that regional back-office processes actually depend on: the Saudi e-invoicing integration, customs declaration systems, wage protection file formats, local bank statement and payment formats that differ by institution, and the various government portals that each department deals with. Every one of those becomes a custom connector, which is where the cost and the fragility concentrate. The question to put in writing during evaluation is not whether a connector can be built, but who maintains it when the authority changes its schema — which happens on the regulator's timetable, not yours, and typically with weeks of notice. Price that maintenance explicitly, name the responsible party, and treat an unanswered version of this question as a reason to narrow the scope. The second is licensing across a group structure, which catches organisations that are otherwise well prepared. Low-code platforms are priced per user or per application, billed annually in dollars, and the contracting entity matters more than it does for most software. A group with eleven legal entities across three countries needs to know whether one licence covers users employed by different companies, whether an intercompany recharge for the shared platform is defensible under transfer pricing documentation, and whether the invoice supports input tax recovery in each jurisdiction where the cost lands. None of these are exotic questions, and all of them are considerably easier to settle before signature than to unpick in a tax review two years later. Involve whoever owns your intercompany agreements in the procurement, not just information technology and the sponsoring function. The third is key-person risk, which low-code amplifies rather than reduces. The person who builds the useful applications in a regional back office is frequently an accountant or an operations supervisor with an aptitude for it, working outside their formal job description, with nothing in source control and no documentation. When that person moves — and in a market where people change employer and country regularly, they will — the applications remain, working, until the first time one of them needs a change. Require every application to be owned by a function rather than a person, export definitions to a repository the organisation controls on a schedule, and make a short handover note a condition of the application going live. That is twenty minutes of discipline per application and it is the difference between an estate you inherited and an estate you own.
The objection worth taking seriously
The strongest objection is that this is shadow information technology with a procurement contract attached. Give operational teams a tool that builds applications without engineering involvement and within two years the organisation has an ungoverned estate of business-critical software written by people who have never heard of a test environment. Add the platform vendor's pricing power once you are embedded, and the whole thing looks like a slow-motion mistake dressed up as agility. Both halves of that are real, and anyone who has cleaned up a sprawling low-code estate will recognise the description. The response is to be honest about what the alternative actually is. It is not a well-governed custom-built system delivered by a capable internal team, because that team does not exist and the budget for it was refused. The realistic alternative is the spreadsheet that already runs the process today — with no access control, no audit trail, no version history, a macro nobody understands and a single owner who emails the file around. Measured against that, a low-code application with a register entry, an owner, logged changes and an approval trail is a substantial improvement in control rather than a degradation. The governance that matters is not restricting who can build; it is maintaining the register, enforcing retirement, and keeping exports of everything important in a repository you control. Organisations that do those three things get the benefit. Organisations that either ban the tools or ignore them end up in the same place, eighteen months apart.
Common Questions
Should the provider or the client hold the platform licence?
The client, in almost every case where the process will outlive the contract. The cost difference is small relative to what portability is worth at renewal.
How many applications is too many?
More than you can list from memory is the practical threshold. The number matters far less than whether every one of them has a named owner and a review date.
Does this reduce headcount?
Rarely by itself. It reduces the cost of changing a process, which is a different and often more valuable thing, particularly where regulation keeps moving.
What should we expect over the next twelve months?
Expect providers to keep leading with platform capability in renewals, and expect ownership of the artefacts to become the negotiated point rather than the rate card. Expect low-code vendors to add assistant features that generate applications from a description, which will accelerate the sprawl problem considerably before anyone solves the governance one. Expect at least one prominent failure in the market caused by an unowned application touching a payment or a filing. And expect the buyers who insisted on holding their own licence this year to have a materially easier renewal conversation next.
Low-Code Back Office Strategy — we decide who owns the platform before transition starts, price the connectors that actually matter here, and leave you holding artefacts you can take with you.