How to Scope the First Release of Enterprise Software

The first release of an enterprise system is where most of its long-term shape gets decided. It fixes the data model other things will be built on, the permissions everyone will argue about, and the integrations the business will quietly come to depend on. It is also the point at which the organization has the least information and the most enthusiasm, which is why first releases so often arrive late, oversized, and wrong in the places that matter.

Scoping it well is less about cutting features than about choosing which decisions to make now and which to deliberately postpone. This article sets out a practical way to do that for internal business software: the operational systems that hold state, enforce permissions and record what happened.

Why "minimum viable" misleads inside an enterprise

The phrase comes from consumer products, where a thin release tests whether anyone wants the thing at all. Internal software has a different problem. Demand is usually not in question; someone has already decided the process needs a system. What is in question is whether the system can carry the real process, including its exceptions, without people reverting to the spreadsheet it was meant to replace.

So the useful test for a first release is not "is it minimal?" but "can one real group of people do one real piece of their work in it, start to finish, every day, without a workaround?" The Scrum Guide makes a similar point in its own vocabulary: an increment has to be usable to provide value, and it has to meet a stated definition of done. A release that demonstrates well but cannot be used for the actual work has not delivered anything yet.

Scope by workflow, not by feature

Feature lists are the wrong unit. They invite trading items against each other ("drop reporting, keep approvals") without asking whether what remains still completes a piece of work.

A better unit is the end-to-end workflow: a request comes in, is assessed, is approved or rejected, is acted on, and is recorded. Pick one such workflow, for one team, and make it complete. Completeness here includes the unglamorous parts that feature lists omit:

• The exception path. What happens when an item is rejected, returned for more information, or needs to be reversed after approval. Software built only for the documented path is abandoned at the first case the documentation did not anticipate.
• The handover. Who picks the work up when the assigned person is on leave, and how they see its history.
• The record. What an auditor, a manager or the same user six months later will need to reconstruct why something was decided.
• The exit to the next system. Where the output goes once the workflow finishes, even if in the first release that is a controlled export rather than a live integration.

One complete workflow is worth more than three partial ones, because it produces the only evidence that matters: people using it for real work.

Decide early: the things that are expensive to change

Not every decision deserves equal care in a first release. A useful sorting question is how expensive each choice becomes to reverse once data and users have accumulated on top of it.

Get right now

• The core data model. Entities, identifiers and the relationships between them. Renaming a screen is trivial; splitting one record type into two after a year of production data is a migration project.
• Identity and permissions. Who can see and do what, and how that maps to your existing directory. Permission models retrofitted after launch tend to leak.
• The audit trail. Recording who changed what and when is cheap to build in and very hard to reconstruct later. History that was never captured cannot be recovered.
• The security baseline. Authentication, session handling, input validation and access control. The OWASP Application Security Verification Standard, currently at version 5.0.0, organizes these requirements into three verification levels; agreeing up front which level the system must meet turns "secure enough" from an argument into a checklist.
• Boundaries around anything replaceable. External services, and particularly any model or AI component, should sit behind a defined interface, as described in our article on AI-enabled application architecture.

Deliberately postpone

• Configurability. Admin screens that let the business change rules without a release are valuable once you know which rules actually change. In a first release you are guessing, and every configurable option is a code path that must keep working.
• Reporting beyond the operational minimum. Ship the views people need to do the work and a clean export. Build dashboards once there is real data and real questions.
• Secondary integrations. Connect the one system without which the workflow cannot complete. Each additional integration brings its own data model, authentication, rate limits and owner, and typically consumes more engineering time than the feature work it supports.
• Scale you do not yet have. In enterprise contexts, growth usually means more rules, users and integrations rather than traffic. Premature distribution of a system across services, before its boundaries are understood, makes that harder, not easier.

Postponing is not the same as ignoring. Write each postponed item down with the trigger that would bring it back into scope ("when a second team onboards", "when monthly volume exceeds what manual export can handle"). That list becomes the honest roadmap.

