← All comparisons
Compare
Using an AI app builder for client work
Building for a client is a different problem from building for yourself. The code is not yours, confidentiality may be contractual rather than a preference, and you have to be able to say where the work sits and what happens to it. That narrows the field before any feature comparison starts.
| Adrian | The usual shape | |
|---|---|---|
| Where the client's code sits | In a folder on your disk. On local models nothing goes to a model provider, because there is no provider in the loop. | On the vendor's platform, and with a hosted model, in the model provider's pipeline too. |
| What you can put in writing | That the work stayed on your machine — verifiable, since a local build keeps working with the network unplugged. | Whatever the vendor's terms and subprocessor list say, which you are relying on rather than controlling. |
| Handing the project over | It is a folder of source. There is no account for the client to be added to. | Usually a project on the platform, with an export or Git sync as the handover path. |
| Cost per client project | Nothing on local models. On your own key you pay the provider directly, so per-project cost is traceable to that bill. | A seat or subscription that runs whether or not a project is active. |
| Working without a connection | Yes, on local models — useful on a client site with locked-down networking. | No; the model is remote by definition. |
When Adrian is the better choice
- The engagement has a confidentiality clause that a third-party build platform would complicate.
- You want per-project costs you can trace to a provider bill rather than a flat seat you pay in quiet months.
- Handover should be a folder of source, not an account transfer.
- You work on sites or networks where a hosted builder simply will not reach.
When it is not
- The client wants the finished thing deployed and hosted. Adrian's deploy stage is roadmap, so a hosted builder does today what you would otherwise do by hand.
- You are on macOS or Linux, which is common in agency work. Adrian has not shipped there yet.
- You need several people editing the same project at once — Adrian is a desktop application, not a collaborative workspace.
- The client's own stack is already on a platform and they want the project to live there.
Common questions
- Can I use an AI app builder on confidential client code?
- With Adrian on local models, yes: the prompt, the generated code and every repair pass stay on your machine, and the build keeps going with the network unplugged. If you use your own API key instead, files stay local but code context does go to that provider — so for a strict confidentiality clause, local is the mode that matches the promise. Your own contract is the thing that governs, and this is not legal advice.
- Who owns what an AI app builder produces?
- For Adrian, you do — ownership of what you build is covered in the terms. What that means for a client engagement is set by your contract with them, not by us. The practical point is that with a desktop tool there is no platform account holding the deliverable when the engagement ends.
- Is an AI app builder suitable for professional client work?
- For producing a working first version, yes; as the whole delivery process, not yet. Adrian's checks are a floor — nothing provable is wrong — not a substitute for review of code you are being paid for. Deployment is also still roadmap, so shipping the result to the client's hosting is on you today.
- What happens to a project when the engagement ends?
- It is a folder of source on your disk, so handover is copying it. There is no seat to transfer, no account for the client to be invited to, and nothing that stops working if you cancel a subscription — which on the local path you never had.
The desktop app is free with local models or your own API key. Windows today — macOS and Linux are not released yet, and the build is unsigned, so Windows shows a SmartScreen warning on first run.