Business Software Development: Building Tools That Actually Get Used

Internal software is having a moment. 35% of teams have already replaced functionality of at least one SaaS tool with a custom-built internal tool; 78% plan to build more custom tools in 2026 (Retool Build vs. Buy Report 2026). The low-code/no-code market, which primarily serves internal tooling, is now $26–35 billion, nearly 4x its 2020 size.

Despite this, internal projects still have a higher failure rate than customer-facing products, not because internal users are less important, but because the feedback loop is weaker. External customers churn and tell you why. Internal users complain to their manager, work around the tool, and eventually go back to spreadsheets. The fix is not better technology. It is more user research before the first line of code, faster iteration during development, and actual adoption measurement after launch.

Retool's 2026 Build vs. Buy report ranks the most commonly custom-built internal tools: (1) workflow automations, 35% of teams build these custom, (2) internal admin tools and back-office dashboards, 33%, (3) internal dashboards and reporting, (4) customer data portals, (5) approval and review workflows, (6) data pipelines and ETL tooling, (7) employee onboarding and HR tooling. The gap between what off-the-shelf SaaS provides and what companies actually need is widest in workflow automation and admin tooling.

Operations management tools. Scheduling, resource allocation, work order management: any process that generic project management tools do not model correctly because the domain specifics matter. A construction company's site management workflow is different from a professional services firm's project workflow in ways that generic tools flatten.

Reporting and data platforms. When a business needs visibility into data from multiple sources, the options are either to buy a BI tool and fight with connectors, or to build a reporting layer that sits on top of the actual data. For reporting that is truly core to how the business runs, not generic dashboards, custom is often the right answer.

Workflow and approval systems. Document approval, purchase order routing, compliance workflows, exception handling: these are often simpler to build custom than to configure in a generic tool, and the result is easier to explain to the people using it.

Adoption-first development starts with shadowing the people who will use the tool. Not interviewing: watching. Most people describe their process differently from how they actually do it. The gap between the stated process and the real process is where software projects go wrong.

Early releases should be embarrassingly limited: one workflow, one screen, the minimum to replace one part of what they currently do in spreadsheets. If they use the limited version, build the next part. If they do not, find out why before adding features.

Adoption is the whole game with internal software. Tools that match how people already work get used; tools that force a new process get worked around.

The best internal tool is the one your team would complain about losing.