Offer
Internal tools, admin panels and dashboards
The software your team uses rather than your customers: admin panels, dashboards, approval flows and the operational screens nobody sells off the shelf.
Start with the workflow that costs you the most
Tell us what the process is and what it currently runs on. A senior engineer reads it and replies with either questions or a straight answer that we are not the right fit.
- Discovery
- £500–£1,500
- credited against the build if you proceed
- Build
- £8,000–£25,000
- fixed price against a written scope
- Care plan
- £200–£600
- per month, optional, cancel any time
What this is
Internal tools are the software a business builds for itself: the admin panel that manages the records, the dashboard the operations manager opens first, the approval flow that decides who can sign off what, the screen that exists so a support agent does not have to run a database query. They are unglamorous, they are never in the marketing plan, and they carry an amount of daily work that surprises people when they measure it.
They are also systematically underinvested in, for a reason worth naming: nobody outside the company sees them. A customer-facing page gets designed and redesigned while the screen your team stares at for six hours a day was thrown together years ago and has been tolerated ever since. The cost is real and diffuse, which makes it easy to ignore and expensive to keep ignoring.
This is the same engineering as our thirty-day ops app, framed for the buyer who would never use the phrase "ops app". If you have an admin panel that needs rebuilding, a dashboard assembled by hand every Monday, or an approval process living in email, this is the page for it. The commercial terms are identical: fixed scope, fixed price, you own the code.
You will recognise some of these
- Someone on your team runs database queries by hand because there is no screen for it
- The admin panel was built years ago and everyone has a workaround for the parts that do not work
- Approvals happen by email, so there is no record of who approved what or when
- A manager rebuilds the same dashboard in a spreadsheet every week from exported data
- New staff take weeks to become useful because the internal systems are undocumented folklore
- You are paying for a SaaS tool per seat and using a fraction of it, because it nearly fits
- Support staff cannot answer a customer question without asking a developer
What is included
- Admin and back-office screens built around the records your business actually keeps
- Role-based permissions, so finance, operations and support each see what they should and nothing more
- Approval and sign-off flows with a full audit trail of who decided what, when
- Operational dashboards built on live data instead of assembled from exports
- Bulk actions, search and filtering on the fields your team genuinely uses
- Integrations with the systems you already run, where they expose a documented API
- Data import from whatever the process currently lives in
- Deployment, backups and monitoring on infrastructure in your name
What is not included
Stated as plainly as the inclusions. A fixed price only means something if the boundary around it does.
- Replacing a system that already works. If your admin panel is merely dated rather than broken, targeted improvements are cheaper and we will propose those instead.
- Integrations with software that exposes no documented API. Where a vendor has locked the door, scheduled imports and exports are usually the honest answer rather than a promise we cannot keep.
- Becoming your IT department. This is application development, not desktop support, network administration or licence management.
- Reimplementing your accounting or payroll rules. The package that owns them keeps owning them, and the internal tool hands off to it.
- Ongoing feature development after handover. That is either the care plan or a new project, and it is priced as one rather than drifting into an open-ended arrangement.
Tell us which workflow it is
A short description of the process and what it runs on now is enough to get a straight answer on whether this fits.
Build, or buy and bend
The honest first question is whether you should build at all. Off-the-shelf software is cheaper, faster and better supported than anything custom, and where a product genuinely fits your process you should buy it. We will tell you when that is the case, including when it means we do not get the work.
The argument for building starts when the fit is partial. Paying per seat for a product you use a fraction of, or bending your process to match software written for a different kind of business, both carry costs that never appear on the invoice: the workarounds, the double entry, the exceptions handled in a spreadsheet alongside the tool you are paying for.
The practical test we use is whether the thing that does not fit is central to how you compete. If your process is unusual because of neglect, buy the product and fix the process. If it is unusual because it is genuinely how you win, that is exactly the part worth having built, and it is also the part no vendor will ever build for you.
Internal does not mean lower standard
Internal tools are routinely built to a lower standard on the theory that the users are colleagues rather than customers. That reasoning is backwards. A customer visits a page occasionally; your operations team lives in this screen for most of their working day, and every unnecessary click, every slow load and every confusing error message is multiplied by that.
It also matters for risk. Internal tools usually hold more sensitive data and more destructive capability than anything customer-facing, and they are where a permissions mistake does real damage. Roles, audit logging and sensible confirmation on destructive actions are part of the build here rather than a later hardening exercise.
So these get the same engineering as anything else we ship: proper access control, an audit trail, sensible performance and an interface designed for the person who has to use it forty times a day.
Common questions
How is this different from the Ops App in 30 Days?
It is the same engineering and the same commercial terms, described for a different buyer. The thirty-day page is framed around replacing a specific painful workflow, usually a spreadsheet or a WhatsApp group. This one is framed around internal software generally: admin panels, dashboards, approval flows. If your project is one bounded workflow, the thirty-day framing will fit it. If it is a broader piece of internal tooling, start here.
Should we build or buy?
Buy, wherever a product genuinely fits. It will be cheaper and better supported than anything custom, and we will say so even when it costs us the work. Building makes sense when the fit is partial and the misfit is in a process that is central to how you compete, or when the per-seat cost of nearly-right software has grown past the cost of building the right thing once.
Can you improve our existing admin panel instead of replacing it?
Often yes, and it is usually the cheaper answer. If the foundations are sound the work is targeted: fix the screens people fight with, add the missing permissions, put an audit trail in. We would look at what exists before recommending a rebuild, because "replace it all" is the expensive advice and it is not always the right one.
Will it integrate with the systems we already use?
Where those systems expose a documented API, yes, and that is normally the point of the exercise. Where they do not, we will tell you what is genuinely possible, which sometimes means scheduled imports and exports rather than live synchronisation. What we will not do is promise an integration that depends on a third party who has not agreed to it.
Who owns the finished tool?
You do. Code in your repository, hosting in your name, data exportable at any time, no licence and no per-seat fee. You can keep us on the optional care plan, take it in-house, or hand it to another developer, and none of those routes is blocked by anything we did.
Related
The capability pages behind this work, and the other offers in this set.
Which spreadsheet would you kill first?
Describe the workflow and what it runs on today. If it is not a fit for a fixed-scope build, we will tell you that rather than sell you one.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.