Building Web and App Products That Can Evolve After Launch
Use a service-request example to connect product scope, system boundaries, accessible failure states, release checks, and operational ownership.
Start with a journey that has an ending
Editorial update, September 2026: this article expands the original May 2022 discussion with a practical delivery example and current reference material. The example is illustrative, not a report of an Ulties client project.
A useful way to plan the future of a web or app product is to define what must keep working as the product changes. Consider a service portal: a customer submits a request, receives a reference, checks its status, and gets a response. A polished submission screen is only one part of that journey. Lost requests, inaccessible validation, or unclear ownership can make the entire product unreliable.
Start with the smallest complete journey. Decide what counts as acceptance, which system owns the record, and who handles failures. These decisions give design, engineering, and support a shared set of observable outcomes.
Turn the brief into reviewable decisions
The following JSON is a planning document, not framework configuration or executable application code. It needs no runtime. Its inputs are agreed product constraints; its output is a brief that reviewers can turn into implementation tasks and acceptance checks. Replace the example choices and assign actual owners before development starts.
{
"journey": "Submit and track a service request",
"first_release": {
"client": "Responsive web application",
"backend": "One application and one relational database",
"offline_submission": false
},
"acceptance": [
"A saved request has a reference visible in the account history",
"A customer cannot read or change another customer's request",
"A notification failure does not erase an accepted request",
"The form can be completed and corrected using only a keyboard"
],
"failure_policy": {
"save_failed": "Preserve form input and show that submission failed",
"outcome_unknown": "Reconcile using the submission identifier before retrying",
"notification_failed": "Keep the request accepted and flag delivery for retry"
},
"owners_to_assign": [
"Product acceptance",
"Authorization review",
"Release and recovery",
"Support escalation"
]
}
Choose boundaries that match the work
For this example, begin with a responsive web client and one backend application. Keep request handling, customer access, and notification delivery in separate modules, but deploy them together while their operational needs remain similar. This makes the initial release easier to reason about; the cost is that those modules share deployment and capacity constraints.
Store the accepted request before treating notification delivery as complete. If reliable asynchronous delivery is required, one option is to store a pending notification alongside the request in the same database transaction, then have a worker deliver it. The worker needs bounded retries and a visible failed state. A crash after delivery but before recording success can produce a duplicate, so define how duplicates will be handled.
A native client becomes worth evaluating when the journey requires specific device integration or offline work. Offline submission introduces queued changes, conflicts, and uncertain completion. Specify those behaviors before promising that a mobile interface will work without a connection.
Treat failure states as part of the interface
Separate a rejected submission from an unknown outcome. If the server returns a validation error, keep the entered values and explain the correction. If the connection disappears after sending, the server may already have saved the request. Use a stable submission identifier and a server-side deduplication and lookup policy before offering a retry that could create another record.
Accessibility belongs in these states too. W3C's WCAG quick reference includes keyboard operation, labels, and text descriptions of detected input errors. Test the form, error messages, and confirmation as a continuous journey. A few successful checks are useful evidence, but do not establish full WCAG conformance.
Make authorization a property of every operation
A customer identifier in a URL is an input, not proof of permission. OWASP recommends denying access by default and checking permissions on every request. Apply the policy to reading a request, changing it, listing history, and downloading associated files. Hiding a control in the interface does not enforce that policy.
Use two synthetic customer accounts to test the boundary. After customer A creates a request, try its identifier while authenticated as customer B. Verify that neither data nor a state change is exposed. Keep these checks beside the successful owner-access tests so future endpoints inherit an explicit requirement.
Release against evidence, then watch the journey
Before release, demonstrate failed saves, interrupted responses, delayed notifications, and recovery using synthetic records. Record the deployed revision and the recovery steps. Reverting application code may not undo a database change; verify compatibility with the previous release before relying on rollback.
Google's SRE guidance groups monitoring around latency, traffic, errors, and saturation. For this portal, pair those service signals with an end-to-end check that an accepted request can be retrieved. Track notification backlog separately: a healthy submission endpoint does not prove that the delivery worker is functioning. Agree alert thresholds and a responsible responder from the product's needs rather than copying arbitrary targets.
- Show evidence for each acceptance statement before approving the release.
- Assign someone to investigate failed delivery and unresolved submissions.
- Keep a recovery procedure that another maintainer can follow in a test environment.
Give the next change a clear reason
After launch, choose improvements from observed friction: abandoned forms, confusing status labels, slow queries, or repeated support questions. Treat an AI assistant as another proposed feature with a defined input, review step, failure behavior, and maintenance owner. Compare it with a simpler workflow before committing to it.
Keep the brief with the source and revise it when the product changes. That gives the next developer a reason for the current design, a boundary they must preserve, and a practical way to verify their change.