Features and Capabilities
Exalynt describes every piece of software the same way: as Features, and the Capabilities inside them. This page explains both, how to tell whether new work belongs to an existing Feature or creates a new one, and who makes that call.
Features are the named jobs the product does. Capabilities are what those Features can do.
At a glance
- Show availability
- Book
- Reschedule
- Cancel
- Enforce booking rules
- Calendar sync
- Send email
- Send SMS
- Schedule delivery
- Retry failures
- Use templates
- Respect preferences
- View reports
- Filter
- Group
- Change date ranges
- Export CSV
- Schedule reports
- A Feature is a distinct product job, like Customer Scheduling. It has a name the client would use.
- A Capability is one thing that Feature can do, like rescheduling an appointment.
- Implementation is how it's built. It's never a Feature, however much of it there is.
- Exalynt makes the final classification using this published standard, because Exalynt is responsible for operating the result. It's never an approval step, and it never holds up a release. See Who decides.
Why the distinction matters
One shared vocabulary lets Exalynt, and you:
- describe software in terms everyone recognizes, not in terms of its architecture,
- talk about work clearly: "Scheduling can now reschedule" or "we added Online Payments",
- organize work and estimates around the jobs the client cares about,
- decide Operated Scope, the production Features Exalynt keeps running, and
- avoid arbitrary billing, since the operations fee follows Features, not how the code is split up.
Features
A Feature is a named product function that fulfills a distinct user or business job.
A good Feature has four things:
| It has | What that means | Examples |
|---|---|---|
| A clear job | It does something recognizable for the user or the business. | Schedules customers, collects payments, sends notifications, produces reports |
| A clear name | The client understands the name without a technical explanation. | Customer Scheduling, Online Payments, Reporting |
| A durable identity | It stays the same Feature as its Capabilities and implementation change. | Scheduling is still Scheduling after a rewrite |
| A product job shape | It describes what the product does, not a technical component. | Route Optimization, not "the routing service" |
Typical Features: Customer Scheduling, Online Payments, Reporting, Automated Notifications, Customer Portal, Route Optimization.
Customer Scheduling is still Customer Scheduling if we change the database, add rescheduling or cancellation, switch calendar providers, redesign the screens, move work into a background queue, or rewrite the backend. The job didn't change, so the Feature didn't either.
Capabilities
A Capability is something a Feature can do as part of its job.
A Feature usually has many Capabilities, and gains or loses them over time without becoming a different Feature:
| Feature | Some of its Capabilities |
|---|---|
| Customer Scheduling | Show availability, book, reschedule, cancel, enforce booking rules, calendar sync |
| Automated Notifications | Send email, send SMS, schedule delivery, retry failures, use templates, respect preferences |
| Reporting | View reports, filter, group, change date ranges, export CSV, schedule reports |
Adding or changing a Capability, such as CSV export for Reporting, doesn't add a Feature as long as it serves the same job.
How to classify work
The test
When work adds or changes product behavior, ask one question:
Does this help an existing Feature do its job, or does it give the product a new job?
| Answer | It's | Operated Scope |
|---|---|---|
| It helps an existing Feature do its job | A Capability of that existing Feature | No change |
| It gives the product a new job | A new Feature | Added when it's operated in production |
| It only changes how something is built | Implementation: neither | No change |
The tie-breaker
When the test doesn't settle it, imagine taking the behavior away:
If we removed this behavior, would a distinct user or business job disappear, or would an existing Feature simply do less?
| Remove… | What's left | So it's |
|---|---|---|
| Rescheduling | Customer Scheduling still exists, but does less | A Capability |
| CSV export | Reporting still exists, but does less | A Capability |
| SMS | Automated Notifications still exists, with fewer delivery methods | A Capability |
| Online Payments | The product can no longer collect payments | A Feature |
| Customer Scheduling | The product can no longer arrange appointments | A Feature |
The client-language check
As a sanity check, ask how the client would naturally describe it:
Would the client reasonably describe this as a new part of the product, or as something an existing Feature can now do?
| If the client would say… | It's likely |
|---|---|
| "We added Online Payments." | A new Feature |
| "Scheduling can now reschedule appointments." | A Capability of Customer Scheduling |
| "Notifications can now send SMS." | A Capability of Automated Notifications |
This is guidance for getting the classification right. It isn't a request for the client's approval.
What doesn't make a new Feature
A new Feature exists because the product gained a distinct job.
It never exists just because:
- the implementation became more complex,
- the work took a lot of engineering capacity,
- a new service, database, or queue was added,
- another integration was connected,
- a new screen or endpoint was created, or
- splitting the behavior out would increase the operations fee.
Who decides
Exalynt makes the final classification, using the published Feature and Capability standard, because Exalynt is responsible for operating the resulting scope.
Whether product behavior is a Feature, a Capability of an existing Feature, or implementation detail is Exalynt's call for the purposes of Operated Scope. In practice, the engineer doing the work classifies it as part of normal closeout, and talks it through with another Exalynt engineer when it isn't clear. Close calls can go either way; Exalynt makes them as fairly as it can, not by a fixed rule.
Why Exalynt makes the call
Because Exalynt agrees to keep the Features in Operated Scope running, Exalynt defines the Feature boundaries used for that scope. Exalynt is the party that:
- takes on the ongoing responsibility for keeping those production Features running,
- carries the operational work that scope creates,
- maintains the product and engineering model that defines Features,
- needs the same standard applied across every client and engineer, and
- is accountable for operations being sustainable over time.
How Exalynt makes the call
Final authority isn't arbitrary authority. Exalynt:
- uses the published definitions on this page,
- applies them consistently across clients and engineers,
- tries to be fair to the client, especially on close calls,
- doesn't split a Feature just to increase operations fees,
- explains its reasoning when asked, and
- doesn't back-bill after reclassifying past work (see below).
No approval step before deployment
Feature classification doesn't need a separate client approval before work is deployed.
Classification is part of the ordinary engineering closeout, not a contract change or sign-off. Work ships at its normal pace; it doesn't wait on a classification decision.
Telling the client
Exalynt tries to be clear with clients about Feature changes, as early as is practical. When work adds or removes a Feature, the engineer says so in a short Feature impact note: which Feature, and what it does to the fee. Operated Scope in practice has examples.
That note isn't guaranteed to arrive before a Feature goes live. Exalynt ships and iterates quickly, and a release doesn't wait for a conversation about the fee. A new Feature can join Operated Scope when it enters production, with the note at or after that point.
Questions and disagreements
A client can ask why something was classified the way it was, or ask Exalynt to reconsider. When they do, Exalynt reviews the classification against this standard, explains the reasoning, and corrects it going forward if the standard was applied poorly.
There's no formal negotiation, arbitration, or approval process for classifications. Exalynt keeps the final call.
No retroactive reclassification
Exalynt doesn't reclassify past work to create operations charges for past periods.
If Exalynt later decides a Feature boundary should be drawn differently, the corrected classification applies going forward. There's no back-billing for months already operated.
What isn't a Feature
These can support a Feature or add a Capability, but they never make a Feature on their own:
| Technical pieces | Pieces of a Feature |
|---|---|
| A database, a database table, a queue, a worker, a cache, a microservice, a container, an endpoint, a cron job, a third-party SDK, a deployment, an integration detail | A single button, a single screen, one step in a workflow |
Technical complexity doesn't set the Feature count
A Feature doesn't become several Features because it uses multiple services, databases, background workers, queues, caches, APIs, or integrations, or because it took significant engineering effort. Likewise, a technically simple implementation can still be its own Feature if it does a distinct job.
Feature classification follows the product model, not the technical architecture.
Feature boundaries stay stable
A Feature's boundary changes only when the product itself gains or loses a distinct job.
Customer Scheduling stays one Feature as it gains rescheduling, cancellation, calendar integrations, availability rules, waitlists, reminders that are part of the scheduling job, different infrastructure, or a new storage model. A Feature isn't split because it gained more Capabilities or became more complicated to build.
Getting the size right
Too small splits one job into many Features. Those are Capabilities of one Feature:
| Too small | Right |
|---|---|
| Book Appointment, Reschedule Appointment, Cancel Appointment | Customer Scheduling |
| Email Notifications, SMS Notifications | Automated Notifications |
| Sales Report, CSV Export | Reporting |
Too broad hides several clearly different jobs behind one vague name, such as Application, Platform, Backend, or Customer Experience. Name the jobs inside it instead.
Right is broad enough to hold many Capabilities, and specific enough that the client knows what job it does.
Examples
| The work | Feature | Classification |
|---|---|---|
| Reporting gets CSV export | Reporting | Capability |
| Automated Notifications can now send SMS | Automated Notifications | Capability |
| Customer Scheduling can now reschedule and cancel | Customer Scheduling | Capability |
| Customer Scheduling moves to a new database | Customer Scheduling | Implementation |
| Automated Notifications gains a queue and a worker | Automated Notifications | Implementation |
| A product that schedules customers adds payment collection, refunds, transaction status, and payment history | Online Payments | New Feature |
Calendar sync
If calendar sync exists to help Customer Scheduling do its job, it's a Capability of Customer Scheduling, not a new Feature. If Exalynt deliberately builds a broader calendar sync function that stands on its own and serves its own job, independently of Scheduling, it may be a Feature. The deciding factor is the product job, not the technical integration.
Dispatch and scheduling
The example estimate for a home-services company has both Customer Scheduling and Technician Dispatch. They're separate Features because they're different jobs for different people: customers requesting appointments, and dispatchers deciding which technician goes where. Remove Technician Dispatch and Scheduling still works, but nobody can assign technicians: a distinct job disappears. Warning a dispatcher before double-booking a technician is a Capability of Technician Dispatch.
Why this policy is fair
The policy is built to avoid two failure modes: arbitrary charges, and endless negotiation over every change.
| Need | How the policy meets it |
|---|---|
| Speed | Classification is part of normal closeout. It never gates a release, and neither does telling the client. |
| Consistency | One party applies one published standard across all the software Exalynt operates. |
| Accountability | The party that carries the ongoing operating responsibility defines the scope it's responsible for. |
| Fairness | Classification follows the product job, not effort, complexity, or what would earn Exalynt more. |
| Transparency | The definitions, tests, and prices are published, and Exalynt explains any classification on request. |
| Sustainability | Exalynt can define the scope it agrees to run, so operations stay viable for the long term. |
Features in estimates and operations
- Estimates list Features and their Capabilities. An item in an estimate can be a new Feature, or new Capabilities for an existing one, such as "Reporting: CSV export and scheduled reports." See Creating project estimates.
- Operations are priced by Feature. When Exalynt operates the software, each production Feature it keeps running is in Operated Scope and adds $75/month. Capabilities never change the fee. See Operating software.
- Capacity doesn't decide classification. A large block of work may add only a Capability, and a small one may add a new Feature. Engineering hours, block count, payout basis, and infrastructure cost play no part.
Frequently asked questions
What's the difference between a Feature and a Capability?
A Feature is a job the product does, like Customer Scheduling. A Capability is one thing that Feature can do, like rescheduling an appointment. A Feature usually has many Capabilities.
Who decides whether something is a new Feature?
Exalynt, using the standard on this page. Exalynt makes the final call because it's the party agreeing to keep that scope running in production. It tries to make close calls fairly, and explains its reasoning when asked. See Who decides.
Does the client have to approve a new Feature before it's deployed?
No. Classification is part of normal engineering closeout, not an approval step, so releases aren't held up by it. Exalynt tries to tell the client early when work adds or removes a Feature, but that note can come at or after go-live rather than before it.
What if I disagree with a classification?
Ask us. We'll review it against the published standard, explain our reasoning, and correct it going forward if we applied the standard poorly. Exalynt keeps the final call.
Can Exalynt reclassify past work and bill for it?
No. If a Feature boundary is later redrawn, the change applies going forward. Exalynt doesn't create operations charges for past periods.
Does adding Capabilities ever turn into a new Feature?
Only if the product gains a distinct new job. Many Capabilities added over years still belong to the same Feature, as long as they serve the same job.
Can a Feature be split into two later?
Only if the product itself changed and the Feature is now doing two clearly different jobs. It's never split because the code got bigger or more complex, and any change applies going forward.
Is sign-in or user management a Feature?
It can be, when it's a job the client recognizes, such as Staff Access: controlling who in the company can use the system. The shared production work underneath every Feature, like deployments, monitoring, and certificates, isn't a Feature; it's part of the Production Foundation.