StudioOne person, twelve products
A studio of one, on purpose
Two product lines that look unrelated until you notice they are the same craft: instrument-grade software, built to be used offline, by one person, for years.
01The studio
Control rooms and menu bars
One engineer. Two halves of the same craft. One half is process and control engineering software: control-logic design that produces deliverable drawings, PLC programming and simulation, plant-model review, electrolysis process simulation. The other half is macOS utilities: a document index, a file manager, a menu-bar instrument, a LAN transfer tool, an archiver.
Both halves are local-first, offline-capable, and unusually complete for a one-person shop. That is the pitch and it is also the constraint: no roadmap that needs a team, no feature that needs a server we do not run.
The work comes from having stood in front of the plant, and from using a Mac all day. The tools are what was missing in both places.
Everything is free during the launch period. After it, four products keep a public MIT core while builds and later add-on features are commercial; the rest are paid editions. That distinction is spelled out on the pricing page rather than implied here.
02The method
Five rules that decide what gets built
01
Finish the thing
A tool that stops at eighty percent is a tool nobody uses twice. Every product here has an end state: a drawing set, a transfer that completes, an archive that extracts, an index that returns the document.
02
Local first, not local only
Offline is the default because it is the honest default for engineering files and for small utilities. Nothing syncs. Nothing needs an account. Where a feature genuinely needs a network, the product page says so.
03
The artefact is the product
For the engineering line the deliverable is a drawing, not a screen. For the Mac line it is a file that ended up where you expected. Both are judged on the artefact, not on the interface tour.
04
State the gaps
Early access, in development, services only — those words appear on this site next to the products that need them. A feature table with no gaps is a marketing document, not a specification.
05
One path from problem to build
The person who answers the email wrote the code. That is why the tools stay specific, and why a request can become a fix rather than a ticket in a backlog nobody owns.
03What we do not do
The short list
Four things this studio does not do, written down so they are easy to hold us to.
Cloud accounts
No product needs a login, a workspace or a sync service. There is no platform to adopt before using the software.
Telemetry
No product reports usage back. The macOS telemetry tool is the pattern for permissions: no network, no admin rights, no special access.
Invented customers
There are no customer logos on this site, because there are no customers to name yet. The products are real; the social proof is not there, and is not invented.
Stock screenshots
Every product image on this site is either a real screenshot or a drawing labelled as a drawing. Product images are never mocked up.
04Upstream
Fixes go upstream
When a fix belongs to a project somebody else maintains, it goes there rather than into a private fork. Recent example: a patch to OpenPLC Editor, submitted upstream to Autonomy-Logic/openplc-editor (pull request #1169).
We are not the maintainers of that project, and this studio does not sell it. It is mentioned because contributing upstream is part of how the software here stays honest about what it depends on.
05Tools
What it is built with
Chosen per product rather than standardised across the line. A file manager and a control-logic editor do not want the same runtime.
- Swift · SwiftUI
- Rust · axum
- TypeScript
- Python
- Tauri
- pywebview
- SQLite · FTS5
- OPC UA
- Web Worker
- Zod
06Contact
Write to one person directly
Questions about a product, a licence, or a piece of engineering work all reach the same inbox — and the same person who wrote the code.