Home · About · Services · Industries · Projects · Products · Process · Blog · FAQ · Contact
Internal tools: build, buy or use a low-code platform? How we decide between a SaaS product, a low-code builder such as Retool or Appsmith, and custom software for admin panels, approvals and operations tools.
An operations manager asks for a screen to approve refunds. Today the team edits a spreadsheet, someone runs a query, and a developer updates the database by hand on Fridays. Three options come up in the first meeting: buy a product that does refunds, put together a quick app in a low-code builder, or have the developers build it properly. All three can work. They fail in different ways.
Short answer: buy internal tools when the process is standard and a mature product models it. Use low-code when the tool is a thin layer of forms and tables over data you own, for a small group. Build custom when the workflow is core to how you operate, carries real business rules, or will serve many users for years.
The rest of this post is how we apply that in practice. It is about operational tools such as admin panels, approval flows, review queues and dashboards. If you are choosing a whole HR system, our separate post on HRMS build versus buy covers that case.
Three different things, not one spectrum It is tempting to see these as cheap, medium and expensive versions of the same thing. They are not. Each one hands a different part of the work to someone else.
Buying a SaaS product hands over the process design. You adopt the vendor's idea of how refunds, tickets or inventory should work, and you get their updates, support and hosting. A low-code platform such as Retool, Appsmith, Budibase, ToolJet or Microsoft Power Apps hands over the user interface plumbing. You still design the process and own the data, but tables, forms, buttons and permissions come ready-made. Custom software hands over nothing. You own the process, the code, the hosting and every future change, and in return the tool does exactly what you need. Framed this way, the question becomes: which part of this work is genuinely yours? If the answer is none of it, buy. If it is the data and the steps but not the screens, low-code fits. If the rules themselves are where your organisation differs from everyone else, build.
When buying is the right call Most internal needs are less unusual than they first seem. Help desks, leave requests, expense claims, asset registers and simple CRMs are solved problems, and a mature product has already handled edge cases you have not thought of yet.
The process is one that most organisations in your sector run the same way. You are willing to change how you work to fit the product, at least a little. The product has an API or export, so your data is not trapped if you leave. Per-user pricing still makes sense at the headcount you expect in three years, not just today. Where the data is stored and who can access it are acceptable for your organisation. The common mistake is buying a product and then customising it heavily. Once you are writing scripts against a vendor's extension system to bend it into your process, you have the costs of a custom build without the control.
Where low-code platforms fit well Low-code builders are at their best for tools that are mostly CRUD: look up a record, edit a few fields, trigger an action, see a table. Connect the platform to your database or API, drag in components, and a usable tool can exist within days. Several of them, including Appsmith, Budibase and ToolJet, can be self-hosted, which keeps data inside your own network.
We think they fit when the users are a small internal group, the logic is light, and the tool can be thrown away or rebuilt without much pain. A support team's customer lookup screen or a weekly data correction form are good examples.
The limits show up over time rather than on day one:
Business logic ends up scattered across query snippets and button handlers, with no tests and little code review. Version control and promotion from staging to production exist on most platforms, but often on paid tiers, and teams frequently skip them. Per-user or per-app licensing can grow faster than expected once other departments want access. Each platform has its own way of building apps, so moving to another platform or to custom code usually means rebuilding the screens. Direct database access from a builder is powerful and risky. One badly written update query can change thousands of rows. If you use a low-code tool against a production database, give it the narrowest access possible. In PostgreSQL we create a separate schema of views for the tool and a role that can only read those views. Writes go through a small API with validation, or through specific functions, instead of raw table access.
-- A schema the internal tool is allowed to see
CREATE SCHEMA tools;
CREATE VIEW tools.pending_refunds AS
SELECT r.id, r.order_id, r.amount, r.reason, r.created_at
FROM public.refunds r
WHERE r.status = 'pending';
-- A login role that can only read those views
CREATE ROLE internal_tool LOGIN PASSWORD 'change-me';
GRANT CONNECT ON DATABASE app TO internal_tool;
GRANT USAGE ON SCHEMA tools TO internal_tool;
GRANT SELECT ON ALL TABLES IN SCHEMA tools TO internal_tool;
-- ALL TABLES covers views, but only ones that exist now.
-- Run this as the role that will create future views:
ALTER DEFAULT PRIVILEGES IN SCHEMA tools
GRANT SELECT ON TABLES TO internal_tool;The role has no privileges on the tables in the public schema, so it cannot read or change them directly, even if someone writes a careless query in the builder. The views still work because, by default, a view reads its tables with the privileges of the view owner. Do not create these views with the security_invoker option (PostgreSQL 15 and later), or that protection disappears.
When building custom earns its cost Custom software is the right answer less often than developers would like, but when it fits, it fits clearly. We recommend it when several of these are true:
The workflow encodes rules that make your organisation work, such as fee structures, allocation logic, clinical review steps or multi-level approvals with exceptions. Mistakes are expensive, so the logic needs automated tests, audit trails and code review. Many people will use it, including people outside the organisation such as students, patients or suppliers. It needs to integrate with several other systems in both directions, not just read from one database. It will be in use for years and will keep changing as the organisation changes. You need full control of where it runs and who can see the data. The cost of building is not mainly the first version. It is the years after: dependency updates, security patches, hosting, backups and the developer time to keep adding features. Budget for that from the start. A custom tool with no one responsible for it after launch ages faster than any SaaS product.
Custom does not have to mean starting from nothing. A modern framework with a generated admin interface, such as the Django admin, gives you authenticated CRUD screens for free, and you write code only for the parts that are specific to you. For many internal tools that combination is faster to build than people expect and far easier to maintain than a large low-code app.
A practical way to decide Before comparing products, write a one-page description of the tool: who uses it, what they do in it, which data it reads and writes, and what happens when it is wrong. Then answer these questions honestly.
Does a well-known product already do this? Try two of them with real data for a week before ruling them out. How many users will it have in three years, and does any licence model stay sensible at that number? How much of the value is in the rules rather than the screens? Who will maintain it, and do they know the chosen tool? What does leaving look like? Can you export the data and the logic, or only the data? What is the impact of a bug: a mildly annoyed colleague, or wrong money moving? Hybrids are often the sensible answer. Buy the standard product for the standard part, build a small service for the part that is yours, and connect them through APIs or an automation tool such as n8n. Or start in a low-code platform to learn what the users actually need, and plan to rebuild in code once the requirements settle. That second path works only if everyone agrees in advance that the prototype is a prototype.
Signs it is time to change course Whatever you choose, revisit it when the warning signs appear. Watch for these:
A bought product needs more workarounds and spreadsheets beside it every quarter. A low-code app has grown into dozens of screens, and only one person understands how it works. Licence costs for a builder or SaaS product are approaching what a small custom build would cost to run. A custom tool has no tests, no owner and dependencies several major versions behind. Users are exporting data to do their real work somewhere else. Any one of these is a reason to step back and redo the one-page description. Usually the process has changed and the tool has not. Choosing again with current information is cheaper than carrying a poor fit for another few years, and it is a normal part of running internal software well.
Infigini IT Services · 11 Kanwali Road, Dehradun 248001, India · info@infigini.com · +91 95684 87789