Anyone who has built the software side of a connected product knows the integration job. The device keeps its readings and settings in one format and the gateway or cloud service wants those same values as rows in a SQL database. Somebody writes a converter. Then somebody has to keep that converter alive for as long as the device stays in the field, which for industrial equipment or embedded systems can easily be ten years. The converter has to handle offline periods, retries, out-of-order updates, and the device’s own data format changing over time.

Most sites run a thin slice of nginx in front of their application: TLS termination, serving static files from a folder, a couple of routes to a backend service, health checks, and the occasional reload. The configuration grows anyway, one regular expression at a time, until nobody is quite sure which block handles a given URL, and a change that looks safe to one person breaks something in production that another person didn’t know existed.

Most dashboards ask the same few questions all day long: requests per endpoint, month-to-date usage for one customer, error rates by status code. The usual setup recounts raw rows from scratch on every refresh, or ships every row to a hosted analytics service that bills by the gigabyte. A dashboard that needs to answer quickly on demand either waits for a database query to finish, or pays for a service that stores everything.

Cloud coding agents start each task on a fresh machine. Before the agent can run a single test, something has to install the right runtime, start a database, configure environment variables, and download dependencies. Every platform that runs agents wants those instructions in its own file: Copilot expects a setup workflow, Cursor builds a Dockerfile, other platforms want shell scripts or configuration in other formats. A team that uses two or three agents writes the same setup two or three times, and mistakes usually show up later as an agent session that stalls because a database port wasn’t open or a runtime was the wrong version.

A coding agent spends its day reading text written by strangers: issues on your issue tracker, snippets pasted into prompts, code from repositories, instructions on web pages. One malicious instruction planted in that text can be enough to make an agent send a deploy token somewhere it shouldn’t. On a machine-wide VPN, that request leaves the same way as everything else, and afterwards nobody can say which program sent it.

Cloudflare shipped Worker Previews today, and the headline is easy to state. Every git branch gets its own running Worker, with its own URL, its own config, its own logs, its own traces. You run npx wrangler preview, and the branch you’re sitting on becomes something you can open in a browser and click through. Cloudflare says you can run hundreds of them side by side without them touching each other or production.

Every app idea has a boring 90% and a nasty 10%. The boring part is CRUD, auth, a settings page, Stripe. The nasty part is the one subsystem that decides whether the thing works at all, and it’s usually not the part that looks hard in the pitch. Below are nine builds worth attempting, with the nasty 10% named up front so you can decide whether you want to spend your weekends there.

A team spends three weeks rewriting a hot loop in Rust bindings, shaves forty milliseconds off a function that runs once per request, and ships it. The page still takes four seconds to load. Nobody profiled first. That’s the pattern behind most performance work that goes nowhere: real effort, wrong target.

Optimization only pays off when you know where the time actually goes, and that’s rarely where intuition points. Developers tend to suspect their own code, because that’s the part they wrote and the part they can picture running slowly. The database, the network, the third-party API call buried in a middleware layer — those stay invisible until you measure them.

The AI app builder market is usually ranked as a single leaderboard, which is the wrong shape for it. These tools are not competing for the same job. Sorting them by what they actually produce, and for whom, gives a far more useful picture than any overall score.

Prompt-to-app and full-stack MVPs

These convert natural language into working full-stack applications or rapidly scaffolded prototypes.

Lovable. Built for non-developers, product managers and founders who want fast SaaS prototyping. It generates clean React and Tailwind frontend code paired with built-in Supabase backend infrastructure, authentication and continuous GitHub sync.

Every one of these platforms will take a sentence and hand you a running application. That part is settled, and it works. What separates them is everything that happens afterwards: what the bill looks like in month three, whether you can take the code somewhere else, and whether the app is open to the internet by default.

They also get lumped into one category when they belong in three. Hosted prompt-to-app builders (Lovable, Base44, Bolt, Replit) generate and host the whole thing. UI-first generators like v0 hand you code and leave hosting to you. Editor and terminal agents such as Cursor and Claude Code sit inside a real repository and assume you can read the output. Security researchers draw the line in the same place, and for a reason: the editor tools require a human to review code before it ships, while the builders generate, execute and deploy with almost no oversight in between.