How to build an AI content studio with Claude Code

Rule of thumb: if what you need is posts going out on a schedule to several accounts, with analytics afterwards and somebody else absorbing each platform’s API changes, rent, and Buffer’s free tier in particular is hard to argue with for one person and three channels. If what you need is a lot of generations in your own brand, kept in your own library, at the provider’s price rather than a credit bundle’s, that is the half worth owning. The comparison that decides it is arithmetic you can do in a minute: work out how many images you would actually generate in a month, price them at your provider’s rate, and hold that against $19 for about eighty-six. Below a few dozen, renting wins on effort alone. Well above it, the credit bundles are the expensive part, and the thing you have to build in exchange is the ceiling those bundles were quietly providing.

* On this template the free-tier line to watch is the 1 GB of file storage rather than the database. Generated images accumulate faster than anything else in this catalogue, and a few hundred of them will pass it. Pro, from $25/mo, takes file storage to 100 GB (then $0.0213 per GB) and egress to 250 GB (then $0.09 per GB), and keeps a daily backup for 7 days. It also ends the pause, which matters here for a dull reason: a free project sleeps after a quiet week, and a studio you open when inspiration strikes is exactly the sort that goes quiet.

A credit bundle is the pack of generations a rented studio sells you each month, and neither column above buys one, because your own provider key is billed at the provider’s list price instead. What that leaves is a difference in which line grows. Renting means a monthly floor and a credit allowance that runs out in a busy week, whichever way your usage goes. Owning means a small fixed bill and a provider charge that tracks exactly what you made, cheaper on a quiet month, and genuinely open-ended on a busy one unless you have set a limit. That trade suits somebody making a lot of content, which is the only reason to build this at all.

Prices and rates from supabase.com, developex.com and claude.com, checked August 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 Claude Code runs the commands.

1. 01

   Boot it, then write down the two rules that keep this build honest

   An app running against your own database, and a CLAUDE.md holding the two constraints everything after this leans on.

   PromptSet up the projectCopy

   Set up a new React 18 + Vite + TypeScript project with Tailwind and the Supabase JS client. Read VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key, which replaces the older anon key) from .env, and add .env to .gitignore in the same step so neither value reaches GitHub. Add a typed Supabase client under src/lib, then write a short CLAUDE.md describing the stack and fixing the vocabulary for an AI content studio (workspace, asset, generation, prompt, brand kit, caption variant, post, preview) and recording two standing rules. First: a model provider key never reaches the browser, so every call to a model happens in a server-side function, and whatever that function gets back is written into my own storage before anything links to it, never a provider URL that expires. Second: every model call is logged and counted against a limit before it is made, because each one is a charge on my card, and a signed-in user is not a spending cap.

   Put both in the file rather than only in this message. The second one is the rule an assistant will not infer: asking for a generation feature gets you a generation feature, and nothing in the request implies that pressing the button forty times in a test should cost anything.

2. 02

   Model it, sign in, and draw the workspace boundary once

   The schema, the accounts, and the rules keeping one workspace out of another, together, because on this app they are one idea rather than three.

   PromptModel it and draw the boundaryCopy

   Write the data model as Supabase migrations, with a workspace reference on every table from the start. Workspaces. Profiles linking an account to exactly one workspace. Assets with a type, a source of generated, ai-edited or uploaded, a storage path, dimensions, a mime type, and the prompt that produced it. Posts with a title, a caption, hashtags, the asset ids used, and a preview configuration. Caption variants belonging to a post with a flag for the one I chose. A brand kit per workspace holding colours, a logo path and a paragraph describing the voice to write in. A generations log with the account, the model, the prompt, the size and quality, whether it succeeded and an estimated cost. Then add Supabase Auth with email and password: sign-up, login, logout, a persisted session, and a trigger that creates a workspace and a profile for a new account. Then row-level security on every table: rows are reachable only from the workspace the person belongs to, with explicit WITH CHECK on every insert and update, and the update rule on the profile row must forbid changing which workspace it points at. The row you may edit is not the same question as what that row may become, and this column is what every other rule resolves to. Prove it before moving on: two accounts in two workspaces, and show me that the second cannot read the first’s assets or posts.

   Insist on that proof as a query you watch fail. Every mistake in a workspace boundary is invisible while there is only one workspace, and a second account with its own content in it is the cheapest test instrument in this whole build.

