Internal business software: when to build your own solution

Internal software is a system your team uses to carry out and track business processes: approving requests, reconciling information, organizing documents, or coordinating work across departments. It does not have to replace your ERP or include AI everywhere. Its value lies in solving a recurring problem that existing tools do not address well.

When off-the-shelf tools are no longer enough

Spreadsheets, email, and commercial tools can work well for a long time. The warning sign is a team constantly reconciling versions, entering the same information twice, and asking what stage a request has reached. Before building anything, identify the process, who makes decisions, where the authoritative information lives, and which exceptions actually occur.

Compare three approaches: configuring your current system more effectively, buying an off-the-shelf solution, or developing a custom extension. Consider implementation, integrations, licenses, maintenance, security, and training. An inexpensive subscription can become costly if it creates substantial rework; a proprietary system can also become costly if every change depends on one person.

An example: orders and approvals

Hypothetical example: a distributor receives orders by email, checks customer records in the ERP, and requests discount approvals through messages. Internal software could consolidate the orders, retrieve the records, and route exceptions to the responsible person. The ERP remains the system of record; the new application coordinates the handoffs between stages.

Discount rules, duplicate checks, and permissions stay in code. AI can extract information from a message or prepare a summary, with review whenever uncertainty arises. The first pilot does not need to authorize purchases or payments. This limited scope makes it possible to observe usage without immediately delegating irreversible actions to the system.

Build less and integrate better

Start with one small, complete workflow: intake, validation, ownership, completion, and history. Define who can read or change each piece of information and what happens when an integration fails. A retry must not create two orders; a partial failure must not appear as a completed operation.

Microsoft’s application lifecycle documentation covers requirements, development, testing, deployment, and maintenance. The practical takeaway is to treat an application as a product that needs ongoing care, not simply an initial delivery of screens.

Microsoft Learn — application lifecycle management in Power Platform

Security belongs in the scope

Define individual accounts, role-based access, action logs, and a process for revoking access. Document backup and recovery, and test with data appropriate for the development environment. Avoid placing secrets in screens, spreadsheets, or messages. Agree on code ownership and data export rights when contracting the project.

OWASP ASVS brings together verifiable application security requirements. It can inform acceptance criteria proportionate to the project; using this reference does not mean a system is certified or free of vulnerabilities.

OWASP — Application Security Verification Standard

How to evaluate the pilot

Choose indicators before starting: working minutes per request, time to completion, rework, integration failures, and actual team adoption. Compare similar periods and request types. Include support and human review in the cost; more application visits alone do not demonstrate better operations.

Hypothetical numerical example: 200 monthly requests require 12 minutes of manual work each, totaling 40 hours. If a pilot reaches 8 minutes for equivalent cases, the effort would fall to about 26.7 hours. The 13.3-hour difference is not guaranteed financial savings: costs, quality, and how that time is used still need to be assessed.

What to ask for in a proposal

Ask for a defined functional scope, confirmed integrations, acceptance criteria, responsibilities, documentation, and support terms. A phased rollout plan should explain how data will be migrated or preserved and how to return to the previous workflow if problems occur. The decision to build should follow operational needs, not a desire to put AI into every stage.

Authorship and review

Artinos team. Published and reviewed on October 6, 2026. The examples and calculations are hypothetical and do not describe Artinos clients, measured results, or commercial proposals.