This page explains two practical routes for turning a business idea into a working AI application. The OpenAI SDK route gives you a code-based application with a server, controlled data access, integrations, and room to grow into a customer-facing product. The ChatGPT Sites and Codex route helps you create a focused internal tool by describing the workflow in plain language, reviewing the first version, and refining it through conversation.
Both routes begin with the same discipline: define one useful job, provide reliable context, keep consequential actions under human approval, and test the result with realistic cases. Use the comparison below to decide which route fits your project, then follow the step-by-step example to build a support-policy assistant and understand what changes when you move from a learning prototype to a more integrated business system.
A support specialist pastes a customer question. The app finds the relevant policy, drafts a grounded reply, and shows the source. A person reviews before anything is sent.
Use this when the app needs a real backend, controlled data access, live integrations, or a customer-facing product.
Best for: a durable app that must integrate with operational systems.
Use this when you need a focused internal site or lightweight app and want to describe the workflow in plain language rather than write the first version yourself.
Best for: a student project, calculator, tracker, dashboard, or narrow internal workflow.
The SDK route is for teams that need to place an AI capability inside a real application. You build the interface and server, keep the API key on the server, decide which business data the model can access, and connect the workflow to approved tools or systems.
It gives you more control over authentication, logging, evaluation, costs, and future integrations. That control also means more responsibility: someone must maintain the code, protect data, test the model’s behavior, and define what happens when the answer is uncertain.
import OpenAI from "openai";
const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });
const response = await client.responses.create({
model: "your-approved-model",
input: "Draft a reply using only the supplied policy and case facts."
});This is an illustrative server-side pattern, not a complete production application. Review the current OpenAI Responses API reference ↗ before implementing.
The ChatGPT Sites and Codex route is for learning, prototyping, and focused internal tools. You describe the user, task, inputs, rules, and desired result in plain language; Codex creates a first version that you can inspect and improve through targeted requests.
This route makes it easier to move from an idea to a testable workflow without writing all the initial code yourself. It is best when the scope is narrow and the data is reviewed or supplied as examples, while more complex live integrations and operational controls may require the SDK route.
Build a lightweight internal support-policy assistant.
User: a support specialist.
Input: customer question, product, and policy category.
Output: a short draft reply plus the policy source used.
Rules: do not send email, do not promise refunds, and show
“Needs human review” before the specialist copies a response.
Use sample policy data for the first version. Include a page that
shows 20 test cases and the metrics we should review.OpenAI describes ChatGPT Sites as a way to create and share lightweight sites or apps from Codex, starting from a plain-language description. See the official ChatGPT Sites guide ↗.
Does it improve the defined task on realistic cases?
Can a reviewer inspect the policy or evidence behind the answer?
Are sending, refunds, data access, and other consequential actions kept behind explicit approval?
Use the Canvas to define the owner, assumptions, value, risk, and decision gates before scaling.