Your team has a spreadsheet three people edit, an approval that lives in email threads and a report someone rebuilds every Monday. Custom internal tools development replaces that patchwork with one screen your team trusts and your data stays behind. The real question is who can build it, and how you hire them without regret.
The short answer: an in-house developer, a freelancer, an agency or a low-code consultant can all do it, and each fits a different size of need. What decides the outcome is the scope you hand over, more than the badge on the builder's site. This guide shows you how to write that scope, how to choose between low-code and a custom Next.js build, and how to vet a team.
You do not need to be technical to follow it. By the end you will have the pieces of a one-page brief that works with any builder, werun.dev included.
Key takeaways
- Start with the single workflow that costs your team the most hours, and scope only that for the first release.
- Choose low-code for short-lived or small-team needs and a custom build for tools your operation will depend on for years.
- Write roles, logins and audit logs into the first scope, because adding them later costs far more.
- Plan a first release in 4 to 8 weeks, with testing by real users before launch.
- Ask who owns the code, where it is hosted and how handover works before you sign anything.
Who can handle custom internal tools development
Four kinds of builder take on this work, and each fits a different need. Match the builder to the size and lifespan of the tool, and the project starts on firmer ground.
In-house developer, freelancer or agency
| Builder | Fits best | Ask about |
|---|---|---|
| In-house developer | A tool that changes weekly and sits close to the team | Cover for holidays and for the day they leave |
| Freelancer | A small, well-defined tool with one clear owner | Backup person and handover documents |
| Agency or product team | A core tool with logins, integrations and a long life | Who maintains it after launch |
| Low-code consultant | A short-lived need or a team under about 20 users | Licence cost as the team grows |
An in-house developer knows your business best, but one person is a single point of failure when they are on leave or move on. A freelancer suits a small tool with one clear owner, provided code and documents are handed over. An agency suits a tool that touches several systems, needs strict access rules and must keep running for years. A low-code consultant is the quickest route when the need is short-lived or the team is small.
What a good partner brings besides code
The code is the visible part. The value sits in what happens around it, and it separates a tool your team uses from one they quietly abandon. A good partner gives you:
- Questions about your workflow before any screen is drawn, so the tool mirrors how work really flows.
- A written access map: who sees what and who changes what.
- A plan for the data, including which system owns each record.
- A handover you can run without the builder, with the code in your own repository.
- Support after launch, because the second month of use always produces the best change requests.
This is how we work at werun.dev: you set the goal, we build the way there and stay beside you afterwards. Replies arrive in under 2 hours on business days, which matters when a tool your team uses daily stops working.
Four internal tools worth building first
Most internal tools fall into four types. Naming yours early shortens the scope, because each type has a familiar shape and a familiar set of questions.
Type 1
Admin panel
Removes editing records by hand in spreadsheets or the database.
Type 2
Approval workflow
Removes chasing sign-offs through email and chat.
Type 3
Reporting dashboard
Removes rebuilding the same report every week.
Type 4
Client back office
Removes routine questions about orders, invoices and bookings.
Pick one. A tool that tries to be all four in its first release usually stretches past the budget and the deadline. The best first release is a single type solving a single workflow for a single team.
Admin panels for your own data
An admin panel gives your team a safe screen to view and edit the records that run the business: customers, orders, products, bookings. For example, a support agent corrects a delivery address in one form instead of asking a developer to change a database row. You get fewer interruptions for technical staff and fewer risky manual edits.
Approval workflows
An approval workflow routes a request (a discount, a purchase, a refund over a limit) to the right person and records the decision. For example, a sales rep asks for a discount and the director approves it from a phone in a minute. You get faster decisions and a trail that shows who agreed to what.
Reporting dashboards
A reporting dashboard pulls figures from your CRM, store and accounting into one view that refreshes itself. Think of the Monday report that takes someone two hours: it becomes a page that is already current when the meeting starts. You get hours back and numbers that everyone reads the same way.
Client back offices
A client back office lets your customers or partners see orders, invoices, bookings or documents without writing to you. A distributor, for example, checks stock and reorders alone. It cuts routine email and gives your clients a reason to stay.
Low-code or custom Next.js: how to decide
Choose by lifespan and size. Low-code platforms such as Retool let you assemble screens quickly on top of your data. A custom build with Next.js, the React framework described in the official Next.js documentation, gives you full control of screens, logic and hosting. Neither wins every time, so the comparison below uses criteria.
Quick start
Low-code (Retool style)
- Speed: first screens in days
- Cost shape: low build cost, a licence per user every month
- Limits: the platform's components and pricing tiers
- Ownership: the tool lives on the vendor's platform
Our pick for a core, long-lived tool
Custom Next.js
- Speed: first release in 4 to 8 weeks
- Cost shape: higher build cost, then flat hosting and care
- Limits: the ones you design
- Ownership: the code sits in your own repository
For the wider strategy beyond internal tools, our guide to low-code and no-code versus custom development covers the general framework.
When low-code is the faster answer
Low-code fits when most of these are true:
- The need is temporary, like a migration or a seasonal campaign.
- The team has fewer than about 20 users.
- The data lives in one or two systems the platform connects to.
- The screens are standard tables and forms.
In these cases low-code often wins on time and cost, and we say so to clients. A tool you can retire next year does not deserve a custom build.
When a custom build pays back
A custom build pays back when the tool becomes part of how you operate. The signs are many users (licences grow with each one), rules unique to your business, strict access needs, several systems behind the screens, or a plan to offer the tool to your clients. You also keep the code, so a change in a vendor's pricing never forces a rebuild.
What each path costs over three years
The shape of the cost differs more than the total. Low-code starts cheap and grows with every user, while custom starts higher and stays flat. The table is an illustrative example with assumed figures, not a quote: it assumes 30 USD per user per month for licences and 300 USD per month for hosting and care on the custom build.
| Item (USD) | Low-code, 25 users | Custom, 25 users | Low-code, 100 users | Custom, 100 users |
|---|---|---|---|---|
| Build | 6,000 | 30,000 | 8,000 | 32,000 |
| Licences or hosting and care, 36 months | 27,000 | 10,800 | 108,000 | 10,800 |
| Total over three years | 33,000 | 40,800 | 116,000 | 42,800 |
In this example low-code is cheaper for a small team and custom wins as users grow. Your own crossover depends on real licence prices, so ask each builder for a three-year figure and not only the build price.
Roles, logins and audit logs from day one
Access rules belong in the first scope, because an internal tool holds the data you least want exposed: customers, prices, payroll. Decide them with the builder before screens exist and they cost little. Retrofit them after launch and they touch every screen.
Why it matters
Access rules and audit logs are cheapest when written into the first scope and costly to retrofit. Broken access control has led the OWASP Top 10 list of web application risks, so treat it as a scoping decision, not an add-on.
The OWASP Top 10 is the standard reference for the most common web application risks. A good builder can tell you how the tool addresses each one.
Who can see and change what
List the roles in plain words, for example support agent, finance, manager and administrator. For each role, write which screens it sees, which records it edits and which actions it can never take. A table of five roles and ten actions is often enough. Sign-in with company email and two-step verification then decide who gets in at all.
Audit logs that answer who did this
An audit log records who changed what and when. When a price is wrong or an order disappears, you find the answer in a minute instead of a week of guessing. Ask that every sensitive action (edit, delete, approve, export) is logged, and that the people it describes cannot edit the log.
Where the data lives and who can reach it
Decide where data is stored, who hosts it, how backups work and in which country it is held. For teams in Spain and the European Union, that includes data protection rules. Ask also for separate test and live environments, so experiments never touch real records.
Connect the tool to your CRM, ERP and store
An internal tool earns its keep when it reads and writes the systems your team already uses: CRM, ERP, accounting, your WordPress or Shopify store. The aim is one screen where people act, with each change travelling back to the system that owns the record. Ask every builder how that connection works and what happens when a system is down.
The diagram shows the usual path. Your systems feed an API layer (the doorway software uses to talk to other software), the tool applies roles and records an audit log, and the team acts on one screen.
Tool connection path
- 01Your systemsCRM, ERP, WordPress or Shopify
- 02API layerConnects each system to the tool
- 03Internal toolApplies roles and records an audit log
- 04One team screenPeople review and act
- 05Changes sync backEach update reaches the source system
Flow showing CRM, ERP and store data entering an API layer, the internal tool applying roles and audit logs, and changes returning to the source
One source of truth for each record
Each record needs one owner. The customer lives in the CRM, the invoice in the ERP and the order in the store. The tool shows and edits them, but it does not hold a second copy that drifts apart, which is how two screens end up showing two different prices.
WordPress and Shopify both expose their data through APIs, so a tool can read orders, products and customers without touching the live site. Older systems can add work: some ERPs offer limited APIs or only file exports, and in Latin America the tool may also need local electronic invoicing services such as CFDI in Mexico. Our article on API and legacy system integrations goes deeper on these cases.
Automations with n8n for the routine steps
Some steps need no screen at all. When a deal closes in the CRM, an n8n workflow can create the client folder, send the welcome email and open the onboarding task. n8n is a workflow automation tool, and its documentation lists the connectors available. Small automations beside the tool often save more hours than one more screen.
Custom internal tools development: phases and budget
A first release fits in 4 to 8 weeks when it covers one workflow. One team, one workflow and two or three roles is a realistic first target, and more can follow once people use it.
Typical phases week by week
- Week 1
Scope and access map
You and the builder agree the workflow, the screens, the roles and the systems involved.
- Weeks 2 to 3
Data and login
Connections to your systems are built and sign-in with roles is working.
- Weeks 3 to 6
Core screens
The screens for the workflow take shape, with reviews you can click through every week.
- Weeks 6 to 7
Testing with real users
Your team runs real tasks and the builder fixes what gets in their way.
- Week 8
Launch and handover
The tool goes live with short training, documentation and the code in your repository.
Two or three people from your team should test during weeks 6 to 7, with real tasks. Their feedback does more than any specification. The first month after launch is for removing small friction.
What moves the price up or down
The table gives typical market ranges as illustrations. They are not werun.dev quotes, and your scope sets the real number.
| Size | What it covers | Typical time | Illustrative range (USD) |
|---|---|---|---|
| Small | One workflow, one or two roles, one data source | 4 to 5 weeks | 8,000 to 20,000 |
| Medium | Two or three workflows, several roles, two or three integrations | 6 to 8 weeks | 20,000 to 50,000 |
| Large | Several teams, complex rules, legacy systems, client access | 3 months or more, in phases | 50,000 and up |
The price rises with the number of integrations, systems without APIs, complex approval rules, client-facing access and heavy reports. It falls with one clear workflow, clean data, an existing design to follow and quick feedback from your side. At werun.dev, projects are sized Small, Medium, Large or Custom, and a monthly Retainer or Care plan can follow once the tool is live.
Questions to vet a builder and red flags
Good builders welcome questions about ownership and handover. Use the list below in your first call and compare the answers across two or three proposals.
Seven questions to ask before you sign
- Who owns the code and the data once the project is paid?
- Where is the tool hosted, and in whose account?
- How are logins, roles and audit logs handled?
- How does handover work, and what documents do I receive?
- What happens after launch: support, fixes and response times?
- Who exactly will work on it, and who is my contact?
- Can you show similar work and explain the trade-offs you made?
Listen for specifics. A builder who has done this before names a hosting provider, describes how roles are stored and explains what the handover pack contains. Our Casamiento app project shows what a purpose-built application looks like, as opposed to a template.
Red flags in proposals
- A fixed price with no written scope and no list of what is excluded.
- Code held in the builder's account with no promise of transfer.
- No mention of roles, logins or testing.
- Hosting on a personal server with no backup plan.
- A promise of everything in two weeks.
- No named team or contact.
- Pressure to sign before you have seen a plan.
One red flag is a reason to ask. Three are a reason to keep looking.
Where to start this week
Start with one page. Pick the single workflow that costs your team the most hours and write down five things: who uses it, what they do today, what the tool must show, who may change what, and which systems hold the data. Send that page to two or three builders and compare how each one responds.
If you want a team that scopes it with you, tell us your goal through the contact page and we reply in under 2 hours on business days. You can see the range of what we build on our solutions page, and how a custom build works on our custom apps platform page.
Frequently asked questions
Who can develop custom internal tools for my company?
An in-house developer, a freelancer, an agency or a low-code consultant can build them. Choose by size and lifespan: a low-code consultant for short-lived needs, an agency for core tools with several integrations and strict access rules.
How much does a custom admin dashboard cost?
Typical market ranges, given here as illustrations, run from about 8,000 to 20,000 USD for a small single-workflow tool to 50,000 USD and more for a large multi-team system. Integrations, legacy systems and access rules move the price the most.
Is Retool or a custom internal tool better for my team?
Retool and similar low-code platforms often win for short-lived tools and teams under about 20 users, because they are quick and cheap to start. A custom build wins when many users, unusual rules, strict access or a long life make per-user licences and platform limits costly.
How long does it take to build an internal tool?
A first release covering one workflow usually takes 4 to 8 weeks: scope, data and login, core screens, testing with real users and launch. Larger tools are delivered in phases after that first release.
What should an internal tool contract include?
It should state who owns the code and data, that hosting sits in your own account, a written scope with exclusions, access and audit log requirements, a handover with documentation and the support terms after launch.
