If your operations run on spreadsheets, shared inboxes and a back-office system nobody likes, you've probably started looking for a company to build an internal tool. This post is for founders, COOs and operations leads who want to know what to check before signing. I run SiteFusion, which builds internal tools, customer portals and SaaS products for B2B teams, so read it knowing we're one of the companies you might compare. The checklist applies to whoever you hire.
What an internal tools development company builds
An internal tool is software your own staff use to do their work. Typical examples are an operations dashboard, an approval workflow, a scheduling or dispatch screen, a back office for customer accounts, and a reporting view that pulls data from several systems. It's separate from your customer-facing product, and it does more than a plain admin panel that edits database rows. A good internal tool is built around one role's daily work and applies your business rules, so people make fewer mistakes without having to remember every exception.
A company that specialises in this work should be comfortable with permissions (who can see and approve what), integrations with the systems you already pay for, audit trails, and data-heavy screens such as tables, filters and bulk actions. Our internal tools guide covers the kinds of tools teams usually build first, and our internal tools development service page explains how we take on this work.
Decide whether you need custom software at all
Before you contact anyone, check whether a product you can buy or a low-code builder already does the job. For a small team with a standard process it often does, and it's cheaper. Custom development makes sense when the workflow is specific to your business, when per-seat pricing grows faster than your team, or when you need integrations and permissions a generic tool can't handle. Our build vs buy guide goes through that decision in detail. A good development company will ask this question too, and some of the time it should tell you not to build.
What to check before you hire
Ask to see similar work
A portfolio of marketing websites tells you little about whether a team can build a permission model or an integration that keeps working when the other system has an outage. Ask for an internal tool, dashboard or B2B platform they've built. Then ask what they'd do differently now. A team that has shipped this kind of software will have a specific answer. You can see the kind of work we've shipped on our portfolio page.
Find out who writes the code
Some agencies sell the project and hand it to subcontractors. That can work, but you should know before you sign. Ask who the developers are, how senior they are, and whether they'll be on your calls. Ask who you'll speak to when something breaks after launch.
Ask how they scope and price
A serious team will want to understand your process before giving a price. If you get a fixed quote after one short call, the quote is a guess, and the gaps will come back as change requests. A short paid discovery phase that ends with a written scope, a clickable prototype and an estimate is a good sign. Compare quotes against the same written scope, and ask each company to break its quote down by feature and by role.
Check ownership of the code and the accounts
Your contract should say the source code and related assets belong to your company. The hosting, domain, database and third-party service accounts should be registered to your company from day one, with the agency added as a user. This matters more than almost anything else if you ever change vendors. Our dev partner contract checklist lists the clauses to look for.
Ask about security and data protection
Internal tools often hold the most sensitive data in the company: customer records, pricing, payroll, contracts. Ask how the team handles login and roles, whether actions are logged, how backups work and where the data is hosted. If you're in the UK or EU, ask how they'll support your GDPR obligations. In the UAE or Saudi Arabia, ask about the local data protection law and whether data has to stay in the region. You'll still need your own legal advice, but the developer should raise these questions early rather than after launch.
Ask what happens after launch
Internal tools need small changes every month as your process changes. Ask whether the company offers ongoing support, what's included, and how quickly urgent issues get a response. We describe how we handle this on our post-launch support page.
Ask about the stack
You don't need to be technical, but you should get a clear answer. A common, well-documented stack makes it easier to hire someone else later if you need to. At SiteFusion we mostly build with Next.js, React, Node.js and PostgreSQL, as described on our full-stack development page.
Red flags
A fixed price for a large project after one call, with no discovery.
No examples of internal tools, dashboards or B2B platforms, only marketing sites.
Reluctance to put code ownership in the contract, or hosting accounts registered to the agency.
No mention of what happens after launch.
Nobody asks to talk to the people who'll use the tool every day.
We cover more of these in dev partner red flags and in our longer guide to hiring a software development partner.
How a build usually runs
The order we follow, and the one I'd expect from most good teams, goes like this. Someone sits with the people who'll use the tool and maps the current process, including the workarounds. The team agrees on a first version that covers the most repeated task for one role, with a clickable design to check before any code is written. The build happens in short cycles, with a working version you can test every week or two. After launch, the team watches how people use it and fixes the rough edges.
Be wary of anyone who gives you a timeline before they've seen your process. A focused first version for one team is usually a matter of weeks. A tool that replaces several systems takes months. If you want an example of how a first version can be kept small, our post on building an internal approval workflow tool walks through one.
Working with a remote team
Many companies hire a development team in another country. That works well when working hours overlap enough for regular calls, the team writes clearly in English, and the contract covers IP ownership and data protection under the law that applies to you. Ask how often you'll see a demo, who your day-to-day contact is, and how decisions get recorded.
Frequently asked questions
How much does it cost to have an internal tool built?
It depends mostly on the number of screens, roles and integrations, so any number given before someone has seen your process is a guess. Ask for a paid discovery or scoping phase first, then a fixed price or capped budget for a clearly defined first version. Compare quotes on the same written scope.
How long does it take to build an internal tool?
A focused first version for one team usually takes weeks, and a tool that replaces several systems takes months. The biggest factors are integrations with other systems and how quickly your side can answer questions and test.
Should we use a low-code builder instead?
For simple workflows with a few users, a low-code tool can be faster and cheaper. Custom code fits better when the tool is central to daily operations, needs detailed permissions, or has to connect closely to other systems.
Who owns the code when an agency builds an internal tool?
You should. Make sure the contract assigns the source code and related assets to your company, and that hosting, domain and database accounts are registered to you.
What should we prepare before contacting a development company?
A short description of the process you want to fix, who does it today, how often it happens and which systems it touches. Screenshots of the spreadsheets or tools you use now help a lot.
Can a remote development company build tools for a US, UK or Gulf business?
Yes, as long as working hours overlap for regular calls, communication is clear, and the contract covers IP ownership and data protection under the laws that apply to you.
Talk to us
If you're planning an internal tool and want a second opinion, you can book a call with us. We'll ask about your process and the people who'll use the tool, and we'll tell you if you don't need custom software at all.
