What happens below
the surface.
The home page explains what you get out of it. This page explains how it comes about — for everyone who wants to know that before entrusting someone with their project.
From a sentence to a running application
Describe
In conversation, a specification takes shape: what the application has to do, which workflows it covers, who uses it. It is not a requirements document in jargon, it is your description, put in order.
Design
From that, a data model and a build plan are derived. Both are put in front of you before anything is built — in understandable form, not as program code.
Build
Cody writes the application, sets up automated tests and runs them on every change. Whatever fails the check does not go any further.
Verify
Before handover, security checks run: dependencies against known vulnerabilities, database access rules, tenant separation. Anything that stands out blocks the release.
Go live
The application goes live in your infrastructure — your own domain, your own database. The second instalment falls due before go-live; after that you have fourteen days to check it against the plan before it counts as signed off.
Maintain
After that, Cody monitors operations, applies security updates and checks again after every change that everything runs.
What it is built from
Deliberately ordinary, widely used building blocks. Nothing exotic — precisely because you should stay independent.
| Role | Building block | Why |
|---|---|---|
| Application | Next.js and TypeScript | A widespread, well-documented foundation. Any developer can take the application over — that is the precondition for you being genuinely independent. |
| Database | PostgreSQL, run via Supabase | An open standard for decades. Your data sits in your own project, and the access rules are enforced at database level — not just in the interface. |
| Delivery | Vercel, Frankfurt region | Operated in the EU. Every change goes through the same chain of checks before it goes live. |
| Source code | Git, in your own repository | Every change is traceable: you see what happened when and why. Code can be taken back, what is published can be replaced. What has taken effect in the database or at third parties stays — we say that beforehand, not afterwards. |
| AI access | Your own key with the provider of your choice | You pick the provider and see the costs directly. No markup, no dependency on our contract. |
Who owns what
The point where Cody Studio differs from most other routes — which is why it is spelled out here.
- Where is the source code?
- In a Git repository that runs on your account. Not on ours. You have full access from the first line on and can hand it to another provider at any time.
- Where is the data?
- In a database that runs on your account, located in the EU. We only have access for as long as you grant it — and that access is revocable.
- What happens if we stop working together?
- Nothing gets switched off. The application keeps running, because it runs in your infrastructure. We hand back access and delete any copies left with us. There is no data handover, because there is nothing to hand over.
- Is there a dependency on Cody?
- Not technically. The application is ordinary software on a widespread foundation. What you buy is the speed at which it is built and maintained — not a lock that only we have the key to.
- Does an AI see my customer, pricing and staff data?
- While building, Cody works on your program, not on your customer list — what it needs is your description of the workflows. Where real data is required for debugging or a data migration, we say so beforehand; a data processing agreement under Art. 28 GDPR applies to that, and you remain the controller. AI access runs through your own key: you see every use directly with the provider and can block it at any time. We do not train any model on your content — that is in our terms, not just on this page. Whatever the AI provider you choose commits to beyond that depends on their conditions; we put those in front of you before the project starts.
How it is secured
Separation of data
Access rules are enforced at database level (row level security). A faulty spot in the interface therefore cannot break the separation.
Checked dependencies
Third-party components are continuously checked against known vulnerabilities. Findings from severity “high” upwards block the release until they are fixed.
Traceable changes
Every change is tied to a point in time, a reason and a test result. In case of doubt, any state can be restored.
Approvals in the right places
You decide which operations run without asking and which wait for your approval. The default is: anything with an outside effect waits.
Where the limits are
What a vendor keeps quiet about, you otherwise only find out when it gets expensive. That is why it is here.
- Cody does not replace a specialist department. You know what is professionally right — Cody builds it, but does not judge it.
- Where good standard software exists, it is usually cheaper and faster. Accounting and payroll are typical examples.
- We are not ISO 27001 certified. We work to recognised principles — that is something different from a certificate.
- A specific availability only applies if it is agreed in writing as a service level agreement. Without that agreement there is no promised level.
- Applications that have to be designed for very large numbers of users need their own upfront planning. Say so early and we'll work it out early.
Still got a question?
Then it is probably a fair one. Write it to us — we answer concretely, even when the answer is “we can't do that”.