From AI-built prototype to a tool your team can use

A prototype has already done something valuable: it has made an idea concrete. Perhaps you built a dashboard that replaces a weekly spreadsheet, an approval form that removes repetitive emails, or a small CRM that follows the way your team actually works. You can demonstrate the workflow. Someone else wants to use it. The next question is what needs to be true before they depend on it.

The useful distinction is between demonstrating a workflow and operating that workflow. A demonstration can assume one friendly user, clean example data and an available creator. Everyday operation must handle mistakes, departures, failed integrations and people who never saw how the app was assembled. Moving between the two is a series of decisions, not necessarily a rewrite.

Start with one useful workflow

Write a short description of the first release: who will use it, what they can do, what information it holds, and what happens when it is unavailable. Keep this specific enough that another person can tell whether the tool is doing its job. “An internal operations platform” is too broad. “Five project managers submit spending requests, and one finance manager approves or rejects them” is something you can inspect and test.

Define what remains outside the first release. An approval tool might record a decision without initiating payments. A reporting dashboard might show last night’s synchronized data rather than claiming to be live. These boundaries make it easier to choose sensible technical controls and explain the tool honestly to its users.

Choose a business owner as well as a technical owner. The business owner decides what the workflow means and whether the output is useful. The technical owner handles deployment, access, incidents and maintenance. One person can hold both roles, but leaving either role unnamed creates an avoidable gap.

Trace the data before changing the code

List the systems the tool reads from and writes to. Include its database, files, email service, spreadsheet connections and any AI services used inside the application. For each connection, identify whose account owns it, what permissions it has, and whether it uses test or real data.

This exercise often exposes a launch problem more quickly than reading every component. An integration may run through the founder’s personal account. A spreadsheet may be writable by everyone with its link. A supposedly disposable database may contain the only copy of a week’s work. None of these findings requires a dramatic story about AI; they require an explicit decision.

Draw the simplest possible data-flow diagram. A browser sends a request to an application; the application reads a database; a background job updates the spreadsheet. Mark where authentication and authorization happen. If an important permission exists only as a hidden button in the browser, it needs closer inspection: a user can send requests without using that button.

Give permissions a real test

Create a short role table. For an approval tool, a requester might create and view their own requests, a manager might approve requests in their team, and an administrator might manage membership. Decide whether a manager can change an already approved amount, whether an administrator can approve their own request, and what a departed employee should still be able to access. The answers belong to your business workflow.

Then test with separate accounts. Viewing a page as an administrator is not evidence that a normal user is properly restricted. Try another user’s record identifier, a direct file URL, and an action that the interface hides. Check the server response and resulting data. The objective is to verify the intended boundary, not merely to observe that the normal path works.

OWASP’s Application Security Verification Standard provides a structured reference for application security requirements. It can inform the review, but mentioning OWASP is not the same as completing an assessment against the full standard. Record the checks actually performed and what remains unknown.

Make one repeatable deployment

A production deployment should have a known source version, reproducible dependencies and configuration that can be recovered. Someone other than the original builder should be able to tell which version is live and where the application’s secrets are managed. Avoid making manual edits to a running server the only record of an important change.

Use a separate place to test changes before they affect your team. This does not have to imitate a large enterprise environment. It does need an unmistakable separation between experiments and real work, especially for email, billing, data imports and destructive actions. Label the environments, use separate credentials where appropriate, and make accidental production writes difficult.

Plan the rollback before the first release. Returning to an older image may reverse a code change, but it will not automatically undo a database migration or restore deleted records. Describe which changes are compatible with rollback and which require a different recovery procedure.

Prove that recovery works

A backup job reporting success is useful evidence, but it is not a demonstrated restoration. Recover a copy into an isolated environment and verify that the expected records and files exist. Confirm how the application reconnects to them. Record how long the exercise took and which credentials or instructions were missing.

Ask how much lost work and downtime the team could tolerate. These answers determine the necessary backup frequency, retention, monitoring and support arrangements. A dashboard that can be rebuilt from its source system is different from the only record of customer approvals. The infrastructure should reflect that difference.

Include an exit path. The company should know how to export its data, obtain its source code, recover credentials through the agreed process and move away from a supplier if necessary. Ownership is easiest to establish before the tool becomes essential.

Roll out to a small real group

Choose a small group of users and a specific observation period. Give them a short guide that covers the workflow, known limits and how to report a problem. Ask them to perform real tasks rather than simply say whether the interface looks good.

Record errors and surprising workarounds. If people keep editing exported spreadsheets because the tool cannot represent an ordinary case, the issue may be the workflow rather than the software architecture. Keep an alternative process available while you learn. A controlled launch allows useful feedback without making every mistake a business interruption.

Define a small acceptance checklist before inviting the wider team: key workflows completed, intended access restrictions tested, recovery exercised, responsible people named, and unresolved risks explicitly accepted or scheduled for work. “It seems fine” is a poor handover document.

What the research can—and cannot—tell you

A 2025 study combining three randomized field experiments with 4,867 developers found increased completed-task output with an AI coding assistant. That supports taking the productivity opportunity seriously. It does not establish that every generated application has correct permissions, recoverable data or an appropriate operating model.

METR’s February 2026 update also cautions against generalizing its earlier developer-slowdown finding to current tools and users. Tool capability, task context and study selection matter. The practical conclusion is to assess the actual application and intended use rather than assume quality from how its code was written.

Your prototype is the starting point. A focused review can identify the most valuable next work, and a scoped launch can turn that work into a tool with a clear owner. The goal is not to make a small internal app look like a giant software company. It is to make it dependable enough for the job you need it to do.

Sources

• Microsoft Research: three field experiments with software developers
• METR: February 2026 productivity research update
• OWASP Application Security Verification Standard