Internal tools built by business teams, governed by IT.
Equipment requests, the supplier register, non-conformities: each team describes the tool that replaces its spreadsheet. Before it goes live, you see what it keeps, which screens require sign-in and who is allowed to publish it.
Updated on
Demo: Ferroux Remises and Ferroux Tarifs, two internal tools of a fictional industrial group in Saint-Étienne, built with Kubbler.
The pages before sign-in
In the tree panel, the Ferroux Remises home page: what a colleague reads before signing in, section after section.
The rule, stated up front
On the canvas, the public page sets out the discount rule: up to 5 %, 5 to 12 %, above 12 %. The copy can be reworked in place.
One form, three routes
newRequestForm calls getSummary, simulate and submitRequest, three routes under /discounts that all require sign-in.
The tool's front door
Ferroux Remises published: sign in, or read "À propos de cet outil". The rest of the application waits behind sign-in.
The Ferroux group's tools, a demo built with Kubbler.
The Ferroux group makes and distributes industrial parts from Saint-Étienne: 900 people, five sales branches. Two internal tools replace its spreadsheets, Ferroux Remises for discount requests and Ferroux Tarifs for the price list, with one shared brand and one ladder of roles.
Remises: ten sales reps, autonomy up to 5 %, the director from 5 to 12 %, automatic refusal above
Tarifs: 315 items in 5 families, 4 price breaks, every increase traced
An "À propos de cet outil" page in each: data kept, role required screen by screen, who publishes
The group, its reps, its customers and its prices are fictional; these two internal tools take no payments.
The whole site, page by page
Each thumbnail is a complete page of the demo, as a visitor sees it. On a computer, hover one to scroll through it.
A discount, a price increase, two tools reviewed before publishing.
At each step, the tool as a business team uses it, and what IT reads of it in Kubbler at the same moment.
The tool's fact sheet, open to all
Before anyone signs in, Ferroux Remises says who uses it (ten sales reps, five branches, one director), what it keeps, collection by collection, and who publishes it: IT, alone.
The public part, in the Workshop
The tool's public page, with its sections in the left panel. You see what a visitor without an account can read; every working screen requires sign-in.
A 7.5 % discount requested
Usinage Gier Précision, €27,400 excl. VAT, 29 % margin: before sending, the rule says the request will go to the sales director, with 23.2 % margin left.
The rule lives in the API
In Mechanisms, newRequestForm calls simulate for the preview, then submitRequest on send. The 5 % and 12 % thresholds sit on the server; the form only displays them.
A 3.5 % increase on one family
In Ferroux Tarifs, machined parts had not moved in 25 months: +3.5 % from 23 October on 28 items, each shown with its price before and after.
The items table
315 rows in articles: reference, description, family, unit, the four price breaks, date of last change. In production Kubbler opens this table with no write access: you sort and filter it, nobody touches it.
Screenshots: Ferroux Remises and Ferroux Tarifs with the group's demo data, then both projects open in the Workshop.
Saturday 17 October, 10 discount requests are waiting for the sales director.
The dashboard replaces remises_2026.xlsx: 10 requests pending, 1 of them urgent, an average response time of 1 d 6 h, €61,677 in discounts granted in October on €983,060 of orders. The API computes every figure from the recorded requests, and a sales rep opening the same screen sees only their own.
The director's queue
Top left, 10 requests awaiting a decision, 1 of them flagged urgent.
Response time and amount
1 d 6 h to answer, over 29 decisions in 30 days; a 6.8 % average discount across the 32 granted in October.
Rep by rep
Sandrine Rivoire, Saint-Étienne branch: 7 requests, 5 granted, 2 pending, €18,651 in discounts. The list ranks by amount granted.
One foundation under every tool, the calls left to IT.
Three teams, three tools, the same foundations: hosting and accounts don't get re-approved with every request. What you decide is who builds, who publishes, and what each tool collects.
Our part
Identical in every team's tool, with no setup to redo.
User accounts
The same screens in every tool, never a per-project variant: sign-up and email verification, password reset, two-factor authentication.
Hosting and processing
OVHcloud in France, HTTPS, one database per tool, automatic backups, Dev and Prod kept apart. A DPA under GDPR article 28 is annexed to the terms.
Consent and legal notice
A banner that refuses everything by default. The legal notice and privacy policy use the publisher's details, entered once for the workspace.
Your part
What IT decides for each tool, without writing a line of code.
Who builds, who publishes
Each member is a viewer, editor or administrator of their workspace. An editor builds; going live, the domain and hosting stay with administrators.
What each tool collects
In the Workshop, every collection shows its fields, and every screen or route states whether it is public or for signed-in accounts only. You read it before you say yes.
The AI budget
Generations are paid in sparks. An administrator splits the workspace budget between members, and usage reads project by project.
Customer data on the shared drive, found during the GDPR review.
In a group of several hundred people, every team keeps its own file: equipment requests in HR, the supplier register in Purchasing, non-conformities in Quality. They live on a shared drive, with names, addresses and contracts inside, and IT finds out about them the day one breaks or an auditor asks. Meanwhile the roadmap is booked for the year, and every new request waits its turn.
Each known answer has its cost. Blocking unapproved tools pushes the files onto USB sticks and personal accounts. An enterprise low-code platform needs its own rollout project, often per-user licences, and developers who know it. A SaaS tool signed up for by one team often arrives with no data processing agreement. And a tool generated by a consumer AI leaves IT facing code nobody has reviewed.
With Kubbler, the team describes its need and the AI builds the tool on a shared foundation: accounts with two-factor authentication, a database of its own for each tool, hosting at OVHcloud in France. Members work in a workspace of your organisation as viewer, editor or administrator, and only administrators put a tool live. Before publication, the Workshop shows you the public screens and those that require sign-in, the fields each collection keeps and the routes that write to it.
What it costs
One project and 500 sparks a month, the budget that pays for AI generations. Packs can be added if you need more.
With your own domain: €44 excl. VAT a month.
No commitment. The domain name itself is paid separately.
See all pricesWhat to have ready
The first need to move out of a spreadsheet, and the team that owns it.
The people to invite, and each one's role: viewer, editor or administrator.
The company name, registration number and head office address, entered once for the workspace and used in the legal pages.
The contact for personal data and your retention periods, which the privacy policy picks up.
The list of data to keep out of the tool: the hosting is neither designed nor certified for health data or the other special categories under GDPR.
Nothing else: no specification, no mock-up.
The questions we get asked.
Including the ones where the answer is "not yet".
At OVHcloud, in France: each tool has its own database, separate from other projects and backed up automatically. A DPA (GDPR article 28) is annexed to our terms and lists the subprocessors. Generation goes through Anthropic, in the United States, which receives the excerpts it needs under standard contractual clauses, with no right to use them to train its models.
Not yet. Each person has their own Kubbler account, with two-factor authentication available, and joins a workspace by invitation. When someone leaves the team, an administrator removes them from the workspace.
In Kubbler, a viewer reads, an editor builds, and putting a tool live, choosing its domain or suspending it is for administrators only. Inside the tool, the foundation tells administrators from users. The demo's Ferroux tools add an editor level between the two, checked by their own routes; no screen yet lets you assign those levels, and per-field rights do not exist.
Not yet: there is no central audit log to consult. Each project keeps the history of its changes, by the AI or by hand, readable as a diff. In production, collections stay read-only in Kubbler.
Your data, yes: at the end of the contract, the DPA provides for its return or its deletion, as you choose. The code, no: there is no export, and the shared foundation stays with us, read-only in the Workshop.
The Starter plan is €29 excl. VAT per month, plus hosting for the tool: €5 excl. VAT per month with a kubbler.app address, €15 excl. VAT per month with your own domain. No commitment. Each tool put live has its own hosting, and the team plans, which share one budget across several seats, are on the pricing page.
Start with the spreadsheet that worries you most.
In the Studio, the team that owns it describes its need. You read the resulting tool in the Workshop, collection by collection, and only an administrator puts it live.