3. 03

   Generate one image, and cap it in the same breath

   The feature this app exists for, and the limit that stops testing it becoming expensive. Ask for both in one prompt so there is never a version of this code without the ceiling.

   PromptGenerate one image, with a ceilingCopy

   Build image generation as a server-side function, with my provider key in the function’s secrets and nowhere else. It takes a prompt, a size and a style, requires a signed-in user and refuses with a 401 otherwise, calls the model, and then (this is the part I want done carefully) handles the response arriving either as base64 in the body or as a URL, writes the bytes into my own storage under the workspace, and inserts an asset row with the prompt that made it. Never link to a provider URL. Before it calls the model at all, it writes a row to the generations log and checks two limits I can configure: how many generations one account may make in a rolling window, and a workspace total. Over either, it returns a clear "you have reached your limit" and does not call the provider. The limit and the cost estimate are read on the server, never sent by the client. Then a screen with a prompt box, a size and style picker, and the result. Finally, show me three things: an image generated end to end, the file sitting in my own storage rather than the provider’s, and the limit refusing an eleventh call when I set the limit to ten.

   That last check is the one to insist on, and to run yourself. It is also the one moment in this series where a test costs money, so set the limit low (ten is plenty) and watch it stop you. A ceiling you have not seen refuse anything is a ceiling you are hoping is there.

4. 04

   The library, uploads, and editing what you already have

   Somewhere for the output to live, your own photographs beside it as equals, and a second generation path for changing an image by describing the change.

   PromptBuild the library and the editorCopy

   Build the asset library over the assets table: a grid with filters by type and source, the prompt shown on each generated asset, a detail view, and delete. Add uploading my own files into the same library and the same storage, so an upload and a generation differ only by their source field. Then the second generation path: an edit function that takes an existing asset and a description of a change, calls the image model in edit mode, and saves the result as a new asset that records both the original it came from and the instruction I gave, never overwriting the original. It goes through the same log and the same ceiling as step 03. Add a crop tool and simple adjustments that work locally without a model call, and make sure the library also previews an uploaded video rather than showing a broken thumbnail. Then show me an edit that keeps the original, and confirm the edited file is in my storage too.

   Ask for the original to be kept explicitly. Overwriting is the natural implementation and it is the one you regret, because the point of an AI edit is that two out of three are worse than what you started with.

5. 05

   Captions as three options, and a brand kit worth having

   The writing half. The interesting decisions here are asking for choices rather than an answer, and getting your own voice into the request.

   PromptAdd captions, hashtags and the brand kitCopy

   Build the brand kit screen first: my colours, a logo upload into storage, and a paragraph describing how I want to sound, all stored per workspace. Then caption generation as a server-side function that takes a post and the selected assets, sends my brand voice paragraph verbatim along with the title, and returns three distinct caption variants, stored as rows against the post with one marked as the primary, not one string overwritten each time. Then hashtag suggestions that run from the caption I actually kept rather than from the title. Both go through the same log and ceiling as the image calls. In the interface, show all three variants side by side with the chosen one marked, and let me edit any of them by hand afterwards. Do not have the model rewrite anything I have typed unless I ask.

   Write your brand paragraph properly before you run this, even if it takes twenty minutes. It is the highest-leverage text in the whole application (it goes into every request) and no amount of prompt engineering downstream compensates for "professional but friendly".

