FROM AI IDEA TO BUSINESS SOFTWARE
When AI-built software becomes business-critical: what must be in place?
Someone needs to care for what is working.
When the business depends on the app, assign responsibility for operation, changes, costs and incidents. Establish controlled access, detection of problems and tested recovery of code and data. Decide what the business does during an outage. The consequences determine the need, not how quickly the app was built.
Recognise when the use has changed
Ask what happens if the app is unavailable for a working day or shows incorrect information. If orders, billing or important decisions stop, the responsibility differs from a demo. Reassess when more users, real customer data or new integrations are introduced.
Assign responsibility before something happens
| Area | What must be clear |
|---|---|
| Business | Who prioritises needs and accepts that the workflow works? |
| Technology and support | Who receives defects, investigates causes and can make a change? |
| Accounts and costs | Who controls hosting, domain, database and billing? Who receives cost alerts? |
| Data and access | Who grants permissions, removes access and owns responsibility for records? |
| Incidents | Who decides to stop the system, inform affected people and restart it? |
Technical safeguards and clear ownership need to go together throughout the system’s life.
Demonstrate updates and recovery
Use a test environment and an identifiable code version. Run important tests before a change. Practise handling a failed update, including database changes that cannot always be undone by reverting code. Having a backup is not the same as demonstrating recovery of a working system.
Decide how problems are detected
Choose checks reflecting the important workflow: do orders arrive, do updates finish and are failures recorded? Assign alert recipients and response expectations. Do not put secrets or unnecessary customer records into logs. Decide what staff do during an outage, such as a temporary manual workflow.
Set boundaries for costs and maintenance
List ongoing services and which volumes drive cost. If the app uses AI at runtime, model calls and usage may also need monitoring. Plan security updates and regular access reviews. Allow time for maintenance as well as new features.
PRACTICAL TEMPLATE
Copy: a simple operations card
Use the headings as a starting point for your conversation. Leave secrets and customer records out of the document.
System and critical workflow: Business owner and technical owner: Accounts, billing and backup administrator: Alerts sent to / handled when: Recovery plan and last completed recovery test: Acceptable outage and data loss agreed by the business: Fallback process, incident contact and next review:Download template (.txt) ↓
Common questions
Is platform-managed hosting enough?
No. Managed hosting may cover infrastructure components, but you still need to understand the service scope and who owns app logic, data access, integrations and user support.
Does every app need round-the-clock support?
No. Set availability and support according to business needs and the consequences of an outage. Make the arrangement explicit so users do not rely on support that is not provided.
Sources and method
The review structure, examples and templates are Miller Development’s practical recommendations, informed by Sven Miller’s description of our approach. The references explain related principles; they do not validate these templates or certify a solution. Platform features and terms can change. This guide does not replace a review of your specific system.
OWASP ASVS provides a framework for technical security requirements and verification.
MILLER DEVELOPMENT
Want help taking the next step?
We help prioritise business value, review AI-built solutions and develop secure, stable systems integrated into your business. The next step may be a small test, a technical review or a bounded first delivery.
Talk to us ↗