Operations dashboard
One screen for the status your team currently hunts across inboxes and spreadsheets.
SiteFusion is an internal tools development company for founders and operations leads in the US, UK, EU, Canada, Australia, the UAE, Saudi Arabia and Qatar. We build software your own staff use to do the job, when spreadsheets and a generic admin panel are no longer enough.
An internal tool is separate from the product your customers see. It does more than a plain admin panel that edits database rows. A useful one is built around one role's daily work and applies your business rules, so people make fewer mistakes without having to remember every exception.
One screen for the status your team currently hunts across inboxes and spreadsheets.
Requests, decisions and exceptions in one place, with a record of who approved what.
A screen for assigning work, instead of a shared sheet that goes stale by midday.
Staff can see the account, the history and the next action without opening four systems.
A view that pulls numbers you already have, so nobody rebuilds the same report by hand.
A team that specialises in this work should be comfortable with permissions, 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. You can see shipped work on the portfolio.
For a small team with a standard process, a product you can buy or a low-code builder often does the job. Custom development makes sense when the workflow is specific to your business, when per-seat pricing grows faster than the team, or when you need integrations and permissions a generic tool can't handle. A good development company asks this too, and some of the time it should tell you not to build. The build vs buy guide goes through that decision.
Be wary of anyone who gives you a timeline before they have seen your process. A focused first version for one team is usually a matter of weeks. A tool that replaces several systems takes months. Our post on building an internal approval workflow walks through one way to keep a first version small.
Someone sits with the people who will use the tool and maps the current process, including the workarounds.
The first version covers the most repeated task for one role. You see a clickable design before any code is written.
You get a working version to test every week or two, and you can tell us what is wrong while the change is still small.
After launch, the team watches how people use it and fixes the rough edges. Internal tools need small changes as the process changes.
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 have built, then ask what they would do differently now.
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, whether they will be on your calls, and who you will speak to when something breaks after launch.
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 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.
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. The dev partner contract checklist lists the clauses to look for.
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 are in the UK or EU, ask how they will 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 still need your own legal advice. The developer should raise these questions early.
Internal tools need small changes every month as your process changes. Ask whether the company offers ongoing support, what is included, and how quickly urgent issues get a response. We describe how we handle the period after launch on the post-launch support page.
You do not need to be technical, but you should get a clear answer on the stack. 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 the full-stack development page.
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 will see a demo, who your day-to-day contact is, and how decisions get recorded.
More of these are in dev partner red flags and the guide to hiring a software development partner.
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.
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.
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.
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.
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.
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.
If you are planning an internal tool and want a second opinion, book a call. We will ask about your process and the people who will use the tool, and we will tell you if you do not need custom software at all.