Choose off-the-shelf software when it demonstrably supports the essential workflow, can be configured acceptably and has clear operating costs. Consider custom software when important gaps remain after testing available options and you can define, fund and maintain the missing capabilities. A small integration or custom module may be enough to retain a useful existing product.
The buying decision is therefore about demonstrated fit, manageable ownership and lifecycle cost. The worksheet below gives a procurement team a way to compare evidence without assuming that more features, a lower subscription or bespoke development automatically wins.
Clarify what each supplier is proposing
Packaged software is an existing product sold under defined terms. It may be delivered as a cloud subscription or deployed elsewhere. SaaS is a delivery model, not a synonym for every off-the-shelf product.
Configuration uses options the product already provides, such as request types or role settings. Customization may involve a new extension or changes to product code. A custom-built system follows an agreed scope and can still use existing components. Ask what “customizable” means in each proposal: available configuration, separately priced development or an untested possibility.
The GOV.UK purchasing-strategy guidance recognizes buying, building and combined approaches and discusses practical product trials. It is a useful methodological reference here, not a statement of rules binding private businesses in the Gulf.
Set the gates before you score the options
Some requirements cannot be offset by a strong overall score. Give them observable tests rather than labels such as “secure” or “flexible.”
| Essential gate | Evidence to request |
|---|---|
| Core workflow | Complete it with representative test data |
| Access control | Show an allowed user and a blocked user attempting the same action |
| Usable data access | Provide an export with the required fields and relationships |
| Operating responsibility | Name owners for incidents, updates, backups and recovery |
| Organisational constraints | Review your approved hosting, privacy and procurement requirements |
An option that fails a gate needs a specific, verifiable remedy before it remains a candidate. A lower price or a long feature list cannot compensate for a capability without which the process cannot run. Equally, resist turning every preference into a gate: ask the process owner what actually stops the work.
Give every supplier the same demonstration task
Suppose the business is selecting an internal purchasing-request tool. This is a hypothetical evaluation exercise, not a PIXELSAA customer story. Use the same sample data and ask each candidate to demonstrate:
- An employee submits two line items and an attachment.
- A reviewer rejects one item and returns the other for correction, preserving the reasons.
- The employee corrects the request but cannot approve their own submission.
- Approval moves to an agreed delegate when the usual approver is away.
- A manager produces a report and exports requests with their decision reasons.
Record where the journey finishes inside the product and where someone must work outside it. Ask what closing each gap would cost and how the proposed customization would survive an upgrade. A verbal assurance is not a successful demonstration.
For software not yet built, a limited functional prototype can test the most uncertain part. Request a plan for what remains unproven. A successful prototype provides evidence about that slice; it does not establish that the complete system is production-ready.
Use a weighted worksheet, with evidence attached
After the gates, rank the acceptable candidates. The weights below are an original editorial starting point, not an industry standard or a measured result. Adjust them before reviewing proposals.
| Criterion | Example weight | Evidence beside the score |
|---|---|---|
| Workflow fit | 30 | Passed scenarios and remaining gaps |
| Integration and data | 20 | Connection and export checks |
| Ownership cost | 20 | Items and assumptions over one time horizon |
| Operations and support | 15 | Accountable owner and incident process |
| Change and exit flexibility | 15 | Supplier dependencies and handover path |
Use 0 for a criterion not met, 1 for a significant manual workaround, 2 for a fit requiring identified additional work and 3 for a fit within the compared scope supported by appropriate evidence. Mark missing evidence unresolved rather than awarding an optimistic score.
For a complete worksheet, add weight × score ÷ 3 across the criteria. The maximum is 100 because the weights sum to 100. This is a ranking aid, not a predicted success rate or financial return. There is no universal passing score. If a small change in priorities reverses the ranking, revisit the decisive assumptions rather than treating a narrow points difference as certainty.
Compare total ownership cost over an equal period
A development invoice and a single month's subscription are not comparable. Choose a horizon relevant to the decision—24 months is an example planning period, not a recommended contract term—and request the following for each option.
| Cost category | Packaged or configured product | Custom or integrated solution |
|---|---|---|
| Getting started | Configuration, migration and training | Analysis, build, testing and migration |
| Use | Licences, accounts and add-ons | Hosting, services and applicable licences |
| Changes | Configuration or extension updates | Development and verification of changes |
| Operations | Contracted support and internal work | Maintenance, support and internal work |
| Connections | Access charges and integration, if applicable | Connection delivery and operation, if needed |
| Leaving | Export and transition assistance under the terms | Handover and dependency transition under the agreement |
Leave a cost blank until it comes from a proposal or a documented tariff. Separate cash payments from internal time estimates. If you value employee time financially, show the assumed hours and valuation rate; an unexplained “cost of inefficiency” is not evidence.
Custom development is not automatically free of recurring expense. Nor is a packaged product always cheaper over a longer period. Model current usage and a changed user or data-volume scenario using explicit assumptions, rather than presenting a growth plan as a forecast that will certainly occur.
Assign the work that follows the purchase
Neither “packaged” nor “custom” guarantees security. AWS, for example, divides security responsibilities between provider and customer, with the allocation depending on the service. That illustrates the need to establish responsibilities; it does not describe every SaaS supplier's contract. AWS shared responsibility model.
Ask who provisions and closes accounts, reviews export permissions, tests recovery and approves updates. Clarify the data, code, documentation and accounts handed over under the agreement. Paying for development should not be treated as proof that every right or dependency transfers automatically.
Someone inside the business must also own the process decisions. If departments disagree about approval rules, resolve that ownership before expanding the build. A supplier can implement an agreed rule; another screen cannot resolve an organisational disagreement by itself.
Make a conditional decision
- Buy and configure when the essential journey passes, the configuration is acceptable and the operating terms are workable.
- Add a focused integration or module when an existing product already does most of the job and the remaining gap can be connected without uncontrolled duplicate records.
- Investigate a custom build when a documented essential gap remains after appropriate trials, and the business can fund and manage delivery and operation.
- Delay the implementation commitment when the process or source data is still unclear. Commission a bounded analysis or experiment with a specific question to resolve.
PIXELSAA's published Network Card Sales System documents sales, inventory, customer accounts, collections, reports and an activity log. Those capabilities can help you describe a concrete evaluation scenario. The page does not establish that another company needs the same system or that a packaged alternative was rejected during that project.
Once custom development is the chosen direction, use the custom software cost guide to turn requirements into a budget and acceptance conditions. Our Laravel business-system guide covers implementation and technology questions. For the current purchasing decision, prepare your essential requirements and the gaps observed during trials. Review custom software development, then discuss your software gaps and options with PIXELSAA. The useful outcome is a clear view of what to build, configure, connect or retain.
