Automation & No-Code
Internal tools built on Retool, Airtable and Notion
The screen your team actually needs, sitting between a spreadsheet that has gone feral and a custom build you cannot justify.
- From
- $500–$8,000
- Typical time
- 1–6 weeks
- Usually bought by
- Ops teams
What this actually solves
Every company has work that no off-the-shelf product fits properly. The warehouse needs a screen showing today's orders with a button that marks one dispatched. A manager needs three numbers visible at once without asking anyone. Support needs one place holding everything about a customer instead of four tabs. None of this is complicated, and none of it is worth a software project.
So it ends up in a spreadsheet, and the spreadsheet does what spreadsheets do. Someone downloads a copy to work on offline. Someone else makes a version with an extra column. Within a few months three versions are circulating, nobody is sure which is current, and there is no way to know who changed the figure that is now wrong. It is cheap, and it is quietly costing more than it saves.
The alternative used to be a full custom build — a serious budget and half a year — so the spreadsheet stayed. The middle ground is what changed. It is now reasonable to build, in days rather than months, something that is better than the spreadsheet in the specific ways that matter: it has permissions, it keeps a record of who did what, and it can be wired into the rest of your automation so that pressing one button also updates the database and sends the notification.
There is a second motivation that is often the real one, and clients rarely lead with it. The owner wants to see what their people are actually doing. A spreadsheet cannot show that. An internal tool records every change, which means workload, throughput and where things are getting stuck all become visible without anyone being asked to report on themselves.
What we do, and in what order
- Define what each person can do on each screen. The answer is always some combination of four things — create, read, update, delete. Forcing the conversation into those terms is the fastest way to find out what the tool actually needs to be, and it is the main defence against a scope that keeps growing. One to two days.
- Decide where the data lives, and consolidate if it is scattered. Airtable when it should be easy to work with, Google Sheets when volume is small and budget is zero, or a real Postgres database via Supabase when the record count is genuinely large. If the information currently sits in three places, this step is the project. One day to two weeks.
- Sketch the screens and get them approved before building. Paper or Figma, whichever is faster. Cheap to change now, expensive to change once the logic is behind it, and it is where you discover that the thing the manager wanted and the thing the operator wanted are two different screens. One to three days.
- Build the smallest version that is genuinely useful. The features without which the tool has no reason to exist, and nothing else. Everything the room asked for beyond that goes into a written phase two. Four days to three weeks.
- Build the permission map. Who sees which screen, who can change what, and what nobody is allowed to delete. This is the step that gets skipped and the one that causes the worst incidents, because a tool with real write access and no permission model is a loaded weapon in the hands of whoever logs in. One day.
- Wire it into the automation layer. One press updates the record, sends the WhatsApp message and writes the row, so the person does not have to remember three follow-up actions. One to three days.
- Train the team and leave a one-page document. Short, and written for the person who will use it under time pressure rather than for the person who commissioned it. Half a day.
Tools we typically reach for: Airtable and Airtable Interfaces, Softr or Glide for an app-shaped front end, Notion where the work is document-led, Retool when there is a real database and complex logic, Supabase for genuine Postgres, and Baserow or NocoDB where self-hosting is a requirement.
What moves the price
Where the data currently lives. This dominates everything else. Already in one place, already structured — the build is short. Spread across systems with inconsistent identifiers — the consolidation comes first and is charged as its own piece of work, because it is one.
How many people will use it. Three users and fifty users are different systems. At fifty you are paying for permission tiers, an audit trail, concurrency protection and training, none of which a three-person tool needs.
How messy the edge cases are. Two people opening the same order at the same time. Someone starting a task and abandoning it half-finished. A record deleted that other records point at. Every one of those has to be given a defined behaviour, and the number of them is a better predictor of effort than the number of screens.
What usually goes wrong
Time is spent making it beautiful. An internal tool is used by someone wearing gloves in a warehouse, or by a support agent with a customer waiting on the line. They will open that screen a hundred times a day. What they need is big targets, unambiguous labels, and fewer options — not a considered colour palette. A week spent on visual refinement is a week not spent removing the two extra clicks that will be paid a hundred times daily for the next three years.
Permissions are treated as a later concern. Unlike a spreadsheet, this tool has real write access to real operational data, and everyone gets the same view because that was quicker to ship. Then a junior deletes a record that three other records depend on, or a temporary contractor can see the pricing table, and the tool becomes the reason for an incident rather than the fix for one. The permission map costs a day at the start and is close to impossible to retrofit cleanly.
Nobody defined whether it is a viewer or a worker. "Can you build us a simple dashboard" is the most expensive sentence in this category, because dashboard means two entirely different products. Left unresolved, it is quoted as reporting and delivered as an application, and the gap between those two is where the project goes over. The question has to be asked and answered in writing before anything is priced.
See where the site stands before you brief anyone.
If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.
Questions people ask before they commit.
- What is the difference between a dashboard and an internal tool?
- One question separates them — will the person on that screen change anything, or only look at it. If they only look, that is a reporting job and Looker Studio can usually do it in a couple of days. If they press a button that updates a record, assigns a job, marks something dispatched or triggers a message, that is an internal tool and it is roughly ten times the work, because now you need permissions, validation, concurrency handling and an audit trail.
- Airtable, Softr, Notion or Retool — which one?
- It follows the data and the difficulty. Airtable with its own interfaces is the fastest route when the data already lives there and the workflow is straightforward. Softr or Glide sit on top of Airtable when the team needs something that feels like an app. Notion suits work that is mostly documents with light structured records attached. Retool is the answer when there is a real database behind it and the logic is genuinely complex.
- Our data is in three different places. Does that matter?
- It is the single biggest factor in the price. If everything already sits in one Airtable base, a useful tool can exist in about four days. If the same information lives partly in a spreadsheet, partly in an e-commerce platform and partly in someone's inbox, consolidating it comes first and can take several weeks on its own. We quote that cleanup separately so you can see what you are paying for.
- Will it cope with fifty users, or is this for small teams?
- Both, but they are different projects. Three people sharing a screen can operate on trust. Fifty cannot — you need permission tiers, a record of who changed what, protection against two people picking up the same job, and a plan for the mistakes fifty people will inevitably make. That difference shows up in the timeline and the price, so the user count is one of the first things we ask about.
- How do you stop this turning into a full software project?
- By deciding on day one what the smallest version is — the features without which the tool is pointless — and pushing everything else explicitly into a second phase that is quoted separately. Scope expansion is the normal cause of death for internal tools, because every person who sees it has one more thing it could do. Writing down what is not included is as important as writing down what is.
- What happens to the tool if we outgrow these platforms?
- You keep your data, which is the part that matters. Airtable, Supabase and Postgres all export cleanly, and a tool built with the data model separate from the interface can be rebuilt on something heavier without starting from nothing. We will tell you honestly where the ceiling is — Airtable becomes expensive as records climb into the hundreds of thousands, and Google Sheets starts to struggle past about fifty thousand rows.
Often taken together.
Start with the brief, not the invoice.
Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.
Talk about Internal tools (Retool / Airtable / Notion) All Automation & No-Code services