Off-the-shelf or custom software: choose according to the work your team needs to complete and the total cost of running the system. Consider an existing product when it covers essential tasks with manageable configuration. Custom development is worth assessing when important business rules repeatedly require manual work or features the vendor cannot support.
You can also keep software that works well and build the missing part. Compare the options using the same task, sample data and expected result.
What are you buying with each option?
Off-the-shelf software can be an online subscription service, often called SaaS, or a product installed on your own infrastructure. Introducing it may still require data migration, access configuration and staff training. Custom development can use existing libraries and services alongside code written for your process.
The Odoo documentation, for example, describes an online service and several ways to install the same business system. Check hosting, customisation and maintenance separately when reviewing a proposal.
Scroll the table sideways to see all columns.
| Option | When to consider it | What to check |
|---|---|---|
| Off-the-shelf product | The main workflow already exists and suits your team. | The plan, user limits and the cost of moving to it. |
| Product with customisation | The core fits, but fields, rules or reports are missing. | Configuration limits and whether changes remain compatible after upgrades. |
| Custom development | Available products struggle to cover important requirements. | The specification, testing, maintenance and handover arrangements. |
| Combined solution | An existing product handles part of the work and a separate application covers the rest. | Data exchange, responsibilities and the cost of both components. |
How can you test a product before buying it?
Ask the vendor to demonstrate your task in the product. Choose a routine case and an exception that causes problems for the team. Use sample data without personal or confidential information.
- Write down where the task starts and ends. For a service job, specify who opens it and what must be recorded before it can close.
- Work through every user's role. Note where someone copies data into another program or needs an administrator's help.
- Try correcting a mistake, returning a request for more information and assigning it to another person. This helps reveal limitations before purchase.
- Export the result. Check that it includes the required fields and attachments, with the relationships between records.
- For each unsupported rule, ask whether it needs configuration, development or an integration, or whether the limitation will remain.
For sales and customer management, include CRM and ERP solutions in the assessment. If you are still deciding whether to leave spreadsheets, start with Excel versus custom software.
How do you compare costs over the same period?
A development quote and a monthly subscription cover different costs. Use the same assessment period, such as three years, and the same number of users. Include implementation, data migration and training in both options. Allow for the time your staff will spend checking the system.
For a subscription, check charges for the planned user count, extra modules, storage and connections. For custom development, include hosting, support, security updates and expected changes. A combined solution needs a budget for both components and their integration.
Check whether the plan allows the connection you need. Odoo's external API documentation specifies access with the Custom subscription plan, while One App Free and Standard do not include it. Confirm the terms of your chosen plan before basing an estimate on data exchange.
Product customisations can require work after an upgrade. Odoo's upgrade guidance requires custom modules to be compatible with the target version before upgrading the database. Ask who maintains those changes and how that work is charged.
Estimate the cost of current manual work separately. Measure time spent on recurring tasks, then use the trial to check how much of that work disappears. Compare the measured difference with the cost of the new system.
A hypothetical example: a service company with an existing ERP
Imagine a company that uses an ERP for invoices and stock. Field staff send findings and photos through messages. A manager copies them into a log and later checks whether the customer accepted the completed work. This is a hypothetical scenario for comparing the options.
The ERP's existing service module could be the first candidate. Test whether staff can use it comfortably on their phones and whether it supports the required review of findings. If it covers the task, introducing that module may be sufficient.
If important rules are missing, another option is a field application connected to the ERP. Invoicing stays in the ERP; the application manages jobs and field records. For the integration between systems, agree where each piece of data belongs, who may access it and what happens when a transfer fails. Assess replacing the ERP if it no longer supports the company's other work.
How can project examples help you assess the scope?
For Livsmedelsstädarna, internal checks cover departments, machines and inspection points, with findings reviewed again after corrective work. The customer portal is a separate area for viewing records and working with the service provider. When assessing an existing product, we would check whether it supports reviewing the same inspection point while retaining the original finding. Our case-study screens use demonstration data.
Azur Travel has a different scope: a public travel catalogue connected to an admin area for offers, hotels and destinations. Its public demo uses sample offers, has enquiry submission disabled and does not accept real bookings. For a particular agency, the actual content and enquiry handling still need to be agreed.
Who controls the data and maintains the system?
Before signing, ask for written details of data exports, admin access and the process for changing suppliers. For custom development, clarify access to source code, documentation and infrastructure. Agree usage and handover terms for the specific project.
With either model, identify who receives support requests, what support covers and who checks backups. If several products are involved, agree who investigates failed connections so your staff are not left passing the same request between vendors.
Frequently asked questions about choosing business software
Can you start with a product and move to a custom system later?
Yes. Before choosing it, check export formats, attachment access and how records are linked. Moving a small sample into a test system helps establish what a later migration would involve.
Is a small team a reason to rule out custom development?
Headcount alone is not enough to decide. The frequency of the task, its rules and the cost of the problem matter too. Development may be excessive for a simple, occasional task.
How can you limit the risk of the first version?
Keep its scope to one complete process that a user can finish. Agree acceptance criteria, a trial and what to do if data transfer or an essential function fails.
For a custom software development assessment, send a short description of one process and the programs you already use, without confidential data. Through our free project estimate, we can assess what to keep, what to connect and which part needs development.