Custom software or off-the-shelf: how to decide
Choose custom software when an important workflow justifies the build and the responsibility of maintaining it. First, check what existing tools can do.
A custom application is a business commitment. It can fit a workflow closely, but someone still needs to own the requirements, access, hosting, and future changes. The decision starts with a process, not a feature wish list.
Map one real workflow
Choose a recurring task and follow it from the first input to the final result. Record who does each step, which systems they use, where information is copied, and what happens when a case does not follow the usual path.
Use a recent example. “We need a dashboard” is broad. “The operations team combines three reports every Monday and needs to identify missing submissions” describes a task that can be evaluated.
Compare three options
Configure an existing product
Consider this when the process is common and a product covers the important steps. Test the actual workflow, permissions, exports, and exception handling. A long feature list does not prove a good fit.
Connect existing tools
Consider an integration when each system already does its own job but the handoff is manual. Check the available APIs, provider limits, data formats, and ownership of failures. An integration may solve the gap without creating a whole new application.
Build a focused custom application
Consider this when the workflow matters to the business and the remaining gap is specific, repeated, and costly enough to justify a build. Define a usable first release and a maintenance owner before committing.
Look beyond the initial price
Compare the same set of costs for each option: setup, subscriptions, user seats, integration fees, data migration, training, hosting, maintenance, and future changes. Include the time people spend working around the current process.
Mark assumptions separately from measured costs. If you do not know how much time a task takes today, observe it before presenting a savings estimate as fact. A pilot can test whether the expected improvement survives real cases.
Ask who will own the system
- Who approves changes and decides what the next release includes?
- Who manages accounts and controls access?
- Who responds when an integration fails?
- Can the business export its records in a usable format?
- What is included in handoff, and what needs an ongoing care agreement?
- Which provider fees continue after delivery?
These questions belong in the proposal. They affect whether the application remains useful after the first demonstration.
Define a release you can accept
Write the first release as a complete task for a defined group of users. For example: receive an incoming report, store the source, show the current records, and flag missing deliveries. Include the relevant error paths and review steps.
Agree on acceptance criteria before the build. Use the same representative examples to check the current process and the new application. A polished screen matters, but the task needs to reach its intended result.
Use project evidence carefully
Business Data Hub shows how incoming reports, source history, and delivery tracking can form a connected system. The dealership CRM project shows conversation and assignment workflows and is in active development. These examples illustrate approaches; they do not establish a return on investment for a different business.
Bring this to the first conversation
One workflow, the people involved, the tools used today, and a representative example.
The gap you need to close, any constraints, and the result you would accept.
Known costs, assumptions you still need to test, and who will own the system after delivery.
That is enough to begin deciding whether configuration, an integration, or a custom application is the right first step.