New Services Are Contracts

Why this matters

Every new service, app, automation, dashboard, pilot, or prototype creates an implied contract with its users. If real work would stop when it disappears, the organization has already accepted a responsibility to own, fund, secure, support, and eventually retire it.

In government and high-regulation environments, this transition is especially fast. A pilot can become operationally essential before procurement, ATO, funding, staffing, monitoring, or ownership has time to catch up.

Mental Model

Dependency creates the contract. The moment a team, manager, workflow, report, or constituent-facing process relies on the tool, the organization owes users an answer about availability, support, funding, security, and exit.

This does not mean every idea needs enterprise ceremony on day one. It means every useful idea needs a boundary: stop, stay small, transfer, sustain, or retire cleanly.

The Simple Service Test

flowchart TD
    Idea["Idea or prototype"] --> Pilot["Limited pilot"]
    Pilot --> Users["Real users rely on it"]
    Users --> Question{"Would work stop if it disappeared?"}
    Question -- "No" --> Bound["Keep bounded or retire cleanly"]
    Question -- "Yes" --> Contract["Make the service contract explicit"]
    Contract --> Owner["Owner, funding, ATO, support, monitoring"]
    Owner --> Decision["Sustain, transfer, or shut down deliberately"]

The key question is not whether the work started as a pilot. The key question is whether people now depend on it; if they do, the service contract already exists and needs to be named.

The Contract to Make Explicit

Build every new service as if success creates long-term maintenance. That does not require full enterprise ceremony on day one, but it does require an honest exit and sustainment path before users become dependent.

The contract has two parts, and both have to be real before adoption expands. A service with only the technical side defined still leaves the organization exposed.

The technical contract: what the service does, what data it touches, how failures are handled, how monitoring works, and who is authorized to change it.
The institutional contract: ownership, funding, approval authority, vendor renewal, security accountability, and on-call response ownership when it degrades.

If the technical contract is mature but the institutional contract is missing, the service becomes operational debt: it is used, but no one has the authority, budget, or review path to run it responsibly.

How Work Becomes a Service

The safest way to manage new work is to be honest about what it has become. Each stage carries a different promise to users, support teams, budget owners, and security reviewers.

Stage	What it looks like	Decision before expanding
Experiment	A small team tests whether an idea is worth pursuing, usually with disposable data and no operational dependency.	Decide what would make the experiment stop, transfer, or become a bounded pilot.
Pilot	A limited group uses the service for real work, usually with manual support nearby. Users are spending real time and making real decisions through the tool.	Name the owner, user boundary, data boundary, support path, success criteria, and stop date.
Service in practice	Repeat users depend on it, managers ask for reports from it, other teams plan around it, or support requests arrive when it breaks. It may still be called a pilot, but the organization treats it like infrastructure.	Confirm sustainment funding, security path, monitoring, release process, and support ownership.
Production service	The service is expected to be available, reliable, governed, and supported. Informal coverage from the original build team is no longer enough.	Treat it as an owned system with ATO evidence, incident response, roadmap intake, budget, access review, monitoring, and release authority.
Retirement	The service no longer has a justified owner, control path, budget, or business need. Keeping it alive creates hidden risk and support debt.	Communicate shutdown, export or archive required data, remove dependencies, close access, and give users a replacement path or clear end date.

What Usually Goes Wrong

These are not edge cases. They are the default outcome when successful pilots launch without a named path to sustain, retire, or transfer, and they become harder to correct after users depend on the service.

Signal	What it looks like	Contract to make explicit
Shadow production	A dashboard built for one program office becomes the Monday status source for multiple teams. People use it for leadership updates, operational decisions, and delivery planning.	Reclassify it as a service, name the owner, document reliability expectations, and decide whether the implementation can support the role it now plays.
Security control drift	A prototype starts handling real constituent, employee, or case data before the ATO path is clear. The work may have started as a harmless demo, but the data classification changed once real records entered the system.	Define data classification, risk owner, access model, audit evidence, retention expectations, and the security review required before adding more users.
Budget uncertainty	A pilot saves staff several hours every week, but the renewal date arrives without a sustainment line item. Everyone agrees the service is useful, but no team has accepted the cost of keeping it alive.	Assign funding responsibility before the pilot boundary expands, including procurement, renewal, and support ownership.
Unplanned vendor dependency	A vendor integration speeds delivery, then becomes required for intake, reporting, approvals, or notifications. The dependency becomes critical before renewal terms, exit options, data portability, or support obligations are clear.	Document renewal ownership, exit strategy, data export path, support escalation, outage expectations, and what the internal team will do if the vendor is unavailable.
Unowned operations	The build team keeps answering support tickets after launch because no operations owner was named. The team that created the service becomes the default help desk, release manager, incident responder, and roadmap owner.	Transfer support, monitoring, incident response, release authority, intake triage, and user communications to an accountable owner.

How to recognize the transition

A pilot has become a service when people would be disrupted if it disappeared tomorrow. That disruption can be user-facing, operational, financial, or political, and it is the signal that informal support is no longer enough.

The transition is usually visible before anyone names it. Look for recurring users, scheduled reports, leadership references, support requests, vendor dependencies, data retention expectations, or teams delaying other work because they expect the pilot to continue.

How to start responsibly

Name the service owner before the first user depends on it.
Write the shutdown, transfer, or sustainment path before the pilot begins.
Decide what evidence is needed for ATO, procurement, renewal, and budget approval.
Limit the pilot audience until the operating model can support more users.
Treat “people love it” as a signal to fund and govern it, not as permission to bypass those steps.

The goal is not to block pilots. The goal is to preserve velocity while making commitments explicit before dependence hardens.

Better Questions

Before starting a new app or service, ask these questions while the scope is still small. The answers decide whether the work is safe to expand, should stay bounded, or needs a clean stop date.

If this works, who maintains it in six months?
If people depend on it, what authority lets us keep running it?
If it handles real data, what ATO path covers it?
If a vendor is involved, who owns renewal and exit?
If we cannot sustain it, how do we stop cleanly without stranding users?

If those answers are not known, record them as explicit risks and assign owners before increasing adoption.

Takeaway

A service begins when dependency begins. The responsible move is to name the contract while the work is still small enough to sustain, transfer, or shut down deliberately.