Ship an AI MVP to production with a checklist that catches the real gaps

Shipping an AI MVP to production is not the moment to add a final button and hope the demo holds. It is the point where you prove who can use the app, what data it can reach, how model failures appear to users, how spend is bounded, and how you recover when an external service is slow or unavailable.

Use this checklist as a release gate, not a backlog of aspirations. Every unchecked item should have an owner, a reason, and a next action. A small application can ship safely when its boundaries are explicit; a large application can remain risky when they are not.

Define the production boundary

Write down what the MVP does and what it deliberately does not do. Include the user roles, data types, model calls, external tools, side effects, and deployment environments.

The MVP may:
- Accept an authenticated request.
- Read records owned by the current workspace.
- Call the configured model provider.
- Return a validated response.

The MVP may not:
- Read another workspace’s records.
- Expose provider credentials to the client.
- Run arbitrary commands from model output.
- Perform financial or destructive writes without approval.

This boundary gives your tests a target. It also gives an AI coding agent a smaller task than “make the app production-ready.” Split the work into changes that can be reviewed independently: authentication, data access, model gateway, UI states, background jobs, and deployment.

Authentication is only the first check

Confirm that every protected route identifies the actor and rejects missing or invalid credentials. Then check authorization at the resource boundary. A signed-in user should not automatically be able to read every record in the database.

For a workspace application, derive the workspace from the authenticated session and constrain every query by that scope:

export async function getDocument(request: Request, documentId: string) {
  const actor = await requireActor(request)
  const document = await db.document.findFirst({
    where: {
      id: documentId,
      workspaceId: actor.workspaceId,
    },
  })

  if (!document) {
    return new Response("Not found", { status: 404 })
  }

  return Response.json(document)
}

Test the negative path with a document from another workspace. Test a user who can view a project but cannot invoke an expensive model operation. Test direct requests to the API, not just clicks in the interface.

The OWASP Top 10 is an awareness document, not a substitute for your threat model. Use it to prompt review of broken access control, misconfiguration, unsafe dependencies, and logging gaps, then test the specific boundaries in your application.

Keep model calls behind one gateway

Do not scatter provider calls across route handlers and UI actions. Put them behind a small application-owned gateway that accepts a typed request, applies policy, records usage, and returns a typed result.

type GenerateInput = {
  actorId: string
  workspaceId: string
  task: "summarize" | "classify" | "draft"
  text: string
}

type GenerateResult = {
  output: string
  providerRequestId?: string
  usage?: { inputTokens?: number; outputTokens?: number }
}

export async function generate(input: GenerateInput): Promise<GenerateResult> {
  await authorizeModelTask(input.actorId, input.workspaceId, input.task)
  const requestId = crypto.randomUUID()

  const response = await provider.responses.create({
    input: input.text,
    metadata: { requestId, task: input.task },
  })

  await recordModelUsage({ requestId, ...input, usage: response.usage })
  return { output: response.output_text, providerRequestId: response.id, usage: response.usage }
}

The exact provider API will vary. The boundary should not. Keep credentials server-side, validate the input length, apply a timeout, classify errors, and record enough metadata to explain the result without storing unnecessary private content.

A gateway also gives you an exit path. If the provider changes, you can replace the adapter without rewriting every screen. AI provider portability covers that boundary in more detail.

Set limits before traffic arrives

An MVP can become expensive through a bug, a retry loop, a malicious request, or one user pasting a large document repeatedly. Set limits at more than one layer:

• Maximum input and output size.
• Per-user and per-workspace request limits.
• A request timeout and retry budget.
• A daily or monthly spend alert.
• A hard stop for traffic above the approved budget.
• A cap on background work and queued tasks.

OpenAI’s production best practices describe securing API keys, reviewing usage limits, setting spend alerts, and using hard spend limits where appropriate. Apply the same discipline regardless of provider: credentials belong in secret management, not source files or browser bundles.

Return a useful rate-limit response. Do not silently downgrade a user to a different model or change the task scope without recording that decision. If the product has a free or trial tier, make its model and usage boundary visible.

Define the answer contract

A model response is not automatically a valid application result. Define the fields your application needs and validate them before storing or displaying them.

type DraftResult = {
  title: string
  summary: string
  tags: string[]
}

function parseDraft(value: unknown): DraftResult {
  const result = draftSchema.parse(value)
  if (result.tags.length > 8) throw new Error("Too many tags")
  return result
}

If parsing fails, return a classified application error and preserve the request ID for diagnosis. Do not display raw provider output as trusted HTML. Escape or sanitize user-visible text according to the rendering context.

