Custom web software or an off-the-shelf package? Seven questions for the right choice

The core difference between an off-the-shelf package and software built for your organisation is this: with a package, you adapt to how the software works; with custom software, it is shaped around your workflow. Web software is a business application that runs in the browser and manages an organisation’s own users, roles, data and business rules; a customer portal, an operations panel, an approval system or a SaaS product all fall into this group.

The right answer is rarely “always off the shelf” or “always custom”. The real work is being honest about how much of your process is truly standard. Let’s start with an example to make this concrete.

Imagine a distribution company that collects orders from its dealers. Orders arrive by e-mail, stock levels are kept in a spreadsheet, and every dealer has its own discount and shipment rules. A ready-made order package can handle most of these rules; but if dealer-specific rules are the heart of the business, the package’s settings screens eventually fall short and the team goes back to the spreadsheet. In the end, the company keeps paying both for the package licence and for maintaining the spreadsheets. When the same company offers its dealers an order portal that reflects its own rules, stock, discount and shipment information come together in one place; the dealer places orders from their own screen, and the team only deals with exceptions.

When is an off-the-shelf package enough?

For work that everyone in the industry does in roughly the same way and that does not set you apart from competitors, a package is often the shortest route. These situations favour a package:

• Your process fits the package’s flow with small adjustments.
• The number of users and the variety of roles are limited; everyone uses roughly the same screen.
• No data exchange with other systems is needed, or the package already offers it.
• Starting quickly matters more than being flexible in the details.

When does web software make sense?

If several of the signs below sound familiar, you may be approaching the limits of a package:

• Employees run the “real” work outside the software, in a spreadsheet, an e-mail chain or a paper form.
• You want to give customers, dealers or suppliers an entry point that works by your own rules.
• Customers, field staff, managers and auditors need to see the same data in different scopes.
• Your workflow has exceptions, and those exceptions are what make your business valuable.
• You need regular data exchange with ERP, CRM, accounting, payment or shipping systems.

Before choosing software, ask: which part of our process makes us different? If a package standardises that part as well, you will pay for it somewhere else.

Seven questions before you decide

1. Is the process standard? Draw the flow on a single page and put it next to the package’s flow. If the gap is small, a package is enough; if the gap sits at a critical step, the effort to adapt it may cost more than the software itself.
2. How often do exceptions occur? If an exception comes up once a month, it can be handled by hand. If the exceptions are the job, the software needs to know about them.
3. Who will use it? Only the internal team, or customers and suppliers too? As external users come in, the need for permissions and security grows.
4. Which systems will it talk to? As the number of systems to connect grows, a package’s ready-made connections may not be enough; the same data then gets entered by hand in two places.
5. What are the reporting needs? If the indicators management wants to see are not in the package’s standard reports, the data has to be compiled somewhere else.
6. How will you grow? Ask today whether the structure can carry more users, transactions or branches without trouble.
7. Who owns maintenance and support? Either way, it should be clear from the start who is responsible for updates, backups and support.

Comparing costs correctly

Comparing only the initial investment is misleading. Maintaining the spreadsheets that sit outside the package, re-entering the same data, manual methods that depend on one person, and extra tools are all part of the cost. On the other hand, custom software also carries a maintenance and development load; talking about it up front makes things easier for both sides. A good comparison should give a concrete answer, for each option, to the question “a year from now, who will run this work, and how?”

There is a middle path: progress in modules

The decision does not have to be all or nothing. Work that stays standard is left to ready-made solutions, and a custom application is developed for the part that sets your business apart. YazSis runs Web Software projects in three steps:

• Mapping the workflow: users, data, rules and exceptions are made visible.
• Building the product architecture: user experience, data model, integration and security are designed together.
• Developing in modules: parts are tested and taken live, then improved with usage data.

In this approach, security topics such as permissions, transaction logs, validation and backups are not features added later but part of the architecture from the start. That way, as the application grows, new modules are added instead of rewriting it from the ground up. In practice, starting with the flow that wastes the most time makes it easier, once the team has got used to it, to build the next need on the same structure.

For details of our approach to portals, admin panels and integrations, take a look at the Web Software page.