Direct File’s quiet exit made retirement part of service design

The week

April 15, 2026 was the federal individual income tax filing deadline, and the first since 2023 without IRS Direct File, the free tool that let eligible taxpayers file directly with the IRS. Most Americans use commercial software or a paid preparer. For two filing seasons, some had another choice: rather than buying software or going through a company’s website, a taxpayer with a fairly simple return could log in to an IRS service, answer straightforward questions and submit the return straight to the agency.

Direct File was piloted in 12 states in the 2024 filing season and offered in 25 states in 2025. That year, an internal IRS evaluation, later released under a public records request, counted about 296,500 accepted returns, more than double the pilot year. An “accepted” return is one the IRS’s systems received and processed without rejecting it for errors.

Then the service ended between seasons. In early November 2025, the IRS told participating states that Direct File would not be available in the 2026 filing season and that no future launch date had been set. Treasury Secretary Scott Bessent, also serving as acting IRS commissioner, said private-sector alternatives could do a better job. Taxpayers were pointed to options including IRS Free File, the long-standing program run with private software companies.

So the April deadline was historic, though few noticed. People who had used Direct File once or twice, and who might reasonably have expected it to be there again, had to find another way. States that had connected their own systems to it had to adjust. And a public service with real users simply stopped.

Whatever one thinks of the policy, the week raised a question every agency and many companies face sooner or later: what does an organization owe the people relying on a digital service when it decides to shut that service down?

The policy argument over a government filing tool has been made at length on both sides, and we will not repeat it. Some argue a government filing service crowds out private firms and costs taxpayers money; others argue it saves filers money and time. That debate belongs elsewhere.

The operational question is narrower and applies to any public service, and to many private ones. Agencies launch digital services with roadmaps, user research and launch plans. They rarely plan for the end. Direct File was unusual: a service with returning users, state partners and a hard annual deadline, ended between seasons by a policy decision. That makes it a clear case study in what a retiring service still owes.

We see three obligations, each owed to a different group and each with a different owner. They run to the users, to the partners whose systems connect to the service, and to the public record of what the service cost and taught. First, though, a word on what a “digital service” actually is, and why ending one is harder than it sounds.

More than a website

To most people, a digital service is a website. To the organization running it, it is much more: a set of connected parts that happen to show up as web pages.

There is the part users see, often called the front end: the screens, questions and buttons. Behind it sit the back-end systems that store data, run calculations and send information onward. For a tax tool, that includes the connection that delivers a finished return into the agency’s processing systems.

Then there are integrations: the agreed connections to other organizations’ systems. These usually run through an interface or API, short for application programming interface, a defined doorway that lets one computer system pass information to another in a format both understand. As long as both sides agree on the format, information can move between very different systems.

Around all this sit shared building blocks, such as identity verification (proving a user is who they say they are), payment handling and data exchange. And there are people: a contact center answering questions, a web team keeping content current, records officers responsible for what happens to the data.

Switching off the front end is the easy part. It can be done in an afternoon. Everything else, the users’ expectations, the partners’ integrations, the stored data and the accumulated know-how, keeps existing whether or not anyone plans for it. Retirement therefore deserves the same design attention as launch.

Private companies know this pattern well. When a software vendor retires a product, good ones publish an end-of-life date well in advance, explain the migration path, keep support running for a period and offer customers their data. Customers judge the vendor by how it handles that moment. Public services are judged the same way, by citizens and by partner agencies.

To the users: a route as well as a notice

A service with returning users creates an expectation that it will be there next year. When it is not, the agency owns the question of where those users go. A press statement and a closed web page meet the legal minimum. They do not reach a user who files once a year and remembers only the address they used last time.

Tax filing makes this especially sharp. People file once a year, often close to the deadline, and many do not follow tax news. A user who filed through Direct File in 2025 might not learn it was gone until they typed the familiar address in April 2026.

A better pattern has four elements:

1. Notify users directly. Use the channel they registered with, such as their account or email, before the season starts.
2. Match alternatives to situations. Map the options to the situations the old service handled, so a user with a simple return knows which option fits and what its income limits are.
3. Hand back their data. Give users their own prior-year data in a portable form, because last year’s figures help with this year’s return.
4. Keep a signpost. Keep the old address alive with clear guidance, because many users will arrive there at the deadline.

