What people actually build on cloudlets.

Wrap the SQL estate you already run.

Somewhere in your building is a SQL Server or MySQL database holding decades of operational truth — and no API. Every team that needs that data files a ticket, and the integration backlog is measured in quarters.

A cloudlet points at that database and generates the API around it: full CRUD per table, reporting endpoints for the queries people keep asking for, every route gated by roles, an OpenAPI spec for whatever consumes it. The schema is untouched and the data never moves — the capabilities come to it.

Agents that work your data — without improvising SQL.

An agent that merely talks about your business is a demo. An agent that reads and writes your CRM records, invoices, and orders is a colleague — and the difference is what stands between it and the database.

On a cloudlet, the agent never touches tables directly. Every capability it has is a generated, role-gated endpoint handed to it as an MCP tool, running inside the runtime's capability grants. It can do exactly what you built for it — and structurally nothing else.

From an existing database to a working agent, in minutes.

This is the previous two cases shaking hands, and the most demo-able thing on this site. Connect a cloudlet to a database you already run. Describe, in a few sentences, what an assistant over that data should be able to do. The cloudlet generates the SQL-aware endpoints, gates them, and hands them to any MCP-capable harness as tools.

No migration, no rebuild, no integration project. The schema you already have becomes the toolbox the agent gets — and when the agent needs a capability that doesn't exist yet, you describe that too.

A calculator to the visitor. A lead machine to you.

The screenshot beside this text is a real cloudlet build: a carbon-footprint calculator described during a live client meeting and running the same day. Visitors get a genuinely useful tool — miles driven, flights, diet, home energy in; metric tons out.

The business gets something better. The form asks for a name and an email, and every submission lands in a table on the cloudlet — inputs, results, contact details — that sales can query like any other database. One build, two audiences: a public utility on the surface, a lead-capture instrument underneath.

Swap the CO2 math for a quote estimate, a savings model, or an eligibility check and the anatomy doesn't change. Any calculator your prospects would use is a lead machine wearing a costume.

Internal tools, without the internal-tools team.

Every department has one: the tracker, the mini-CRM, the approval flow that lives in a spreadsheet because it never survived prioritization. The build was always small — a few tables, standard operations, a screen. What killed it was the queue.

On a cloudlet that whole shape — database, full CRUD, the KPI endpoints management actually wants, an auth-gated frontend — comes out of a working session instead of a sprint. And because roles are runtime objects, "support can edit, admins can delete, everyone else reads" is a sentence in the description, not a middleware project.

The ambient layer: jobs on a clock, answers on your site.

Not everything is an app. Nightly syncs, hourly polls, weekly report runs, cleanup jobs, threshold alerts — described in a sentence, scheduled on an interval or a fixed date, and journaled so "what ran at 03:14" is a query rather than a mystery.

And on the public side: a chatbot trained on your own website, embedded with a single snippet, answering from your material — with the same lead-capture instinct as the calculator above. The visitor gets answers; you get a record of who asked what, and how to reach them.