The Streamlit app your first engineer wrote for ten people now runs the company
Rebuilding a load-bearing internal tool properly costs £25,000 to £90,000 and takes 8 to 16 weeks for most Cambridge scale-ups. The trigger is nearly always the same: a Python script or Retool app written in two days by a founding engineer is now the only way ops can process a customer, and every sprint loses days to patching it. You are not paying to build something new. You are paying to stop paying the interest on something old.
It started as a Jupyter notebook. Then it became a Streamlit app so the ops team could stop asking an engineer to run it. Then someone added a Google Sheet as the database because Postgres felt heavy for four rows. Two years and a Series B later it has 900 rows an hour, no auth beyond a shared link, no audit trail, and one engineer who understands it and is now your platform lead. Every time she is pulled in to fix it, your actual roadmap slips.
Retool and Airtable are excellent at the stage you have left. Retool stops being cheap when you have forty internal apps and per-user pricing across an ops team. Airtable stops being safe when the record that decides whether a customer gets billed can be edited by anyone with the link and no history is kept. The tools did their job. The job changed.
- The tool is on the critical path for revenue, billing or customer delivery
- Engineers lose more than two days a month to keeping it alive
- You cannot answer who changed a record last week
- The number of daily users has grown past twenty and is still climbing
- The process is under six months old and still changing every sprint
- Fewer than ten people use it and the blast radius of an error is small
- Retool or Airtable genuinely covers it and the licence cost is under a few thousand a year
- You are about to change the underlying business process anyway
- Engineering sprints stop absorbing unplanned support work for tools nobody owns
- Role-based access and a full audit log, so a wrong record has a name and a timestamp against it
- Ops staff can be trained in an hour instead of shadowed for a week
- The tool survives the departure of the person who wrote the original prototype
- A real database and API underneath, so the next three internal tools take days rather than restarting from a notebook
- Retool and Airtable let a non-engineer change a screen in ten minutes; custom means a change request and a deploy
- You are adding a codebase to maintain, monitor and patch for security, forever
- Rebuilding a tool users already know means a period where everyone insists the old one was better
- If the process the tool supports is still changing weekly, you will build the wrong thing at speed
Internal Tools pricing in Cambridge: the real numbers
| Project scope | Typical cost | Timeline |
|---|---|---|
| Single tool rebuilt properly (auth, audit, tests) | £18,000 to £40,000 | 5 to 9 weeks |
| Internal platform with shared auth, API and two or three tools | £45,000 to £85,000 | 10 to 16 weeks |
| Full ops platform replacing a Retool and spreadsheet estate | £85,000 to £150,000 | 16 to 26 weeks |
The features that matter for Cambridge
Cambridge internal tools: the full scope
Everything an internal tools build here can cover: back-office software, operations tooling, approval workflows, internal portal, business process automation, data-entry tools and admin panel development.
Exactly what you get
The same job, done by software that expects to be depended on. Login through the identity provider you already pay for, roles that mean an ops associate cannot accidentally trigger a billing run, validation that rejects bad input at the edge instead of corrupting a downstream report, and an audit trail you can query. Underneath it, a real database and a documented API, which is the part that pays off later: your next internal tool, your BI (Business Intelligence) dashboards and your CRM (Customer Relationship Management) all read from the same place. It usually connects to project management software and helpdesk software so ops stop copying identifiers between tabs.
How to choose a developer in Cambridge
You are an engineering-minded buyer, so use that. Ask for a code sample from a comparable project and read it. Ask how they handle background jobs, because the timeout in your current Streamlit app is the thing that actually breaks. Ask what tests they write and what coverage means to them. Most importantly, ask them to spend the first fortnight reading your existing prototype rather than designing a replacement, because five years of business rules are encoded in its if-statements and none of them are written down. Insist on code ownership, a README your own team could ship from, and a deployment your platform lead can run without the agency. Cambridge engineers will judge the handover, so make the handover part of the contract.
From kickoff to launch: the schedule
- !They start with screens rather than the data model; ask what the schema looks like before any UI is drawn
- !No mention of an audit log; ask how you will answer an investor or auditor asking who changed a number
- !They propose rebuilding all nine tools at once; ask which single one is costing you the most and why start there
- !They will not touch your existing Streamlit code to understand it; ask how they plan to capture undocumented business rules
- !No handover plan for your own engineers; ask what the runbook and README will contain
Most Cambridge teams pricing internal tools end up comparing notes on custom software, wordpress, accounting too; the systems share one data spine. Weighing options across the region? We publish the same internal tools guide for London, Birmingham, Manchester. Prefer to talk to the team that builds these? Digital Heroes handles custom software development end to end.
The evidence behind this guide
Independent findings on why this investment pays off. Every link goes to the primary source.
- McKinsey's Developer Velocity research finds best-in-class tools are the top contributor to software business success, yet only about 5% of executives ranked tools among their top-three software enablers, signaling underinvestment in developer tools (this finding originates in McKinsey's Developer Velocity study rather than the linked generative-AI article). Source: McKinsey & Company (2023) →
- Salesforce research indicates sales reps spend only about 30% of their time actively selling, with much of the rest lost to administrative work including manual CRM data entry and updates. Source: Salesforce (2024) →
- In Gartner's 2025 AI in Finance Survey of 183 CFOs and senior finance leaders (fielded May-June 2025), 59% reported using AI in their finance function, with accounts payable process automation adopted by 37% of respondents (the second-highest single use case, behind knowledge management at 49%). Source: Gartner (2025) →
- Criteo's Global Commerce Review found retail apps convert at 18% versus 4% on mobile web (roughly 4.5x), and travel apps convert at 20% versus 6% on mobile web (about 3.3x). Source: Criteo (2017) →
Lachlan heads mobile design at Digital Heroes, covering iOS and Android work from first flows through to handoff specs the engineering leads can build against. He spends a lot of time on the unglamorous parts: navigation, empty states, permissions. Readers get the design side of what makes an app feel finished.
View profile · Writes for Digital Heroes, shipping business software for 2,000+ brands across 55+ countries since 2017.
Frequently asked questions
What does it cost to rebuild an internal tool for a Cambridge scale-up?
A single tool rebuilt with authentication, audit logging and tests typically runs £18,000 to £40,000 over five to nine weeks. Building a shared internal platform that hosts several tools costs £45,000 to £85,000. The variable is almost always how much undocumented logic is buried in the existing prototype.
Should we just pay for more Retool seats instead?
If you have under twenty users and the tools are not on the revenue path, yes, keep paying. The maths flips when per-seat cost across a growing ops team meets a workflow that needs real permissions and audit history. Price three years of seats against a build before deciding, and include the engineering time you currently spend maintaining Retool queries.
How do we stop our engineers being pulled into internal tool support?
Give the tool an owner, a support path and a change process, which mostly means building it as a real product rather than a script with a UI. In our Cambridge delivery data, teams typically recover about two engineer-days a month per tool once error handling, validation and monitoring exist, because most interruptions were people asking for a rerun.
Can you migrate our Google Sheets data without losing history?
Yes, though expect the messy parts to take longer than the clean ones. We extract the sheet, profile it for inconsistencies (dates entered five ways is the classic), agree rules for each ambiguity with your ops lead, then load with a reconciliation report. Historic rows that cannot be resolved get flagged rather than silently dropped.
How long until the ops team is off the old tool completely?
Plan four to six weeks of parallel running after go-live. Ops teams keep a spreadsheet open out of habit long after the new system works, so the way to finish the migration is to turn the old one read-only on a scheduled date agreed in advance rather than hoping people stop.
Do we own the code and can our own engineers extend it?
You should own everything: repository, schema, deployment configuration and documentation. Given how many Cambridge companies have strong in-house engineering, we build assuming your team will take it over, which means conventional stacks, real tests and a README that gets someone productive in an afternoon rather than a bespoke framework only the agency understands.
What about security if the tool holds customer or research data?
Treat it like production because it is. Single sign-on, role-based access, encryption at rest, no shared credentials, and an audit log that survives deletion. If you sell into the NHS or handle any patient-linked data from Addenbrooke's or a clinical partner, this is also the point where the Data Security and Protection Toolkit conversation starts, so build to it now rather than retrofitting during a procurement review.
Is it worth hiring an internal tools engineer in Cambridge instead?
One person is not a team, and in Cambridge you are competing for that hire against Arm, Microsoft Research and every funded spinout on the Science Park. Most companies we work with use an agency to build the platform and then hire one engineer to own it, which is a much easier role to fill and to retain than a lone builder.
Can you rebuild one tool first and prove it before we commit further?
That is the sensible sequence and the one we recommend. Pick the tool causing the most engineering interruption, build it on a foundation (auth, API, database) designed for reuse, then measure the interruption reduction over a quarter. The second and third tools land far faster because the foundation already exists.
Can custom software connect to the tools we already use, like QuickBooks, Stripe, and Google Workspace?
How do we migrate years of spreadsheet or Airtable data into a new internal tool?
What does an internal tool cost for a small business with 20 to 50 employees?
Can we start on Airtable or Retool now and move to custom software later?
How many SaaS seats do we need before building custom becomes cheaper?
Should we build the whole internal tool at once or start with an MVP?
How do I vet a development agency for an internal tools project?
How many developers does it take to build an internal tool?
Is custom software more secure than off-the-shelf SaaS?
What does it cost to keep an internal tool running after launch, and do we need to hire a developer?
Who can build custom internal tools for a business in Cambridge?
Digital Heroes builds custom internal tools systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, so an operator in Cambridge gets an assigned senior team rather than a local account manager.
Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.
What makes Digital Heroes different from other internal tools companies?
Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.
Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.
How can I check Digital Heroes is legitimate before getting in touch?
Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.
Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.
