When do you need custom software? Situations where an off-the-shelf product falls short

Custom software is a web, mobile or back-office application designed around an organisation’s business rules, user roles and integration needs. If an off-the-shelf product covers your work, you do not need custom software; the real question is noticing in time where the off-the-shelf product falls short.

Off-the-shelf products are a good solution for common needs and are often the fastest route. Still, at some points, bending your process to fit a product costs more than changing the process. The signs below show that you are approaching that point.

Six situations that point to custom software

1. A “shadow” system runs alongside the software. You use an off-the-shelf product, but the real tracking is still done in a spreadsheet or an e-mail chain. This is the clearest sign that the product does not cover the actual flow of the work.
2. Approval and assignment rules are specific to you. Your request, approval, assignment, deadline and status flows change by amount, department or customer type, and do not fit ready-made flows.
3. Every role needs to see a different screen. Customers, field teams, managers and auditors need separate permissions and separate views; the role structure the product offers does not cover this.
4. Data exchange with other systems is a must. The data has to talk regularly to the ERP, accounting or an external service, and the ready-made connections do not cover it.
5. Management wants different indicators. The role-based KPIs, reports and operational visibility you need go beyond the product’s standard reports.
6. Operations are intensive and repetitive. For a team that performs the same task hundreds of times a day, every extra click is a big loss; these teams need an efficient admin interface.

One or two of these six points may not take you to custom software on their own. If three or four sound familiar, it may be time to stop pushing the off-the-shelf product and separate what can stay standard from what needs to be custom-built. The picture that emerges is often a mixed one: standard work such as accounting or office applications stays in off-the-shelf products, while the flow that makes your business different is built specifically for your organisation.

An off-the-shelf product may still be the better choice

Custom software is not the answer to every problem. In these situations, staying with an off-the-shelf product usually makes more sense:

• Your process fits the common flow in your industry and you do not want to differentiate yourself from competitors in this area.
• The product’s settings cover most of the need; the small remaining gap can be managed by hand.
• The process has not settled yet. If you are setting up a new line of work for the first time, trying an off-the-shelf product first teaches you what you need at lower cost.
• There is not yet a plan to maintain and develop custom software.

Custom software is not a delivery but a product that the organisation has to own; it does not end on the day it goes live, that is the day it starts to learn.

The real risks of custom software

When deciding on custom software, you need to talk about the risks as well as the benefits. The first risk is that the scope keeps growing: a new request is added in every meeting and the project turns into a list that never ends. The second risk is that undocumented rules are carried into the software wrongly; if the current state of the process lives differently in everyone’s head, the software copies this confusion as it is. The third risk is maintenance: an application that has gone live ages over time if no one is there to handle updates, backups and changing needs. Talking about these three risks up front keeps both the scope and the expectations healthy.

How does custom software progress?

In custom software, the process is designed before the screen, and the user, data and business-rule architecture before the feature list. YazSis follows four stages in its Custom Software projects:

1. Discovery: the purpose, users, data and business rules are mapped out. What is written at this stage is not code but a shared understanding.
2. Experience and architecture: the usage flow and a sustainable technical structure are designed; roles, the data model and integration points become clear.
3. Development and testing: the application is developed in modules and verified with real scenarios.
4. Going live and support: the system goes live, usage is measured and it is improved with feedback.

The scope can range from web applications to admin panels, from request and approval systems to mobile apps, and from API services to back-office interfaces for intensive operations teams. Starting with a single flow and adding new modules over time reduces both the risk and the pressure on the budget. Once the first module starts working with real users, what the next module should be often emerges on its own; so instead of trying to draw the whole system in one go from the start, learning as you progress is the safer way.

Three things to prepare before you start

• Process map: the current flow written step by step, with its exceptions.
• Role list: who should be able to do what, who should be able to see what, who should approve what?
• Connection list: which systems the new application will exchange data with.

For details of our custom web, mobile and back-office solutions, take a look at the Custom Software page.