How to scope a custom application MVP as one complete workflow

Name the primary user, situation, and completed result. “A field technician records a completed inspection with required evidence before leaving the site” is clearer than “mobile inspection app.” Pair it with a business outcome such as a reviewable record entering the existing compliance queue. Interview and observe the people doing the work, including those who handle exceptions. The U.S. Digital Services Playbook starts with user needs and the complete service because organizational assumptions are weak substitutes for real behavior.

Define how you will know the workflow is viable. Evidence may include task completion without staff rescue, valid records reaching the next operational step, manageable exception volume, or users understanding the status. Record the current baseline where possible and identify what the pilot must learn where it is not. Avoid a success metric such as registrations if the actual business need is an approved request. Activity can grow while the core service still fails.

Give one product owner authority to decide scope and tradeoffs. Gather legal, security, privacy, accessibility, operations, finance, and technology input, but avoid a committee in which no one can close a question. Document the target audience, excluded users, pilot limit, workflow boundary, non-negotiable policies, and decision date. A narrow boundary is not permission to ignore an affected group; it is a transparent plan for whom this release can safely serve and how everyone else continues.

• Named user, triggering situation, and observable completed result
• Business record or operational step produced by completion
• Pilot evidence tied to task success rather than account activity
• One authorized product owner and transparent audience boundary

Map the workflow from trigger through confirmation and downstream handoff. Include enrollment or invitation, sign-in, data entry, validation, save and return, submission, review, correction, approval or rejection, notification, and record export only where the chosen outcome needs them. A vertical slice touches interface, business rules, data, permissions, and operation. A horizontal slice such as “build all database tables” or “design every dashboard” may create components without putting useful behavior in a user’s hands.

Walk through ordinary and difficult examples with the people who perform each step. Include missing information, a duplicate record, an ineligible request, an unavailable dependency, a user who loses connection, a reviewer who sends work back, and a submission that must be withdrawn. Decide which exceptions the MVP handles automatically, which go to a visible manual queue, and which make the workflow unavailable with an honest explanation. Unhandled does not mean invisible.

Cut optional breadth before cutting the integrity of the slice. The pilot might support one service, one region, one customer type, one language, or one approved file format if those limits are lawful, usable, and clearly communicated. It should not accept a request and then lose it, expose records across accounts, or imply completion when staff still must repair data. Defer customization, secondary reports, rare automation, and cosmetic variety before removing confirmation, traceability, or essential support.

• Trigger-to-handoff map across interface, rules, data, and people
• Ordinary, invalid, duplicate, interrupted, and corrected examples
• Visible manual route for exceptions not yet automated
• Breadth deferred before workflow integrity and trustworthy status

Write acceptance examples in concrete language: given a verified user attached to one client account, when the user submits the required fields and an allowed file, then one request is created, a reference is shown, and the review team can see it. Add examples for permissions, validation, duplicate submission, timeout, cancellation, and provider failure. Agree on what evidence—automated test, review, log, or user exercise—demonstrates each result. Feature names alone do not establish a shared definition of done.

Include security and privacy from the beginning. Identify data, threats, role boundaries, authentication, authorization, input validation, logging, retention, deletion, backup, and incident responsibilities appropriate to the workflow. NIST SSDF treats secure practices as part of the development lifecycle, and OWASP ASVS offers testable controls for web applications. Use those references to define relevant verification, not to claim that a checklist guarantees safety or that every MVP needs the same controls.

Make accessibility part of acceptance rather than future polish. WCAG 2.2 provides testable criteria, but the team should also observe representative people completing the workflow. Test keyboard operation, assistive technology, visible focus, zoom and reflow, headings, labels, instructions, errors, status announcements, time limits, and authentication. Preserve entered work where practical. A pilot that excludes disabled users creates misleading learning and often bakes costly assumptions into the next version.

• Given-when-then examples for success, permissions, errors, and interruption
• Defined evidence for every high-value acceptance decision
• Risk-based security, privacy, backup, and incident requirements
• Manual accessibility and usability testing in the real workflow

