How to build a startup directory website with OpenAI Codex

Rule of thumb: if you want a directory this week and do not care whose software it runs on, rent one. Brilliant Directories or eDirectory will have you live before this guide is finished. If the directory is the product, or the thing that brings people to your newsletter, your fund or your community, the shelf is worth owning, because the meters above are exactly where a growing directory pays and a curated list of companies with their rounds is an asset you should be able to move, export and redesign at will. The honest middle case is a directory whose value is somebody else’s data. There the answer is a subscription, because you may read Dealroom’s rounds and you may not republish them.

* On this template the free-tier lines to watch are images and the pause. The free plan includes 1 GB of file storage, and a cover or gallery image may be up to 10 MB, so a directory with a few hundred companies and their pictures reaches it. It also pauses a project after a week without activity, and a directory nobody edits for a week is normal. Pro, from $25/mo, lifts storage to 100 GB, ends the pause and keeps a daily backup for 7 days, with spend caps on by default.

Prices and rates from supabase.com, developex.com and learn.chatgpt.com, checked September 2026.

Nothing here is worth memorizing. These four just need to exist on your machine. From step 01 on, you say what you want and Codex runs the commands.

1. 01

   Write AGENTS.md before anything is scaffolded

   Codex loads AGENTS.md at the start of every task, so the two rules that matter most on this build (drafts are hidden by the database, only admins write) are loaded before any code exists to break them.

   PromptSet up the projectCopy

   Start by writing an AGENTS.md at the project root: the stack is React 18, Vite, TypeScript, Tailwind and the Supabase JS client, and this project is a startup directory with news and a funding tracker. Fix the vocabulary (startups, funding rounds, categories, tags, articles, admins) and record two standing constraints: nothing is public until its status is published and the database enforces that rather than the screen, and only an admin may add, change or delete anything. You load that file automatically at the start of every later task. Then scaffold the project: a typed Supabase client under src/lib reading VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key that replaced the older anon key) from .env, with .env confirmed present in .gitignore.

   The two constraints are the ones worth writing down. Filtering drafts in the component and letting any signed-in user edit are both reasonable-sounding shortcuts, and both leak on the first day a stranger tries.

2. 02

   Have Codex write the schema and the public rules, and read the SQL before it runs

   Ten tables and a trigger, then the half of the access rules that decides what a stranger sees. Everything later reads these tables, which is exactly why they are worth reading rather than approving on trust.

   PromptWrite the data model and the public rulesCopy

   Write the migrations for this site and show me the SQL before running it. Categories and tags with a name and slug. Startups with name, slug, short and long descriptions, a category, a funding stage from a fixed list (Seed, Series A through Series E+, IPO, Grant, Acquisition), a published or unpublished status defaulting to unpublished, an archived flag, logo and cover addresses, a gallery, team size, city and country, external links, and total_funding and funding_amount_latest columns. A startup_tags join table and a startup_social_links table. Funding rounds with stage, amount, date, lead investor, co-investors, valuations and notes, and a trigger that recalculates the startup’s total and latest raise on insert, update and delete. Articles with title, slug, body, featured image, category, author, status and published date, and a news_tags join table. Enable row-level security everywhere and write the public half: anyone may read categories and tags, a startup and its rounds and links when published and not archived, and a published article. Seed three companies with a round each, one unpublished, and show me an anonymous query returning two.

   Reading the SQL here costs ten minutes. Finding a draft on the public site after a hundred companies are in costs a support conversation with every founder who saw it.

3. 03

   Narrow permissions, then add sign-in, roles and the admin gate

   This task touches authentication and the rules that let an admin write, which is exactly the kind of change worth scoping Codex down for rather than leaving whatever settings you use for routine edits.

   PromptAdd auth, roles and the admin rulesCopy

   This task touches authentication, so narrow your permissions to just this one. Wire in Supabase Auth with email and password: a sign-in screen, logout, a persisted session and a useUser hook, and no public sign-up screen. Add a user_roles table with admin and viewer roles, a security-definer has_role function, and a trigger that gives every new account a profile row and the viewer role. Write the admin half of every access rule so an admin may read, add, change and delete every row in every table, drafts included. Build an admin layout that redirects anyone without the admin role to sign-in. Give me the one SQL statement that promotes my account, and show me that a viewer sees exactly what an anonymous visitor sees.

   Two roles, and the viewer can do nothing the public cannot. One clean line between the public and the admins beats three roles with a gap.

4. 04

   Give the directory its own task, and the funding page the next one

   The public side is the screen visitors live on and the funding page is a second view of the same rows. Keep them as two tasks so each change is small enough to read.

   PromptBuild the directoryCopy

   Build the public directory page: a grid of company cards with the logo, name, one-line description, category, stage and total raised, a filter sidebar with search over name and description, categories, funding stages, a minimum and maximum amount raised and a location field, a sort menu (newest, oldest, most funded, least funded, A to Z, Z to A), and a live result count with a clear-all button. A card opens a detail view with the full description, links and the rounds in date order, at an address of its own so it can be shared. Read only published, unarchived companies. Walk me through the component structure before you build it.

   PromptBuild the funding pageCopy

   Build the funding page: every round with its company, stage, amount, date and investors, filterable by stage and by a maximum amount, sorted by amount by default, reading only rounds whose company is published and not archived. Add a link from each row to the company’s own address.

   Ask for the address per company in the first task. The template opens a panel instead, and it is the second decision above for a reason.

