Software Register

Software Product

Stoa

One typed backbone for the work around the work

Fig. 1 · Product ViewPublished
Stoa

Product Record

Status
In Development
Last Updated
Jul 2026

Specification

Product Overview

Stoa, One Place for the Awkward Bits

It Was Supposed to Be a Backend

Stoa began as the sensible place to keep content for two websites. Then projects needed tags and images, articles needed proper publications, files needed collections, and time logs began asking inconvenient questions about money. The project woke up one morning with people workflows and payroll calculations. This is how a small backend becomes a business operating system when nobody is watching closely enough.

The underlying problem is real. A small organization accumulates separate tools for the work around its work, then spends a surprising amount of time teaching them each other’s names.

One Contract, Several Surfaces

Stoa keeps organizations isolated as tenants and gives them content, files, projects, time tracking, finance, people operations, products, and administration. Articles are authored from Typst collections and published as versioned HTML and PDF artifacts. Projects can carry budgets, assignments, public metadata, and long-form overview articles. Files live in S3-compatible storage; operational data lives in PostgreSQL.

A shared contract defines both the typed RPC surface and OpenAPI. The dashboard, the Stokker Technologies site, and my personal site all consume that contract rather than maintaining their own copies. Permission checks remain on the server, where they cannot be improved by hiding a button.

Documents as Real Outputs

Typst is more than a rich-text editor bolted onto the side. Collections hold source and assets, the render pipeline produces durable artifacts, and organization branding travels into the output. The same machinery can serve an article, a proposal, a report, or a template without turning each into a special file format.

Still Becoming

Stoa is broad because the boundaries between these workflows are where much of the useful context lives. It is also broad enough to require restraint. The current work is mostly about making those boundaries explicit, keeping the public contract narrow, and refusing to solve tenancy or permissions in the frontend.

Both public sites already run through it, which is a healthy way to discover when an elegant API is elegant only from inside the server repository. Stoa remains in active development. It is already the place where the awkward bits meet, which was the point even before I had a name for it.