How to build an AI content studio with Bolt

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 bolt.new, checked August 2026.

The GitHub step comes before Bolt exists for you at all. Everything after it happens inside the browser tab Bolt opens, with no install.

1. 01

   The repository, then two rules written into a file

   Bolt cannot open a folder or a zip, so the way in is a repository. Once imported, the first prompt writes down the two constraints everything after it depends on.

   PromptSet up the projectCopy

   This repository is a new React 18 + Vite + TypeScript project for an AI content studio. Add Tailwind and the Supabase JS client, with a typed client under src/lib reading VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key that replaced the older anon key) from .env, and confirm .env is in .gitignore so neither value is committed. Then write a short PROJECT_NOTES.md fixing the vocabulary (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 model call happens in a server-side function, and whatever comes 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 checked against a limit I configure before it is made, because each call charges my card and a signed-in user is not a spending cap. Start the dev server so I can see it boot.

   Keep both rules in the file rather than only in the chat. Clearing Bolt’s context between features is the cheapest way to keep prompts small on a build this size, and anything that lived only in the conversation goes with it.

2. 02

   Plan the schema out loud, then build it with the boundary

   The one step where arguing is cheaper than generating, and on this app the schema, the accounts and the workspace rules are one decision rather than three.

   PromptModel it and draw the boundaryCopy

   Use Plan Mode before writing anything. I want the schema as Supabase migrations 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. In the plan, tell me two things before I approve: how an AI edit will relate to the asset it came from, and how the generations log will be structured so a limit can be checked against it cheaply. Once I approve, write the migrations, add email-and-password auth with a workspace and profile per new account, and turn on row-level security everywhere: rows reachable only from the person’s workspace, explicit WITH CHECK on inserts and updates, and the profile update policy forbidding a change to which workspace it points at. Then prove with two accounts that the second cannot read the first’s assets.

   Settle the edit relationship in the plan rather than after it. Whether an AI edit is a new row pointing at its original or an update to the existing one is a two-line difference that reads fine either way and quietly destroys the version you liked, and on a token meter you pay twice for discovering it late.

3. 03

   Generation and its ceiling, checked in the running app

   The feature and the limit in one prompt. The running app makes this satisfying and, on this build, expensive, which is the whole reason the cap comes first.

   PromptGenerate one image, with a ceilingCopy

   Build image generation as a server-side function with my provider key in its secrets and nowhere else, together with its limit. It takes a prompt, a size and a style, requires a signed-in user and refuses with 401 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 when either is reached. The limit and the cost estimate are worked out on the server and never accepted from the client. When the model responds, handle both base64 in the body and a URL, write the bytes into my own storage under the workspace, and insert an asset row carrying the prompt. Then a screen with a prompt box, a size and style picker and the result. In the running app, show me an image generated end to end, the file in my own storage rather than the provider’s, and the limit refusing an eleventh call when I set it to ten.

   Set the limit to ten before you start testing in the preview, and watch it refuse you. Every other build in this series lets you press the button as often as you like while you check it works. This one bills you for each press, and the running app makes pressing it very easy.

4. 04

   The library and the edit path, with context cleared first

   The grid, your own uploads, and a second generation path. Barely overlaps with the generation prompt, so clearing context is both cheaper and safer.

   PromptBuild the library and the editorCopy

   Clear your context, then 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, differing from a generation only by the source field. Then the edit path: a function 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 I gave (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 render a broken thumbnail. Then show me an edit in the running app whose original is still there afterwards.

   Point this prompt at the library components and the edit function specifically rather than letting it read the whole project. It keeps the prompt cheap and it stops Bolt helpfully revisiting a generation function you had just got working.

5. 05

   Captions as three options, and the brand kit behind them

   The writing half, and the twenty minutes of your own work that improves every caption the app will ever produce.

   PromptAdd captions, hashtags and the brand kitCopy

   Build the brand kit screen first: colours, a logo upload into storage, and a paragraph describing how I want to sound, stored per workspace. Then caption generation as a server-side function taking a post and its selected assets, sending my brand voice paragraph word for word along 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 on each call. Then hashtag suggestions from the caption I actually kept rather than the title. Both go through the same log and ceiling as the image calls. In the interface show all three variants together with my choice marked and let me edit any of them by hand, and never rewrite something I have typed unless I ask.

   Write the brand paragraph yourself before running this. It is sent with every request, so it does more for the output than any change to the prompt around it, and it is the one input no assistant can produce for you.

6. 06
   Destination

   The five frames, the download, then publish the app

   The previews made accurate, a real file at the end, the spend checked against the provider, and only then a deploy.

   PromptBuild the previews, the export, and rehearseCopy

   Finish the app. The post builder: a title, assets picked 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 environment values I have to set on the host (the provider key included) and confirm the ceiling is enforced on the deployed functions rather than only locally.

   Ask that last question before you tell anybody the address. A ceiling that exists only in your local copy is not a ceiling, and a deployed generation endpoint reachable by everybody you have given an account to is the one mistake in this build that arrives as an invoice.

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.

Pick a lighter model for the high-volume prompts above and save a stronger one for wherever the reasoning actually matters. That is the same token-budget logic as the rest of this page, applied to the app’s own AI calls instead of the build itself. When Bolt flags a missing secret, add the key through its secrets settings instead of pasting it into the chat, and keep every AI feature behind one server-side function so there’s only one key to manage.