Internal tools development. Built bespoke. Owned outright.

An internal tool is the software your own team runs the business on rather than software your customers see, also called a back-office system or an operations system: an approval queue, a job board, a request inbox, an onboarding flow, a report. Most businesses already have one, spread across a spreadsheet, a shared inbox and a rented product or two. Internal tools development replaces that spread with one system that holds the whole workflow, records who did what, and reads and writes the systems that already hold the record.

From £10,000. The first two bands are above; a system across a multi-site operation, with data moved out of an incumbent tool and a release in phases, is £50,000 and above. The blueprint fixes the price in writing before you commit.

Five things, and a sixth when an old tool’s records have to come across. All of them show up in the first conversation. User roles: how many distinct roles there are, by team and by site. Integrations: how many systems of record must stay in sync, and in which direction. Data: whether the data model already exists or has to be discovered, and whether years of records have to come out of a spreadsheet or an old tool. Complexity: branching rules, thresholds and exceptions. Compliance: audit logging, data residency and retention. Migration: whether an existing tool has to be replaced with its history intact.

You do: the repository, the hosting and database accounts and the assigned intellectual property, from the first week. Paying the invoice is not what transfers the copyright; the written assignment in the agreement is2.

It depends on whether the workflow is standard. Products like Airtable fit a standard shape and charge per seat, so the cost compounds across a whole team; the own-or-rent guide has the list prices and the dates they were read. If a product fits your process, it wins, and we will say so on the call. If the process is the thing that makes the business run, or the data and the code need to be yours, a build pays.

Yes, and directly rather than through a chain of automation steps. The system reads and writes against the accounts package, the CRM and the directory through their own APIs, so the same fact is never typed twice. Some connections carry real constraints: Sage 50 runs on your own machines and needs a sync agent; Xero is a cloud API.

Yes. The records and their history are extracted, the new system runs alongside the old one on real data, teams or sites move across in groups rather than on a weekend, and the audit trail comes with them. A spreadsheet exports without a fight; a rented tool is the one to check first.

About £800 a year for a version one, with nothing per seat, every account in your name and paid by you directly; the itemised list is in the running-costs guide. A system nobody changes still needs security patching, and any supplier who says an owned system has no running cost is describing something else.

Only if it replaces the spreadsheet and the inbox rather than sitting next to them. Internal tools fail on adoption, not on features: a second place to type the same thing, a screen that does not match how the work is done. So the people who do the work are in the blueprint, the view they use every day is in version one, and the old spreadsheet is retired on a date. If the team routes around the system, the build is wrong, and that is a design constraint rather than a training problem.

Where they fit. Both are fine for a few low-volume steps where a delay does not matter, and both become the failure point once retries, error handling or an audit trail start to matter. Clientflow is not a partner or a reseller for any platform, so the recommendation is not decided before we meet.

That is a portal: a slice of the same records with their own login, so a client sees their jobs and a supplier sees their orders without seeing anyone else’s. It is usually the second phase of an internal tool, once the internal side is running, and it has a page of its own.