5. 05

   Build the news section and the admin, two tasks again

   Articles with a page each, then the back office: one screen per table, four buckets with limits, and the one function that checks a logo before it is stored.

   PromptBuild the news sectionCopy

   Build the news section: a list of published articles with the featured image, title, category and date, and a page per article at /news/its-slug showing the featured image and the body with its line breaks kept, reading only published rows.

   PromptBuild the admin and the image storageCopy

   Build the admin behind the admin layout: a dashboard with counts of startups, articles and accounts, a startups screen with add and edit dialogs, add a funding round, publish or unpublish, archive, and delete a company together with its rounds, links and tags, then articles, categories, tags, and a users screen where a role is switched between admin and viewer. Create four storage buckets (logos up to 5 MB, covers, gallery and article images up to 10 MB, image types only), readable by anyone and writable only by admins. Write an upload-logo edge function that verifies the caller’s session and admin role, checks the startup exists and the file is under 5 MB, uploads with the service key and writes the logo address to the startup. Other images upload directly under the bucket rules.

   Read the delete. A company that leaves the directory must take its rounds, tags and links with it, and it is one line in the schema to get wrong.

6. 06
   Destination

   Hand the landing page and the meta to a cloud run, then test it yourself

   The marketing page, the titles and share cards, and demo mode are self-contained and well specified, a reasonable set to hand to a cloud run while you do something else, provided you read the change before it merges.

   PromptAdd the landing page, demo mode, and testCopy

   Three remaining pieces. A marketing landing page with a hero, a sector section, a funding section, a trends section and a closing call to action, written as copy I can edit rather than pulled from the database. A title and description and a share card for every public page. A demo mode switch on the sign-in screen that opens the admin with every write intercepted in the browser and a banner saying changes are not saved. When they are in, run the site and take it end to end yourself as a stranger: confirm the unpublished company from step 02 is nowhere, confirm an article address opens directly, confirm the admin redirects to sign-in, then sign in, publish that company, and confirm it appears, and fix whatever does not hold up.

Review the access rules (row-level security policies) on every table. For each one, tell me in simple terms who can view, add, edit, and delete records, confirm that people can only reach their own data while the right roles can reach more, and flag anything left open that shouldn’t be.

One rule outranks everything above it: your database service key belongs on the server only, never in the app a visitor downloads and never in a repository. The publishable key is meant to be public and the access rules are what protect the data behind it, so if the service key escapes, treat it as compromised and replace it the same day.

Two things decide this, and speed is not one of them. Does the plan allow commercial use, since a directory that runs ads, sells listings or belongs to a fund is a business and Vercel’s Hobby tier is not for one. And does a link to a single article open that article for someone arriving cold, because every host here needs one routing rule for that and the template ships the Vercel version. The host serves one small static folder. Every listing comes from your database.

Add a server-side function called ai that calls my AI provider with the key held in function secrets, never in the browser. It accepts a task name and the text or fields for that task, refuses any caller who is not a signed-in admin, records every call in an ai_calls table (who, which task, tokens in and out, a cost estimate, success or failure), and returns the model’s answer as structured fields the admin screens can fill in. Add a small usage panel to the admin dashboard showing calls and estimated spend this month.

In the add-startup dialog, add a “Draft from website” button that sends the company’s homepage text to the ai function and gets back a one-line and a paragraph description, a suggested category from my categories table, up to five tags, the city and country, and any social links it found. Fill the form with the results for the admin to edit, and never publish anything automatically.

Add a “From announcement” action on the news screen that sends pasted text to the ai function and gets back a draft article (title, slug, body) and, if the text describes a raise, a funding round (stage from my stage list, amount, date, lead investor, co-investors). Show both as prefilled forms for the admin to confirm, match the article to a startup by name with a confirmation step, and leave both unpublished until the admin publishes them.

When an admin saves a startup or an article without tags, call the ai function with the description and get back a suggested category from my table and up to five tags, preferring tags that already exist. Show them as chips the admin accepts or removes before saving, and add a “Suggest tags” button on existing records so the back catalogue can be tidied a page at a time.

Add a “Weekly digest” button on the admin dashboard that gathers the startups, rounds and articles published in the last seven days and asks the ai function for a short digest with a headline, one paragraph, and a bullet per raise with the amount and stage. Save it as an unpublished article and offer a copy-as-text button, since this site does not send email.

Each prompt above should pick whichever model tier fits the job: a fast, lower-cost model for high-volume work, and a stronger reasoning model for anything that weighs tradeoffs against each other. Codex’s model names change faster than this page does, so check OpenAI’s current model line-up (linked in the references below) before you build, rather than copying a name you saw once. Keep all of it behind that same ai function, so one key and one rule set covers every feature you add.