What really goes into a custom business system, and how to scope one

Most companies that consider a custom system start with the question of how big it is. The more useful question is what the system has to understand about the business. This article explains where the real work sits, why the first build is only part of it, and what to clarify before anyone writes code.

Where the work really sits

The code is rarely the hard part. In a typical business system, the work sits in four places:

• Understanding the process. Someone has to learn how your team works today, including the exceptions nobody wrote down. Skipping this is the most common reason systems get rebuilt.
• Integrations. Every connection to an accounting system, an e-commerce platform or a legacy database brings its own authentication, rate limits and data quirks.
• Edge cases. The happy path is 20 percent of the work. Refunds, partial deliveries, duplicate customers and permissions are the rest.
• Operations. Hosting, monitoring, backups, deployment and a handover that lets someone else maintain it.

A plan that covers only the first build and none of the operations is not a smaller project. It is an incomplete one.

Agree on results, not effort

A plan measured in effort says nothing about what you will be able to do once that effort is spent. Agree instead on concrete deliverables: what the system does when each part is finished, and how you will check it on your own data. That keeps everyone working towards a result rather than a clock.

With AI agents handling much of the coding, testing and review, a senior engineer can now deliver in weeks what used to take a team a quarter. That makes it realistic to work in short steps, with something real to look at after each one.

Five questions to answer before you start

You do not need a full specification to get started. You need answers to five questions:

1. What manual work should disappear, and how much time does it take today?
2. Which existing systems must it talk to?
3. Who will use it, and with what permissions?
4. What happens when it is wrong? A human review step is easy to build and risky to skip.
5. Who owns it after launch?

With those answers, an experienced developer can tell you within one conversation how large the project is and where the risks are.

A sensible first step

Start with the smallest thing that proves the idea on real data. A short proof answers the hard questions early and gives you something concrete to show colleagues. If it works, you extend it. If it does not, you have learned that in days rather than months.

Considering a custom system? Contact us and tell us what it should do, and we will help you find the right place to start.