Build internal tools with AI without developers: what works, which model and workstation

Building internal tools with AI when nobody in the firm programs

A company without developers can build its own small internal tools with AI. An office, operations or production manager describes the tool in plain words, an AI app builder writes the code, and the manager checks the result in a preview and corrects it in words. With the open-source app builder Dyad and a language model on a workstation the company owns, the descriptions, the code and the test data stay in the building. A workstation with one NVIDIA RTX PRO 4500 Blackwell (32 GB) is the smallest configuration we recommend for one person; tools that talk to the ERP system, sign in with company accounts or face the internet still need a developer.

Three terms first. An app builder is a program in which you describe an application in a chat, and it writes and runs the code for you; this way of working is often called vibe coding. A model is the AI that writes the code: a large file that runs on a graphics card (GPU) with enough memory. Local means that the model runs on your own hardware instead of in a provider's cloud.

This guide is for the person who would build the tools and for the owner who decides whether to allow it. Our comparison of self-hosted alternatives to Lovable and Bolt covers the app builders themselves.

What a non-programmer can build, and what needs a developer

Dyad's FAQ states that it "only supports JavaScript-based apps at this time", in practice web applications that open in a browser. That covers much everyday office work; the table sorts typical requests.

Dyad FAQ, read 30 October 2026; the sorting is our recommendation.

Turning an Excel list into a web app is the most common first wish. Describe the columns and what the screen should do, attach a few rows of invented sample data, and ask for a form that adds entries and a table that filters them. Use made-up names, not the real customer list, until it is clear where the data will live. The more of the tool's logic you can state as rules ("5 per cent discount above 100 pieces"), the better, because you can check the result against cases you know.

What limits a tool is what it touches. A tool that reads a file and shows it is easy to check. One that several people write to at once needs a database, user rights and backups, and once it holds personal data or connects to other systems, someone with IT responsibility should review it. If the job fits a spreadsheet, our guide to Excel macros and VBA with a local AI is the shorter path; IT teams that want a platform with roles and approvals compare Power Apps alternatives with local AI.

Describe, check, correct and keep versions

Dyad's quickstart describes the loop. You type what you want into the chat, the AI generates the code, you approve it, and the app "will be saved and run on your computer" in a preview next to the chat. The preview runs on Node.js, the program that runs JavaScript outside the browser, and the first preview of an app installs its npm packages, ready-made code building blocks, so the workstation needs internet access for those downloads. When an error appears, Dyad may offer a "Fix with AI" button; otherwise you describe the symptom in words, such as "I don't see anything after I log in", the example its debugging guide gives.

Every change is kept: Dyad's versioning guide states that "Every version in Dyad is essentially a git commit", and restoring an earlier version adds a new commit instead of deleting work. Three habits help:

1. Start with one screen and one task, then add features one request at a time.
2. Test the main flows in the preview after every change, as Dyad's debugging guide recommends.
3. Keep tools small: Dyad's guide to large apps advises splitting an app that grows too big into smaller ones.

What stays in the building with a local model

While you build a tool, the prompts contain your field names, sample records and price rules, and sometimes real customer or employee data that someone pasted in to test. With a cloud model, all of that goes to the model provider. Dyad's privacy policy, last updated on 22 June 2026, puts it plainly: with your own API keys "your prompts and code are sent directly to the model providers", with local models "everything stays on your device", and in both cases "your data never passes through Dyad's servers". Telemetry is collected only with your consent and, by the same policy, "does not include your chat messages, prompts, or code". The same policy says that with Dyad Pro "your prompts and code are proxied through Dyad servers before reaching the model providers", so a setup that keeps everything in the building uses Dyad without Pro, and Ollama with its cloud models and web search switched off (OLLAMA_NO_CLOUD=1, as Ollama's FAQ describes).

Some paths still lead out of the building, and the builder should know them:

