How It Works
ResourceSpec is structured plain text that describes a monthly resource plan as a central source of truth.
One monthly text file becomes the team’s internal contract. It defines the month, project registry, people, allocations, capacity, PTO, and goals.
Define projects once using stable project codes and optional contract constraints. Codes create consistency. Structure reduces ambiguity.
Declare person-level allocations in hours. When reality gets uneven, add weekly overrides without rewriting the whole month.
Run the file through a renderer that turns it into a read-only planning board. It calculates totals, flags over/under capacity, and rolls up projects automatically.
Let validation act like a compiler. Unknown projects, over-capacity plans, and SOW overages surface immediately instead of drifting quietly.
Build your own UI if you want. The spec is portable. The renderer we built is just one interpretation.
The text file is the contract.
Everything else is a layer on top.
Notes from Building
We started with a simple question: what is the minimum structure required to answer a planning question clearly? Most planning tools start with an interface. A dashboard, a board, a timeline. But underneath every planning tool is an implicit language: projects, people, allocations, capacity, constraints. So we tried something different. Instead of designing another planning tool, we tried designing the language underneath one.
We’re exploring grammar instead of software. This doesn’t replace anything and we haven’t adopted it internally. It’s a thought experiment made concrete. Writing a plan as a structured file forces a different discipline because you cannot hide ambiguity behind UI. The structure itself has to answer the planning question.
Most small teams inherit their workflow from SaaS tools. Very few teams would actually build something like this, and in many cases they shouldn’t. It’s niche and probably unnecessary for most organizations. But experiments like this start to hint at a different future, where internal operations are written in shared, structured formats that tools and AI agents can read directly. For a small team that is aligned, technical, and opinionated about how it works, defining that structure can sometimes be simpler than forcing those ideas into someone else’s interface.
The file is the system. ResourceSpec lives as a structured text file, and that file becomes the source of truth. This is already a native format for developers and AI systems alike. Agents can read it. Tools can parse it. You can diff it, fork it, generate it with AI, render it differently later, or plug it into another system. We built a renderer because visualizing capacity is useful, but the renderer isn’t the product. It’s simply one interpretation of the file.