Replacing an existing process, not just adding software

Most first releases replace something: a spreadsheet, a shared inbox, a legacy application, or a set of habits. The replacement is the risky part, and a big-bang cutover concentrates that risk into a single day.

The alternative is incremental replacement, which Martin Fowler describes as the strangler fig pattern: new software grows around the old system, taking over one slice at a time until the old one can be retired. Its benefit, in his framing, is that investment and returns both occur gradually and visibly. For a first release this suggests a concrete scoping rule: choose a slice that can be moved over completely and cleanly, and define how the old and new systems coexist until the next slice follows.

Two practical consequences follow. First, plan data migration as real work with its own discovery, because the existing data will be less consistent than anyone believes. Second, decide in advance what happens to items that are in flight on cutover day, since they belong fully to neither system.

Writing a definition of done that means something

A first release needs an explicit, written statement of what "finished" means, agreed before building starts. Without it, scope expands to fill whatever time is available and quality is negotiated downward at the end.

A workable definition of done for internal business software usually includes:

1. The chosen workflow completes end to end, including the exception and reversal paths, for the named team.
2. Permissions are enforced on the server, not merely hidden in the interface, and have been tested with accounts at each role.
3. Every state change is recorded with actor and timestamp.
4. The agreed security verification level has been checked, not assumed.
5. Existing data needed for the workflow has been migrated and reconciled against the source.
6. Someone other than the builders can deploy, roll back and restore from backup, and has done so at least once.
7. There is a named owner for the system after launch, with time allocated to it.

The last item is the one most often missing. As the build-versus-buy analysis notes, enterprise software never reaches a finished state; a first release without an owner is already on its way to becoming a system too embedded to remove and too neglected to trust.

Measuring whether the first release worked

Decide before launch what evidence would show the release succeeded, and take a baseline of the current process while it still exists. Useful measures are operational rather than technical: how long an item takes from request to completion, how many items are handled outside the system, how often work is returned for missing information, and how many support requests the release generates in its first month.

The most revealing single signal is the workaround rate. If people are still keeping a parallel spreadsheet after a few weeks, the first release did not cover the real workflow, whatever its feature list says. The return-measurement article describes how to set that baseline in operational units.

A short scoping procedure

1. Name one team and one end-to-end workflow they will run entirely in the new system.
2. Map the workflow including its exceptions, reversals and handovers, by observing the work rather than reading the procedure document.
3. List every decision and sort it into "expensive to change later" and "cheap to change later". Resolve the first group now.
4. Choose the single integration without which the workflow cannot complete. Defer the rest, each with a written trigger.
5. Agree the security verification level and the definition of done in writing.
6. Plan cutover as incremental replacement, including in-flight items and data reconciliation.
7. Record the baseline and the success measures before launch, and name the owner who will be answerable for the system afterwards.

More on how this approach shapes our own engineering is set out on the software development page.

Common questions

How long should a first release of enterprise software take?

There is no reliable general figure, and published averages rarely transfer between organizations. A more useful constraint is to scope until one team can run one complete workflow; if that still looks long, the workflow chosen is probably too broad rather than the estimate too pessimistic.

Should the first release include an AI component?

Only if the workflow genuinely depends on it. If it does, keep a deterministic fallback path, validate model output before acting on it, and isolate the model behind an interface so it can be changed without reworking the application.

Is it better to pilot with a small team or launch to everyone?

A single team running real work is almost always the better first step. It exposes gaps in the workflow while the cost of fixing them is still small, and it produces a group of users who can explain the system to the next team.

References

1. Schwaber, K. and Sutherland, J. (2020). The Scrum Guide. Sections on the Increment and the Definition of Done.
2. OWASP Foundation. Application Security Verification Standard (ASVS) 5.0.0.
3. Fowler, M. Strangler Fig Application. martinfowler.com.