• Databases. Dyad's documented integrations for data and login are Supabase and Neon. Supabase server functions run on Supabase's servers, and Dyad's documentation describes Neon as "a serverless, fully-managed Postgres platform". A tool connected to either keeps its data with that provider.
• Publishing. Dyad's publishing guide covers GitHub and Vercel, which hold the code and the running app on their platforms.
• Downloads. npm packages and model files come from the internet, so the workstation needs that access even when the model runs locally.

A local model takes the model provider out of the picture; it does not settle the rest of data protection. Our guide to local AI and the GDPR explains what own hosting solves and what remains the company's duty, and your data-protection officer confirms how personal data may be used in tools built this way.

You can order the workstation alone, the setup of Dyad, Ollama and the model 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.

Which model is good enough for an app builder

Model size decides whether an app builder works at all. Dyad's FAQ says that when the builder fails, "you're likely using a local model which is too small and not smart enough to follow Dyad's instructions". Its blog post of 4 February 2026 adds that "Smaller models (under 7B parameters) often struggle to follow structured output formats", recommends Qwen 2.5 Coder 14B or 32B for the best local results, and states that the best cloud models "are still stronger at complex coding tasks than most models you can run locally".

Models have moved on since that post, and we start from the 27B class (27 billion parameters):

• Qwen3.8-27B, published by Qwen in August 2026 under Apache 2.0, with a context of 262,144 tokens. Ollama lists it as qwen3.8:27b, an 18 GB download in 4-bit (Q4_K_M), and as a 30 GB 8-bit version (q8_0). In Qwen's own table it scores 90.3 on LiveCodeBench v6 against 88.8 for Anthropic's cloud model "Opus4.6 Max", and 73.0 against 78.2 on Terminal Bench 2.1; these are the vendor's figures.
• Qwen3.6-35B-A3B, published in April 2026 under Apache 2.0, a mixture-of-experts model that uses about 3 billion of its 35 billion parameters for each token (a word or part of a word), so it writes faster. Ollama's 4-bit version is a 24 GB download. Qwen's table gives it 1,397 on QwenWebBench, Qwen's test for building web pages, against 1,197 for Gemma4-31B.

Both need a long context, the amount of text the model reads at once: the builder's instructions, your request and the app's code. Ollama's documentation says coding tools "should be set to at least 64000 tokens", while its default on a card with 24 to 48 GiB of memory is 32K. Whether a local model can stand in for cloud services in your case is the subject of our article on whether a local model is good enough for vibe coding.

How many builders one workstation serves

The hardware question comes down to memory: the model and its working memory must fit on the graphics card. We use our users-per-card rule: 90 per cent of the memory the driver reports, less 3 GiB per card, must hold the model plus a cache for each session that works at the same moment. A session of 64,000 tokens with Qwen3.8-27B needs 4.14 GiB of cache with Ollama's default 16-bit cache, by our arithmetic from the model's configuration as in our Qwen hardware guide.

Usable memory by our users-per-card rule: 25.7, 40.0 and 83.0 GiB per card; Ollama download sizes (18 and 30 GB) as listed on ollama.com on 30 October 2026, converted to GiB; 4.14 GiB of cache per 64K session. WS: Workstation Edition (a Max-Q has the same memory), SE: Server Edition. Our estimates, not measurements.

The entry tier in figures: 18 GB is 16.8 GiB, and 25.7 − 16.8 leaves 8.9 GiB, room for two sessions. A workstation with one RTX PRO 4000 Blackwell (24 GB) has 18.5 GiB by the same rule, which leaves 1.7 GiB after the model, too little for one session of 64K; it suits other AI tasks, not this model in an app builder. On the RTX PRO 5000 48 GB, the 8-bit version (27.9 GiB) leaves 12.1 GiB for two sessions, and the 4-bit version room for five. One RTX PRO 6000 Blackwell Workstation Edition with 96 GB holds the 8-bit version with thirteen. In the server tier, one card runs the builder model and the second card a chat model for the whole firm, as our guide to an AI server for a company of 10 to 100 people describes. Our guide to vibe coding workstations by RTX PRO tier compares these kits at 128K context for longer projects.

