If you write the same kind of document every week with ChatGPT, you can save the setup once so you never retype it. That saved setup is called a Custom GPT, and it is the simplest way to turn a good prompt into a shared tool.
Say you write a status update for your directors every Monday. You open ChatGPT and type the same paragraph: who you are, who reads it, the hard rules, and the order of the sections. Then you paste last week’s bullet notes and get a one-page draft. By week six the routine still works, but you have forgotten a rule twice, and two teammates keep their own slightly different versions on sticky notes. Nobody is doing AI wrong here. They are paying a small tax every week for a recipe that only lives in memory.
A Custom GPT is a saved ChatGPT setup for one job: a name, standing instructions, and optionally some reference files. You open it, and the recipe is already loaded. This post builds one simple GPT for a weekly task, with no outside connections and no private data. If ChatGPT itself is new to you, start with the beginner series on learning ChatGPT.
Menu labels, plan packaging, and who may create GPTs keep changing. Treat the names and rollout notes below as a July 2026 field guide, and re-check chatgpt.com/gpts, GPTs in ChatGPT, Creating and editing GPTs, and openai.com/chatgpt the week you write team policy or promise a department that everyone will build a GPT.
Custom GPT in one sentence
A Custom GPT is a version of ChatGPT configured for a specific purpose: standing instructions, optional uploaded knowledge, and optional capabilities or connections, all saved under a name people can open again.
You still chat with it, and the model can still be wrong, so you still own the result when it reaches a customer or a board packet. What changes is the setup cost. You stop retyping the same role every Monday, and teammates stop inventing five private variants of the same prompt. The recipe becomes a shared object that anyone can edit, instead of something people half remember.
Rule of thumb: A GPT is a saved recipe inside ChatGPT. It is not a full software product with its own database, uptime promise, and audit history, so treat it like a well-named template that can reason, not like a shipped app.
OpenAI’s help docs say the same idea in product language: GPTs combine instructions, knowledge, and selected capabilities for a more tailored ChatGPT experience. You build a GPT in a web editor. Phones can use GPTs, but building stays on the web for nearly everyone. Creating or editing needs a paid subscription on consumer plans, plus workspace permission on managed plans. Using a GPT is broader, because any signed-in user can talk to GPTs they can access, including ones others shared or published, when product rules allow.
What a GPT is made of (day-one view)
You do not need every setting on the first build, but you should know the layers so you can tell what to touch and what to leave alone.
| Piece | What it is | Day-one advice |
|---|---|---|
| Name and description | How people find and understand the GPT | Boring and clear beats clever and vague |
| Conversation starters | Example prompts shown on open | Three realistic jobs, not marketing slogans |
| Instructions | Standing role, rules, format, refusals | This is the spine; write them first |
| Knowledge | Uploaded reference files | Optional; only stable, non-secret docs |
| Capabilities | Built-in helpers such as web search, canvas, and code tools, if the product offers them | Turn on only what the job needs |
| Actions / apps | External connections you define or user-connected tools | Skip for a first GPT, because they add risk and setup cost |
A later post in this series goes deep on instructions, knowledge files, and a light tour of actions. The job of this post is narrower. You will ship one useful recipe for one repeating task, prove it on real inputs, and stop there.
Plan reality: creating versus using
OpenAI’s public help pages, checked in July 2026, say signed-in ChatGPT users can talk to any GPT they have access to. Creating or editing GPTs requires a paid subscription. On managed Business, Enterprise, or Edu workspaces, the right to create can also depend on admin settings and roles. Free users can often still open GPTs that others made or shared, within product and workspace rules. Exact plan names (Go, Plus, Pro, and team plans) and create rights change by market and by year, so confirm on your own account before you promise that everyone will build one.
| Question | Practical answer (hedge and re-check) |
|---|---|
| Can Free users chat in ChatGPT? | Yes, within Free limits. |
| Can Free users create Custom GPTs? | Usually no on consumer plans, where creating needs a paid plan. |
| Can Free users use someone else’s GPT? | Often yes when shared or available under product rules. |
| Where do you build? | Web ChatGPT GPT editor; mobile is mainly for use. |
| Do Business/Enterprise change the story? | Yes: workspace controls, sharing, and data settings matter. |
| If you cancel paid create rights? | OpenAI’s help notes say you may still use GPTs you made, but you cannot create or edit until you pay again. Confirm on the current help page. |
If you are the only person with a paid seat, you can still create a GPT that teammates open when sharing allows. That is a question of ownership and budget, not a free-for-all, so decide who pays, who maintains it, and who retires GPTs nobody uses. A later post in this series covers team sharing without chaos.
Pick one repeating job (not a career)
The first GPT fails when its job description starts with “help with everything.” Successful first GPTs sound like an entry on your calendar:
- “Turn weekly bullet notes into a one-page leadership status.”
- “Rewrite support replies in our calm tone with no invented refunds.”
- “Score a draft brief against our checklist and list missing sections.”
- “Explain this metric definition pack in plain English for new analysts.”
- “Turn meeting notes into action items with owners and open questions.”
Use this filter before you open the builder:
- Repeats. You or your team do this weekly or daily, not twice a year.
- Stable shape. The output format barely changes from month to month.
- You can name hard rules. You can list at least three constraints you refuse to drop.
- You have three real past inputs. Made-up examples hide weak instructions, so use real ones.
- No outside system required. Day one should not need a custom connection to another program.
- No secret data required. Use only public material or internal reference you are already cleared to share.
If the work is still exploratory, stay in plain chat. The product map series put it simply: invent the recipe in chat, freeze it, then save it. Building first and learning later is how teams end up with five half-broken bots that have cute names.
What to leave out of your first GPT
Ambition is the enemy of a first useful recipe, so this section lists what to leave out.
Skip actions on day one
Actions let a GPT call outside services that you define, through what programmers call an API (a way for one program to ask another for data). That is powerful, and it carries more risk. You have to handle sign-in, decide how a third party treats your data, and cope with failures that look like the bot being smart when the outside service actually returned garbage. OpenAI documents a full path for actions, and a later post in this series touches on it lightly. For your first GPT, do not connect anything outside. Prove the text recipe first.
Skip secret and live operational files
Knowledge is for reference material, not a vault. Do not upload customer exports, raw HR notes, unreleased forecasts, API keys, or “the whole shared drive as a zip.” Prefer public docs or internal docs you are already allowed to share in the way this GPT will be shared. Put a date in each file name so you can tell versions apart. If a file changes every day, you will spend more time maintaining the GPT than using it.
Skip “replace Work or Codex” fantasies
A Custom GPT does not replace Work for multi-step office agent jobs that gather across files and produce decks or sheets. An agent is a program that can take actions, such as opening files, across several steps. It does not replace Codex for repo work with diffs and tests. Those are separate products in the product map. A GPT is mostly a better way to start certain conversations with a fixed recipe, so if your real pain is multi-step office packages or code changes, go to those tutorials first.
Prep offline before you open the builder
Write these answers in a note before you open the builder. If you cannot fill them in, you are not ready to create the GPT yet.
- Job sentence: “This GPT helps ___ produce ___ for ___.”
- Audience: who reads the output, and what they will do with it
- Hard rules: three to seven constraints (no invented numbers, ask when a detail is missing, a maximum length, and so on)
- Output shape: section order, tone, length limit
- Refuse list: what it must decline (legal advice, credentials, confidential systems outside scope)
- Knowledge list: zero to a few stable files, each with a purpose and date
- Owner: the person who will update it and eventually retire it
- Test set: three real past inputs and a one-line quality bar for each
A thin starter for instructions looks like the block below. Adapt it to your job, and never paste secrets into it.
You are a careful weekly status editor for a product team.
Audience: busy directors who skim.
Hard rules:
- Never invent metrics, dates, or customer names.
- If a number is missing, write UNKNOWN and ask one clarifying question.
- Prefer short sentences. Aim for one page equivalent.
- List assumptions in a final section.
Output sections in this order:
1) Headline (one line)
2) What shipped
3) What slipped
4) Risks
5) Asks
6) Assumptions and unknowns
If the user pastes messy notes, reorganize into those sections.
If the notes look like confidential HR data or raw credentials, refuse and say why.
Example of good behavior: if notes say "revenue was up" with no number, do not invent 12%. Write UNKNOWN and ask for the figure and grain.Build path: create the GPT on web
This is the official create flow. Confirm the button labels if the screen has changed since July 2026.
- Sign in to ChatGPT on the web with an account that can create GPTs.
- Open Explore GPTs in the sidebar, or go to chatgpt.com/gpts.
- Select Create, which opens the GPT editor.
- Choose the conversational builder or the configuration view. For learning, the configuration view is better because every field is visible, though the conversational builder is fine if you still paste your offline checklist into the chat.
- Fill name, description, and a few conversation starters.
- Paste your instructions, and prefer concrete steps and one short example over a long list of things not to do.
- Optional: upload knowledge files that you are allowed to share and that rarely change. If you are unsure, leave this empty.
- Leave actions alone, and turn on only the built-in capabilities the job needs.
- Use Preview, the test panel beside the editor, with your three real inputs, and fix the instructions before you share anything.
- Save or create the GPT when Preview passes your quality bar, and keep sharing set to private until you trust it.
A few help notes are worth remembering. Drafts save while you edit, and you should use Preview before broad sharing. Put rules and tone in the instructions, not only in files, because knowledge files are for reference material. Version history exists when you need to roll back, although you should re-check sign-in settings if you later add actions and then restore an old version.
Name it like a tool, not a mascot
Good: “Monday status brief,” “Support tone rewrite,” “Metric glossary coach.” Bad: “Ultimate Strategy Superbrain 9000.” Cute names hide stale bots, and a few months from now you will search for the job, not the joke.
Conversation starters that teach usage
Conversation starters are the example prompts shown when someone opens the GPT, so write ones that match real work:
- “Turn these messy notes into this week’s status sections.”
- “Score this draft against the section checklist and list gaps.”
- “Rewrite this reply in our calm support tone without promising refunds.”
Avoid starters that promise magic, such as “own the quarter” or “be my CEO.” Starters train habits, and vague starters train vague use.
Worked example: Monday status brief GPT
Imagine your team ships product features. Every Monday you turn chat bullets and ticket titles into a one-page leadership status, and you have three past note dumps saved as plain text. Leadership cares about what shipped, what slipped, the risks, and what you need from them, and they dislike invented metrics.
Job sentence
“This GPT helps product managers produce a one-page Monday status for directors from messy weekly notes.”
Build choices
| Field | Choice |
|---|---|
| Name | Monday status brief |
| Description | Turns weekly product notes into a one-page status with assumptions listed. Never invents metrics. |
| Instructions | Role, audience, section order, refuse invented numbers, refuse credentials |
| Knowledge | Optional: short public-style metric glossary file dated in the name, or none |
| Actions | None |
| Share | Private until Preview passes three real tests |
Test set (do not skip)
Run all three inputs in Preview before anyone else opens the GPT.
| Input | What good looks like | Fail signal |
|---|---|---|
| Notes with clear shipped items and one missing number | Sections filled; UNKNOWN for the number; one clarifying question | Invented “about 12%” or silent omission of unknowns |
| Notes that are pure venting with no facts | Thin shipped section; explicit unknowns; asks for facts | Confident paragraph of empty leadership prose |
| Notes that include a password-looking string or raw personal data | Refuse or strip and warn | Echoes secrets into a polished status |
Your first Preview run fails test one, because the model softens “revenue was up” into “solid growth.” You add an explicit example to the instructions saying that if there is no number, the answer should be UNKNOWN. The second Preview passes. You keep the GPT private for one more Monday of solo use, then share it with two teammates who already know the format, and you stay its owner. That is a complete first GPT, with no outside connections, no public store listing, and no time spent redesigning the icon.
How first-week use should feel
Open the GPT and paste in your real notes, then read the draft like a skeptical editor. Fix any facts that are wrong and send the human-checked version. If the draft saves you ten minutes of structure work, the GPT has earned its seat. If you rewrote every sentence for accuracy, either the instructions are weak or the job still needs plain chat while you work out the recipe.
Help docs also note that GPTs do not use your saved memory, custom instructions, or previous conversations the way personal Chat settings might. Each conversation with the GPT starts from the GPT’s configuration plus what you put in that thread. That helps consistency, but it also means you cannot assume it remembers last Monday unless you paste in that context.
GPTs compared with other ChatGPT products
| If your job is… | Prefer | Why |
|---|---|---|
| One-off exploration, still inventing the format | Plain Chat | Flexible; no premature freeze |
| Same role and format every week | Custom GPT | Saved recipe, shareable when ready |
| Multi-step office deliverable (deck, sheet, long doc package) | Work | An agent works through the steps for you, which a chat recipe cannot do |
| Repo edits, tests, diffs | Codex | Built for software projects |
| App embedded in your product with audit | API / platform engineering | GPTs are not website embeds |
OpenAI’s own FAQ is blunt about embedding, which here means putting a chat inside your own website or app: GPTs live inside ChatGPT, and if you need an assistant inside your own product, you use the API. An API is a way for one program to ask another program for data or an action. Do not tell leadership you shipped a product when you published a GPT with a friendly icon.
Common mistakes with a first GPT
Building before the recipe is stable
If the section order changes every week, stay in chat. Freeze the format after a few real runs, and only then create the GPT.
Instructions that try to boil the ocean
A long pile of conflicting rules makes the model flail. Prefer short sections for the role, hard rules, steps, format, refusals, and one example. OpenAI’s troubleshooting advice is practical: shorten the instructions, remove conflicts, write rules as “when X happens, do Y,” add one or two examples, and test small changes in Preview.
Knowledge as a junk drawer
A 200-page PDF of everything is not a plan for reference material. Short, purposeful, dated files beat archives, and behavior rules belong in the instructions, not only in files.
Actions as day-one theater
Every call to an outside service adds a new way for things to fail. Prove the text quality first, and let actions wait until the recipe is boringly reliable.
Sharing before Preview
Keep the GPT private until three real inputs pass, because team trust is harder to rebuild than instructions.
No owner
A GPT with no owner slowly turns into office folklore, so assign a person to it. Write a simple retirement rule too, such as deleting it after 90 days without use. A later post in this series goes deeper on team process.
Try it this week
- Pick one job that already repeats on your calendar.
- Write the offline checklist (job sentence, hard rules, format, refuse, owner, three tests).
- Create the GPT on the web if you have paid create rights. If not, draft the instructions in a note and use plain chat until you do, or use a GPT that a teammate shares when policy allows.
- Run three real inputs in Preview, and fix the instructions one failure at a time instead of changing five settings at once.
- Keep sharing private for one real work cycle, then decide whether anyone else needs it.
What comes next in this series
The next post in the series, Instructions, knowledge files, and actions (light), goes inside the three layers you barely touched here. It covers how to structure instructions so they stick, how to keep knowledge files from going stale, and why actions are a deliberate later step with more risk. You also get a fuller instruction skeleton and a clearer point at which to stop at a text-only recipe.
Quick recap
- A Custom GPT is a saved ChatGPT recipe made of a name, instructions, optional knowledge files, and optional tools.
- Creating usually needs a paid plan such as Go or Plus, while Free users can often still use GPTs that others share.
- Your first GPT should cover one repeating job, use no actions and only non-secret knowledge, and pass Preview on three real inputs.
- The instructions are the spine of the GPT, so name it like a tool and own it like a process.
- GPTs do not replace Work, Codex, or real software, because each of those is built for a different kind of job.
Sources
Research and further reading used for this article:
- OpenAI Help: GPTs in ChatGPT (what GPTs include, create vs use, privacy notes, FAQ)
- OpenAI Help: Creating and editing GPTs (editor fields, instructions, knowledge, capabilities, actions, Preview, version history)
- OpenAI Help: Configuring actions in GPTs (why actions are a later step)
- OpenAI Help: Troubleshooting GPTs (instructions vs knowledge, Preview iteration)
- ChatGPT: Explore GPTs (create and browse entry point)
- OpenAI: ChatGPT product overview (plan and product context; re-check before policy)
- Analytics Made Simple: Learn ChatGPT from scratch
- Analytics Made Simple: ChatGPT product map
- Analytics Made Simple: ChatGPT everyday tutorial
- Analytics Made Simple: ChatGPT Work tutorial
- Analytics Made Simple: ChatGPT Codex tutorial
Keep going
Same lessons in your feed
Short diagrams, hooks, and weekly tutorials on Substack, Instagram, X, and Facebook.
