Operated Scope in practice
When Exalynt operates a client's software, the client pays $150/month for the Production Foundation plus $75/month for each Feature in their Operated Scope. After any work for that client, check whether it changed that list of Features, and let the client know. In normal cases it takes under a minute.
Operated Scope is the set of production Features Exalynt agrees to keep running.
Did this work change Operated Scope?
Ask:
Does this help an existing Feature do its job, or give the product a new job?
- Existing job: a Capability. No Operated Scope change.
- New job: a Feature. Add it when Exalynt operates it in production.
- Implementation only: no Operated Scope change.
- Feature removed: remove it from Operated Scope.
Unsure? Ask:
If we removed this behavior, would a distinct product job disappear, or would an existing Feature simply do less?
Still unclear? Talk it through with another Exalynt engineer and make the fairest call you can.
Who decides? Exalynt makes the final classification using this standard, because Exalynt takes on the ongoing operating responsibility. You make the call as part of closeout; it's never an approval step, and it never holds up a deployment. Features and Capabilities has the full guidance and examples.
Self Operated software has no Operated Scope, so there's nothing to check.
Quick examples
| The work | Operated Scope | Fee change |
|---|---|---|
| Reporting gets CSV export | Unchanged: a Capability | $0 |
| Automated Notifications can now send SMS | Unchanged: a Capability | $0 |
| Customer Scheduling moves to a new database | Unchanged: implementation | $0 |
| Automated Notifications gains a queue and a worker | Unchanged: implementation | $0 |
| Bug fixes, upgrades, refactoring, performance work | Unchanged | $0 |
| The product adds Online Payments | Add Online Payments | +$75/month |
| Legacy Reporting is retired | Remove Legacy Reporting | −$75/month |
| Two Features are consolidated into one | Two become one | −$75/month |
When it's billed
- A new Feature is billable once it enters real production use and Exalynt agrees to keep it running. Local, development, preview, QA, testing, and staging environments never start a charge, and there's no retroactive fee for the time spent building it.
- A removed Feature stops being billed when Exalynt stops operating it: when it's retired, handed off to the client or another operator, or consolidated into another Feature.
- Tell the client as early as is practical. Flag a likely new Feature when you can see it coming, but don't hold a release to give notice first. Telling them at or after go-live is fine.
- Never backdated. If a Feature boundary is redrawn later, the change applies going forward. Don't reclassify past work to create charges for past periods.
Capacity is separate
Capacity funds change. Operations funds keeping production Features running.
A block can create a Feature, add or remove Capabilities, retire a Feature, refactor, change infrastructure, or do discovery that changes nothing in the product. So blocks don't automatically change Operated Scope. A large block may add only a Capability, and a small one may add a Feature. The question is never how much capacity was used; it's did the product gain or lose a Feature?
Telling the client
Add a short Feature impact note when you present work for a client whose software Exalynt operates. It tells the client what changed and what it does to their fee. It's information, not a request for sign-off, and it doesn't have to go out before the release.
- New Feature
- Existing Feature
- Removed Feature
Feature impact
This work adds Online Payments as a new Feature.
Because it introduces the distinct product job of collecting and managing payments, it's added to Operated Scope once Exalynt operates it in production.
Operations impact: +$75/month.
Feature impact
This work adds SMS delivery to Automated Notifications.
SMS is another Capability of the existing Notifications Feature rather than a new product job.
Operations impact: $0.
Feature impact
This work retires Legacy Reporting.
When Exalynt no longer operates that Feature in production, it will be removed from Operated Scope.
Operations impact: −$75/month.
The wording is yours; the pattern is what matters: which Feature, what changed, and the fee change.
Checklist: at the end of the work
- Ask: did the product gain or lose a Feature? Usually not.
- If unsure, use the removal tie-breaker, and talk it through with another Exalynt engineer.
- Write the Feature impact note at the checkpoint where you show the work. Don't hold a release for it.
- Keep Operated Scope current: add a Feature when it goes live, and remove it when Exalynt stops operating it.
Frequently asked questions
Do I need to do this after every block?
Only for clients whose software Exalynt operates. For most work the answer is "existing Feature, no change," and the note is one line.
Does a new database, worker, queue, or service add a Feature?
No. Those are implementation. Ask whether the product gained a new job, not whether the system gained a new component.
The Feature got much bigger. Should it be split?
Not because it got bigger. Split a Feature only if it's really doing two clearly different jobs. The boundary follows the product job, not the architecture, and the fee is flat per Feature so that complexity never earns more.
What if I'm still not sure?
Talk it through with another Exalynt engineer, and make the call that best fits the definitions. Be fair: a Feature should be a job the client would recognize, and charging for one that isn't erodes their trust. Don't hold the release while you decide.
Do I add the Production Foundation?
Only when Exalynt starts operating a production system for the client for the first time, usually at launch. Most clients have one Production Foundation, and later work adds Features on top of it.
Do I need the client's approval before deploying a new Feature?
No. Classification is part of normal closeout, and deployment doesn't wait on it or on telling the client. Send the Feature impact note when you present the work.
What if the client sees it differently?
Take the question seriously. Review the classification against the published standard, including the client-language check, and explain the reasoning. If the standard was applied poorly, correct it going forward. If a Feature needs a technical explanation to justify it, it probably isn't one. Exalynt keeps the final call.
Should estimates show operations impact?
Yes, when Exalynt will operate the software. Mark the estimate's new Features. See Creating project estimates.
Does any of this affect my pay?
No. Your payout is set by the Capacity Payout Basis and your Engineer Share. Operations fees aren't part of a capacity payout. See Engineer compensation.