Your application is data. A change is a write, and it’s live on the next request — at month one and at month thirty.
Your code runs the instant you write it, straight from the database. While their pipeline is still deploying, you’re already live.
No build. No pipeline.
This space is empty on purpose.
A typical enterprise pipeline takes 18 minutes. We don’t have one.
The platform in three layers
Nothing is compiled, nothing is bundled, nothing is shipped. A save is live on the very next request, because a request resolves the code it needs at call time. Deployless, in the literal sense: nothing stands between writing a change and running it. It works because page code and Python are rows in the database, and every save is an insert rather than an overwrite, so the version you replaced is still there. How the runtime works.
An MCP server sits on that runtime. An assistant you already use connects to your tenant and reads what exists, writes a new frame, or edits one function of one that already runs. It is changing the live application, not producing a candidate for a build. How that works.
One key names one tenant and cannot be pointed at another. Every write goes through a single validated entry point. Every edit previews its exact byte delta first. Production is unreachable from the connector, and promotion is one gated path. Security and isolation.
The order matters. Take the assistant away and the platform still stands, because the runtime was finished before any model was aimed at it. Take the runtime away and there is nothing for an assistant to write into except files, a repository, and a pipeline — which is what every other platform is quietly still doing underneath its own connector.
Model Context Protocol
Frames Studio exposes an MCP connector. Claude can create a new frame, register it on the desktop, and edit one that already exists — writing directly into your tenant’s database. There is nothing to rebuild, so the change is there the next time the frame is launched. It works by voice, from a phone, with no keyboard involved.
“Add a field to the equipment log for the technician who signed it off, and show it on the list.”
That needs a column on the table and a change to the component that renders the list. Writing both now.
ALTER TABLE ridgeline_hvac_equipment_log
ADD signed_off_by NVARCHAR(120) NULL;
INSERT INTO code_repository
(codename, codetype, tenantid, codetext)
VALUES
('equipmentlog', 'schemacode', 'ridgeline_hvac', @ddl),
('equipmentlog', 'componentcode', 'ridgeline_hvac', @html);Two rows inserted. Neither overwrote anything — the previous versions are still queryable.
equipmentlog renders the new column on next launch. No build ran. Nothing deployed.
The request was one sentence and sounded like a label change. Underneath it: a schema migration, a new versioned schema row, a rewritten component, and a live UI. On a conventional stack that is four artifacts, a migration review, and a pipeline run. Here it is four writes — and a write costs the same whether the change is cosmetic or structural. That is the part worth noticing.
The desktop shell, the windows, the launch surface, tenancy, schema and hosting are already there. Code lives in the database and executes at runtime, so nothing compiles and nothing ships — every iteration skips the step everyone else pays for.
Real Python, real HTML, real JavaScript, any CDN, any library, your own code. You get the speed of a low-code tool without the ceiling that comes with one.
Export everything at any time. Stand it up on your own Flask instance and walk away. Every save is an insert, never an overwrite, so every version you have ever had is still there and going back is a read.
Today, Frames Studio is a web application platform for form-based, API-connected business applications — the low-code sweet spot, written in real code. Python microservices on the same runtime are next on the roadmap.
Read this before you pattern-match
A new development platform gets sorted into a familiar bucket in about four seconds. Frames Studio does not belong in any of the three it gets thrown into most often — and the reason it does not is the entire argument.
Those tools write you a codebase and hand over the keys. You still own the repo, the dependency tree, the build config, the pipeline, and every line you did not write. Frames Studio hands you no repo, because there is nothing to compile. AI writes straight into a runtime that is already executing.
Drag-and-drop platforms trade capability for a fast start. You move quickly until you reach the edge of what the component library permits, then you file a feature request or rewrite it outside the tool. Here you write real HTML, real CSS, real JavaScript, real Python. There is no ceiling to climb out of, because there was never a box.
The industry spent fifteen years shortening the build: better bundlers, warmer caches, parallel CI. That work made the pipeline quicker. Frames Studio removes the pipeline. An edit is a row in a table, live on the very next request.
What it is instead
Everything Frames Studio gets compared to begins with the stack already standing. Those tools take the toolchain as a fact of life and compete on what sits above it — a better editor, a faster deploy, a component library, a model that writes the files for you. We went the other direction. Down past the framework, past the build system, down to the moment a request arrives. Then we built back up from there.
So there is no toolchain. Not a shorter one, not a managed one. No package manager, no bundler, no transpiler, no build artifact, no image to push, no registry, no pipeline, no release. None of that was optimized away. It was never introduced.
What stands in its place is smaller than what it replaced. Application code is rows in a database, addressed by codename, resolved and dispatched through a single endpoint at request time. Every other property falls out of that one decision: complete version history on every save, because writing is an insert and never an overwrite. Per-tenant overrides that fall back to a platform default. A production site that is also the development site.
AI has a real job here, and it is not the headline. It writes components into a runtime that worked before any model was ever aimed at it. Take the AI away and the platform still stands. That is the difference between a foundation and a trinket.
Judge it on the runtime, not the category.
The Runtime
Everything an application is made of — every backend function, every UI component, every window definition, every table schema — lives as a text row in one table called code_repository. There is no compile step. There is no build. The row is the running code.
This is the actual DB Explorer that ships inside every Frames Studio tenant. Same admin toolbar. Same table list. Same grid. Click Refresh and the rows re-fetch — because that’s all a query is.
A tenant defines a table by writing a schemacode row. The runtime materializes it on first access. There is no admin. No migration ticket. No DBA queue.
The tables you see here don’t exist until a tenant writes them. The {TABLE:invoices} macro is prefixed with the tenant ID at query time, so every tenant lives in its own logical database inside one physical one. Adding a table is one row in code_repository — not a schema migration, not an ops ticket, not a deployment.
When a request comes in, the runtime SELECTs the row and executes its text directly. The moment you save, the next request runs the new code.
INSERT INTO code_repository (codename, codetype, tenantid, codetext) VALUES ('Invoices', 'pythoncode', 'acme_ltd', 'class Invoices: …');
SELECT TOP 1 codetext FROM code_repository WHERE codename = 'Invoices' AND codetype = 'pythoncode' AND tenantid = 'acme_ltd' ORDER BY createdat DESC;
# Python: exec(codetext, namespace) cls = namespace['Invoices'] cls().execute(conn, req) // JS component: globalEval(scriptText);
TIME FROM SAVE TO LIVE
One database round-trip.
No npm install. No docker build. No CI queue. No blue-green cutover. No cache invalidation. The next request through the door is running your new code.
Ship when you’re ready. Not when the pipeline allows.
This is the mechanic every claim on this page rests on. If you want the deeper walk through the dispatcher, the tenant precedence rule, and the auth model, the platform page has it.
See the platform architecture →The Thesis — in 42 seconds
Recorded this morning · 18 minutes · Unedited
Most platform demos show the happy path. This one does not. It opens with a schema change going out to production, runs into a genuine deployment error, and works through finding and fixing it from inside the browser. Then it goes on to generate a working contact form end to end, with no compile step and without opening a second tool.
Deploy Manager previews the DDL and asks for approval before anything touches the production database.
A real error, left in. The generated statement carried the schema name twice, and production refused it.
Claude and the in-browser SQL runner locate the offending statement, read it straight out of the database, and correct it. No local checkout, no redeploy cycle.
Model definitions and their relationships live in SQL Server as indexed columns alongside JSON, read back with OPENJSON.
The AI Component Builder writes the HTML, the Python, and the frame configuration together, because all three are rows addressed by the same codename.
It pulls from the connected table on the next request. Nothing compiled, nothing bundled, no tab ever left open behind it.
Deep dive · 14 minutes
The session above passes through the Architect on its way to somewhere else. This one stays there. It is the tool where a model gets defined once — its fields, its relationships, the shape of the thing — and where that definition is stored as data in SQL Server rather than scattered across migration files, model classes, and form markup that have to be kept in agreement by hand.
What one definition turns into
A single codename addresses up to four rows. Define the model, and these are the artifacts that carry it — each one a row, each one editable on its own.
schemacode
The DDL. Tables and indexes, written with macros so the same definition lands correctly per tenant.
pythoncode
The backend. The class or function that reads and writes the model, dispatched by name at request time.
componentcode
The interface. HTML, CSS, and JavaScript for the screens that operate on the model.
framecode
The window. Title, dimensions, and icon — how the thing presents itself on the desktop.
Nothing here is generated once and then owned by you forever. Change the definition and the pieces are regenerated; change a piece and it stays changed, because it is just a row.
A Different Paradigm
The Informational Web
Marketing pages. Documentation. Blogs. Content that people read, browse, and navigate.
Scroll-based. Link-driven. Designed to inform.
This page you're reading right now is an informational website. It should be.
Productive Software
The tools people work in every day. Code editors. Project managers. Design tools. The applications where work actually gets done.
Window-based. Task-driven. Designed for productivity.
Frames Studio chose the interface paradigm that 4 billion computer users already understand.
The objection we hear most is "it looks too different from a website." That's the point. It's not a website. It's a workspace. And it uses the most familiar interface in computing — the one you've been using since you first touched a computer.
Security and Governance
It is the right question to ask about a platform where a spoken request can change a schema. The answer is that the conversational path and the production path are not the same path, and only one of them has a gate on it.
It writes to development only. There is no credential, route, or flag exposed to the connector that targets a production tenant. An agent can be as wrong as it likes and the blast radius is your dev desktop.
Deploy Manager in DevTools is the only route from development to production, and it carries code, schema, desktop shortcuts, and users together as a single unit. You do not promote a component and discover its table did not come with it.
Every structural change renders the exact statements it intends to run against production and waits. Nothing executes until someone reads it and approves it. The approval is a human action, not a config setting.
A save is an insert. The row that was live a minute ago is still there, still queryable, still loadable. Full history is a query, and so is rollback. There is no state you can reach that you cannot read your way back out of.
Deploy Manager is usually described as a convenience, and it is one. But its real job is to be the only door.
How We Compare
Cloud IDEs and AI assistants made the old stack faster, smaller, or more portable. Frames Studio made it unnecessary.
Market Map
Cloud IDEs sit on the right (heavy toolchain). AI code-gen tools sit on the left (lighter toolchain, but still emit code). Frames Studio is the only point where AI emits frames, not files — with no toolchain to maintain.
Feature Matrix
| Replit | Codespaces | Cursor | Frames Studio | |
|---|---|---|---|---|
| Toolchain | Cloud-hosted | Cloud VM | Local + AI | None |
| AI output | Code files | Code files | Code files | Frames (executable intent) |
| Versioning | Git on files | Git on files | Git on files | Immutable versioned rows |
| Cold-start | Container boot | VM boot | Instant (local) | Instant |
| Multi-tenant | One workspace / user | One VM / user | Local only | Tenant-aware by design |
| Onboarding | Account + setup | GitHub + container | Install + license | Open a browser |
Each row reflects an architectural decision, not a marketing claim. Frames Studio is the only column where the answer is structural — not just faster, but different.
Replit moved the toolchain to the cloud.
We removed it.
Cursor generates code that runs on your toolchain.
We generate frames that need no toolchain at all.
StackBlitz recreated Node in WASM to fit it in your browser.
We deleted the part that needed Node.
The Experience
No installation. No setup. No learning curve.
That's the entire installation process. No downloads. No installers. No system requirements beyond a web browser.
A familiar desktop environment greets you. Taskbar at the bottom. Toolbar on the right. Desktop shortcuts. You already know how this works — you've been using it your whole life.
Click Launch. Code Manager and Deploy Manager sit at the top, and underneath them are the tools you built. Test Manager, Job Inspector, Gen AI, Architect — all made on the platform, all opened the same way. Nothing marks yours as second-class.
Write HTML, CSS, JavaScript, and Python in a unified editor. Or describe what you need and let AI build it — Claude, ChatGPT, Grok, and Gemini are built right in.
Open multiple tools at once. Drag them, resize them, stack them. Here Contact Manager is running in front of its own source in Code Manager — the component on the left, the working app on top of it. The taskbar tracks everything.
Click "Push to Prod." The platform compares versions and transfers only what changed. No CI/CD. No build process. No waiting. Your code is running.
That's the entire installation process. No downloads. No installers. No system requirements beyond a web browser.
A familiar desktop environment greets you. Taskbar at the bottom. Toolbar on the right. Desktop shortcuts. You already know how this works.
Click Launch. Code Manager and Deploy Manager sit at the top, and underneath them are the tools you built — opened exactly the same way.
Write HTML, CSS, JavaScript, and Python in a unified editor. Or describe what you need and let AI build it.
Open multiple tools at once. Here Contact Manager runs in front of its own source in Code Manager.
Click "Push to Prod." The platform compares versions and transfers only what changed. Your code is running.
Familiar by Design
Double-click to open. Drag to rearrange. The same desktop you've used since Windows 95.
Drag, resize, minimize, close. Real windows, not tabs or panels.
Light or dark theme. Six accent colors. Compact mode. Your workspace, your preferences.
The Development Lifecycle
Every stage of building a component happens inside Frames Studio. No context switching. No environment drift. No pipeline to configure.
Launch the Frame Designer from the desktop. Choose a blank canvas or start from a component template.
Drag panels, set layouts, and define your component structure visually — or write HTML/CSS directly in the same view.
Describe what you need. The AI generates the initial component markup and wires it to your data schema.
Write HTML5, CSS3, JavaScript, and Python in the built-in editor. Code lives in the database — no files, no folders, no npm install.
Connect your component directly to data. Query, bind, and preview live data without switching to another tool.
Changes render instantly in the adjacent frame. What you see is exactly what ships — no build step, no hot reload config.
Run unit tests, component tests, and SQL validation tests directly inside Frames Studio. Tests are frames — not external config files.
Inspect state, step through execution, and view logs in a dedicated debug frame alongside your component — no browser DevTools required.
Verify your component behaves identically across dev, staging, and production — without ever leaving the platform.
Promote your component from dev to staging to production with a single click. The code is already in the database — no pipeline runs.
There are no pipelines to trigger, no YAML to write, no deployment tokens to rotate. Promotion is a database operation.
Every change is versioned in the database. Roll back to any prior state instantly — without Git, without a revert commit.
Code Manager
Open the Code Manager and start writing. HTML, Python, configurations, and static files — all in one place. Every component is a codename. Every save creates an automatic version. No file system to navigate. No directory structures to maintain. Just write, save, and see your changes immediately.
AI Component Builder
Type a description — "Create a contact form with validation" — and choose your AI model. Claude, ChatGPT, Grok, or Gemini generates the complete component: HTML frontend, Python backend, and configuration. Review it, save it, and it's part of your application. Start from templates or describe something entirely custom.
Deploy Manager
The Deploy Manager shows you exactly what changed between dev and prod — every codename, every schema, side by side. Select what to promote, click one button, only the changes transfer. When your new components need a new table or column, Deploy Manager previews the DDL, waits for your approval, then runs it in prod. No migration scripts to write. No pipeline to configure. No deploy window to schedule.
DB Explorer
Browse tables, inspect schemas, run queries, insert rows — all from within your development environment. No need for Azure Data Studio, SSMS, or a separate database client. The DB Explorer shows every table with row counts, supports Data, Schema, and Query views, and even allows creating new tables. Your entire data layer is visible and manageable from the same platform you build on.
Debug Tools
The Debug Tools give you complete visibility into your running application. The Event Log streams every FramesEvents bus emission with timestamps and payloads. The State Inspector shows open frames, authentication status, and event bus health. The API Tester lets you call any Python method directly. The Component Registry lists every registered component.
The Desktop
This isn't a tabbed interface or a single-pane editor. It's a real multi-window desktop running in your browser. Open Code Manager, AI Builder, and Deploy Manager simultaneously. Drag them where you want. The taskbar shows every open frame. A launch menu organizes tools by category. Light and dark themes with six accent colors let you work the way you prefer.
One Codebase
There is no separate development environment to spin up. No local Docker stack. No staging clone that drifts from prod. Every user hits the same site — what they see is decided by whether they're an admin. Admins get the toolbar. Everyone else gets the app.
A Different Premise
HTML5 has been fundamentally stable since 2010. Sixteen years. Same HTML5. Same CSS3. Same JavaScript. Enhanced, not replaced. The browser platform is the most stable runtime in the history of computing.
Frames Studio bets on that stability. Instead of wrapping web technologies in framework abstractions that break every 18 months, Frames Studio uses them directly. HTML5, CSS3, and JavaScript on the front end. Python on the back end. That's the entire stack.
The platform itself ships no dependency tree, so there is no framework churn underneath your application. Pulling in a library or a CDN is still your call — the difference is that nothing you did not choose is sitting under your code, revving on its own schedule.
And because we run the runtime, keeping it current is our responsibility. Runtime upgrades happen on our side of the line, not as work your application has to absorb.
16 years. Same HTML5. Same CSS3. Same JavaScript. Enhanced, not replaced.
No Angular 15 → 16 → 17. No React class → hooks → server components. No npm vulnerability alerts. The technology stack is stable by design — not by accident.
For Professional Developers
For Developers
Write elegant HTML, JavaScript, CSS, and Python. Express functionality directly without configuring your environment, managing dependencies, or waiting for builds. Get immediate feedback on your changes. Focus on craft, not infrastructure.
This is not low-code. This is not drag-and-drop. This is real code, written by real developers, running directly on the platform.
For Product Owners & Teams
Work directly alongside developers in the same platform. See changes immediately — not after a sprint cycle. Remove the communication layers — the Jira tickets, the sprint ceremonies, the handoff documents — that sit between a requirement and working software.
When a developer writes code, it's live. When you need a change, it happens now.
One Number
This is not a savings model. It counts one thing: the minutes between pushing a change and that change being live, multiplied by how often your team does it. Every input is yours — nothing here comes from an industry average.
Engineer-hours per year spent waiting
780
hours your team spends watching a pipeline run
The arithmetic, in full
10 devs × 5 deploys/wk × 18 min × 52 wks ÷ 60 = 780 hours
This counts pipeline wait time only — the minutes between pushing a change and that change being live. It excludes tool licensing, DevOps staffing, onboarding, incident response, framework upgrades, and every other cost. It is not a total cost of ownership figure and it is not a savings estimate. Frames Studio has no pipeline, so this particular time is not spent. That is the only claim being made here.
Assumes a 52-week year and 2,080 hours per full-time year. Read the Zero-Toolchain Development thesis →
White Paper
The Zero-Toolchain Development thesis in full — the runtime architecture, how code and schema are stored and dispatched, and a competitive analysis against Vercel, Retool, and OutSystems.
See It for Yourself
This isn't a sandbox with fake data and limited features. Once your access is open, you get a full Frames Studio environment — your own tenant, your own desktop, your own workspace. In 30 minutes, you'll have a working component you can show your team, your boss, or your next client.
No install. No config. No "setting up your environment" step. Open your browser, create your account, and you're looking at your desktop. The launch menu, the taskbar, the multi-window layout — it works the way a computer should.
Open the Frame Designer and start building. Use the AI Component Builder to scaffold something real — a dashboard widget, a data form, a reporting panel — or start from scratch with HTML, CSS, and JavaScript.
Open the DB Explorer alongside your frame. Connect to a database, write a query, and bind it to your component. No API layer to build. No ORM to configure. Just data flowing into your UI.
Run your tests in the Test Manager frame. When they pass, open Deploy Manager and promote to production. One click. No pipeline. No YAML. No waiting.
You now have a working, deployed component. Show it to your team lead to prove the concept. Demo it to a client as a rapid prototype. Send the link to a friend and say, "I built this in half an hour."
The Starter tier is free. Build, test, and deploy up to three projects before you ever think about paying.
Everything runs in the browser. No dependencies. No Node versions. No Docker. Open a tab, start building.
If you can build a web page, you can use Frames Studio. The learning curve is the one you already climbed — using a computer.
You won't leave with a "hello world" demo. You'll leave with a real, working component connected to real data. Something worth showing off.
An open question
Frames Studio began as a way to build database-driven applications without the ceremony stacked around them. It kept going from there. The question we keep coming back to is what else belongs on a runtime where code is data and a change is live on the next request. Six places we would start — and we would rather hear yours.
Line of business
The Access file, the shared spreadsheet, the internal app nobody wants to touch because the person who wrote it left. Real tables, real forms, real reports, without standing up a stack around them first.
Markets
Position monitors, trade blotters, portfolio dashboards, reconciliation screens. The kind of tooling where the requirement changes mid-session and waiting on a release window is the actual bottleneck.
Logistics
Rate quotes, label generation, and tracking against FedEx, UPS, Amazon, and whichever carrier gets added next quarter. Each one is a Python row and a component row, not a new service to operate.
Multi-tenant
Every client gets their own tenant. Override a single component for one of them and the rest keep falling back to the platform default. No forks, no per-client branches to keep in step.
Internal tools
An extra column, a corrected label, one more filter on a report. Work that is trivial to write and expensive to ship, so it sits in a backlog for a quarter instead of taking four minutes.
Environments
Development environments themselves: editors, runners, schema tools, deployment surfaces. The admin toolbar on this platform was built the same way everything else is, which is the honest test of the idea.
The pace here is not really about the models. It comes from removing the steps between writing something and running it: no build, no bundle, no pipeline, no release window. That shifts what is worth attempting at all — and that part we cannot map on our own.
Send us your use case →Opens your email app with a short prompt already written. We read every one.
Nothing opened? Your browser has no mail app registered. Compose it in Gmail, or copy
Tell us what you would point it at. We open environments in small batches and read every request.
You get your own tenant and your own desktop — not a sandbox with fake data.