Build your startup's MVP without a developer, ready for a pilot customer.
Your pilot customer wants to try it with their team, and their legal department asks where the data will be hosted. Describe your product: the AI builds it with verified accounts, a database of its own and hosting with OVHcloud in France. You read what it does before you send the link.
Updated on
Demo: Midi Pile, a fictional Lille startup delivering lunch to the staff of a pilot company, built with Kubbler.
The promise, section by section
The home page's tree lines up its sections, from the "Commandé avant 10 h 30" promise to the pilot sheet written for Ostrale's management.
The kitchen, shown to the pilot
In the page being edited, the section on La Cuisine des Sarrazins and the one on per-floor crates: copy, photo and checklist can be reworked before the next meeting.
The order, five routes
The lunchOrder block calls five routes, from the day's menu to checkoutOrder, which creates the order and its payment; the chain touches seven collections and the payment brick.
The link sent to Ostrale
The published site: the menu for Monday 19 October (ratatouille at €9.50, waterzoï, risotto), orders close at 10:30, delivery at 12:00, 2nd to 6th floor.
Midi Pile, a demo built with Kubbler.
Midi Pile is a two-founder startup in Lille, run by Inès Kaddour and Thomas Vandamme: employees order lunch in the morning, and a neighbourhood kitchen in Wazemmes delivers it to their floor at noon. Its app handles verified accounts, the day's menu, card-paid orders before 10:30 and the kitchen board, for a first pilot customer, Ostrale Ingénierie in Euralille.
3 dishes from €9.50 to €12.90 and 1 dessert at €3.50, published the day before
A 10:30 cutoff enforced by the API, one paid order per person per day
A 200-employee pilot, delivered across 5 floors, 2nd to 6th
Midi Pile, Ostrale Ingénierie and La Cuisine des Sarrazins are fictional, the orders are demonstration data and payment runs through Stripe in test mode.
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.
The first real journey, screen by screen.
For each of your user's screens, the Kubbler view that answers it: what they saw, what was checked, what was saved.
The day's menu, with its deadline
Monday 19 October: ratatouille, chicken waterzoï, salmon risotto, and a timeline marking 10:30 and 12:00. Once orders have closed, the page says so and takes the order for the next delivery day.
The pilot's site, in the Workshop
The home page and its tree, in Dev: the Sarrazins kitchen, the crates labelled by floor, the sheet that answers Ostrale's management. Whatever the pilot asks to change gets reworked here, without touching the version its employees use.
Camille Martin puts lunch together
Carbonnade flamande at €12.90, plus a tarte au sucre: the label on the right fills in with each choice, 4th floor, delivery on Friday 16 October at 12:00, €16.40 incl. VAT.
The order, link by link
In the Mechanisms view, the lunchOrder block calls the day's menu, the employee record, their orders, their account, then checkoutOrder. The refusals (a same-day dish after 10:30, an unverified email, a second paid lunch on the same day) come from the API: this is the chain you show the pilot's IT manager.
She pays €16.40 by card
She picks her floor from five boxes, 2nd to 6th, then taps "Payer 16,40 €". The card goes through Stripe: Midi Pile neither sees nor keeps her card details.
One row per paid lunch
The order joins the orders collection: first name, last name, floor, dish, dessert, total, payment status, order time. Nothing beyond what delivery needs, and in production the table opens read-only.
Screenshots: Midi Pile, a lunch delivery app built with Kubbler for a fictional pilot, with demonstration orders and Stripe in test mode.
When orders close at 10:30, the kitchen reads 64 paid lunches, dish by dish.
Romain Delattre opens the board on the tablet at La Cuisine des Sarrazins: the orders for Friday 16 October, the last one paid at 10:29. He cooks exactly those quantities and fills one crate per floor. Payments that did not go through are left out of the totals: what the screen shows has been paid.
64 paid orders
At the top of the board: 64 lunches, 23 desserts, €819.80 taken, and 2 failed payments set aside.
28 carbonnades to cook
The row for carbonnade flamande with fries and salad, the most ordered dish, ahead of 19 battered pollack and 17 vegetarian lasagnes.
One crate per floor
The 2nd to 6th columns say what goes into each crate: for the 4th, 5 lasagnes, 5 pollack, 5 carbonnades and 6 tartes au sucre.
What the pilot checks, what you change every week.
A first customer's security questionnaire covers accounts, hosting and data. Those answers already exist, and your weeks go into the product.
Our part
What the pilot's IT department asks for before opening access to their team.
Sign-up and sign-in
Two-factor authentication, forgotten password, email checked at sign-up: screens and rules included, before your first page.
Data in France
OVHcloud servers in France, HTTPS access, and a database your project shares with no other, backed up automatically.
Trials kept apart from production
You try a new version on the Dev database; the pilot's team works on the Prod database, which your trials never touch.
Your part
What the pilot's feedback makes you change from one week to the next.
Your promise and your plans
The home page copy, the plans, your customer's industry vocabulary: you rework them in the Preview or by asking, and the new version goes out the next time you publish.
The journey's rules
A field that becomes required, a minimum notice before booking, a capped quantity: every rule changes in the Workshop, in Dev first.
Your users' data
Accounts, bookings, entries: everything lives in your project's database and belongs to you. When the service ends, the DPA lets you choose between getting it back and having it destroyed.
The pilot customer says yes, then asks where their data will live.
It took three months of meetings to find a first customer willing to test your product with their team. The meeting goes well, then their IT manager's questions come in: who will be able to sign in, where the data is hosted, what happens if a password is stolen. Your prototype chains screens together, but nobody really signs in and nothing typed into it is kept.
To get to the version the pilot will actually use, there are four known routes. An agency quotes the product in weeks, and every round of pilot feedback goes back through a quote. Hiring a first developer takes months, before you even know whether the market is there. A no-code tool produces screens quickly, but accounts, hosting and backups are left for you to assemble, then to explain. An AI app generator turns out a version in an evening, and afterwards nobody can say what it wired up behind the sign-up button.
On Kubbler, what the IT manager checks exists before your first page: sign-up with email verification, two-factor authentication, a database for your project alone, hosting with OVHcloud in France, automatic backups. Your time goes into the journey that makes your product. You try every change in Dev while the pilot's team works in Prod, and when the IT manager wants to understand, you open the Workshop: every page leads to the route that serves it and to the collection its data is written to.
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 main action in your product, the one the pilot must be able to do alone from the first week.
The information to collect every time, and which of it is required.
What a user sees, and what only an administrator should see.
Your company's name, registration number and address, for your legal pages.
The domain name the pilot will receive the link on, if you have already registered it.
Nothing else: no specification, no mock-up.
The questions we get asked.
Including the ones where the answer is "not yet".
In France, on OVHcloud servers, accessed over HTTPS. Your application's data lives in a database reserved for it and backed up automatically, and our DPA (GDPR article 28) can be passed on to their legal team. In the Workshop, you can also show them each collection and the fields it keeps.
The Starter plan is billed €29 excl. VAT monthly. Hosting comes on top: €15 excl. VAT a month to serve the application under your own domain, or €5 excl. VAT a month for a kubbler.app address. No commitment, and no agency fees or salary to pay before the market is validated.
Not yet. A Kubbler application takes one-off card payments (Payment brick, through Stripe), but does not handle subscriptions yet. During the pilot, subscriptions go through your usual tools.
No, the code does not export: the foundation stays Kubbler's. What belongs to you is the data, and your API's description, which exports to OpenAPI 3.0 at any time. Your CTO can join the project in Kubbler, read every mechanism in the Workshop and write a custom route by hand.
The application knows two: administrator and user. The pilot's operations manager can be an administrator, and their partners users. Finer roles, or separate spaces for each of your customers, are not possible yet.
Not with an analytics tool: a Kubbler application cannot take an audience measurement tool yet, and computes no funnel or conversion rate. What you can read is your collections: every saved booking is a dated row there, which you filter in Kubbler.
Describe the product your pilot customer is waiting for.
In the Studio, Kubbler starts from your description to propose the pages and the data. You approve that plan, then reread every screen before sending the link to the pilot.