The Backlit manifesto

The operating system for your back office.

Backlit is an SDK, a protocol, and a collection of building blocks for creating admin panels and internal apps. It exists because the software that runs your business deserves better than being rebuilt from scratch every single time, or trapped inside someone else’s platform.

Your back office deserves better

Every application has a second application hiding behind it. It’s where someone looks up the customer, issues the refund, retries the stuck job, approves the payout. Your customers never see it. Your business can’t get through a day without it.

And it gets built last, in a hurry, again and again. The same tables, the same filters, the same forms, the same API behind them.

There have been two ways to get it built. You build it yourself, and you’ve signed up for a second application to write and maintain forever. Or you hand it to a low-code platform, where you can only build what the platform allows, the bill grows with every person you hire, and the thing you built isn’t code you own.

Spend your engineers, or give up your back office. For years that was the whole menu.

Low-code was built for a world without agents

Low-code rests on one assumption: code is expensive, and the people who can write it are scarce. So you draw your software instead of writing it.

That assumption is dying in front of us. The person who would have dragged boxes onto a canvas last year can sit down with a coding agent today and produce real software, in a real repository, with real version control. Engineering-first companies already work this way. Larger, slower companies will get there too.

Low-code platforms have noticed this, and their answer is to add an AI assistant to the canvas. It doesn’t fix the problem. The assistant can only build what the canvas allows, so you keep the same limits with a chat box on top. And it is never the agent you would have picked.

The coding agents you use every day for other work, get better every month, and you can’t bring any of them into someone else’s editor. You get the one the vendor built.

Code was always the most expressive way to build software. Now everyone has a collaborator who can write it. We are not going back to canvases.

Agents need a foundation and guardrails

So should the agent build the whole back office from scratch? It can. It will be slower than it looks, and far more dangerous.

Dangerous, because vibe-coded software is not safe by default. Veracode tested more than 100 models in 2026, and roughly 44% of their coding tasks came back with a security vulnerability. The best model still failed nearly one task in three. A scan of over a thousand vibe-coded apps found security flaws in 98% of them. An admin panel is the worst place for that. It is the most privileged software your company runs. It reads every customer record and it can move money.

Slow, because every app starts over. The agent regenerates the API, the frontend, and the wiring between them, making hundreds of small decisions along the way, and somebody has to read all of it. Six months and two agents later, screen thirty looks nothing like screen one.

So embrace the agent, and give it an intentional foundation to build on. On top of Backlit, a new screen is a short description of your business, not another copy of the plumbing. The agent has less to write and fewer decisions to get wrong. You have little enough to read that you will actually read it.

That is what a foundation buys you: speed, safety, and consistency in every direction.

Built for complex apps, not just the basics

Admin panel tools have always aimed for a small footprint. A handful of concepts and a short API, something a developer could learn in an afternoon. That was the right call when people wrote every line, because every extra option was one more thing to learn and remember.

It also put a ceiling on them. They covered the basic flows, list a record, view it, edit it, delete it, and ran out the day you needed anything more.

That constraint is gone. Agents write the code now, and an agent doesn’t mind a large API. It reads the whole reference in seconds. So we are not optimizing Backlit for a small footprint. We are optimizing it for expressive power: enough to describe a real operational app, with its multi-step actions, conditional forms, lookups, and dashboards.

And when even that isn’t enough, you write custom frontend code, call a regular API, or package the work as an extension. Those exits are part of the design. A foundation with strong opinions is a gift. A foundation you can’t step outside of is a trap.

Better with every package

Imagine a future where pulling in a library from npm also brings the views, actions, and workflows to operate it, ready to plug into Backlit. You install a queue, and its jobs page is already in your admin panel, with retry and cancel wired up. That is the future we are building toward, and the protocol-first approach is the foundation for it.

An operating system gives everyone one target to build for. It defines how a window opens, how a button behaves, and how a program gets installed. Backlit is that target for the back office, and anyone can contribute operational flows to it.

The protocol is JSON, so nobody ships bespoke JSX, CSS, or frontend assets. A package describes its interface as data, and Backlit renders it.

TypeScript is the first SDK. Multiplying this across languages and ecosystems is what will create true network effects.

Build for operators too

Backlit is not only for engineers. It is for operators too, because operators are the ones building these apps. The tools that run operations, support, data, and finance are mostly built by the people who work there.

Operators are technical. They write SQL, they know what an API is, and with a coding agent beside them they are more capable than they have ever been. The tools made for them assume the opposite. They lock operators into a rigid system and have them drag boxes onto a canvas.

We give them a foundation instead. On Backlit there is no API to design and no interface to build from scratch. An operator describes the data and the screens, and an internal app ships in hours, not days or weeks.

Operate, monitor, and manage

Building is half of it. An app that runs on someone’s laptop still has to be deployed, and that is where engineering gets pulled back in. Somebody has to find it a place to run, put a login in front of it, decide who can open it, and notice when it breaks. The tool was built in an afternoon, and it waits weeks to go live.

We recognize this pain, and Backlit will not stop at building. A company will deploy the Backlit control plane once. After that, every team builds its internal apps and gets them live the same afternoon. Who can open each app, what is running, and what is failing are all in one place, and engineering is not involved at every step.

This part of Backlit is ahead of us, and we are committed to it.

Come build with us

If this future excites you, or you like where Backlit is heading, come join us on Discord. Tell us what you’re building, tell us what’s missing, and argue with us about any of the above.

Welcome to Backlit.