Business teams build. You govern.
Shadow IT exists because teams no longer wait for the roadmap. Open them a frame you validate once: accounts, two-factor authentication, roles, per-project isolation, hosting in France, DPA, exportable code.
- foundation validated once, applied to every tool
- 1foundation validated once, applied to every tool
- data hosting (Scaleway), backups included
- Parisdata hosting (Scaleway), backups included
- proprietary formats: readable, exportable JavaScript
- 0proprietary formats: readable, exportable JavaScript
Banning doesn't work anymore. Framing does.
Every IT department knows the inventory: shared spreadsheets holding customer data, SaaS subscribed by credit card with no processing agreement, access never revoked when a colleague leaves, and a six-month IT project for every need that comes up. Shadow IT isn't a discipline problem: it's the rational response of teams that have a need now and a saturated roadmap.
Banning moves the problem without solving it, and consumer no-code tools often make it worse: quick to adopt, but with no access governance, no controlled hosting, no reversibility. AI code generators add a new risk: code nobody has reviewed, foundations reinvented for every project, secrets in the browser.
Kubbler offers a frame rather than a ban. The foundation is written and operated by engineers, identical for every tool: accounts and enforceable two-factor authentication, roles and organisations, per-project isolation (database, secrets, domain), hosting in Paris, backups, security headers, DPA. The AI doesn't touch it; it interprets the business need to assemble the application layer within it. You validate the frame once, you keep visibility and reversibility, and business teams move forward.
Ban, endure, or frame.
What shadow IT costs when left alone, and what it becomes on a governed foundation.
What you validate once.
Governance isn't a brake when it lives in the foundation rather than in a process. Here is what applies to every tool built, without having to ask again.
The frame
What applies to every tool built, without having to ask again.
Organisations & roles
One space per organisation, one role per member, traced invitations, access that leaves with the colleague.
Security
Enforceable 2FA, quotas, anti-fraud, security headers (CSP), systematic validation: set for everyone, once.
Secrets
End-to-end encrypted vault, per environment, injected at deploy time. Never in the browser.
Control
What lets you say yes without fearing tomorrow.
Isolation
Each tool its own database, secrets, domain, backups. No leaks between projects.
Hosting
Backend in Paris (Scaleway), frontend on Cloudflare's edge, automatic backups, a test version before release.
Reversibility
Code exportable at any time, readable, conventional JavaScript, DPA provided. No proprietary format.
What you can build with it.
Three cases where "no" is no longer tenable, and where a frame beats a ban.
Internal tools built by business teams themselves
On a foundation you validated once: accounts, two-factor authentication, roles, per-team isolation, backups. What would have ended up in a spreadsheet ends up in a governed tool.
A partner or supplier portal
External access partitioned per organisation, data hosted in France, end-to-end encrypted secrets, logging. Open to the outside without opening the information system.
Shadow IT brought back onto a shared foundation
The spreadsheets and small tools lying around everywhere, put back on a base you govern: registered, isolated, backed up, reversible. Without a six-month project for each.
How it works, concretely.
Four steps, three actors: you set the frame, the AI interprets the business need, and the engineers who wrote the foundation answer for it.
You open a frame
One workspace per organisation, roles per member, two-factor authentication enforced if you wish, centralised billing. You validate the foundation once, not every tool.
The AI interprets
Teams describe their need; the AI translates it into screens, fields and access rights, from existing blocks. It works strictly within the application layer, never within the foundation.
The foundation carries
Authentication, roles, per-project isolation, encrypted secrets, security headers, quotas, anti-fraud, hosting in Paris, backups: written, reviewed and operated by engineers, fixed for every tool at once.
You keep visibility
You see the projects, the members, the access. You can audit, export the code, revoke an access. Business teams publish their tools; you govern the frame in which they do it.
Why Kubbler, for an IT department.
Four reasons that answer the criteria you apply to every tool: compliance, security, reversibility, risk control.
Compliance lives in the foundation
Data hosted in Paris, DPA compliant with GDPR article 28, consent-respecting usage analytics, automatic backups, logging. You don't validate every tool: you validate a frame that applies to all of them, and that is documented.
The AI doesn't touch the foundations
It's the new risk of code generators, and the one Kubbler is designed to rule out: the AI interprets the business need and assembles the application layer; authentication, payments, security, data and deployment are written, reviewed and operated by engineers, identical for everyone.
A team of engineers answers for the foundation
The foundation is fixed and extended for every project at the same time; a vulnerability fixed for one is fixed for all, with no action from business teams. You have a contact, support, and (on the Team plan) an availability commitment.
Reversibility is total
Every tool's code belongs to your organisation and exports at any time to GitHub, in readable, conventional JavaScript, with its data model. No proprietary format, no imposed dependency: you can take any tool back in-house whenever you decide.
The questions we get asked.
Precise answers, because decisions are made on facts, not on promises.
The backend runs on our Scaleway infrastructure in Paris, the frontend is served from Cloudflare's edge. Each project has its own database, encrypted secrets and domain, isolated from the others, with automatic backups. A data processing agreement (DPA, GDPR article 28) is provided.
Two-factor authentication (TOTP, email, SMS) enforceable for an organisation, roles and organisations, quotas and anti-fraud, security headers (CSP), systematic input validation, end-to-end encrypted secrets per environment never exposed to the browser. The same foundation for every project, fixed for all at once.
Low by construction: the code belongs to your organisation and exports at any time to GitHub, in readable, conventional JavaScript (Next.js, Node.js, MongoDB), with its data model and migrations. No proprietary format, no closed runtime. You can take a tool back in-house whenever you decide.
One workspace per organisation, roles per member, traced invitations, centralised billing. You see the projects and the access, you can audit, revoke and export. Business teams assemble inside a frame you set once: the AI can't step outside it.
It interprets the need expressed by business teams to assemble the application layer: screens, fields, journeys, access rights, from existing blocks. It never writes authentication, security, payments, migrations or deployment: those foundations are written by engineers and identical for everyone. What it produces is checked before being saved.
Open a workspace for a pilot team, set the roles and two-factor authentication, and let them build their first tool. You audit the result, export the code if you want to read it, then widen the scope. Free during the beta, no commitment.
Frame instead of banning.
Free during the beta. Open a space for a pilot team, set the frame, and watch what they build inside it, then audit the code.