The aim is to make sure that a person who relied on a public service last year can still meet a legal obligation this year without needing to have followed the news; persuading users that the decision was right is a separate matter. For a tax return, missing the deadline can mean penalties and interest, so a user who arrives at a dead link on April 14 has a real problem rather than an inconvenience.

Each element has a cost and an owner. Notice requires that contact data was collected with consent to use it for this purpose; if the original sign-up said the email address would be used only for filing updates, using it to announce the end may need care. Portable data requires an export built while the service still runs, because once the systems are dismantled, building one is far harder. Signposting requires a contact center briefed on the alternatives and a web team that keeps the page current through the season.

To the partners: integrations that outlive the service

Direct File did not work alone. Participating states connected their own filing processes to it so that users could move from a federal return to a state return. Each integration represented work by a state revenue agency: interfaces, testing, user guidance and budget. When the federal service ended, those states had to decide whether to retire their side, repurpose it, or find another route for the same users.

The timing matters more than the decision. A notice in November leaves a state revenue department a few weeks before its own season begins, at a point when most system changes are frozen. Revenue agencies, like banks at quarter-end, generally avoid changing systems just before their busiest period, because a mistake then affects the most people.

The principle applies to any shared service, from a federal identity platform to a state benefits hub used by counties. A retirement plan should name the partners, give them a timeline that fits their cycles, and say what support continues during the transition.

Contracts and agreements are where this is enforced. Interagency agreements and data-sharing arrangements should include notice periods for termination and a description of what each party must do at the end. Few do. Adding them at launch costs little, because no one is yet arguing about the end and everyone is still optimistic.

To the record: what the public paid for

A retired service still holds data and still carries knowledge. Returns submitted through it remain subject to federal tax confidentiality rules and records schedules, whatever happens to the front end. A records schedule is the formal rulebook that says how long each type of government record must be kept and what happens to it afterwards. Disposal and retention should follow those schedules deliberately, with a named records officer, rather than by default when infrastructure is switched off.

The risk here runs both ways. Data deleted too early may breach retention duties and leave taxpayers or auditors without records they need. Data kept indefinitely on systems nobody maintains becomes a security liability: an unwatched store of sensitive information.

The knowledge matters too. User research, accessibility findings, performance data and code represent public investment. Accessibility findings, for example, record what made the service usable for people with disabilities, which is hard-won and reusable. The IRS had published much of Direct File’s source code, the human-readable instructions that make up the software, in 2025, which preserved part of that record. Research findings and operating lessons are easier to lose, because they live in team documents and in people who move on. Ask most teams where a project’s lessons live and the honest answer is a shared drive, a chat channel and the heads of three people. When those people move to other jobs, what they learned goes with them. An agency ending a service should publish or archive what it learned in a form others can find, whether the next attempt is by the same agency, another agency or a state.

Trust, cost and risk after the switch-off

It is easy to treat the end of a service as an afterthought, because the people deciding to end it are usually focused on the reasons for the decision. But the way a service ends has consequences of its own, and they land on someone’s desk whether or not anyone planned for them.

Trust. Public digital services depend on people being willing to try them. Every abrupt ending teaches the public that the next new service may not last either, which makes the next launch harder. The same is true inside government: a state that invested in an integration and was given weeks of notice will be more cautious the next time a federal partner proposes one.

Cost. A messy retirement shifts cost rather than removing it. Confused users call contact centers, write to elected officials and visit offices in person. Partners spend unplanned budget unwinding integrations in the middle of their busy season. Staff time goes into improvised fixes rather than planned work.

Risk. Systems that are switched off without a plan leave behind data, accounts and connections that nobody is watching, and forgotten servers and stale credentials become security incidents years later. For a tax service, where the data is among the most sensitive any government holds, the stakes are obvious.

Accountability. Oversight bodies, auditors and legislators will eventually ask what a service cost and what it achieved. An agency that captured its research, performance data and code can answer. One that let the knowledge scatter cannot, and that weakens its position in every future budget discussion.

Why some services retire more cleanly

Architecture affects how cleanly this can be done. Services built on shared platforms for identity, payments and data exchange leave those components running for other uses when they retire. Services built as self-contained systems take their components with them.

