What to consider before building a custom business application

Custom software is the right answer for some businesses and a costly mistake for others. The difference usually comes down to the thinking done before any code is written. A business that knows exactly which problem it is solving, who will use the system every day and what it will replace tends to get a tool that pays for itself. A business that starts with a vague wish to “have an app” tends to end up with a half-finished project and a strained relationship with its developer. This article covers the questions worth answering first.

Check whether something already does the job

The first question is uncomfortable but necessary. Is there an existing product that does most of what you need? For many common functions, such as invoicing, scheduling, CRM, rostering, project tracking and inventory, there are mature tools that cost a fraction of a custom build and are maintained by someone else.

Custom software makes sense when your process is genuinely different from the norm, when the off-the-shelf options force you into a workflow that hurts the business, or when you need several systems to work together in a way no product supports. It also makes sense when the process is the business, such as a specialised quoting engine for a manufacturer or a compliance workflow unique to an industry.

A useful exercise is to list what you need and then spend a day trialling two or three existing products. If one gets you most of the way, configure it and move on. If none come close, you have a stronger case for building.

Define the problem, not the feature list

Developers can build almost anything you describe. The risk is that you describe the wrong thing. Before writing a feature list, write a plain statement of the problem. For example: “Our technicians record job details on paper, the office retypes them, and invoices go out a week late with errors.”

That statement points to the outcome you want, which is accurate same-day invoicing. The features follow from it: a mobile form for technicians, automatic transfer to the accounting system, a review step for the office. Starting with the feature list instead often produces a long wish list where the important items are mixed in with ideas someone had in a meeting.

Keep a separate list of things the system must not do. If it is not meant to replace your accounting package, say so. Scope boundaries prevent the project from growing until it collapses.

Know who will use it and where

A system used by office staff on large screens is a different build from one used by tradespeople in the rain with gloves on. Interview the people who will use it daily and watch how they work now. Note what they skip, what they work around and what they complain about.

Consider the environment too. Does the system need to work offline on a job site? Will it be used on personal phones? Does it need to be usable by someone who joined last week? These answers affect the design more than any list of features.

If the people who will use the system are not involved in the planning, they will find reasons not to use it. Adoption is where most custom projects fail, and it is decided long before launch.

Decide what it connects to

Almost every business application needs to exchange data with something else: an accounting system, a CRM, an email platform, a payment gateway, a booking tool. Each connection is a piece of work and a point of failure. List them early, confirm each one offers a usable way to connect, and decide which direction the data flows.

Also decide where the master record lives. If customer details exist in both the new system and your accounting package, one of them has to be the source of truth, or you will spend years fixing mismatches.

Plan for the ongoing cost

A custom application is never finished. Operating systems update, browsers change, the third-party services it connects to change their rules, and the business itself changes. Budget for hosting, monitoring, security updates and a steady stream of small improvements. A system nobody maintains becomes a risk within a couple of years.

Ask who will own the system internally. Someone in the business needs to be responsible for deciding what changes, prioritising requests and testing updates. If nobody has that role, the application drifts.

Choose a developer you can work with for years

You are not buying a product, you are starting a working relationship. Look for a developer who asks about your business before talking about technology, who pushes back on ideas that will not help, and who can explain their recommendations in plain terms.

Ask practical questions. Who owns the code and the data? What happens if you want to move to another provider? How are changes requested and priced? How do they handle security and backups? What does support look like after launch? Clear answers matter more than an impressive portfolio.

Be cautious of a fixed quote for a system that has not been properly specified. Either the price is padded for the unknowns or the developer will be cutting corners when they appear. A short paid discovery phase that produces a specification and a realistic estimate is a better footing for both sides.

Build small and prove it

Resist launching with everything. Identify the smallest version that solves the core problem, build that, and put it in front of real users. The first few weeks will produce more useful feedback than months of planning. Then improve it in short cycles.

This approach also protects the budget. If the first version shows the idea does not work as expected, you have learned that cheaply. If it does work, every later release is building on something proven.

Where to start

Spend a week on the groundwork before contacting anyone about a build.

• Write the problem statement in two or three sentences and have the people affected agree with it.
• Trial existing products and record where they fall short.
• List the daily users, their environment and the systems the application must connect to.
• Decide who in the business will own the system after launch.
• Set a budget that includes the first two years of maintenance, not just the build.

With that in hand, a conversation with a developer becomes a discussion about how, rather than a guess about what, and the result is far more likely to be a tool the business keeps using.