Client prototypes with AI under NDA: a shared RTX PRO workstation for agencies and studios

Client prototypes and MVPs without uploading the brief

An agency can build client prototypes with AI under an NDA by running the app builder and the language model on its own workstation: Dyad or OpenHands as a local alternative to Lovable, an open model such as Qwen3.8-27B in Ollama, and an NVIDIA RTX PRO Blackwell card with enough memory for several people at once. The brief, the screens and the generated code are then processed on that machine and stored in one Git repository per client. For a studio where several people build at the same time, one RTX PRO 6000 Blackwell Workstation Edition or Max-Q with 96 GB is the practical shared machine.

This page is for owners and technical leads of digital agencies, product studios and freelance developers who sell clickable prototypes, proofs of concept and first versions of an app. The question behind it is usually contractual. A client's NDA or data-processing terms say which third parties may see the brief, the customer data in a demo or the client's existing code. A cloud builder is such a third party, together with the model providers it uses. What the EU Trade Secrets Directive expects from the holder of confidential information, and what changes with a server of your own, is the subject of our guide to trade secrets, NDAs and AI tools.

Cloud builders publish their own rules, and they differ by plan. Lovable's documentation, read on 30 October 2026, states that from 9 September 2026 customer data from its Free and Pro plans may be used to train models unless each user opts their own content out with an account setting, which works from then on. Workspace data on its Business and Enterprise plans is "excluded from model training by default". With a local builder, no training question arises because no outside service receives the content. The tools themselves, compared one by one, are in our article on the self-hosted Lovable alternative; this page covers what changes when the work is done for paying clients.

The tools and their licences for paid client work

An agency needs two things from a licence: permission to use the tool commercially, and no claim on the code it produces. The table shows what the licence files and project pages state.

Dyad README, FAQ and the licence file in src/pro, OpenHands repository and release page, Ollama repository, the Qwen3.8-27B model card, the bolt.diy repository page and the WebContainers licensing page, all read on 30 October 2026.

Dyad is the closest local equivalent of a prompt-to-app builder. Code outside its src/pro folder is under Apache 2.0. The pro folder is under the Functional Source License 1.1, which allows any purpose other than a "Competing Use": making the software available to others in a commercial product or service that substitutes for it or for another product its makers offer with it, or that offers "the same or substantially similar functionality". The clause is about passing on Dyad's own code, and the licence names among its permitted purposes use "for your internal use and access" and "in connection with professional services that you provide to a licensee using the Software". An agency that builds client apps with Dyad passes on the apps, not Dyad's code, and each version of the pro code becomes Apache 2.0 two years after its release. Dyad's FAQ answers the ownership question directly: "Your code is your code, and it's all on your computer." Its privacy policy, last updated on 22 June 2026, states that with local models "everything stays on your device" and that telemetry, sent only with consent, does not include chat messages, prompts or code. The FAQ also states that "Dyad only supports JavaScript-based apps at this time", so a client backend in Python or Java is a task for OpenHands.

OpenHands is an MIT-licensed coding agent that edits files and runs commands. It suits the step after the clickable prototype: an MVP with a backend, tests and a build script. Its local web interface binds to 127.0.0.1 by default.

bolt.diy is MIT-licensed, but the apps it builds run in StackBlitz's WebContainers runtime, whose licensing page requires a licence for "production usage of the API in a commercial, for-profit setting" and exempts "Prototypes or POCs". Which of the two covers paid client prototypes is a question for StackBlitz, so we do not deliver bolt.diy preinstalled.

The model's licence matters as much as the tool's. Qwen3.8-27B and Qwen3-Coder-Next are under Apache 2.0 by their model cards. Some image and video models used in agencies are not free for commercial use, as our guide to an AI server for creative agencies shows; check each model before it goes into client work.

You can order the RTX PRO workstation alone, the setup of Ollama, the model and Dyad or OpenHands alone, or both together: the workstation delivered with everything installed and configured; write to us and we suggest the best solution for your tasks and budget.

Keeping clients apart on one machine

A shared workstation holds the work of several clients at once, so separation has to be designed in. The NDA usually decides how strict it must be; the steps below go from the minimum to the strictest.

1. One repository per client project. Dyad stores each app in its own folder, typically ~/dyad-apps/<name>, and each app is a Git repository. Name projects by client, and keep briefs, screenshots and test data inside the project folder, not in a shared download folder.
2. One operating-system account per person. The app folder sits in the user's home directory, so separate accounts give each person their own set of projects, and file permissions decide who can read another person's work.
3. One sandbox per agent task. In its Docker setup, OpenHands runs the agent's commands in a sandbox, so an agent working on one client's code reaches only the folders mounted into it; its README marks the npm launcher as running without a sandbox.
4. Separate caches at the model server. A model server keeps no memory of earlier conversations, but vLLM's prefix caching reuses stored context between requests. vLLM's documentation warns that shared caches allow "timing-based attacks where an adversary could infer cached content by observing latency differences", and offers a cache_salt field per request: only requests with the same salt reuse each other's cache. A small gateway in front of the model can set one salt per client project, as our guide to an LLM gateway with keys and logging describes for keys.
5. A clean end of project. When the NDA asks for return or deletion of materials, delete the project folder, its Git history and any copies in the model server's logs and in backups, and write down the date.

