Launching a minimum viable product is an important milestone. It proves that a concept can be transformed into working software. It may also confirm that users are interested, that the main workflow makes sense and that a business is willing to invest further.
But an MVP does not prove that a product is ready to operate reliably over time.
There is a significant difference between software that works during a controlled demonstration and software that remains available, secure and financially sustainable while real customers use it every day. This difference becomes even more important as companies add artificial intelligence to their applications.
AI introduces new possibilities, but also more variability. Outputs may be probabilistic. Usage patterns may be difficult to predict. Infrastructure costs can rise quickly. External model providers can change their pricing, limits or behaviour. Data must move through more components, increasing the number of potential failure points.
This is why software resilience has become a strategic concern rather than a purely technical one.
An MVP answers a different question
An MVP is designed to answer questions such as:
- Does the product solve a relevant problem?
- Can the proposed user journey work?
- Will customers use or pay for the solution?
- Can the concept be developed with available technology?
- Which features matter most?
These are essential questions, but they are not the same questions that a production system must answer.
Once software is used in a real operational environment, the questions become more demanding:
- What happens when hundreds or thousands of users perform the same action simultaneously?
- What happens when a third-party service becomes unavailable?
- Can the company identify suspicious activity before it causes damage?
- How quickly can the team understand and resolve an incident?
- Can infrastructure costs remain proportional to revenue?
- Can the system be modified without breaking critical workflows?
- Is sensitive data being processed according to the correct permissions and policies?
An MVP focuses primarily on proving value. A resilient product must preserve that value under pressure.
Real users do not follow the expected path
During design and development, teams naturally think in terms of intended workflows. A customer creates an account, fills in the correct information, completes a payment and receives confirmation.
In production, people behave differently.
They open several browser tabs. They press the same button repeatedly. They refresh a page halfway through a transaction. They upload unexpected file formats. They copy information into the wrong field. They share accounts. They leave processes incomplete and return days later. They use old devices, unstable mobile connections and unusual combinations of browser extensions.
Sometimes a user action is technically valid but operationally unexpected. A customer may generate hundreds of reports because the interface allows it. Another may repeatedly trigger an AI analysis process without realising that each request creates a cost. An integration partner may send duplicate events. A customer may attempt to process a dataset much larger than anything used during testing.
Software resilience begins with the assumption that unexpected behaviour is normal.
This does not mean trying to predict every possible action. That would be impossible. It means designing systems that limit damage, preserve data integrity and provide enough visibility for teams to understand what happened.
Rate limits, input validation, transaction controls, idempotency and clear permission models are practical examples. Just as important are logs and operational alerts that help teams distinguish between normal variation, product misuse and an active incident.
AI makes system behaviour less deterministic
Traditional software normally follows explicit rules. When the same validated input reaches the same version of the system, the result is usually predictable.
AI applications may behave differently.
A language model can produce different responses to similar prompts. An AI agent may select different tools depending on the available context. Retrieval systems may return different documents as indexes change. Models can misunderstand ambiguous instructions or generate plausible but incorrect information.
This does not make AI unsuitable for production. It means that AI features require controls beyond standard functional testing.
Teams must decide where probabilistic behaviour is acceptable and where deterministic safeguards are required. An AI-generated product description may tolerate some variation. A financial approval, access-control decision or medical recommendation requires much stricter boundaries.
In many applications, AI should assist a controlled workflow rather than replace it completely. The system may allow a model to interpret a request, summarise information or suggest an action, while deterministic business rules decide whether that action can be executed.
Resilience therefore depends on separating intelligence from authority.
An AI model can propose. The application must still validate.
Security must be designed for production conditions
Security is often simplified during the MVP phase. Test data may be used instead of real customer data. Access may be limited to a small internal group. Integrations may run with broad permissions because the priority is proving that they work.
These shortcuts become dangerous when the product enters production.
Every new user, API, model provider, database and integration expands the system’s attack surface. AI applications create additional concerns because they often process unstructured information and connect systems that were previously isolated.
A resilient architecture should consider:
- Authentication and authorisation for users, services and automated agents
- Separation between customer environments and datasets
- Encryption in transit and at rest
- Secure storage and rotation of API keys
- Protection against prompt injection and malicious uploaded content
- Restrictions on which actions an AI agent may perform
- Audit trails for sensitive operations
- Data-retention and deletion policies
- Dependency and vulnerability management
- Incident response procedures
One of the most important questions is not simply whether a system is secure today. It is whether the organisation will notice when its security assumptions are no longer valid.
A permission may be configured incorrectly. A new integration may expose more data than expected. An employee may leave while retaining credentials. A third-party library may become vulnerable. A model may begin processing information in a region that conflicts with the company’s data policy.
Security is an ongoing operational discipline.
Monitoring must explain more than uptime
A basic monitoring dashboard may confirm that an application is online. That is useful, but insufficient.
A system can be technically available while delivering a poor or unsafe experience. Pages may load, but an important integration may be failing silently. AI responses may take too long. A payment may be accepted without creating the corresponding order. A background process may be accumulating a backlog. Infrastructure may be operating normally while costs increase far beyond expectations.
Resilient software requires observability at several levels.
Technical health
This includes availability, response times, error rates, database performance, memory consumption, queue sizes and infrastructure capacity.
Business health
Technical metrics should be connected to customer outcomes. Teams may need to monitor completed orders, successful document processing, subscription activation, payment reconciliation or the percentage of users reaching a critical step.
AI performance
AI-enabled products may also need to measure model latency, token consumption, retrieval quality, fallback frequency, refused requests, tool-call failures and the rate at which human review is required.
Security signals
Failed login patterns, unusual data exports, unexpected geographic access and abnormal API usage may indicate misuse or an attack.
The purpose of monitoring is not to collect as much data as possible. It is to reduce the time between a problem beginning and the organisation understanding what it means.
Cost monitoring is part of reliability
Software is not resilient if it remains available but becomes economically unsustainable.
Cloud platforms make it easy to increase capacity, add services and process more data. AI services make consumption even more variable because costs may depend on prompts, outputs, document volume, model selection, image generation, embeddings or repeated agent actions.
A small change in user behaviour can therefore create a large change in spending.
For example, an AI feature initially designed for occasional use may become part of a customer’s daily operational process. A poorly configured agent may call the same external service repeatedly. Large documents may be reprocessed unnecessarily. A public endpoint may be abused by automated traffic. A model with more capacity than the task requires may be used for every request.
Cost monitoring should be built into the product’s operating model.
This includes budgets, alerts, usage limits, cost allocation by customer or feature and regular reviews of infrastructure consumption. Teams should know which customers, workflows and technical components generate the highest costs.
This information is valuable for engineering, but also for pricing and product strategy. A feature that is popular but expensive may need different usage limits or a different commercial model.
Cost visibility makes it possible to scale deliberately rather than reactively.
Infrastructure decisions shape future options
During an MVP, infrastructure choices are often based on speed. A managed platform, a single database and a small number of external services may be enough to launch.
As usage grows, those early decisions begin to influence performance, cost, security and the speed of future development.
This does not mean that every MVP needs enterprise infrastructure from the first day. Premature complexity creates its own risks. Teams can spend months preparing for a level of scale that may never arrive.
The better approach is to make conscious decisions about where simplicity is acceptable and where future change would be especially difficult.
Important questions include:
- Which components must scale independently?
- Which data requires stronger isolation?
- Which services are critical to the customer journey?
- What happens if a cloud region or external provider fails?
- How easily can the system move to another provider?
- Which operations require backups and tested recovery procedures?
- How much downtime can the business tolerate?
- Which components need redundancy?
- Which workloads can be processed asynchronously?
Infrastructure resilience is not measured by the number of technologies used. It is measured by whether the architecture matches the business’s real risk profile.
A system used internally by ten employees has different requirements from a payment platform, a medical application or a customer-facing AI assistant.
Third-party services create hidden dependencies
Modern applications rarely operate independently. They depend on payment providers, authentication platforms, analytics tools, communication APIs, cloud services and AI models.
These services allow companies to build faster, but they also create dependencies outside the development team’s direct control.
A provider may experience an outage. An API may introduce a breaking change. A service may stop supporting a specific feature. Usage limits may be reduced. Pricing may change. An AI model may be deprecated or replaced.
Resilient systems identify critical dependencies and prepare alternatives where the business impact justifies them.
This may involve fallback providers, queued processing, cached information, degraded operating modes or manual procedures. Not every dependency needs full redundancy. The key is understanding the consequence of failure before it happens.
A useful question is: if this service became unavailable for six hours, what would customers experience?
The answer often reveals whether the product has a technical dependency or a business-critical vulnerability.
Maintenance is part of product development
Maintenance is sometimes treated as the phase that begins after development is finished. In practice, software development is never fully finished while a product remains in use.
Operating systems change. Browsers evolve. Mobile platforms update their policies. Security vulnerabilities are discovered. Customer processes change. Teams add new integrations. Data volumes grow. Employees who understood early architectural decisions leave the company.
Without active maintenance, the gap between the software and its operating environment becomes larger every year.
Resilience therefore requires time for work that may not be visible to customers:
- Updating dependencies
- Improving automated tests
- Reviewing access permissions
- Optimising database queries
- Replacing obsolete components
- Testing backups
- Analysing incidents
- Updating monitoring rules
- Documenting system behaviour
- Reducing technical debt
This work protects the company’s ability to continue changing the product.
Technical debt becomes dangerous when even small modifications require excessive time or create uncertainty across unrelated parts of the system. At that point, the product may still be running, but it is no longer adaptable.
Incident response should be prepared before the incident
No production system is completely immune to failure.
The practical objective is to reduce the frequency, impact and duration of incidents. This requires preparation.
Teams should know who is responsible for investigating problems, who communicates with customers and how urgent decisions are escalated. They should have access to relevant dashboards, logs, credentials and recovery procedures.
After an incident, the focus should not be limited to identifying who made a mistake. A useful review examines why the system allowed a single mistake, unexpected input or service failure to create such a large impact.
The result may be a technical change, but it may also involve better documentation, monitoring, ownership or communication.
A resilient organisation learns from failure instead of repeatedly recovering from the same type of problem.
Software resilience is an organisational capability
Reliable software does not come from infrastructure alone.
It depends on product managers understanding operational constraints, developers designing for failure, security specialists reviewing risk, commercial teams understanding cost drivers and business leaders deciding what level of interruption is acceptable.
Clear ownership is essential. When a critical workflow fails, the organisation should know which team is responsible for restoring it and which business stakeholder decides the priority.
Documentation also matters. Systems become fragile when critical knowledge exists only in the memory of one developer or supplier. Architecture decisions, dependencies, recovery processes and known limitations should be recorded and kept current.
Resilience is strongest when technical and business teams share the same understanding of what must remain available, what can temporarily degrade and what must never happen.
From a working product to a durable product
The transition from MVP to production is not a single launch event. It is a change in responsibility.
Before launch, the main objective is to make the product work.
After launch, the organisation must keep it working while users, data, regulations, threats, providers and business requirements continue to change.
This requires more than additional development capacity. It requires monitoring, maintenance, security controls, cost governance, infrastructure planning and a clear operating model.
AI makes these disciplines more important, not less. Intelligent features may accelerate development and improve customer experiences, but they also increase system complexity and introduce new forms of uncertainty.
The organisations that benefit most from AI will not simply be those that launch the largest number of experiments. They will be the ones capable of turning successful experiments into secure, observable and economically sustainable products.
At Dink, we help organisations move beyond the initial implementation and build software that can be maintained, monitored and improved over time. Because the real measure of a digital product is not whether it worked during its first demonstration. It is whether the organisation can continue trusting it after thousands of real interactions.