Custom software or an existing platform?

Describe the work before choosing the software

Start with the work your business needs to complete. An ecommerce business may need catalogue management, payments, fulfilment and customer support. An internal HRM system may need employee records, leave requests and approval rules. An ERP project may connect purchasing, stock, finance and reporting. These labels describe broad areas, so turn them into actual workflows before comparing products.

Map one ordinary case and a few important exceptions. Who starts the task? What information is needed? Who approves it? What happens if a record is incomplete or a request is rejected? This exercise creates a more useful basis for selection than a long checklist of features with unclear definitions.

Test how well an existing platform fits

An existing platform is worth evaluating when its standard workflows are close to yours. Ask for a demonstration using representative examples from your business. Include the administration tasks as well as the customer-facing screens. A process that looks simple for the customer may leave your team doing substantial manual work.

Identify which requirements are available as standard, which need configuration, which depend on add-ons and which need custom development. Confirm those assumptions with the provider. Review the limits of the plan you are actually considering, including user roles, exports and integration access. A broad product description is not enough to establish what your proposed setup will include.

Identify where custom development has a clear purpose

Custom development deserves consideration when a critical workflow cannot be handled cleanly by the available options, or when the product experience itself is part of what your business sells. A specialised SaaS application, for example, may need distinctive customer journeys, business rules and reporting that do not fit a standard configuration.

Be specific about that difference. “We need flexibility” is difficult to evaluate; “each client has its own approval sequence and permission model” is a requirement a team can investigate. Custom software also needs ongoing ownership. Agree who will maintain the application, manage changes and support the infrastructure after the first release. Building it is one part of operating it.

Consider a combination of standard and custom tools

The decision does not always need to apply to the entire system. You might keep an established commerce platform and build a customer portal around a particular ordering process. You might retain your CRM and create a focused integration that moves approved enquiries into another system.

For a combination to work, define the boundaries clearly. Identify where each record is created, which system is authoritative and how updates move between systems. Include duplicate records, failed synchronisation and correction procedures. A short integration specification can expose more useful questions than a large diagram of connected products. Ask who will investigate failures and how staff will know that something needs attention.

Compare the whole cost of operating the solution

Compare the options over the same realistic period and user volume. For an existing platform, include subscriptions, add-ons, implementation, integration work, training and potential migration. For custom software, include discovery, design, development, testing, hosting, monitoring and ongoing maintenance. Both approaches may require content preparation and changes to internal processes.

Make the assumptions visible. An estimate for a small team using standard workflows should not be compared directly with a proposal covering multiple departments, complex permissions and data migration. Ask what happens when usage grows or requirements change. The purpose is to understand the commitments behind each option, rather than assume that either a subscription or a one-time build price represents the full cost.

Review data access, ownership and continuity

Ask how you can export your information, which formats are available and whether the export includes the relationships your business needs. Review access permissions and the practical process for adding or removing users. For custom work, confirm source code access, account ownership, documentation and handover responsibilities in the agreement.

Plan for ordinary change: a supplier changes, a team member leaves, a new department joins or the business needs a different report. Identify who can make those changes and what dependencies they introduce. Data portability and clear ownership are useful decision criteria even when you expect a long relationship with the same platform or development partner.

Run a focused evaluation before committing

Choose a small number of workflows that reveal whether an option fits. Test those with the people who will use and maintain the system. Record gaps, workarounds and open questions instead of relying only on an overall impression from a demonstration.

• Does it support the essential workflow and its common exceptions?
• Can it connect with the systems you must retain?
• Are permissions, data access and ownership clear?
• Can your team operate it comfortably?
• Are the ongoing responsibilities and costs understood?

Use the findings to choose a standard configuration, a custom build or a combination. A useful decision explains why the approach fits your business today and what would cause you to revisit it.