Local AI vs cloud AI app builders: cost, privacy and speed

The structural difference

Almost every AI app builder sends your prompt to a model hosted by a third party, gets code back, and bills you for it. That design has consequences that have nothing to do with the quality of the product: every generation costs the vendor money, so every generation is metered. Your prompts, and often the code produced from them, pass through infrastructure you do not control.

Local generation inverts this. The model file is downloaded to the browser cache once and then executed on your own graphics card through WebGPU. The prompt never leaves the machine, and the marginal cost of a generation is your own electricity.

Cost

Cloud generation is metered because it has to be — the vendor pays an API bill for every request. That is why free tiers are small and why heavy use pushes you up through plans.

Local generation has no per-request cost to pass on, which is why it can be offered without a cap. The trade is upfront: a model download of several hundred megabytes to a few gigabytes, and a machine capable of running it.

What the numbers actually are here

Abstract comparisons are easy to write and useless to plan around, so here are the concrete figures on this platform.

• Free — 0 SEK / $0. Five cloud generations per month. Unlimited local generation through WebGPU. No AI features inside the apps you build, and no source code export.
• Premium — 179 SEK / $19 per month. Twenty-five cloud generations, unlimited saved projects, ZIP export, subdomain publishing, and AI features available inside your generated apps.
• Pro — 299 SEK / $29 per month. Fifty cloud generations, the larger local models, Shopify, custom domains, webhooks and Fortnox, and automated SEO audits.

Two things are worth reading twice. Unlimited local generation is unlimited on every plan including Free, which means the monthly number is a cloud budget rather than a usage cap. And "AI inside your apps" is a separate thing from "AI that builds your apps" — window.NorthernGoAI in a generated app is a paid feature and runs through the cloud proxy, so a Free plan user can build unlimited apps locally but cannot ship an app that calls a model at runtime.

Which models actually run locally

The in-browser runtime is @mlc-ai/web-llm, and the models are quantised builds cached in the browser after the first download.

• Qwen 3.5 4B — the default, available on every plan. The one most people will actually use.
• Qwen 3.5 9B, Qwen 2.5 Coder 7B, Llama 3.1 8B and Ministral 3 Reasoning — larger or specialist models on Pro. Qwen 2.5 Coder is the code-tuned one and is usually the best of the set for generating an app.

If you already run models on your own hardware, you can skip the browser runtime entirely and point generation at your own Ollama instance instead. That gives you model choices and quantisations the browser cache cannot hold, at the cost of one genuinely fiddly setup step involving CORS.

The hardware requirement is a real requirement

WebGPU inference is not a graceful-degradation feature. Either the browser supports WebGPU and the GPU has enough memory for the model, or local generation does not run at all.

The 4B model is comfortable on a current laptop with integrated graphics. The 7B to 9B models want a dedicated card with several gigabytes of free video memory, and on anything less they either refuse to load or run slowly enough that a cloud round trip would have been faster. The weights download once per browser profile, not once per project, so a different browser or a cleared cache means downloading again. If you are on metered mobile data, do it before you leave.

For the mechanics of running this in your own code rather than in the builder, see WebGPU and local models in a React app.

Privacy

This is the clearest difference and the hardest to fake. With cloud generation, your prompt is transmitted to and processed by an external provider, whatever the privacy policy says about retention. With local generation, the prompt is processed by your own GPU and no request leaves the browser. For anyone handling client briefs, internal systems or regulated data, that distinction is not a marketing detail — it decides whether the tool can be used at all.

It also changes the paperwork. A cloud provider in your generation path is a processor you have to be able to name; local execution removes that entry from the list rather than shrinking it. If you are building under EU rules, the GDPR checklist for EU founders covers where that fits alongside the data your finished app collects — which is, in practice, the part regulators care about far more.

Speed and quality — the honest part

Local models are smaller than the frontier models running in the cloud, and it shows. A 4B parameter model like Qwen 3.5 4B is genuinely good at self-contained components, simple pages, forms and small games. It is not equivalent to a large cloud model on complex multi-file logic, and any comparison that claims otherwise is selling something.

Latency runs the other way. Once the model is loaded there is no network round trip, so responses start immediately and continue working when the connection does not.

Where the quality gap shows up in practice

Knowing that small models are worse is less useful than knowing how they are worse. Generated apps here are a single monolithic HTML document — all the markup, all the styling and all the logic in one file — which puts a specific kind of pressure on a small model. Four failure modes recur.

Length. A long document is a long generation, and small models drift or truncate before they finish. A four-view app is where the 4B model starts producing a beautiful first screen and an unfinished third one.

Cross-cutting state. Anything where a change in one view has to be reflected in two others is reasoning across distance, and that is exactly what parameter count buys.

Contract adherence. The platform SDK is injected into the app and must only ever be called, never reimplemented. Small models are noticeably more likely to helpfully write their own window.NorthernGoDB wrapper with fetch instead of using the one that is already there, which produces an app that looks right and saves nothing.

Long instructions. The system rules that keep generated apps consistent are long. A frontier model holds all of them; a 4B model honours the first few and forgets the rest.

None of this makes local generation useless. It makes it a good tool for a bounded task and a poor one for an ambitious first draft.

The agents are not the same on every engine

The cloud path uses three specialised roles: an Architect that plans the structure, a Builder that writes the code, and a Critic that can attempt a repair of mechanical damage. That review does not add reasoning the Builder never did.

Locally the Builder runs on your GPU. A short Architect follow-up question can also run locally. On Premium or Pro, a new local build may still ask the cloud for a structure sketch when you are online (skipped offline, on Free, and on updates). There is no LLM Critic rewrite on the local path — a syntax check blocks JavaScript that will not parse; it does not repair logic. A broken small-model app stays a small-model app.

What is identical no matter which engine you use

This is the part that makes the choice low-stakes, and it is worth stating plainly because it is unusual.

The output is the same shape either way. The same single HTML document, the same vanilla JavaScript, the same Tailwind CDN, and the same injected SDK — window.NorthernGoDB for the built-in Supabase database and login, window.NorthernGo for e-mail and CSV or Word export, and the same publishing and export paths. There is no local-only file format and no cloud-only project type.

So the engine is a per-generation decision, not an architectural one. You can start a project with the local model, switch to cloud for one hard step, and switch back, and nothing about the project has to be migrated. That also means the engine choice has no bearing on whether you can leave with your code, which is a different question and a more important one.

A workflow that uses both properly

The pattern that wastes the least is roughly this. Do the first structural pass in the cloud, where the reasoning quality earns its cost, and get an architecture you are happy with. Then iterate locally for everything cosmetic and incremental — copy, colours, an extra field, a new card — because those are exactly the bounded tasks a small model handles well and exactly the changes you make thirty times. Go back to the cloud only for the next genuinely structural change.

There are also a few things the cloud is simply required for. Image generation and image analysis run through the cloud regardless of which engine you generate code with, and so does document upload. If your app needs a generated hero image, that is a cloud call whatever your build preference.

How to choose

The useful framing is not which is better but which fits the task. Use local generation for iterating quickly, for anything involving sensitive input, for unlimited experimentation, and for working offline. Use cloud generation when you need maximum reasoning quality on a complex build. A platform that offers both lets you decide per task instead of being locked into one trade-off.