Guides ChatGPT published jul 18, 2026
In this guide, you will learn how to turn one public API into a small hosted web app with ChatGPT Sites. You will create a product plan, build an MVP, and deploy it as a site people can actually use.
You will build a mini-SaaS with one clear job. Our example is WeatherLedger: a tool that uses weather data to show contractors the best hours to work at a jobsite.
In the Sites menu, you can see and track web analytics for your deployed apps all in one place. This is also where you can add custom domain names.
Once the first version is working, expand intentionally. Add only the next feature that helps the same user get the same outcome faster or more reliably. A small app that does one job well is a much stronger starting point than a large product plan.
Open the Public APIs list (https://github.com/public-apis/public-apis). It is a huge list of mini-SaaSes waiting to be built. Pick one API to build your mini-SaaS around.
We used weather data to create WeatherLedger. It takes a jobsite and turns the forecast into a recommendation for when contractors can work.
If you do not know which API to choose, pick a couple that look interesting, give them to ChatGPT, and ask it for a good mini-SaaS idea. That is how we came up with WeatherLedger.
Before you commit, open the provider's documentation and terms. The Public APIs list is a discovery tool, not the source of truth. Confirm the required inputs, free-tier limits, attribution rules, and whether the API fits the use you have in mind.
Tell ChatGPT to turn the API and your idea into a PRD. Ask it to plan only, not code. You want a clear product promise, the smallest possible user flow, the API inputs and data you need, a few acceptance checks, and a list of what to leave out.
Use a prompt like this:
Plan, but do not build yet, a mini-SaaS that uses [API NAME] for [AUDIENCE].
The one job it must do is: [CORE JOB].
Return:
- a one-sentence product promise
- the smallest user flow
- required API data and inputs
- a distinct brand and UI direction
- three acceptance checks
- a short list of features to keep out of version oneFor WeatherLedger, the plan was simple: a contractor selects a jobsite and sees the best work window based on weather conditions. We left out accounts, billing, a database, and every other feature that did not help answer that one question.
Pro tip: Approve the plan before you build. A good-looking landing page is not the same thing as an interactive app that completes the job.
Switch to Codex and give it the approved plan. Ask it to build the MVP, track the project with Git, and include the Sites plugin from the start.
You can keep the request direct:
Build the MVP from this approved plan: [PASTE PLAN].
Keep the first version focused on the core user flow. Use Git to track the project and include the Sites plugin from the start. Use live data from [API NAME], add a useful error state, run the available checks, and open the preview when it is ready.Review the preview before you publish. Test the main user flow with live data and make sure the app gives a useful answer, not just a polished screen. In our example, that means WeatherLedger needs to return a readable work-window recommendation from real weather data.
Once you are happy with the preview, tell Codex to deploy the site with Sites.
You can deploy it privately so only people on your team can use it, or deploy it publicly so anyone can visit it. In the Sites sidebar, you can see and manage these deployments.
Use the narrowest access setting that fits the test. Then open the live URL and repeat the core workflow one more time. A deployment URL is a real hosted version of the app, so it should show the behavior you expect before you share it.
Keep going
Members get all guides, courses, live sessions, and $1,000+ in partner perks.