A few years ago, custom software for the HR team was a project. A requirements document, a quote, an agency, rounds of feedback, eventually a go-live, and then a maintenance contract. Today someone in HR describes what they need in three sentences, and an AI turns that into a working app. That is vibe coding: software comes from a description in everyday language, and the AI writes the code.
We think this is some of the best news business teams have had in a long time. And we think most companies are currently arguing about it in the wrong place.
The people who know the process should build the software
The head of payroll knows when a contract ends after probation and when it doesn't. The head of purchasing knows above which amount a second approval is needed. Until now, that knowledge had to survive several translations: from the business team into a ticket, from the ticket into a specification, from the specification into code. Every translation lost something.
Vibe coding shortens that chain. Whoever knows the process describes it themselves. That isn't an attack on IT. It takes weight off IT, which no longer has to turn every spreadsheet into a project that, in the end, nobody quite wanted.
Building isn't the real problem
The debate often centres on whether AI-generated code is good enough. That is the smaller question. The bigger one is: where does the app run the day after?
An app built in an AI tool often ends up on someone's private account. Sharing means passing on a link. Nobody explicitly decides who may see what. There are no tests, and when the next change breaks something, there is no way back. IT finds out last, if at all.
None of this is bad intent. It is simply the gap between "it works on my screen" and "it works in the company". The long development process used to hide that gap. Now that building is fast, it is out in the open.
What "in the company" actually means
An app a team relies on needs a few things that have nothing to do with its actual purpose:
- Sign-in with company accounts, so nobody keeps separate passwords for every app, and people who leave lose access.
- Permissions per role that apply to every data access, not just to what the screen shows.
- A check before going live, so a small change doesn't quietly expose salaries.
- Versions and a way back when something turns out to be wrong.
- Clear ownership: the code and the data belong to the company, not to an account.
These aren't extras. They are the difference between a prototype and a tool a team can depend on. And they are exactly what one person with an AI tool shouldn't have to build on the side.
Guardrails instead of bans
Many companies respond to all this with bans, or with approval processes that take as long as development used to. Both lead to the same result: people build anyway, just somewhere else.
We believe in a different approach. The guardrails belong in the environment, not in each person's head. If every app automatically runs with company sign-in, is automatically checked and automatically versioned, nobody has to remember any of it. And nobody can forget it.
That is how Openbase.one works. You describe in your own words what the app should do and who may see what. A build agent builds it, and Openbase.one asks you only the domain questions, such as: "Does a contract end automatically after probation?" Every version is built and opened in a real browser as every test persona: as a manager who sees no salaries, as HR who sees all of them. It goes live only when the check passes.
App code runs isolated, with no network access, and every data access is checked against the workspace, the app and the person's permissions. Every version is kept, and the previous one is live again in one click. The code of every app you build lives as a git repository in your workspace.
What vibe coding doesn't replace
To be honest: a check can prove that a manager doesn't see salaries. It can't decide whether your leave policy is right. That stays your decision, and it should. Nobody but you knows how your business works.
What changes is the role of business teams. They don't become developers. They stay who they are, except that their knowledge now turns directly into software. They don't need to understand databases, but they do need to state their rules clearly. Anyone who has written a good process description can do that.
And if you want help, you're not on your own. Platform support is included in every plan. Bookable support contracts help with your own apps, and Premium includes a review of new apps before they go live.
Permission to build, safe to run
In the end, vibe coding at work isn't a technology question. It is a question of permission. Should the people who know the processes build the software for them? We say yes, as long as the result runs where the company can see it, check it and roll it back.
Not everything has to be built. Ready-made apps come from an App Store that keeps growing: Files, Mail & Phone, Meet, Bank, Payroll, Website and Wiki run today. Installing runs the published, checked version, with no build and no AI costs. Whatever is missing, you build yourself.
Try it for free
Openbase.one is priced per workspace, not per user, and every app is included. You start with €15 of AI credit and no credit card. All plans and support contracts are on the pricing page.
Describe your first app and watch it go live, checked.
Start for free