6. 06
   Destination

   The five previews, the export, and one real post end to end

   The post builder, frames that match what each network actually does, a file you can publish, and then the part most builds skip: make something you would genuinely post.

   PromptBuild the previews, the export, and rehearseCopy

   Finish the app. The post builder: a title, assets chosen from the library, the caption and hashtags from step 05, and a preview switching between Instagram, X, Facebook, LinkedIn and TikTok, with the aspect ratio and feed type stored on the post. Get each frame right rather than approximately right: the correct aspect ratios, the caption truncation each network actually applies, and a visible warning when my image does not match the ratio for the platform I have selected. Then a per-platform download of the rendered post as an image file, and a dashboard showing recent assets, recent posts and the current period’s generation count and estimated spend. Then walk me through one real post end to end: generate an image, edit it once, write three caption variants and pick one, add hashtags, preview it on the two networks I actually use, download it, and check the dashboard’s spend figure matches what my provider’s own usage page says.

   Do that last comparison against the provider’s dashboard rather than trusting your own number. An estimate that drifts from the real bill is worse than no estimate, because you will make decisions on it, and the first week is when the arithmetic is easy to check.

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 the rest here: the database service key and the model provider key belong on the server only: never in the app your team downloads, and never in a repository. Either one that gets out is burned, and the provider key is the one somebody will actually spend: replace it the same day and check your usage dashboard for what was done with it.

All eight serve the app well enough that speed is not the deciding question. Three others are: whether the plan permits commercial use, since Vercel’s Hobby tier does not. Whether it publishes from a private repository, given the key sitting next to this code. And whether a deep link resolves for a browser that has never seen your site, because a link to one asset is what you will paste to somebody asking which picture you meant.

Add a generations table that records every model call (who made it, which workspace, which model, the prompt, the size and quality asked for, whether it succeeded, and a cost estimate) and write to it from all four AI functions, images included. Then add a ceiling: a limit per person per rolling window and a workspace total, both settings I can change, checked inside each function before it calls the provider and returning a clear "you have reached your limit for today" rather than an error. Add a small usage panel showing calls and estimated spend for the current period, by person. Do not let the client send the limit or the cost. Both are read on the server.

Add a "make a set from this" action on an asset. Take the stored prompt, generate the same subject at each aspect ratio I have platforms for, and show them as a group I accept or discard together, with the cost estimate for the whole set shown before I confirm. Reuse the ceiling from the generations table so a set counts as its number of images and not as one. Keep the group linked to the original asset so the library shows them together rather than as five unrelated pictures.

When drafting a caption, send the selected image to the model alongside my brand kit and any title I have written, and ask for three variants that refer to what is actually in the picture. Keep all three against the post and mark the one I choose. Send the brand voice paragraph verbatim and nothing else about my other posts. Where the image is ambiguous, have it say so in a short note beside the variants rather than inventing a detail. A caption confidently describing something that is not in the photograph is the failure worth designing against.

Add a pre-export check on a post. Compute what you can (caption length against each platform’s limit, hashtag count, whether the image matches the aspect ratio for the chosen feed type) and show those as plain pass or fail with the actual numbers. Then send only the caption and the platform to my ai function for one line on anything that reads badly for that audience. Never rewrite my caption automatically, never call the model for the arithmetic, and show which checks are computed and which are an opinion.

Add a panel that answers questions about my own library and posts. Compute the figures with queries (assets by type and month, generations that never made it into a post, which caption variant position I choose most often, the prompts I have reused) and use the model only to describe what the numbers suggest. Show the query and the counts under every answer, state the period, and where the sample is too small to mean anything, say so instead of finding a pattern in nine posts.

Each prompt above picks the model that fits the job. As a rule of thumb, that is Haiku for high volume, Sonnet for everyday writing, and Opus for deeper reasoning. Model names move faster than this page does, so check the current list in the Claude docs (linked in the references below) before you build. Send every one of these prompts through that same ai function, so one key and one set of rules governs all of them.