A session is a builder whose request is being answered at that moment, not a person on the payroll.

Speed is the other half. StorageReview measured Qwen3.8-27B in NVFP4 format with vLLM 0.27.1 in a review of 14 October 2026: with a single request, every card that ran the model, from the RTX PRO 4500 Server Edition and an L40S to an RTX PRO 6000 Workstation Edition, landed between 17 and 22 tokens per second. At that rate, an answer of 1,000 tokens takes about 45 to 60 seconds by our arithmetic. On your system the speed depends on the card's memory bandwidth, the format of the model and the serving software.

By our estimate (the card, a 350 W processor and 15 per cent for the rest) one RTX PRO 4500 draws about 0.6 kW at full load, one RTX PRO 5000 about 0.75 kW and one RTX PRO 6000 Workstation Edition about 1.1 kW, each on an ordinary 230 V office circuit. The two-card server draws about 1.8 kW and belongs in a server room.

Where the finished tool runs and who looks after it

In Dyad's preview, the tool runs only on the builder's computer. Dyad describes the result as "normal code in a folder you keep", so the same code can run on another machine in your network. For colleagues to use it, place it on a machine inside the company network: the workstation with the RTX PRO 6000 Workstation Edition from the larger tier, or the company AI server, can host the finished tools next to the model. Keep them off the internet; a tool that must be reachable from outside goes to a developer and a security review first.

Agree three points before the first tool goes live:

• Who owns it. The person who built the tool owns its content and decides on changes; the IT service provider runs the machine, the backups and access, as in our guide to an AI server without an IT department.
• Which data it may hold. A short rule in the firm's AI usage policy says which tools may store personal data and who checks them.
• A review. Dyad has a security review that uses AI to look for issues. Its documentation calls the feature experimental, says it "may not catch all relevant security issues", and recommends using it together with other security products; our checks before an AI-built app goes live list what else to review.

For one builder or for several on your network, send us the tools you have in mind and we propose the configuration.

Licences of Dyad, Ollama and LM Studio for company use

GitHub repositories and release pages of Dyad and Ollama and LM Studio's app terms, read 30 October 2026.

bolt.diy, another open-source app builder, is in maintenance mode and runs on StackBlitz's WebContainers API, which needs a commercial licence for production use in a for-profit company; our comparison of self-hosted Lovable alternatives covers it. For a company's internal tools, Dyad is the simpler choice.

LM Studio, the alternative to Ollama that Dyad supports, has its own terms: a licence "solely for Your personal and / or internal business purposes", and "Certain features of the Software may be offered for a fee". Our overview of open model licences for company use covers the models.

Notes for the IT service provider

• Use Ollama 0.35.0 or later. CVE-2026-103663, published on 8 October 2026, lets an unauthenticated request to /api/pull write a file outside the model store; it is rated critical (CVSS 9.4) where the Ollama service can write to /usr/lib/ollama, since the file then runs as root after a restart, and 6.9 otherwise.
• Ollama listens on 127.0.0.1:11434 by default, and its FAQ describes no login for the API. For several builders on one GPU, bind it to the internal network with OLLAMA_HOST, keep it behind the firewall, and set the same OLLAMA_HOST for Dyad on each PC, which Dyad then uses instead of localhost.
• Set the context with OLLAMA_CONTEXT_LENGTH=64000 or in the Ollama app, and raise OLLAMA_NUM_PARALLEL for the number of builders; Ollama's FAQ notes that the memory needed grows with both.
• Dyad runs on Windows and Mac, and its FAQ calls Linux support experimental. Node.js must be installed for the preview.

Our guides to securing a GPU server and to moving from Ollama on a PC to a company AI server cover the next steps.

FAQ