# The Forge guide Set up Dbrij Forge step by step: what you need, what to press, and how you know each step worked. Canonical page: https://dbrij.com/products/forge/guide ## Set up Forge, step by step By the end you have a working internal app in a repo you own, and a way to change it by describing the change. Before you start, have these ready - Forge, on its own or in the Builder suite from Starter. Your first app needs neither: one app is free. - AI credits for planning and changes. A free app comes with starter credits. - A Hosting plan from Starter, which includes the database. A free app runs a 7 day live preview without one. - A sentence about what the app keeps track of. 1. ### Describe it What it tracks, and what each thing has. Type it in the Build box, or pick one of the Or start from tiles to put a first sentence there for you to edit, then press Build it. [Open Forge](https://dbrij.com/forge) 2. ### Check the plan Records, pages and flows, before any code. Press Edit the plan to correct anything, then Looks right, build it. 3. ### Let it build Code to Source, then the database. The page shows each step and what Forge is doing; you can leave while it works. 4. ### Open and share it Send the link to your team. Open the app opens it in its own tab, and Open repository shows the code. You will know it worked when the app page says Live and Open the app loads your app. 5. ### Change it by describing Say what should be different in Change it and press Plan the change. Each change becomes a checkpoint you can put back. ## How each part works ### [What Forge is](#what-forge-is) Forge plans an app from your description, writes a real codebase into a Source repository you own, sets up the database, and keeps changing it as you describe changes. Nothing is proprietary, so there's no export step. Forge turns a description into a working app. You say what it should do, Forge writes a real codebase into a git repository you own on Dbrij Source, provisions a Postgres database beside it, deploys it on Dbrij Hosting, and hands you a URL that works. A booking tool, an inventory tracker, a simple CRM: the kind of app a business needs and a spreadsheet almost was. The difference from other app builders is what you are left holding. The code is yours from the first commit, in an ordinary repository you can clone, read and change by hand. There is no export step, because nothing is ever proprietary. ### [Describing an app](#describing-an-app) The best descriptions say what the app keeps track of, and what each of those has. For example: "a booking tool for a barber shop: services with prices, and appointments with a customer name and a time". A whole requirements document works too; a single sentence is enough to start. You can also add a picture: a spreadsheet you keep today, a paper form, or a screen of another app. Forge reads what it records, its columns, form fields and statuses, and plans the app from that and your words together. Reading a picture costs a few more AI credits than words alone. Forge plans before it builds, and the plan comes back to you as a spec you can read and correct. Nothing is generated on top of a misunderstanding, because the misunderstanding gets caught while it is still words. If the app is built under a company space, support and email can connect to it; built in your personal space, it stays yours alone. ### [What gets created](#what-gets-created) One confirmed plan produces three real things, none of them owned by Forge: - **A repository on Dbrij Source**, with the whole codebase in it from the first commit. The Open repository button on the app's page opens it. - **A Postgres database**, provisioned and migrated for you. The schema is applied by the release command against the real database before the app serves, so a migration that fails never ships the code that assumed it. - **A hosting deployment** serving at its own URL. It is ordinary hosting underneath, so attaching your own domain, scaling and reading logs are one click away in Hosting, not Forge features rebuilt. Inside the app itself: - **An overview page** that opens first: how many of each record, how many in each status, and what the money fields add up to. - **A page for each kind of record**, with a list, a form, search, a filter by status and a Download CSV button. - **Records that point at each other.** An order can name its customer, and the form offers the customers to pick from. Say it in the description, or choose Points to another list in the plan. - **Files and photos.** A field can hold an uploaded file, like a receipt or a product photo. The app gets its own private bucket in Dbrij Storage, and files count against your Storage plan. - **Messages when something happens.** Ask for it in the description, like "email me when a new order comes in" or "send the customer an SMS when their order is ready". Email goes from your company's verified address; SMS is paid from your Ping units. - **Payments.** Say people pay for something, like an order or a booking, and each record gets a payment link anyone can pay through. The money lands in your Dbrij wallet, less 2.5% plus ₦100 a payment (the ₦100 is waived under ₦2,500, and it is never more than ₦2,500), and you withdraw it from Money like any other balance. - **Lists that are private to each person.** Turn on Each person sees only their own, and every signed in person sees only what they added. The first person to sign up is the admin and sees everyone's. ### [Changing the app](#changing-the-app) Once the app is live, there are four ways to change it, from cheapest to most powerful: - **Edit directly.** Edit the plan, in the app page's more menu, reopens the plan for direct changes, which land as a commit with no model call. No AI, no credits. - **Ask for the change.** Describe what should be different in Change it and press Plan the change. Each change becomes a checkpoint, and any checkpoint can be put back in one click, so trying something is never a risk. - **Ask the code agent.** For anything the plan cannot express, such as wording, layout or behaviour, choose Anything else in Change it. You see the price before anything runs: what such a change usually costs and the most it can cost, and it stops before any step that could go past that. It reads the code, makes the change, checks it, and commits it as a checkpoint you can put back; the app builds on Dbrij Hosting as usual, never on Forge itself, and if that build fails it reads the log and tries one fix within the same price. It never touches secrets, lock files or a database migration that has already run. After its first change the app is edited as code, and from then on it makes every change. - **Change the code.** Clone the repository and edit by hand. It is an ordinary codebase. Once you push your own commits, the app moves to code mode: Forge stops rewriting files, so nothing you wrote is ever overwritten, and it keeps saving checkpoints, deploying, rolling back and publishing. Putting back a version Forge wrote, from Checkpoints, lets you change it by describing again. ### [Preview, publish and taking the code](#preview-and-publish) Turn on the preview in Preview and publish and every change lands on a copy of the app first, with its own copy of the data, while customers keep the version they have. Payments, SMS, email, support and uploads stay off in the preview, so trying a change never reaches a real customer. The preview runs as a second app on your Hosting plan. Publish checks the preview for security problems before it goes live, then gives customers exactly the build you tried. A clean check publishes straight away. If the check finds something worth reading you see what and where, and choose to fix it or publish anyway; a critical problem cannot be published. The check reads the code with AI, so it spends a few AI credits. Your code is yours to take at any time, subscribed or not. Download it as a zip from Your code, or copy it to your own GitHub with its whole history and every checkpoint, into a new private repository the first time and the same one after that. ### [Outgrowing the builder](#graduation) The day the app matters enough to hire a developer, nothing changes hands. The developer clones the same repository, works in a real codebase, and keeps deploying the same way every push already deploys. There is no export, no migration project and no rewrite, because the builder never held anything back. That is the graduation story in one line: outgrowing Forge costs nothing, because there is nothing to escape from. The repository, the database and the deployment were yours from the start, and they simply continue. ### [Good to know](#good-to-know) - Planning uses AI credits. - Every change is a checkpoint you can put back. - Built under your company, so support and email can connect. - **Your first app is free.** Without Forge you can build one app in your personal space, with starter credits to plan it and ask for changes, and a 7 day live preview with its database. After that it stops until your account is on a paid Hosting plan, and nothing is deleted. More apps, or apps for a company, need Forge. - **Planning and changes spend AI credits.** Planning an app and asking for a change are billed from your [AI credits](https://dbrij.com/ai-credits), and so are the code agent and the security check before publishing; building, deploying, direct edits to the plan and rollbacks cost nothing. - **The app itself bills as ordinary hosting**, under Hosting's own plans, exactly like anything else you deploy there. - Build under a company space if support or email should belong to the company; the space picked in the sidebar switcher is where the app lands. - Apps that sign people in open in their own tab rather than the embedded preview, because browsers keep sign in cookies out of embedded pages and the preview would always look signed out. - Access is granted per person on the [Access](https://dbrij.com/product-access/forge) page; the owner always has it.