Network access belongs to the same plan. Ollama listens only on 127.0.0.1 by default; when the model moves to a shared machine, its port should be reachable from the studio's network and nowhere else, as our guide to securing a GPU server describes. What the tools send out by themselves is covered in our article on telemetry in self-hosted AI tools.

Handing over the prototype

Because a Dyad app is "just a regular Git repo", in the words of its FAQ, the handover is the repository: pushed to the client's own Git server, or delivered as an archive. Dyad's GitHub integration pushes to GitHub; for a client who uses another Git server, the usual Git commands work on the same folder. Dyad also offers "Copy app without history", which resets the Git history, for when the client should receive the code without the agency's working steps.

Three points belong in the handover note. First, the libraries the builder added keep their own licences, as in any project, so list them. Second, say which tools and models wrote the code, because some clients ask for it and some contracts require it; who owns code written with AI and what a company policy should say about it is covered in our guide to an AI coding assistant policy. Third, a prototype is not a production system: before it handles real customer data it needs the review set out in our article on vibe coding security checks before go-live. Where the app should run afterwards is the client's decision; a local builder produces source code and a preview, and hosting is a separate step.

Which RTX PRO workstation for an agency

Memory decides how many people can build at the same moment. Each person who is working holds one agent session, and each session keeps its context in the key-value cache, the memory where the model stores what it has read. Our users-per-card rule takes 90 per cent of the memory the driver reports and subtracts 3 GiB per card, as our guide to how many users one RTX PRO 6000 serves explains. Qwen3.8-27B keeps its cache in 16 of its 64 layers: by our arithmetic from its configuration, 64 KiB per token in 16-bit, so about 8.1 GiB for a session of 128K tokens and 4.1 GiB for 64K, including a small fixed state.

Our estimates by the users-per-card rule (usable memory 25.7, 61.5, 83.0 and 166.1 GiB), weights from Ollama's qwen3.8 tags (18 GB at 4-bit, 30 GB at 8-bit), 16-bit cache as Ollama keeps it by default; not measurements. An FP8 cache, as vLLM offers it, roughly doubles the session counts.

The entry tier suits one person; the shared machine starts at 72 GB. One RTX PRO 6000 Workstation Edition or Max-Q gives a studio 13 sessions of 64K, enough for about a dozen people building at the same moment by our estimate, or it runs Qwen3-Coder-Next in FP8 (80.4 GB) with five sessions of 64K. Two Max-Q cards at 300 W each give one model copy per card. NVIDIA states up to four Max-Q per workstation; three or four belong only in a chassis built for them with strong directed airflow, and two Workstation Editions at 600 W are the realistic maximum for that edition. Larger agencies with 20 or more developers running agents are better served by a rack server, as our guide to a server for coding agents shows.

Speed depends on the card's memory bandwidth and the size of the weights. By our estimate from the memory bandwidth NVIDIA states and about 28 GB of weights read per token, one request at 8-bit tops out at about 63 tokens per second on a Workstation Edition or Max-Q (1,792 GB/s) and about 56 on a Server Edition; real speeds are lower (StorageReview measured 17 to 22 tokens per second for one request of the NVFP4 build with vLLM), and a test with your own prompts shows what your setup reaches. Whether a model of this size is good enough for your kind of apps is the subject of our article on whether a local model is good enough for vibe coding, and the full kit by tier is in our guide to the vibe coding workstation.

Send us the number of people who build at once and the kind of apps you prototype, and we suggest the card and the setup that fit.

Running the shared workstation in the studio

There are two ways to set this up. In the first, every developer runs Dyad on their own PC and connects it to the shared workstation's model server; the projects stay on each PC and the workstation holds only the model. Dyad finds Ollama on localhost by itself and uses a custom OLLAMA_HOST when one is set, according to its guide to local coding of 4 February 2026. In the second, the projects also live on the workstation, in one account per person, which keeps all client material on one machine that is backed up and deleted in one place.

Set the model's context to at least 64,000 tokens, which Ollama recommends for coding tools in its announcement of 23 January 2026, and run Ollama 0.35.0 or later, which fixes CVE-2026-103663, as our coding-assistant guide records. The setting OLLAMA_NO_CLOUD=1, described in Ollama's FAQ, removes its cloud models and web search, so no client prompt leaves the machine by mistake. Ollama answers one request per model at a time until OLLAMA_NUM_PARALLEL is raised, and each parallel slot adds context memory, as our comparison of vLLM, SGLang, TensorRT-LLM and Ollama shows; when more than a handful of people share the model, vLLM with its cache_salt field is the better server. The move from a single PC to a shared server is described in from Ollama on a PC to a company AI server.

FAQ