To hire an internal tools developer, look for a pragmatic full-stack engineer who is fast with admin panels, databases, and permissions, and who actually enjoys sitting with the ops or support team to watch how they work. That person may build on a low-code platform like Retool, in custom code, or both. The engineer who wants to build a platform is the wrong hire. Internal tools win by being boring, fast to change, and hard to break.
Key Takeaways
- Internal tools take real engineering time. In Retool's 2022 survey, respondents said they spent 33% of their time building them.
- Use off-the-shelf or low-code first. Hire an internal tools developer when the tool touches core data, needs real permissions, or changes every week.
- Screen for CRUD speed, data safety (audit trails, permissions), and how well they listen to non-engineers.
- A dedicated internal tools developer frees your product engineers to work on the product.
What an Internal Tools Developer Does
Internal tools are the admin panels, billing-fix screens, data-fix scripts, and ops dashboards nobody puts on the roadmap. They still get built, usually by product engineers in between sprints. An internal tools developer owns that work: the support console, the credits and billing-fix screen, the warehouse exception report, the permissions that stop the wrong person from editing the wrong record.
In Retool's 2022 State of Internal Tools survey, respondents said that on average they spent 33% of their time building internal tools. That's a 2022 figure from a vendor that sells internal tooling, so treat it as a signal rather than a benchmark. It still matches what I see: in many startups, a real share of engineering time goes into tools no customer ever sees.
Retool Developer or Custom Code?
A lot of searches for an internal tools developer are really asking whether to hire a Retool developer. The honest answer depends on the tool.
| Option | Good for | Watch out for |
|---|---|---|
| Buy a SaaS tool | Common jobs: CRM, ticketing, basic reporting | Doesn't fit your data model, per-seat cost |
| Automation tools | Moving data between apps, simple workflows | Gets fragile past a dozen steps |
| Low-code builders (Retool and similar) | Admin panels on your database, fast iteration | Complex logic, testing, version control |
| Custom code | Core workflows, sensitive data, heavy logic | Needs an owner and maintenance |
Start at the top of the table and move down only when you have to. Our comparisons of Zapier vs custom software and build vs buy for startups go deeper on where the lines sit.
My preference: hire a full-stack engineer who is comfortable in a low-code builder, not a low-code specialist. The builder covers the simple screens, and the same person can drop into real code when a tool outgrows it.
You need a developer when the tool edits production data, when mistakes cost money (customer credits, billing changes, account merges), when permissions matter, or when the ops team keeps asking for changes every week and your product engineers keep getting pulled in.
What to Screen For
CRUD speed. Can they build a clean form-and-table screen on top of an existing database in a day? Ask them to walk you through the last admin panel they shipped.
Data safety. Internal tools are where production data gets changed by hand. Ask how they'd add an audit log, how they'd stop a support agent from issuing the same credit twice, and how they'd make a bulk update reversible. Good candidates bring up confirmations, soft deletes, and role-based permissions without prompting.
Listening to users. Your users are the ops lead and the support team. Ask: "Tell me about a time a user asked for one thing and needed something else." Engineers who like this work tend to have a good story.
Taste for boring. Ask what they'd use for a new admin tool. If the answer is a new framework they've wanted to try, keep interviewing.
A Concrete Version
A subscription e-commerce company has 15 engineers. Support handles order credits, subscription pauses, and address changes by filing tickets that an engineer fixes with a database script. That's around 40 tickets a week, and each one costs an engineer 15 minutes plus the context switch.
That's about 10 hours of engineering time a week, and it lands at random, so the real cost to focus is higher. The CTO hires one senior full-stack developer to own internal tools.
In six weeks the developer ships a support console on the existing database: search customers, pause or cancel subscriptions, issue credits with a two-step confirmation, and see a full audit log of who changed what. Tickets to engineering drop from about 40 a week to around 3, the edge cases. Support resolves most issues on the first contact. Product engineers get back roughly nine hours a week (37 fewer tickets at 15 minutes each), and more importantly, stop being interrupted.
The developer then takes the next item on the ops wish list: a warehouse exception report that used to be a Friday spreadsheet.
The Honest Counterpoint
Some companies hire an internal tools developer when a low-code builder and one afternoon would have done. If your tool is a simple admin view on one table, don't hire for it.
The opposite mistake is also common: letting a low-code tool grow into a critical system with complex logic, no tests, and nobody who fully understands it. When the billing tool breaks on Black Friday, "the ops lead built it in a low-code app two years ago" is a bad answer. Once a tool is part of how you make money, it deserves an engineer and proper code.
And an internal tools developer needs a clear owner on the business side. Without one, they end up building whatever the loudest person asked for last.
Frequently Asked Questions
What does an internal tools developer do?
They build and maintain the tools your own team uses: admin panels, support consoles, data-fix tools, and ops reports. The job is part engineering, part sitting with ops and support to learn how they actually work.
Should I hire a Retool developer or a full-stack developer?
Usually a full-stack developer who is comfortable in Retool or a similar builder. Low-code covers the simple screens fast, and a full-stack engineer can move a tool into real code when it outgrows the platform.
How do I know an internal tools developer is worth it?
Track tickets that reach engineering, time support spends per issue, and interruptions to product engineers before and after. In my experience the payoff shows up within the first two months, or it probably won't.
The Bottom Line
Buy what you can, low-code what you can, and hire an internal tools developer for the tools that touch money and core data. Ruzora sends a vetted shortlist of senior full-stack engineers within 72 hours. See available engineers or browse full-stack developers in Latin America. If you're weighing the cost, read staff augmentation vs full-time hiring.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.
