For years, many of the agencies joining us asked the same question early on: white label. Above all, they did not want clients to see which tool was building the app. The fear was always the same: if clients discovered the platform, they would leave and use it themselves.
I had seen that fear before. Twenty years earlier, web agencies didn’t dare admit they built their sites on WordPress. Then something flipped: some of those same agencies started advertising themselves as WordPress experts, leaning on the tool’s reputation to reassure their clients. The tool you used to hide became proof of competence.
The same trajectory is repeating with mobile apps. And it says more about the “no-code vs agency” debate than most comparisons do.
The duel assumes you’re fighting over the same clients
The debate is almost always framed as a duel: no-code platforms on one side, development agencies on the other, and a client in the middle, supposedly forced to pick a side. A duel assumes one thing: that both offers answer the same need.
Fifteen years of watching this market tell me they usually don’t. The client who picks an app builder directly wants to build and update the app themselves. An agency’s client wants a partner who translates the need, chooses a solution, builds the product, and takes responsibility for what comes next.
The two audiences overlap at times. But the most useful line doesn’t run between code and no-code. It runs between building yourself and having it built.
For project owners weighing the two paths, there is a detailed decision grid, with the numbers. The question that interests me here is different: what happens when the agency itself picks an app builder?
From a new market to a production tool
The first agencies came to us for a simple reason: their web clients were asking for native apps, and they had no iOS or Android developers to put on the job. An app builder let them open a mobile offering without becoming native development studios.
Some then specialized. They build apps for pharmacies, professional associations, religious communities, or local radio stations, sectors whose constraints, vocabulary, and habits they know from the inside. Serving the same sector over and over, they no longer sell just the making of an app. They sell an understanding of the problem that their client doesn’t have to rebuild with every new vendor.
Others use the app builder as one tool among several. For a content or commerce project that fits the platform’s capabilities, they know it can be the most efficient choice. When the business logic, an integration, or an interface demands something else, they code, add a component, or pick another architecture.
More specialized no-code tools have widened that toolbox further. That movement puts us in competition on every use case. It’s on us to earn our place, project after project.
What an app builder changes in an agency’s economics
When an agency bills for development or integration, a tool that removes those hours cuts directly into that revenue stream. Agencies adopting it therefore have to make up elsewhere for what they no longer bill in production.
An hour of development eliminated isn’t necessarily an hour of revenue lost. It can also let the agency deliver faster, take on more projects, and turn a one-off build into a repeatable offer. It can spend less time rebuilding the same foundations, and more time understanding the trade, designing the service, preparing content, supporting the launch, and running the operation.
The cost of an app never stops at the first build: what an app really costs shows up after day one. For an agency, a platform that centralizes hosting, technical updates, mobile features, and publishing can make the economics of a portfolio very different from a string of isolated builds.
None of that means the tool absorbs the work. The agency has to recognize which projects fit, and know how to complete what the platform doesn’t cover. Some develop plugins. Others now use AI generation to create more specific sections. In both cases, their job starts with judgment: knowing what to assemble, and where the limits require a different approach.
What no tool takes off your hands
A platform contains features. It does not know the client or their business, and it does not take responsibility for the result.
An agency understands why a pharmacy doesn’t communicate like a media outlet, why an association doesn’t manage members the way a shop manages customers, or why an internal team needs different permissions for different users. It balances conflicting requests. It runs the project. It answers when something breaks. That value exists regardless of how much code gets written.
A recent case from our support sums up the shift. An agency had built a fleet of apps for a client. It recently opened, in that client’s name, a separate space to hand over control of the fleet. The handover didn’t erase the agency’s work. Its work had been to design and deploy the fleet, then to organize the conditions of its client’s autonomy.
Not every agency relationship is meant to end that way. Some clients want to delegate operations for good. Others want to take over once the product is stable. Either way, the agency can decide with them what it runs and what it hands over.
Custom development keeps its territory
None of this makes custom development disappear. Proprietary business logic, deep integration with an existing system, a game, or a hard requirement to own the code call for an architecture built for the project. In those situations, an agency able to design and maintain that architecture remains the right answer.
So the choice doesn’t come down to a general preference for code or no-code. Two questions come first:
Does the project owner want to build and run the app themselves, or delegate that responsibility?
Does the need fit a platform’s capabilities, possibly extended, or does it require entirely specific logic?
The first question picks a relationship. The second picks an architecture. An agency and an app builder can end up on the same side of both.
The tool you hid, the tool you claim
The clearest sign of the road traveled is white label itself. It still exists at GoodBarber, and some agencies value it for brand, contract, or consistency reasons. But I hear far less of the fear that used to come with it. Making it real is engineering in its own right: our CTO Dumè calls white label a subtraction job.
I also see agencies going the other way: they display the tool, and make it proof of their ability to choose proven infrastructure. As with WordPress, the platform’s name takes nothing away from their expertise. It simply tells you one of the building blocks they decided to use.
The war between no-code and agencies never happened. Agencies never had to pick a side. They had to pick their tools, based on their clients.