Build an internal tool or back office with AI (sign-in and roles)
A leave, supply or repair system built with AI: sign-in, roles, database, a ready prompt, the steps onto BrewInTH and a checklist before staff use it.
Plenty of companies still request leave over chat, track stock in a spreadsheet that gets emailed around, or report repairs on paper. The data is scattered and nobody is sure who approved what, or when. Ready-made systems cost real money and rarely match the way the team works.
This guide walks through building a back office or internal tool with AI: planning the structure, writing the prompt, and putting it online on BrewInTH so staff can sign in and use it. The example is a leave-request system for a 15-person company with three roles: employee, manager and administrator.
In short
✅ Internal tools suit AI-built software well: few users, a clear job, and you can shape it to how your team works
✅ Four things it must have: sign-in, roles, a database, and a history of who did what and when
✅ Permissions are checked on the server on every request; hiding a button is not enough
✅ On BrewInTH you pick the database when creating the project, the connection values are written for the app, and the site has HTTPS from the start
✅ Before the team uses it: no self sign-up, no portal listing, and backups switched on
What an internal tool is, and why AI is a good fit
An internal tool is a website used inside an organisation, not by the public. For example:
- leave requests and approvals;
- supply or expense requests;
- repair tickets and job tracking;
- office stock or equipment lists;
- a back office for orders or a customer list.
This is ideal vibe-coding work. There are a few dozen users at most, it does not need to look fancy, only to be easy and correct, and you know your team's process better than anyone, so you can tell the AI exactly what you need.
What a good back office needs
Whatever the system does, the skeleton is the same four parts:
- Sign-in. Everyone has their own account. Passwords are stored as one-way hashes, never as plain text.
- Roles. Who can see and do what: an employee sees only their own records, a manager sees the team's.
- A database. One central store, so everybody looks at the same data.
- History. A record of who created, changed or approved what, and when. Nothing is truly deleted; records are cancelled or hidden instead.
Permissions are where things most often go wrong. An AI will sometimes just hide the "Approve" button from employees, yet anyone who knows the address of that action can still call it. Tell the AI to check permissions on the server on every request.
Example prompt: a leave-request system
Copy it and adjust the company details and rules:
Build a "leave request" web app for a 15-person company, for internal use only.
Roles
- Employee: submits a request (type, start date, end date, reason), sees the status and history of their own requests, can cancel a request that is not yet approved.
- Manager: sees requests from their own team, approves or declines with a note.
- Administrator: adds and disables accounts, assigns roles and teams, sets the yearly leave allowance, sees company-wide reports and exports CSV.
Rules
- No sign-up page. Only the administrator creates accounts.
- The first administrator account is created at first start from the ADMIN_EMAIL and ADMIN_PASSWORD environment variables.
- Passwords are hashed. Users can change their own password. Repeated failed sign-ins are slowed down.
- Check permissions on the server on every request, not just by hiding buttons.
- Never delete data for real; use a cancelled status, and keep a history of who did what and when.
- Every page carries <meta name="robots" content="noindex"> so search engines do not index it.
- Works well on a phone.
Technical
- Use the stack you know best with a PostgreSQL database; read the connection from DATABASE_URL.
- Create the tables at first start when they do not exist.
- Read every secret (such as SESSION_SECRET) from environment variables; never write one in the code.
When done, test all three roles, then deploy to BrewInTH.For a different system, change only the "Roles" part and the data it stores. The "Rules" part can be reused almost as is.
Go live on BrewInTH, step by step
1. Create the project and pick a database
In the console press New project, give it a name, pick the technology (not sure? choose Let the platform decide (recommended)) and a database such as PostgreSQL. The platform creates the database and writes the connection values, DATABASE_URL among them, for the app. No passwords to copy around.
The dialog has a tick box, List this site on the brewInTH portal — free promotion, which is on by default. For an internal system, untick it: outsiders have no reason to find it.
2. Give the link and token to your AI
On a computer with a coding agent (Claude Code, Codex, Cursor or Windsurf), press Create the AI link and token (automatic) on the project page and paste the message into the chat of the AI that wrote the code. It uploads, builds and publishes by itself.
If you work with a chat AI that hands back a ZIP file, the Upload and go live menu (still BETA) takes that ZIP into the project you created.
3. Set the first administrator
Open the project's App settings tab, add ADMIN_EMAIL and ADMIN_PASSWORD (names in capital letters), then publish again. An app reads its settings only when it starts, so new values take effect with the next release.
Sign in once and change the password straight away. Then create an account for each member of staff from the administrator page.
4. Test every role
Make one test account per role and try the things that should not work:
- signed in as an employee, type the address of the administrator page: it must refuse;
- signed in as employee A, change the number in the address to look at employee B's request: it must refuse;
- sign out, then press Back: no data may show.
Anything wrong goes back to the AI in the same chat, followed by a new release.
5. Send the link to the team
You can name the site once for free, for example leave-mycompany, which gives leave-mycompany.host.brewinth.net with HTTPS. If the company already has a domain, paid plans (from Starter at ฿99 a month) can connect it, for example leave.mycompany.com.
Checklist before the whole team uses it
- No self sign-up. An outsider who gets the link can do nothing with it.
- Administrator password changed, and no test accounts left behind.
- Permissions checked on the server: the tests in step 4 pass.
- Not on the portal. The project's Portal tab should read "Not listed on the portal".
- Backups on. The Backups add-on costs ฿99 a month and copies the database automatically every day. Company data is worth far more than that.
- Someone owns the accounts. When a person leaves, their account is closed that day.
Which plan?
The Free plan is fine for building and testing: one project and one database. An app on Free sleeps after a long time without visitors, and the first person to open it afterwards waits a moment while it wakes.
Once the team relies on it daily, a paid plan makes sense: you can choose that the app never sleeps, it gets more CPU and RAM, and the company domain can be connected. Current plans and prices are on the console's plan page.
Watch the video
▶ From creating a project to a live site (1:30, in Thai)
Watch on YouTube
FAQ
We have no IT team. Is this realistic?
For a small system with a clear job, such as leave, supplies or repair tickets, yes. Do appoint one owner of the system who tests it, looks after accounts and asks the AI for changes. If it touches payroll, health data or a large amount of personal data, have an expert review it before real use.
Can access be limited to people in the company?
The site is on the internet, so anyone with the link can open the sign-in page. Keeping outsiders out is the job of the app's sign-in: no self sign-up, strong passwords, and a delay after repeated failures. For more, ask the AI to add a second step, such as a code from an authenticator app.
Why not stay with Google Sheets?
You can, while few people use it and nobody needs separate permissions. Once you need "this person sees only their own rows", "someone has to approve" or "who changed this?", a system with sign-in and roles fits better.
Can features be added later?
Yes. Go back to the same AI chat, describe the change, and have it deploy again. The address and the data in the database stay as they are. Before a big change to the tables, make a backup first.
Where does the company's data live, and can we take it out?
In your project's database. Ask the AI for a CSV export button on the administrator page from the start. With the Backups add-on you can also download the database backup files from the console.
Summary
Internal tools are among the best things to build with AI. Write down the roles and who may do what, have the AI check permissions on the server and keep a history, create the project with its database on BrewInTH, test every role, and only then send the link to the team.
Start your first project free →