Off-the-shelf or custom software: a decision guide for organisations

Off-the-shelf software is usually the right choice for organisations whose processes are close to common practice, that want to start quickly and whose integration needs are limited. A custom system suits organisations with distinctive processes, that want to bring several tools together on one data model and want their data, rules and roadmap under their own control. The decision should weigh total cost over several years, process fit, ownership, integrations and maintenance together, not just the initial price.

What is the difference between off-the-shelf and custom software?

Off-the-shelf software is a product designed around the shared needs of many organisations and usually used under a subscription or licence. Its scope, screens and roadmap are set by the vendor; the organisation can adapt it only as far as the available settings and add-ons allow. Its greatest advantage is speed: setup is short, and workflows tested by other organisations can be used right away.

A custom system is software developed by analysing the organisation's own processes, rules and data structure. Screens, permissions and workflows are designed around how the organisation actually works. The approach takes more analysis and development effort but does not force the organisation into the software's limits.

There is also a third path between the two: sector platforms built for a specific field whose modules can be switched on per organisation and configured to fit. These products try to combine the speed of off-the-shelf software with the domain knowledge of custom work, and can be a balanced option for organisations that share similar processes, such as associations, academic journals and congress organisers.

How should costs be compared?

The most common mistake in comparing costs is to set the monthly fee of off-the-shelf software against the one-off development cost of custom software. The right comparison uses total cost of ownership over several years. Alongside licence and subscription fees, that calculation should include setup, customisation, data migration, training, integrations, maintenance and the cost of moving to another system later.

• Licence, subscription or development fees, and how they will change over the years, are taken into account.
• The effort needed for setup, customisation and migrating data from the old system is calculated separately.
• Staff training and the loss of productivity during the transition are not overlooked.
• The budget for setting up and maintaining integrations is listed as a separate item.
• Extra tools for work the product does not cover, and work done by hand, are added to the cost as well.
• The cost of moving to another system later, the exit cost, is estimated at the start.

With off-the-shelf software, cost often rises with the number of users, the volume of records or the number of modules enabled. As the organisation grows, or as more departments use the software, a fee that looked low at first can climb noticeably. Buying a separate tool for a need the product does not cover, or running the work by hand in spreadsheets, is an invisible but very real cost too.

With custom software, the initial investment is higher and an ongoing budget has to be set aside for maintenance. In return, there is usually no per-user fee, and the organisation invests only in the features it needs. Which is more economical depends on the organisation's size, the complexity of its processes and how long it plans to use the software; there is no universal answer.

Why are process fit and data ownership decisive?

Every piece of software imposes a way of working. With off-the-shelf software, the key question is how ready the organisation is to fit its processes to the software. If the processes are close to common practice in the sector, that fit is easy and may even bring in good practice. If they are distinctive, for example involving multi-level approvals, branch-based permissions or domain-specific rules, manual workarounds pile up around the software.

We faced this in our own operations. Monthly packages, quota usage, extra work, revisions, collections and cheques were tracked in different places, and period close and client balances were calculated by hand every month. So we built Bir Finans on a double-entry ledger with a quota and period engine; corrections are made by reversal rather than deletion, and every change lands in an audit log.

Data ownership, meanwhile, is usually noticed only when the organisation wants to change systems. Whether the data can be exported completely and in a usable form, how long it will be kept if the subscription ends and how directly the organisation can access its own records are questions to ask at contract stage. With custom software, the contract should state clearly who owns the source code and the data.

How do integration needs affect the decision?

Institutional software rarely works alone. Connections such as online payments and virtual POS, bank movements, e-Fatura and e-Arşiv, e-Devlet, shipping, SMS services and email services are part of most organisations' daily work. With off-the-shelf software, these integrations are limited to the product's catalogue; for a connection not in the catalogue, you have to wait for the vendor's roadmap.

As integrations multiply, so does the manual movement of data between systems. When membership lives in one system, dues in another and training records in a third tool, it becomes impossible to see a person's full history on one screen. That fragmentation is one of the most common reasons organisations turn to a custom system: the aim is less to add new features than to bring existing work together on one data model.

When assessing integrations, look not only at whether a connection exists but at how it works. Verification of payment callbacks, retrying failed operations, reconciliation reports and how much the system is affected when a provider is replaced determine the quality of daily work in the long run.

How do you plan for scaling and maintenance in the long term?

With off-the-shelf software, infrastructure, security updates and new versions are the vendor's responsibility, which is a significant relief for the organisation. In exchange, the product's direction is also the vendor's decision: a feature the organisation relies on may change, the pricing model may be updated or support for the product may end. These risks should be covered in the contract and an exit plan.

With custom software, continuity of maintenance is something the organisation and the developer must plan together. Documentation, protection by automated tests, keeping the source code where the organisation can reach it and making sure knowledge does not depend on a single person are prerequisites for long-lived software. On scaling, a well-designed system needs only more infrastructure, not more licence fees, as users and records grow.

Whichever route is chosen, preparing an exit plan is a good habit. With off-the-shelf software, the plan covers in what format and how often data is exported, and a transition timeline should the subscription end. With custom software, it defines the documents, access and source-code handover terms a new team would need to take over the system if the developer changes. An organisation with an exit plan also keeps its bargaining power.

The right software decision is not the one that covers today's need most cheaply, but the one that will carry the organisation's work five years from now with the least friction.

Which option fits which situation?

The two lists below can be used like a decision table to clarify the choice. An organisation's situation often touches both lists; which one has more, and more critical, items ticked helps set the direction.

Off-the-shelf software is usually the better fit when:

• The organisation's processes are close to common practice in the sector and open to adapting to the software.
• Starting quickly matters more than a long analysis and development process.
• The required integrations are already available in the product's catalogue.
• The organisation has no budget or team to take on software maintenance.
• It has been confirmed that data can be exported in full and that exit terms are clear.

A custom system is usually the better fit when:

• The organisation's processes are distinctive and can only be met in off-the-shelf products with manual workarounds.
• The aim is to bring several tools together on one data model and see a person's full history on one screen.
• The organisation has its own specific integrations or regulatory reporting needs.
• Licence costs are expected to grow disproportionately as users or records increase.
• Keeping data, rules and the roadmap under the organisation's own control is strategically important.

Frequently asked questions

Is custom software always more expensive?

Often yes in terms of initial investment, but not always in terms of total cost of ownership. Once per-user fees, extra tools and the cost of manual work are spread over several years, the picture can change. The comparison has to cover the same period and the same scope.

Can old data be moved when switching from off-the-shelf to a custom system?

In most cases yes, but the quality of the migration depends on how complete the old system's export is. Before migrating, missing and inconsistent records in the old data should be identified, mapping rules written down and no value filled in by guesswork.

Who owns the source code of custom software?

That depends on the contract and should be settled before the project begins. Different models are possible, such as transferring the source code to the organisation, granting it usage rights, or building organisation-specific modules on the developer's own product core. Whichever model is chosen, it should be written explicitly that the data belongs to the organisation.

Is it possible to combine off-the-shelf and custom software?

Yes, and it is often the most balanced route. The organisation's distinctive processes can run in a custom system while standard work runs in ready-made tools. In that case, the integrations that connect the two and which system holds the master record for each piece of data need to be decided at the start.

How should the decision process begin?

Starting the decision not with product demos but with a written inventory of the organisation's own processes and of which tasks are done by hand today lets you assess both options against the same criteria. That inventory clarifies both off-the-shelf proposals and the scope of custom development. At Bir Web Ajans we start custom systems with process analysis and migrate records from legacy systems into the new structure without inventing a single value.