ScopeCI is a tool I am building for software agencies that do fixed-price client work. It is meant to check each pull request against what the client signed, so unapproved work is caught before it ships.
I am building it end to end as a founder and engineer. It is in development: the evaluator and the GitHub and Linear integrations are built and tested but not yet running on real repositories, and the public site is a waitlist.
Agencies sell scope in contracts and deliver it in repositories. The two drift apart quickly, leading to scope creep, unbilled work, and disputes over what was actually promised.
CI/CD tells you whether code builds; nothing tells you whether it matches the agreement.
The product has to fit into existing agency workflows rather than replace them, so it plugs into GitHub and Linear instead of asking teams to change tools.
The domain model must stay small enough to be trusted by both engineers and account managers.
A TypeScript API (Express, with PostgreSQL through Drizzle) models contracts, clauses, scope baselines, change orders and deliverables, and links them to Linear issues and GitHub pull requests.
A GitHub App receives pull request events, collects the diff, finds the linked issue, and compares the change with the approved scope. It reports the result as a check run and a pull request comment. It is designed to start by only observing: the check is neutral and never blocks a merge.
The repository is a pnpm workspace with the API, the waitlist site, a typed API client generated from an OpenAPI spec, and the scope engine with its test fixtures.
What was sold
Client contract
Clauses, scope baseline, deliverables
ScopeCI API
TypeScript and Express
PostgreSQL
Approved scope
What gets built
Linear
The issue behind the change
GitHub pull request
Event sent to the ScopeCI GitHub App
Scope check
Diff compared with the approved scope
Check run and comment
Flags out-of-scope work; designed not to block
I prioritized the contract-to-code loop over general project management features.
Broad PM tooling, time tracking, and invoicing breadth were intentionally deferred to keep the core model coherent.
Commercial tooling is mostly a domain-modeling problem. Getting contracts, scope changes, and deliverables to relate cleanly matters more than any individual integration.
Building something similar?
We can walk you through how this was built on a free call.
Free consultation
Tell us what you're building. We'll suggest the simplest way to ship it, and tell you honestly if we're not the right fit.
Tell us about the project
A few quick questions in the chat, or an email.
Reply within 24–48 hours
With questions, a rough scope and a starting price.
Free call, then a written quote
No commitment until you're happy with it.