Operations · Internal business tools
We build internal business tools: software your own team uses to run a process that lives in spreadsheets, email or someone's memory today. It is for businesses where one broken sheet or one absent person can stop work. It is fixed-scope work, so you get one number before it starts.
The problem
Most internal processes start as a spreadsheet that worked. Then more people need it, someone overwrites a column, two copies drift apart, and the rules that matter live in the heads of the three people who understand it. Replacing that is not about screens. It is about writing down who can see what, who can change what, what happens at each step, and keeping a record of who did it.
None of these? Two outside groups, such as buyers and sellers, trading through it? That is a marketplace.
| Roles and permissions | Who can see, create, change and approve each thing |
|---|---|
| Workflows and approvals | Each step, who owns it, what happens next |
| Data import | Your spreadsheets brought in, cleaned and checked |
| History | Who changed what, and when |
| Search and views | Filtered lists and saved views for each team |
| Reports and exports | The numbers you pull by hand today, and a spreadsheet export |
| Notifications | Alerts when something is waiting on someone |
| Web first | A mobile app only if people work away from a desk |
What makes this one hard
The real process is not the one written down.
Every spreadsheet has exceptions handled by someone who knows. If the tool only follows the official process, people go back to the sheet. So scoping starts with the people who do the work, and every exception goes either into the build or onto the named list of what we are not building.
Live · FindWorker
FindWorker is ours, and we operate it through its admin console: users, orders, money and disputes. That console is an internal business tool in its own right. We know what one has to get right because our own team depends on it.
Read the The admin console behind every platform we run case study
Most projects fail before any code is written — because a price was given before anyone knew what it would cost to build.
If we can't answer these, we quote a phase, not a platform.
Price and phases
One number, before it starts.
Fixed-scope work is scoped first, quoted second, built third. You own the code on payment, and a defect costs you nothing.
Can it replace our spreadsheets?
Yes, and your existing data comes with it. We import the sheets, clean them and check the totals match before anyone relies on the new tool. Most tools still export to a spreadsheet, because someone will always want one. What changes is where the rules, permissions and history live: in the tool, not in a file someone can overwrite.
Who can see what?
Whoever you decide, down to single records if the process needs it. Roles are the usual starting point: staff see their own work, managers see their team, finance sees the money, and an admin decides who is who. Some tools also need rules by branch, department or region. We write the permission rules into the scope, because they shape every screen and are costly to add later.
Can we start with one process?
Yes, and we usually recommend it. Pick the process that costs the most when it goes wrong, build that, and use it for real before adding the next. Each addition is scoped and priced the same way, with one number before it starts. Starting small also shows whether the tool fits how people actually work before you pay for the rest.
How is an internal tool priced?
As fixed-scope work: one number, before it starts. Scoped first, quoted second, built third. The scope describes the process, the roles, the data being brought across, and a named list of what the tool will not do. A change after that is priced before it is built, and you decide whether it goes in. A defect costs nothing. We don't publish a price list, because the number depends on your process.
How long does an internal tool take?
The date is in the scope, agreed before we start. It depends on three things: how many steps and roles the process has; how messy the existing data is; and how many other systems the tool has to talk to. If a date is going to slip, we tell you before it slips, in writing, with the reason and the new date.
Can it connect to the software we already use?
Often, depending on the software. We look at three things: whether it offers an API, a documented way for two systems to share data without anyone retyping it; whether your account or plan allows that access; and whether data needs to flow one way or both. Each connection is named in the scope. If one turns out to be impossible or unreliable, we say so before the quote, not after.
Does it have to be a mobile app?
No. Most internal tools are web apps opened in a browser, which means nothing to install and one version for everyone. A mobile app earns its place when people work away from a desk: on a site, in a warehouse, in a van. Where that is true, we build it in Flutter, so iOS and Android share one codebase. We tell you during scoping whether you need one.
Who owns the code?
You do, on full payment. Exclusive and perpetual.
What if you disappear?
Your repository, your accounts, your signing keys. Documented so another team can pick it up.
Can we move to another team later?
Yes. We write the handover documents that make that possible, whether you use them or not.
Do you take equity instead of cash?
No.
Who holds the app store accounts?
You, unless you ask otherwise. Decided at kickoff, not at launch.
What happens to our data?
It is yours. Exportable at any point, in a format another system can read.
Other operations we build
No call. A few guided questions, then a tailored quote — usually within one business day.
Or send us the idea in three sentences on WhatsApp, or email support@codingwitht.com.