An MVP becomes a different engineering responsibility when people depend on it repeatedly. The question changes from whether a workflow is useful to whether the team can keep delivering it as data, users, integrations, and expectations increase. Code produced with AI has no special exemption from maintenance, operational costs, or the consequences of an unreliable release.
Chapter 4 established evidence for a first release. This final chapter extends the same discipline into ongoing operation. Our hypothetical request tracker now has returning users who expect their assignments to remain available. We will consider how to grow the system through measured decisions while using AI to assist investigation and implementation.
Define what growth actually changes
Growth can mean more requests, more organizations, larger attachments, stricter access rules, or more people changing the code. These pressures affect different parts of the system. A request-volume problem does not necessarily require splitting the application into services, and a coordination problem between teams may not be solved by a larger database.
List the current promises and the evidence that they are becoming difficult to meet. If coordinators wait too long for a queue, measure the relevant path. If support cannot trace a failed assignment, improve observability. If a customer needs stronger access controls, examine authorization and account administration.
Keep product growth and technical capacity separate. Additional infrastructure does not create demand, while demand does not remove the need for disciplined engineering. The next investment should address the constraint that is visible now or reasonably expected from a specific commitment.
Establish a small operational baseline
Choose indicators tied to the workflow: request-save success, response time for the queue, unresolved background work, and the frequency of support interventions. Define how someone notices a meaningful failure and who responds. A metric without an owner or action threshold can become decorative reporting.
Include costs that grow with use. Storage, external APIs, email, and AI services may have different charging models. Measure actual consumption and investigate unexpected changes. Avoid forecasting precise future costs from a demonstration that uses synthetic data and only the happy path.
Use logs that identify an operation without copying sensitive content unnecessarily. A support record should help answer which step failed, which version handled it, and whether a retry is safe. It should not require exposing an entire customer's request history to everyone on the team.
Optimize a measured bottleneck
Ask the agent to trace a slow path using the actual code and available measurements. Require it to distinguish a suspected cause from a demonstrated cause. A plausible recommendation to add caching may be wrong if the delay comes from an external service or an inefficient database query.
Make one bounded change and compare behavior under representative conditions. An index, a smaller query, pagination, or moving nonessential work out of the request path may address the issue without changing the deployment model. Preserve a rollback path and watch for changed semantics.
Caching deserves particular care around organization-specific data and permissions. A cache key that omits an authorization dimension can turn a performance improvement into an information disclosure. Test the access boundary again when introducing a new place where data is stored or reused.
Keep data changes compatible with ongoing use
As the schema evolves, plan how old records and concurrent application versions will behave. Adding a nullable field can be easier to release safely than immediately requiring a value that existing records do not contain. Separate schema changes, backfills, and later constraint tightening when that reduces deployment risk.
Ask the agent to explain the migration sequence and recovery options. A generated migration should be reviewed as an operation on real data, rather than accepted because it is syntactically valid. Test on a representative nonproduction dataset and understand what cannot easily be reversed.
Backups need a restoration procedure. Decide which data and assets must be recovered together, how recent the recovery needs to be, and who can perform it. A successful export does not establish that the application can run from the restored result.
Introduce background work with clear semantics
Give jobs an identity
A notification or synchronization job should carry a stable identifier that lets the system recognize retries. Determine what counts as completion and retain enough state to diagnose an uncertain result. Repeating a job must not quietly repeat a consequential external action.
Bound retries and expose failures
Define which failures can be retried, how the delay changes, and when an operator should intervene. Infinite retries can hide a persistent error and consume resources. A failed job needs an understandable status and a recovery path.
Preserve the source of truth
A queue is a delivery mechanism, not necessarily the authoritative record of the workflow. Explain how the saved request, job state, and external provider response relate. Reconciliation becomes important when one system succeeds and another times out before confirming the result.
Make AI assistance sustainable for maintainers
Keep repository instructions, architecture decisions, acceptance tests, and operational notes current enough for a new contributor to work safely. AI becomes less useful when its context is a mixture of obsolete documents and unexplained exceptions. Removing ambiguity is often a better investment than writing a larger prompt.
Use agents for bounded maintenance tasks such as tracing an incident, preparing a dependency upgrade, or proposing a missing test. Review each task against the same boundaries introduced in Chapter 1. Broader automation should earn broader permissions through demonstrated need and suitable controls.
Keep a human able to explain critical paths. If only an agent can navigate a subsystem, the team has accumulated a maintainability risk. Reduce that risk with clearer interfaces, smaller modules, and focused documentation rather than relying on repeated generated explanations.
Invest in reliability according to consequences
A temporary delay in an internal queue differs from losing a customer record or exposing confidential information. Classify failures by their effect on users and the business. This helps the team spend limited effort on the risks that matter rather than treating every technical issue as equally urgent.
As contractual or regulatory expectations increase, obtain the appropriate specialist input and verify requirements for the actual service. Do not claim compliance because a framework was mentioned in an architecture document. Evidence, ownership, and operating practice must support any promise made to a customer.
Review incident lessons without turning every incident into a platform rewrite. Find the contributing conditions, choose a concrete corrective action, and verify that it addresses the observed failure. AI can help organize the investigation; people remain responsible for interpreting the evidence.
Conclusion: grow the operating capability with the code
Moving beyond an MVP means developing the ability to support a promise repeatedly. Observe the workflow, address measured constraints, plan data changes carefully, and keep recovery procedures usable. AI can accelerate maintenance when the team retains clear ownership and a system it understands.
Use the five chapters as a recurring engineering loop: define a useful outcome, build a narrow slice, document consequential decisions, verify the promise, and improve from operational evidence. The result should be software that remains understandable and dependable as the business learns what growth requires.
