Built out of
real deployments.

The problem, concretely

Put a touchscreen on a counter and ask it to do one job. On paper it's a small piece of software. In practice you sign up for a second, larger job: installing an operating system on every unit, keeping the application running unattended for years, updating it without visiting, working out what went wrong when it stops, and stopping the customer from wandering into a browser.

The usual answers are all uncomfortable. Ship a full desktop browser in kiosk mode and you get a general-purpose computer pretending to be an appliance. Ship Electron and every device carries a private Chromium build that a Celeron with 4 GB of RAM does not enjoy. Write it native and you throw away the interface skills your team already has. Whichever you pick, you still end up hand-writing provisioning scripts, an update mechanism and a support tool — and doing it again for the next product.

What kept happening

The same components got rebuilt on project after project. A way to get code onto a machine without leaving it readable. A way to keep working when the broadband dropped. A way to find out what a screen three hundred miles away was showing. A way to push a fix to forty devices without forty phone calls. None of it was the interesting part of any project, and all of it was where the time went.

ArdaPlayer came first — a small Go runtime that renders through the WebKit already on the system, loads an encrypted application bundle and exposes a narrow bridge to the hardware. It went onto real tills. Then it needed updating remotely, so it grew a control channel. Then it needed supporting, so that grew a console, a screenshot command and a tunnel for a shell. Then it needed telemetry, because "it's broken" is not a bug report.

At some point the collection stopped being scaffolding around one product and started being a platform that other products could stand on. That's ArdaForm.

What we're deliberately not building

ArdaForm is not a UI framework. It has no components, no opinions about your state management and no preference between React, Svelte and hand-written DOM. The runtime loads whatever your build produces. That boundary is on purpose: front-end fashion changes every three years, and a device you sold has to keep working for ten.

It's not a no-code builder either. The name refers to giving hardware a form and a purpose, not to building forms. If you want to drag boxes around a canvas, this is the wrong tool.

The neighbouring tools

ArdaForm isn't the only thing that came out of this. Two other tools fell out of it sideways, and both ended up more generally useful than the thing they were written for.

APM came first. The control plane — the WebSocket broker the devices dial into, and the API behind it — runs under it, and we built it for the same reason we built this: the existing options were heavier than the machines they were supposed to be supervising. It's a single static Go binary that supervises any Linux executable, proxies HTTP, WebSocket and TCP, rate-limits, and carries cross-language IPC between workers. It's free, it's finished, and if you run anything on Linux it may be more immediately useful to you than a device platform is.

ArdaLive was meant to be an ArdaForm tool. The idea was to give people building device interfaces a faster way to design them — a kiosk screen is often four clicks deep into a flow, and reloading the page to check a change throws away every bit of that state. So it patches the live DOM in place instead: scroll, focus, the half-typed form, all survive the edit.

Then it turned out that nothing about that is specific to devices. An ArdaForm application is plain HTML, CSS and JavaScript with no framework required — so a tool built for designing one already worked on any static page. It shipped as a standalone VS Code extension rather than a platform feature, which is the better outcome: you can use it today, on anything, without ArdaForm existing in your life at all.

How we're building it

Small team, real deployments, no invented benchmarks. Everything on this site marked Working is running on hardware in the field — that's the bar for the word. Everything marked In progress or Planned is labelled that way even where it would be more flattering not to. The roadmap is the same list without the marketing.

The portal — accounts, fleets, releases, the operator surface — is being finished now. It isn't open for public sign-up yet. When it is, early access users go first.