How to build an AI content studio with Replit

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 replit.com, checked August 2026.

The first two are all you need to start. Everything here stays inside the one browser tab, the app included once you publish it, and the GitHub copy is the one deliberate exception.

1. 01

   One message for the app, Postgres, and the ground rules

   The Agent can create the app and provision the database beside it in the same breath. Spend the rest of the message on the two rules the build leans on.

   PromptSet up the projectCopy

   Create a new React 18 + Vite + TypeScript app with Tailwind and its own server, and add a Postgres database to this workspace. Keep the database connection string in Secrets, never in anything the browser downloads. Then write a short PROJECT_NOTES.md fixing the vocabulary for an AI content studio (workspace, asset, generation, prompt, brand kit, caption variant, post, preview) and recording two standing rules. First: my model provider key lives in Secrets and never reaches the browser, so every model call happens on my own server, and whatever comes back is written into object storage in this workspace before anything links to it, never a provider URL that expires. Second: every model call is logged and checked against a limit I configure before it is made, because each one charges my card, and a signed-in user is not a spending cap. Also note that because this workspace has no hosted identity service, my own server is what declares who is asking and which workspace they are in before any request touches a table. Start the app so I can see it boot.

   That last sentence carries more weight here than on the other tools. Nothing is going to hand the database an account on your behalf, and a policy reading a declaration nobody made does not complain. It admits everybody, and on this app what it admits everybody to is a button that spends your money.

2. 02

   Schema, sign-in and the boundary, at a checkpoint

   One idea rather than three on this app. Take a checkpoint once it is right, because everything after reads this shape.

   PromptModel it and draw the boundaryCopy

   Write the data model in the workspace Postgres with a workspace reference on every table. 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, caption, hashtags, asset ids and a preview configuration. Caption variants belonging to a post with a primary flag. A brand kit per workspace with colours, a logo path and a voice paragraph. A generations log with the account, model, prompt, size, quality, outcome and estimated cost. Then email-and-password sign-up, login, logout, and sessions my own server issues and verifies, with a workspace and profile created per new account. Then row-level security on every table, and because nothing hosted is handing Postgres an account here, have my server declare the requesting account and its workspace before each request touches a table, and write every policy to read that declaration. Rows are reachable only from the declared workspace, with explicit with-check clauses on inserts and updates, and the profile update rule must forbid changing which workspace it points at. Then prove three things with a second account: it cannot read the first workspace’s assets, it cannot read its posts, and a request arriving with no declaration at all is refused rather than treated as trusted.

   That third check is specific to this tool and it is the one to be stubborn about. A policy reading a declaration nobody made fails open rather than loudly. Ask the Agent to show you a request with the declaration deliberately missing, and watch it be refused before a single generated asset exists.

3. 03

   Generation on your own server, capped in the same message

   The feature and its limit together. On this tool the server holding the key and the server enforcing the ceiling are the same one, which makes the pairing natural.

   PromptGenerate one image, with a ceilingCopy

   Build image generation as a route on my own server with the provider key in Secrets and nowhere else, together with its limit. It takes a prompt, a size and a style, requires a signed-in session and refuses otherwise, and before calling the model it writes to the generations log and checks two configurable limits (per account over a rolling window and a workspace total) returning a clear limit message rather than an error. The limit and the cost estimate are computed on the server and never accepted from the client. When the model answers, handle both base64 in the body and a URL, write the bytes into object storage in this workspace, and insert an asset row with the prompt. Uploaded and generated files are reachable only through my own server, never a public URL. Then a screen with a prompt box, a size and style picker and the result. Show me an image generated end to end, the file in this workspace’s object storage, and the limit refusing an eleventh call when I set it to ten.

   Set the limit low and watch it refuse before you explore anything. And take a checkpoint straight after this works: a rollback here restores the files, the configuration and optionally the database together, which on a build whose assets cost money to produce is worth more than a code-only undo.

4. 04

   The library, uploads, and describing a change

   The grid, your own photographs beside the generated work, and a second model path with one rule attached to it.

   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 object storage and the same table, differing from a generation only by the source field, and served through my own server rather than a public link. Then the edit path: a route taking an existing asset and a description of a change, calling the image model in edit mode, and saving the result as a new asset that records the original it came from and the instruction given (never overwriting the original) going through the same log and ceiling as step 03. Add a crop tool and simple adjustments done locally with no model call, and make an uploaded video preview rather than show a broken thumbnail. Then show me an edit whose original is still in the library.

   Ask for the original to be kept explicitly. Overwriting is the natural implementation, and on this build the thing being overwritten is an image you paid to generate, which makes it the one data-loss bug here with an actual price attached.

5. 05

   Three caption options, and a brand kit worth the twenty minutes

   The writing half. Everything here is straightforward except the paragraph you have to write yourself.

   PromptAdd captions, hashtags and the brand kitCopy

   Build the brand kit screen first: colours, a logo upload into object storage, and a paragraph describing how I want to sound, stored per workspace. Then caption generation as a route on my own server taking a post and its selected assets, sending my brand voice paragraph word for word with the title, and returning three distinct caption variants stored as rows against the post with one marked as chosen, not a single field overwritten each call. Then hashtag suggestions from the caption I kept rather than the title. Both go through the same log and ceiling as the image routes, with the provider key read from Secrets. In the interface show the three variants together with my choice marked and let me edit any by hand, and never rewrite something I have typed unless I ask.

   Write your brand paragraph before you run this. It goes into every caption request, so it moves the output more than anything else you can change, and no assistant can write it for you, because it is a description of you.

6. 06
   Destination

   The frames, the download, and publishing what you built

   The previews made accurate, a file you can post, the spend checked against the provider, and only then a release.

   PromptBuild the previews, the export, and rehearseCopy

   Finish the app. The post builder: a title, assets 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. Each frame right rather than roughly right: real aspect ratios, the caption truncation each network applies, and a visible warning when the image does not match the selected platform’s ratio. Then a per-platform download of the rendered post, and a dashboard with recent assets, recent posts and this period’s generation count and estimated spend. Then make one real post with me: generate, edit once, three captions, choose one, hashtags, preview on the two networks I use, download it, and compare the dashboard spend against my provider’s own usage page. Finally, tell me which deployment type this app needs, confirm the ceiling is enforced on the published version and not only in the workspace, and tell me what Publishing is about to make visible and to whom.

   Ask those last three before you press publish. A published generation route with the ceiling left behind in the workspace is the one mistake on this build that arrives as an invoice rather than a bug report, and reviewing who the app is visible to is a setting most people meet for the first time after the address is already out.

One rule outranks the rest here: the database connection string and the model provider key live in Replit’s Secrets and nowhere else: not in anything the browser downloads, and not 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 of these are Replit rather than a third party, so the choice is shape rather than vendor. Review who the app is visible to before the first release, since Publishing is what sets it, and on this application that setting decides who can spend against your provider key.

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.

A cheap model is plenty for most of the prompts above. Save Pro’s stronger models for the one or two spots where the extra reasoning actually pays for itself. Add any provider key through Replit’s own Secrets tool rather than hard-coding it, and keep every AI feature behind one server-side function so a single key covers the whole app.