Write your studio’s framework once and start every client from it. Scope lives in one spec per deliverable, with Out of Scope in every one; a change request is a decision the client’s approver confirms, and what they signed off is a named version you can open a year later.
Free for macOS, Windows, and Linux. No account, no subscription.
Sound familiar?
The statement of work is signed and frozen. The real scope moves in calls, emails, and tickets.
Every small extra made sense on the call. Together they ate the margin, and by the end nobody agrees on what was originally in scope.
Five people on the client side can ask for changes and nobody has final approval. The answer is in an email thread, or in the head of whoever was on the call.
Each project copies last year’s template, which drifts a little every time. People moving between clients relearn the structure, and so does every new agent session.
How it fits
Start from the software framework and shape it into your studio’s own: the frames your brief asks for, the sections every spec must have, your roles. Then every new client project starts from it, in that client’s repository.
What you will use most
The collections, templates, properties, and roles your studio works in, installed into every new client project with one command or one click.
Record a version naming the commit the client approved, tagged in the repository. Open the root as it was at that moment, whenever the question comes back.
A Scope decision for each change, assigned to the client’s approver. Confirming it stamps their name and the date on the decision and in the spec.
A question about a criterion is a thread on that criterion, not an email. Close it once it is answered; it stays in the file.
Tasks on a board, each naming the spec it delivers, exported to CSV or Excel for the client report.
A developer joining the project, or their coding agent, reads the specs and the decisions instead of a month of email.
What the client signed off
When the client approves, record a version: a name for that commit, with a tag in the repository if you want one. The proposal, phase one, and each change request become rows you can point to, and the check tells you if a tag ever moves away from the commit it named.
eidos version record
Out of Scope, written down
Out of Scope is a section of the template, not an afterthought, and the decisions made for a spec are listed in the spec itself. “I thought that was included” meets a line that says it is not, and the name of whoever agreed.
One framework, every client
Keep the framework in a repository of your own and install it from there into each client project, or start from the last client’s setup without any of its content. To share it, publish it to the Registry: a pull request to the Registry on GitHub, one manifest pointing at a tagged root, and anyone installs it as @your-studio/name.
$ eidos install your-studio/delivery@v3 --path framework
$ eidos install ../northwind/Blueprints --setup-only
$ eidos install @your-studio/deliveryStart here
Frames for the brief and specs for the deliverables, with Out of Scope in every template. Shape it in Framework Settings until it reads like your studio, publish it, and every client after that starts from your own.
An app, a service, or a system
Frames for architecture, audience, criteria, and market, and specs grouped by domain.
$ eidos install @BuildableWorks/softwareIn the app: New Root, then pick it from the list.
Download Eidos MD, shape the software framework into your studio’s, and record the first sign-off as a version.
Free for macOS, Windows, and Linux. Your files stay plain text in a folder you own.