Describe the work your software must support
Start with a recent piece of work and follow it from arrival to completion. For a hypothetical membership organization, that might mean receiving an application, checking eligibility, collecting a fee, granting access, and handling a renewal. List the people, records, and handoffs involved. A feature checklist alone can miss the spreadsheet that staff maintain because two systems disagree about whether someone is active.
Ask what is actually different about your process. A preferred button color rarely justifies a custom application. A distinctive approval model, specialized quoting logic, unusual data relationship, or customer experience may. Also question whether a difficult step reflects a valuable business requirement or a habit that could be simplified before software is commissioned.
Compare buying, connecting, and building
Buying a product can be appropriate when its normal workflow matches the work and its limitations are acceptable. Configuring or connecting existing tools can address gaps without replacing the underlying systems. A custom application becomes a stronger candidate when the essential workflow is poorly supported, the differences matter, and the organization can own the resulting product over time.
The UK Technology Code of Practice is written for government, but its attention to user needs, reuse, integration, open standards, and purchasing strategy provides useful questions for smaller organizations too. It does not make the commercial decision for you. Evaluate the actual products and requirements in front of you.
| Approach | A good reason to choose it | What to examine |
|---|---|---|
| Buy and configure | The standard workflow is a close fit | Limits, permissions, exports, and pricing structure |
| Connect existing systems | The tools work, but their handoffs do not | API access, ownership of records, and failure handling |
| Build a custom application | The distinctive workflow is central to the business | Scope, maintenance, migration, and operating responsibility |
Custom experiences can use established services
Morgan 5AVAG3’s artist platform illustrates a selective approach. Its interactive presentation and publishing tools are tailored to the artist, while merchandise uses Fourthwall’s catalog and checkout infrastructure. The application validates selected variants, quantity, and currency before handing off checkout. A distinctive storefront therefore does not require a second inventory system or a new payment processor.
LAYIQ combines its product-specific search, recommendations, and application workflows with services for identity and billing. UFAAFU’s custom gifting experience uses Cloudflare Workers, D1, and R2 for application execution and persistence. These projects have different identities and requirements; their shared lesson is architectural. Build the behavior that makes the product useful, while choosing existing components deliberately for the surrounding responsibilities.
Compare costs across the life of the workflow
A subscription quote and a development estimate are different kinds of numbers. To compare them, include setup, data cleanup, migration, staff training, integration work, support, and the work still performed manually. For a custom application, include hosting, monitoring, dependency updates, backups, and the engineering needed when requirements change. For a purchased product, examine the plan needed for APIs, permissions, exports, and the number of actual users.
Use a range of plausible operating conditions rather than one optimistic forecast. What changes if usage doubles, a key integration is withdrawn, or the person managing the system leaves? Keep assumptions visible so they can be challenged. A credible decision does not require inventing a precise return on investment before the workflow and ongoing responsibilities are understood.
Prove the difficult integration before committing
A vendor saying it has an API is the beginning of a discussion. Test the operations your workflow needs: reading the right records, changing the right fields, handling pagination, and recognizing a successful update. Determine what happens during an outage and how repeated requests are prevented from creating duplicate work. Confirm which system owns each important fact rather than allowing several copies to drift without a reconciliation rule.
For the membership example, a payment record and an access decision are related but not interchangeable. Decide when access changes, how refunds or failed renewals are handled, and how staff investigate a disagreement. This may call for a small integration service instead of a new membership platform. A focused technical prototype can make that choice concrete.
Plan who operates it and how you could leave
Ask who controls the source repository, deployment account, domain, service credentials, and data exports. Identify who approves changes and who responds when a critical function stops working. For purchased software, understand export formats and what they omit. For custom work, request usable setup instructions, a documented data model, and a clear handover of accounts and code. Ownership should be practical, not just a line in a proposal.
Migration also needs an acceptance test. Choose representative records, check their history and relationships, and decide how the team will recognize a complete transfer. Keep the previous system available for an agreed transition period where appropriate. Replacing software without a clear route for the existing records can move the most expensive uncertainty to the end of the project.
Choose a first move that teaches you something
When the decision is close, test the narrowest valuable workflow. Configure a trial with representative scenarios, prototype the integration that appears missing, or build a limited interface over the existing system. Judge it by whether the people doing the work can finish the task and resolve exceptions, not by how many features appear in a demonstration.
A boutique software engagement can start with this comparison rather than a commitment to a large replacement. The useful output is a defensible recommendation, visible tradeoffs, and a bounded next step. Sometimes that means buying the right tool. Sometimes it means building a product around a workflow that existing tools cannot adequately support.
Sources & further reading
Primary documentation supporting the technical guidance in this article.