A restaurant in a food hall works the same way. It shares the seating, cleaning and payment terminals with its neighbors, so when it closes the hall carries on and the next tenant can move in quickly. A standalone restaurant that closes takes everything with it, and whoever comes next starts from bare walls.

Shared platforms are worth preferring at launch, regardless of how long a service is expected to last. Agency leaders approving any new digital service should also ask which of its parts are reusable and which would vanish with it.

A benefits tool, retired two ways

Suppose a state human services department decides to retire an online tool that residents used to renew a benefit each year. Counties have connected their case management systems to it.

A poorly handled retirement looks familiar. A press release goes out. The website shows an error page. County staff learn of the change from residents calling in confused. Renewal deadlines slip, and some residents lose benefits for a month because they did not know where to go.

A well-handled one looks different. Months ahead, the agency emails registered users, explaining which alternative fits which situation. It offers a download of each resident’s prior renewal details. The old address becomes a clear signpost page, and the contact center gets a script. Counties receive a timeline aligned to their budget and system cycles, backed by a termination clause written into the original agreement. A records officer signs off on what data is kept and for how long. A short public report captures what the tool cost, what it taught and what code and research remain available. The agency tracks calls, searches for the old tool and uptake of alternatives for the next cycle.

Money separates the two versions only modestly. The emails, the export, the signpost page and the contact center script are small pieces of work. The termination clause was a paragraph written years earlier. The records decision is a meeting and a signature. What separates them is whether anyone was asked to think about the end while there was still time to prepare for it.

In the first version, the cost does not land on the agency that made the decision, at least not at first. It lands on residents, county staff and the contact center, the people with the least say and the least warning.

The second version does not require agreeing with the decision to retire the tool. It requires treating the end as part of the job.

An exit plan approved with the launch

An agency should also decide in advance what it will measure after a retirement. Calls and searches for the retired service, uptake of the recommended alternatives and complaints all show whether users found their way. Without those signals, the effect of ending a service is a matter of opinion on both sides of the policy argument.

The agencies that handle this well put a retirement section in every launch plan. They collect consented contact channels and build a data export while the service runs, write termination terms into every partner agreement, give a records officer a named responsibility, and plan how to measure what happens after the switch-off.

The failures are the mirror image: treating retirement as a communications task rather than a service design task, giving partners notice on the announcing agency’s timetable rather than theirs, letting data and know-how drift into neglect, and declaring success or failure without any evidence about where users actually went.

Where a shutdown would hurt most

• For each public digital service we run, is there a written plan for how it would end?
• Can we contact our users directly, with their consent, and could they download their own data from the service today?
• Which partners connect to this service, what do our agreements say about termination and notice, and would those notice periods respect their busy seasons?
• Who is the records officer for this service’s data, and which retention schedules apply?
• If we ended the service, which signals would tell us whether users found their way?

With hindsight

The 2026 filing season ran without Direct File. IRS Free File, which is limited by income, Free File Fillable Forms and commercial software carried returns the tool might otherwise have handled. Free File Fillable Forms are electronic versions of the paper forms, with basic calculations, for people comfortable doing their own returns without guided questions.

We have not seen reliable figures on how former Direct File users filed in 2026, and we would be cautious about any claim of precision on that question. The absence is itself telling. Without planned measurement of where users went, neither supporters nor critics of the decision can point to firm evidence about its effects on the people who had used the service. The IRS said no future launch date had been set.

What the episode settled is that a public digital service with an established user base can be ended quickly by a policy decision. Nothing about that is unique to Direct File or to tax. Budgets change, priorities change, administrations change. Any public service, and many private ones, can face the same fate.

The more useful thing to ask of a service is whether it would end well if it did end.

That argues for treating retirement as a designed event from the start: notice channels and data export for users, termination terms in partner agreements, and a plan for records and knowledge. Those provisions are cheap at launch and expensive to improvise when a decision has already been made.

In government or out of it, the practical step is to approve a new digital service’s exit plan at the same meeting that approves the service. It costs little, protects the people who come to depend on the service, and spares partners and staff a scramble. It also means that whoever later decides the service’s future, for whatever reason, inherits an orderly path rather than a mess.