PRODUCTProduct Engineering / AI
Why AI-Built Websites Fail After Launch: The Software Engineering Steps People Skip
A website can look complete before it behaves like a complete product. The pages load, the animations feel polished and the demo follows a convincing path. That tells us something about the interface. It tells us much less about what happens when a real person makes a mistake, an integration stops responding or the business changes its process.
AI makes it faster to turn an idea into code. That is useful. The difficulty comes when fast implementation is treated as a substitute for defining, validating and maintaining the system. The following examples are hypothetical, but they show what to inspect before calling a product ready.
1. Requirements are more than a list of pages
‘Build a premium business website’ describes a surface. It does not specify where an enquiry should go, which fields are required, what happens outside working hours or how someone knows their message was received. Those decisions are requirements, even when the brief never names them.
Write down the expected result for each important action. For a contact form, that might mean valid input creates one enquiry, reaches the correct destination and shows a truthful confirmation. Invalid input should explain what to correct. A failed delivery should not look like a successful submission. These conditions give both the developer and an AI tool something concrete to work towards.
2. Product planning needs the whole user journey
An AI-generated interface may have a beautiful dashboard and still miss the workflow the team actually uses. Imagine staff needing to revise a booking, record a partial payment and pass a note to the next shift. A dashboard with attractive summary cards does not establish how those steps connect.
Map who does what, in which order, and what information each person needs. Include cancellations, corrections, handoffs and unfinished work. Prioritise the smallest complete journey instead of a large collection of disconnected screens. The product plan should describe useful behaviour before it describes visual polish.
3. Architecture decisions do not disappear
Someone still needs to decide where data lives, what runs in the browser, which operations need a trusted backend and how parts of the system communicate. A static marketing website, a private staff portal and a scheduled automation have different needs.
Before adding another service or library, ask what responsibility it owns and how it fails. Document key data relationships and environment settings. If every component keeps its own version of the same business state, small changes can produce contradictory results. AI can help compare approaches, but the choice needs to fit the actual workflow and operating constraints.
4. An API integration needs a failure path
A successful request in a demo does not cover an expired token, a changed response format, a rate limit or a slow provider. A contact form can appear to work because the interface shows a thank-you message before confirming that the enquiry was accepted.
Check the provider's contract, validate responses and distinguish success from failure. Decide what the visitor sees during a timeout and what the operator can investigate afterwards. Retrying an operation also needs care: a repeated request should not accidentally create a second booking or duplicate a payment. Integration work includes those decisions, not just connecting an endpoint.
5. Validation and access rules need deliberate review
Client-side validation helps people complete a form, but trusted application boundaries also need to validate the data they receive. A hidden button is not an access rule. An application might require login and still allow one account to request another account's records if the backend never checks ownership.
Review who may read, create, change and delete each type of data. Keep private credentials out of browser code. Check session expiry, password recovery and role changes where they apply. These are areas for scoped engineering review; an attractive interface or an AI-generated implementation is not evidence that the rules are correct.
6. Testing should follow behaviour, including mobile
Start with the actions that matter most to the business. Follow a real enquiry, booking or internal handoff from beginning to end. Then try missing fields, repeated clicks, unavailable services and users without the required access. Useful tests check the expected outcome rather than simply confirming that a component renders.
Use actual narrow viewports and keyboard navigation. Check whether menus open, fields remain readable, dialogs fit and errors appear near the action that caused them. A desktop screenshot cannot reveal a mobile button hidden below a panel or a form that overflows at 375 pixels. Responsive behaviour is part of the product, not a finishing decoration.
7. A deployment needs a reproducible path back
Keep source changes in version control and review what each change affects. Separate environment configuration from source code, and document the build and deployment steps. Confirm that production uses the intended settings and that direct links to important pages work after deployment.
Before changing a live system, understand what can be backed up and how a previous version can be restored. A rollback of application code may not undo a database change. Test the release in an appropriate environment and verify its critical journeys after publishing. ‘It worked on my machine’ describes one environment, not the release process.
8. Automations need observable outcomes
Consider an automation that copies a lead into a CRM and sends a follow-up. If a credential expires and nobody receives an alert, the workflow may stop silently while the website continues looking healthy. A scheduled run is not proof that its intended result happened.
Record enough context to distinguish successful work, failures and skipped work without exposing unnecessary personal information. Assign someone to respond to alerts, decide when retries are safe and provide a way to inspect unresolved cases. Maintenance also includes reviewing service changes, dependencies and whether the workflow still matches the business.
9. Use AI inside the software development lifecycle
Generated code reflects the context and instructions available to the tool. It may make assumptions about permissions, data or edge cases that do not fit your product. It can also help clarify requirements, explore designs, explain existing code and propose tests. The value depends on how those outputs are reviewed and integrated.
Keep the lifecycle visible: define the problem, plan the journey, choose the architecture, implement, verify, release and maintain. These steps can be lightweight for a small website. They still need an owner. Faster implementation leaves more room for careful engineering when the saved time is used to validate the result.
If the site is already live, start with one broken journey
Write down what should happen, what actually happens and the shortest way to reproduce it. Gather the relevant error message, environment and recent changes. Inspect that path before asking for a complete rewrite. The right response may be a small repair, a provider configuration change or a larger structural decision.
If you need help diagnosing an existing website, app or automation, request a technical review. The first step is understanding the evidence and agreeing a realistic scope.