Test missing fields, extra fields, long strings, invalid enum values, empty output, and provider refusals. Include a human review path when the output affects a customer, public content, financial decision, or irreversible action.

Add evaluation cases before launch

Create a small evaluation set from the product’s actual tasks. It does not need to be large to be useful. Include examples that represent normal inputs, difficult inputs, empty data, ambiguous requests, unsafe requests, and known past failures.

Record:

• The input category and expected behavior.
• The repository or prompt revision.
• The model and provider configuration.
• The output schema result.
• Human or rule-based quality labels.
• Latency, error, and usage information.

Run the set before release and after changing the prompt, model, retrieval source, tool policy, or output parser. Separate a quality regression from an infrastructure failure. A timeout is not a bad answer; it is a service failure with a different remediation.

The LLM evaluation loop provides a more detailed workflow for turning examples into repeatable release evidence. Keep the acceptance threshold specific to the task. “Looks good” cannot block a release consistently.

Handle slow and failed work explicitly

A browser request is a poor place to perform work that can take minutes. For document processing, large imports, exports, or multi-step agent tasks, create a job with a stable identifier and expose queued, running, completed, and failed states.

type JobState = "queued" | "running" | "complete" | "failed"

type Job = {
  id: string
  state: JobState
  attempts: number
  errorCode?: string
}

Make workers retry only errors that are likely temporary. Give each job a maximum attempt count. Store the last safe state and make the operation idempotent so a worker restart does not duplicate an external write.

For provider calls, distinguish timeout, rate limit, invalid input, authentication failure, and provider outage. Show the user an honest next action. “Try again” is appropriate for a temporary outage; “fix your account connection” is more useful for an authentication failure.

Secure tools and retrieved content

If the MVP lets a model call tools, inventory every tool and its side effects. Read-only search, database writes, email sends, and deployment actions should not share one approval policy.

Use the smallest scope:

Tool: read_workspace_document
Actor: current authenticated user
Scope: current workspace
Access: read only
Approval: not required
Audit: request ID, document ID, result category

For writes, validate the actor and resource again immediately before execution. Require approval for sensitive actions and record the exact operation approved. Treat retrieved documents, web pages, and tool responses as untrusted data; they can contain text that attempts to influence the agent.

Safe AI agent tool permissions covers narrow tools, server-side authorization, confirmation, replay-safe writes, and audit records.

Make monitoring answer a question

Do not begin with a dashboard full of counters. Decide what you need to know during an incident:

• Did the request reach your application?
• Which model operation ran?
• How long did it wait?
• Did validation pass?
• Which tool calls occurred?
• Did a retry happen?
• What did the user see?
• Was the result stored or discarded?

Log a request ID across the web request, model gateway, background job, and final response. Redact credentials, raw sensitive content, and unnecessary prompts. Keep usage and latency metrics separate from user content so you can measure service behavior without building a private-content archive.

Create one alert for errors and one for spend or volume. A quiet error rate can still hide a sudden increase in cost. A normal cost can still hide a broken output parser.

Test the release and rollback path

Before launch, deploy the same artifact to a production-like environment. Run a smoke test that authenticates, creates a permitted request, checks a denied request, invokes the model gateway, validates the response, and confirms the expected record or job state.

Then test failure deliberately:

• Provider timeout.
• Provider rate limit.
• Invalid model output.
• Database timeout.
• Worker restart.
• Duplicate submission.
• Expired session.
• Revoked workspace access.

Write down the rollback trigger and the person who can use it. A rollback should restore the previous application behavior without deleting records created by the new version. For schema changes, use a forward-compatible migration plan and a tested recovery procedure.

The AI coding agent acceptance checklist can turn these cases into evidence attached to a change. Ask the agent to report checks that were not run instead of treating them as passed.

Ship the smallest useful slice

A production MVP does not need every model feature, integration, or automation on day one. It needs a narrow flow that users can trust. Choose one task, one data boundary, one model gateway, one recovery path, and one measurable acceptance threshold.

OTF’s templates page verifies a free MIT component SDK and a free AI configurations pack for Cursor, Claude, and Lovable. Those are starting assets, not proof that a particular kit includes a specific integration. Verify the current kit scope before making it part of your release plan.

The shortest path from AI MVP to production is not removing every review step. It is making the review finite: authenticate the actor, authorize the resource, constrain the model call, validate the result, limit spend, handle retries, log the request, test the failure paths, and document rollback. When each item has evidence, a small team can ship with a clear understanding of what the system does and where it still needs work.

Sources

• OpenAI production best practices
• OpenAI Agents SDK guide
• OWASP Top Ten
• OTF templates