Every small company has a job that lives in the wrong place. Who has which laptop. Which van is due for a service. Which client asked for what, and who's on it. It sits in a shared spreadsheet, a WhatsApp group and one person's head, and it works until that person goes on holiday.
The usual answer is "we should build a proper tool for that", followed by nothing, because there's no developer free and the job isn't big enough to hire one. That gap is exactly where AI app builders are useful now: you describe the tool, it gets built with a real database, and the team signs in to use it.
This post walks through building one end to end, with the actual prompts. The example is an equipment tracker (who has what, when it's due back, what needs maintenance), because almost every team with more than ten people has one hiding in a spreadsheet. I'll use Mythex because it's what I build, but the steps and the mistakes are the same in any AI builder.
Step 1: Write the one-page brief before the first prompt
AI builders are quick at screens and bad at guessing how your company works. Ten minutes of writing saves an afternoon of patching. Answer four questions:
- What are the things? Equipment items: name, type (laptop, tool, vehicle), serial number, purchase date, condition, location, photo.
- What happens to them? They get checked out to a person, returned, sent for repair, retired. Each of those is a record with a date and a person, not an edit to a cell.
- Who does what? Everyone can see what's available and request an item. Office managers check items in and out. Only admins add or retire items.
- What question do you ask most? "Who has the projector?" and "What's overdue?" Those become the front page.
If you can't answer question 3, stop and ask your team. Permissions are the part of an internal tool that's hardest to bolt on later.
Step 2: The first prompt
Paste the brief in nearly as written. Long is fine; every sentence is a decision the AI won't have to guess.
Build an internal equipment tracker for a 40-person company. Items have a name, type (laptop, tool, vehicle, other), serial number, purchase date, condition (good, needs repair, retired), location and an optional photo. Items are checked out to a team member with a due-back date, and returned with a note on condition. Keep the full history of check-outs and returns for every item. Roles: members can see all items and request one; office managers check items out and in; admins add, edit and retire items. The home page answers "what's overdue" and "who has what", with search by name or serial number.
Within a few minutes you'll have a working preview: a list of items, a detail page, check-out and return forms, and a database behind them. Don't judge it yet. Click through it as if you were the newest person on the team.
Step 3: Fix the data model before the design
The first version usually gets one thing wrong about the data, and it's always cheaper to fix that now than after people start entering real items. Check three things:
- History is its own table. If checking out an item just overwrites a "current holder" field, you've lost the answer to "who had it before it broke?". Ask for a check-outs table with item, person, out date, due date, return date and return note.
- People are real users, not typed names. "Sam", "sam" and "Samantha K" will become three people. Ask that check-outs link to a signed-in team member.
- Status is calculated, not typed. "Overdue" should come from the due date, not from someone remembering to change a dropdown.
Store each check-out and return as a separate record linked to the item and to the team member, so we keep the full history. An item's current holder and "overdue" status should be calculated from its open check-out, not typed by hand.
You can see the tables the AI created and download a backup in the project's database settings. It's a real Postgres database, so the data isn't trapped in the tool.
Step 4: Import what you already have
You almost certainly have a spreadsheet. Export it as CSV and ask for an importer rather than retyping:
Add an admin page to import items from a CSV with columns Name, Type, Serial, Purchase date, Location. Show a preview of the rows first, flag rows with a missing serial number or an unknown type, and skip duplicates by serial number.
The preview step matters. Real spreadsheets have merged cells, dates in three formats and "see Sam" in the location column. You want to see those before they're in the database.
Step 5: Add the two features people will actually use
Two small things decide whether the team opens the tool or goes back to WhatsApp:
On the home page, show my items (what I currently have and when each is due back) at the top, then overdue items for office managers. Send a reminder email to the person holding an item the day before it's due, and to office managers when it becomes overdue.
Add a "Request" button on each available item. Office managers see open requests and can approve them, which creates the check-out, or decline with a reason.
Notice what isn't on the list: dashboards, charts, a mobile app. Add them when someone asks twice.
Step 6: Test it as three different people
This is the step most people skip, and it's where internal tools fail quietly.
- As a member: Can you see the items? Can you request one? Can you check something out yourself, edit an item or retire it? You shouldn't be able to.
- As an office manager: Check an item out, return it with "screen cracked", and check that the item's condition and history both changed.
- As an admin: Retire an item. It should disappear from "available" but keep its history.
Then try the weird cases: a due date in the past, two requests for the same item, a serial number with a space at the end. If something's wrong, describe what you saw ("a member can open the Retire button on the item page"), not the fix you imagine.
Step 7: Publish it for your team only
An internal tool shouldn't be on the open internet. When you publish, choose who can open it.
On the Business plan you can publish as members-only: only signed-in people in your team workspace can open the app, and everyone else gets a sign-in page. You can put it on your own subdomain, like equipment.yourcompany.com, so nobody has to remember a random link.
If your company uses Google Workspace, you can verify your email domain and turn on single sign-on, so people sign in with their work account, and new hires at your domain can join the workspace without an invite.
What the team ends up with
- A web app with a real Postgres database, file storage for photos, and full history.
- Sign-in, with roles that match how your company actually works.
- Members-only access (Business plan) and your own custom domain (Pro and up).
- SSO with Google Workspace on a verified company domain (Business plan).
- The code, which you can edit, export or sync to GitHub if a developer ever does join and wants to take it over.
Honest limits
It's worth being clear about where this approach stops:
- You still own the decisions. The AI builds what you describe. If nobody agrees who's allowed to retire an item, the tool won't settle it.
- Test permissions yourself. AI-generated permission checks are usually right, and "usually" isn't good enough for anything sensitive. Do the three-person test every time you change who can do what.
- Heavy integrations take more work. Reading from Google Sheets or posting to Slack is a prompt away. Two-way sync with an old ERP is still a project.
- SSO beyond Google Workspace (Okta, Microsoft Entra, other SAML providers) isn't self-serve in Mythex yet; you'd contact us to set it up.
- It's software, so someone has to own it. Pick one person who's responsible for changes. That's still far less than a developer's time, but it isn't zero.
The short version
Write a one-page brief: things, events, roles, and the one question people ask most. Make history its own table and link it to real users. Import your spreadsheet with a preview. Build the two features people will use daily, then test as every role. Publish members-only, on your own domain, with your company sign-in.
For teams
If you're doing this for a team rather than for yourself, the internal tools page shows other tools teams build the same way (admin panels, approval flows, inventory and ticket queues), and pricing has the Business plan: a shared team workspace, roles, per-member credit limits, members-only apps and SSO. There's a Free plan to try the build first. If you get stuck on the brief, reply here with what your tool needs to do and I'll suggest a first prompt.
Top comments (0)