As of 13 August 2026, AI can only partly build an internal tool for your UK business.

What to actually do

1. Hand it to a person

   The route this page recommends

   A person who owns the outcome does this end to end, worth it when the failure is dear.

2. Use a tool built for this

   Second choice

3. Do it yourself

   The distant third

   A chat interface, power-user skill, and roughly 4 hours until you can act on the result.

   How to actually do it

   1. Open a document and write the business process, the people who use it, the decisions they make and the failure that the tool must prevent.
   2. List every screen, field, report, approval, notification, integration and retention requirement, and remove real personal or confidential data from any examples.
   3. Paste the specification into an AI development tool such as Lovable, ask it to restate the requirements and risks first, and resolve its questions before asking it to generate the application.
   4. Ask the tool to create the database model, role permissions, audit log, validation rules and automated tests before connecting any live system or production data.
   5. Run the generated application with fictional records and test normal use, invalid entries, duplicate records, deleted records, each user role, exports and failed integrations.
   6. Ask a technically competent colleague to inspect the code, dependencies, authentication, permissions, secrets handling, backups, logging and data flows, then fix each finding before deployment.
   7. Deploy a limited pilot with non-sensitive data, compare its outputs with the existing process, and obtain business-owner approval before introducing real records.

   Prompt

   Act as a software analyst and senior developer. Design and build a small internal web tool for a UK business based on the specification below.
   
   Business purpose: [describe the process the tool should improve]
   Users and roles: [list each user type and what they may view, create, edit, approve or delete]
   Required screens: [list the screens]
   Data fields: [list each field, its type, whether it is required, and who may see or change it]
   Workflow: [describe the process from start to finish, including approvals, exceptions and notifications]
   Reports or exports: [describe them]
   Integrations: [list any required systems, or write none]
   Sample data: [paste fictional sample data only]
   Constraints: [browser, hosting, accessibility, retention, branding or other requirements]
   
   First, restate the requirements and list ambiguities, risks and unanswered questions. Do not invent business rules. Where a decision is needed, offer options and wait for my choice.
   
   Then propose a simple architecture, data model, permission model, validation rules, audit trail and test plan. Treat personal and confidential business data as restricted: use fictional data in development, minimise collection, do not expose secrets, and do not connect to production systems without explicit approval. Include protections against unauthorised access, insecure direct object references, injection, accidental deletion and unsafe file uploads.
   
   After I approve the plan, generate the application in small, testable stages. Include setup instructions, environment variables, database migrations, sample data, automated tests and a manual test checklist. Keep the implementation as simple as possible. Explain every assumption and show the files or changes made. Do not claim that the tool is secure, compliant or production-ready until the listed tests and an independent technical review have been completed.

   Open it prefilled in ChatGPT or Claude, or copy it into Gemini, which takes no prefill link.