From one process to your own teams building.
This is how an engagement runs, from the first conversation to the rollout decision. It follows what we did in our first customer pilot, at a European engineering consultancy, and what we learned there.
Before the pilot
Start from a real process, not a slide deck.
Stage 01
First conversation
You show us a process that lives in a spreadsheet today, or describe it. We show it back to you as a running app, with sign-in, roles and the code behind it.
If we need to look at your systems or data to get there, we sign an NDA first.
- You bring
- One process, and someone who knows it.
- We bring
- A founder and a working example.
- You end with
- A pilot proposal for that process, with a fixed scope.
Stage 02
Agree the pilot
Together we choose the use cases, the people who will build, the systems to connect and what success means. IT and the business both have a say from here on.
Code ownership, data processing and what happens at the end are written down before any work starts.
- You bring
- A named IT sponsor who can make decisions, and the pilot users.
- We bring
- The pilot plan and agreement, including data processing terms.
- You end with
- A signed agreement and success criteria you helped write.
During the pilot
Your people build. We stay alongside them.
Stage 03
Foundation
We set up your environment in Europe and connect sign-in to your identity provider, so people use their company accounts from the first login. You don’t buy any infrastructure for the pilot.
Generated apps carry your brand from the start.
- You bring
- The identity provider configuration on your side.
- We bring
- The environment, its services and the sign-in connection.
- You end with
- The first person signs in with a company account.
Stage 04
Onboarding workshops
Hands-on sessions for the people who will build. We go through the whole path on your environment: signing in, describing an app, reading the code it produces, going live and managing who has access.
Each session ends on the question that shapes the following weeks: what does your app need to connect to?
- You bring
- Builders who own a real problem, ideally with a spreadsheet or specification in hand.
- We bring
- The workshops, led by the engineers who will support your team.
- You end with
- Builders with a running app and a list of the integrations they need.
Stage 05
Building with a forward-deployed engineer
One of our engineers builds the first app with your team, then stays close while your people build the next ones. They take on the hard parts: integrations, data, security and performance.
Questions go to a shared channel, not a ticket queue. Where an old app or workbook exists, it becomes the specification, and the new version is tested against it. What your team asks for goes straight to the people who build the platform. In our first pilot, several requests shipped within the week.
- You bring
- Real use cases, and time set aside to work on them.
- We bring
- One engineer for the length of the pilot, and regular progress reviews.
- You end with
- Apps in production, used by real staff on real work.
Stage 06
Customization and integrations
Each system gets one intake sheet: how to connect, how to sign in, which calls an app may make and which access rules apply. We prefill what we can and you correct it. Secrets never go on the sheet. We agree a secure handover instead.
We start with a small end-to-end test on one real use case and widen from there. IT approves each app’s access, operation by operation, separately for preview and production. Internal-only systems need a published endpoint, for example through your API gateway.
Customization covers your brand, your house rules for how apps are built, and your own AI models.
- You bring
- The systems you most want connected, their API documentation and test access.
- We bring
- The connectors, built and set up with your team.
- You end with
- Connections that later apps can request, without building them again.
Stage 07
Security review
This runs alongside the build and starts from your checklist, not ours. We answer it row by row, each with a screenshot or command-line run from the live platform, and a status: shipped, in progress, documented or gap.
Where a row is only partly done, it says what is left and who owns it. Your team reviews at its own pace and asks for a walk-through where it wants one. Some rows close with a decision from you, such as who approves access or how much notice you want before platform updates.
You can also commission an independent penetration test during the pilot, scheduled with us.
- You bring
- Your checklist, your reviewers and the policy decisions only you can make.
- We bring
- Evidence for every row, and direct access to the engineers behind it.
- You end with
- A record of what is done, what is open and who owns each item.
Stage 08
Results and decision
The last stretch tests the apps under real use. We measure time to live, cost and user satisfaction, and check that someone who did not build an app can maintain it. You decide on those results.
If the answer is no, you export your code and data, we tear the environment down, and we confirm in writing that none of your data remains. The code is yours either way.
- You bring
- Real usage, honest feedback and a go or no-go decision.
- We bring
- A pilot report with the results and a plan for what comes next.
- You end with
- A decision based on your own results.
After the pilot
From one team to many.
Stage 09
Rollout
Here is what we recommend, based on what the pilot taught us. Bring builders in by waves, through team leads, rather than with one general call. Give each app a short cycle with real users, about two weeks, then decide whether to continue, stop or promote it.
Production can move into your own Kubernetes cluster, set up together with us, when you are ready. Your people carry on building, and our engineers step in for the hard parts.
- You bring
- Owners for the rollout, builders with protected time, and a regular portfolio review.
- We bring
- The platform, training for each wave, and engineers for the hard parts.
- You end with
- Your own teams building, inside the same rules.
What the first pilot taught us
Six things to get right early.
Start from something that exists
Builders who began with a spreadsheet, a script or a written specification kept going. Those who began with a one-line idea mostly stopped within a week.
Have someone waiting for it
Every app that reached production had been shared with colleagues. Apps nobody was waiting for did not continue.
Protect the time
Activity dropped sharply over the summer. We now suggest agreeing about four hours a week for eight weeks with each builder’s manager.
Know when to call an engineer
Demanding calculations, integrations, external users and anything relied on in a deliverable are where our engineer should join. Teach that at the start, so people ask early.
Open the network early
Some blockers sat in network rules on the customer’s side, not in the platform. We now raise them in the foundation stage, before they can stall a builder.
Name an owner for access
The platform enforces who may build, but who should get that right is your decision. Name the person who approves it before the group of builders grows.