Define the records the vertical workflow creates and consumes. Specify required fields, identifiers, allowed states, relationships, authority, history, retention, and correction. Avoid modeling the entire enterprise before the first workflow is understood, but do not create temporary definitions that cannot distinguish records the operation considers different. Resolve terms with business owners and keep a data dictionary beside acceptance examples so interface labels, rules, reports, and integrations use the same meaning.

Choose the smallest safe migration. The pilot may need only active cases for participating users rather than every historical record. Inventory sources, quality, duplicates, attachments, permissions, consent, and records that must remain available elsewhere. Run a sample transformation, let business owners reconcile it, preserve the source, and define cutover and rollback. Manual preparation can be appropriate at pilot scale if it is measured, owned, repeatable, and not disguised as permanent automation.

Limit integrations to those required to complete the chosen outcome. For each one, define the system of record, transaction, timing, credentials, failure path, reconciliation, and support owner. A temporary export reviewed daily can be safer than a hurried two-way synchronization if the pilot volume is bounded and the business accepts the delay. Conversely, do not call the workflow complete if an essential handoff depends on untracked copying. The MVP should produce trustworthy evidence at its actual boundary.

• Focused data dictionary with states, authority, history, and correction
• Migration limited to the records needed by pilot participants
• Sample conversion, reconciliation, cutover, and rollback plan
• Only essential integrations, each with failure and support ownership

Name who monitors the application, receives alerts, supports users, reviews exception queues, grants access, corrects records, restores backups, deploys fixes, and communicates incidents. Write short runbooks and exercise high-consequence paths. Define support hours and tell pilot users what they are. A prototype used only beside its developers and a pilot service used during real work have different obligations, even if both carry a beta label.

Select a pilot cohort that is small enough to support but varied enough to expose important conditions. Include willing participants, ordinary cases, difficult cases, different roles, and accessibility needs relevant to the intended audience. Prepare invitations, training, plain-language limits, data migration, feedback channels, continuity steps, and exit. Do not select only expert users whose workarounds hide confusing design from the team.

Set launch gates and rollback criteria before enthusiasm takes over. Required acceptance tests should pass; critical owners should be available; migration and restore should be rehearsed; known limitations should have safe paths; and measurement should work. Decide what triggers a pause, reduced cohort, manual process, or return to the former system. Rollback may involve data reconciliation, not merely redeploying old code, so document which system is authoritative throughout the transition.

• Named owners for access, support, exceptions, recovery, and incidents
• Pilot cohort representing ordinary, difficult, and accessible use
• Invitations, training, limits, continuity, feedback, and exit prepared
• Evidence-based launch gates, pause rules, and data-aware rollback

Observe the complete service, not only application analytics. Combine task completion, time and errors, manual interventions, support themes, exception queues, record quality, system performance, accessibility findings, and downstream outcomes. Protect privacy and avoid collecting behavior simply because an analytics tool can. Speak with users and staff to understand why an event occurred. A low completion rate might reflect confusing design, an eligibility rule, missing documents, or a process people should not have entered.

Maintain a prioritized backlog of evidence, problems, and opportunities. Separate defects against accepted behavior from new scope. For each proposed capability, name the user problem, business value, affected roles, data, risk, operating cost, and evidence that makes it more important than alternatives. Some pilot findings should simplify or remove work rather than add features. The MVP succeeds when it improves decisions about the product, including the decision not to scale a workflow that remains unjustified.

Choose expansion criteria deliberately. The organization may add users, regions, services, integrations, automation, or reporting, but changing several dimensions at once makes new failure hard to diagnose. Review capacity, support, access, migration, security, privacy, accessibility, recovery, and cost before each expansion. Keep the vertical workflow complete as its audience grows. “Phase two” should be a new evidence-backed decision, not a storage place for every requirement removed from the first plan.

• Task, exception, support, quality, accessibility, and outcome evidence
• User research used to interpret behavior rather than guess at causes
• Defects separated from evidence-backed new capabilities
• Expansion reviewed across operation, risk, accessibility, and cost