Bespoke software is developed for a particular requirement, while packaged software supplies an existing set of capabilities that may be configured or extended. Choose between them by the complete workflow, unresolved gaps, ownership terms and maintenance responsibilities. A custom build is not automatically a better fit, and a packaged product is not automatically ready for your process.
ERPNext’s documented purchasing workflow provides a concrete packaged example with explicit control choices. GitHub’s licensing guidance explains why access to source code and permission to use or change it are separate questions. Use those boundaries to evaluate a proposal without assuming a public repository or paid development automatically settles ownership. ERPNext buying, GitHub licensing guidance.
What should the buy-versus-build decision start with?
Describe the business task from beginning to end, including records, roles, exceptions and external systems. A list of screens can hide the real requirement. For example, a purchasing process may need separate request, receipt, invoice and payment decisions rather than one convenient form.
Ask a packaged candidate to demonstrate that workflow with realistic test records. Ask a bespoke proposal to identify which parts will be built, reused or integrated. Neither should receive credit for a capability merely because a screenshot resembles the desired screen.
AWS’s SDLC design guidance includes considering existing modules and integration with current infrastructure. Bespoke work can therefore include reuse; it does not require rebuilding every component. The decision should identify where custom work creates useful fit and where it adds maintenance without a corresponding need. AWS lifecycle design.
How do the delivery choices compare?
| Choice | Useful reason to investigate | Evidence required |
|---|---|---|
| Packaged product | Existing workflow may cover the requirement | Demonstration of the actual task and exceptions |
| Configured package | Existing capabilities need agreed settings | Configuration record and role-based test |
| Extended package | A bounded gap needs additional behaviour | Supported extension route and upgrade responsibility |
| Bespoke application | Essential workflow remains unmet | Requirements, architecture, acceptance evidence and maintenance owner |
This is an original decision framework, not a claim that one category is universally faster or less expensive. Compare the real proposal and its dependencies rather than relying on the label.
What can a packaged workflow reveal?
ERPNext distinguishes purchase commitment, goods receipt, invoice and payment. It also offers a direct purchase-invoice route that updates stock, while noting that this does not separate warehouse confirmation from invoice approval.
That is a useful example of fit evaluation. A business needing independent receipt approval should not accept the combined route merely because it requires fewer entries. Equally, a straightforward purchase may not need a long process if the business has deliberately chosen a simpler control.
The same documentation warns against updating stock through an invoice after a receipt already recorded the goods. Integration does not remove the need to understand physical event boundaries. Ask both packaged and bespoke candidates to explain how the same event is prevented from being counted twice.
Does source access mean ownership?
Not by itself. GitHub explains that a software licence states what others may do with the source. It also distinguishes default copyright rules from open-source licensing and notes that public-repository viewing and forking rights arise under its platform terms.
Do not treat a link to code as a complete handover. Establish the rights and obligations applicable to the actual components and agreement. This article does not provide a jurisdiction-specific contract opinion or decide who owns commissioned work.
Likewise, making a repository private does not remove existing forks or local copies according to GitHub’s guidance. Access control and previously granted permissions need separate consideration. Keep the licensing evidence with the project rather than assuming repository visibility answers every rights question. Source and licence distinctions.
An original capability-gap and exit register
Create a row for each important requirement:
Task: the complete business outcome and relevant user role.
Existing fit: documented capability and actual demonstration result.
Gap: the behaviour not yet met, stated precisely.
Proposed treatment: configuration, extension, integration, bespoke work or a business-process change.
Dependency: external service, library or platform involved.
Rights: applicable licence or agreement evidence, not an assumed ownership label.
Acceptance: cases that will demonstrate the requirement and its failure handling.
Maintenance: who updates, supports and retests the component.
Exit: source, data, configuration and account access needed to continue elsewhere.
Decision: accepted fit, rejected option or unresolved question.
The register is an original evaluation artefact. It makes a proposal reviewable without pretending an unbuilt feature is already available. Keep proposed customisation separate from capabilities demonstrated today.
How should maintainability be tested?
Ask another authorised maintainer to identify the source version, dependencies and configuration needed to run a test copy. A packaged product still needs operating knowledge; a bespoke application still depends on its underlying components and services.
Run a representative workflow with ordinary permissions and inspect the resulting records. Include an invalid input, a repeated action and an unavailable integration. Record actual outcomes rather than awarding a pass because the main screen loads.
For migration or exit, export sample data and inspect whether identifiers and relationships remain meaningful. A file download alone does not prove the application can be reconstructed or another product can import the records correctly.
What should determine the choice?
Choose the approach whose demonstrated fit and operating responsibilities the business understands. A strategic custom component may be justified, while another requirement may be served well by an existing product. The decision can combine approaches if the interfaces and owners remain clear.
Do not invent a delivery timetable, support promise or ownership clause to make one option look complete. Put unresolved commitments into the proposal for an actual decision.
Discuss the workflow through Spout’s web development service or start an enquiry with the gap register and candidate systems.
For a concrete comparison, choose one awkward transaction rather than a long feature list. A corrected customer order might need an amended document, a preserved original reference and an explanation of what changed. Ask each candidate to demonstrate that sequence. Record whether it works through configuration, a supported extension or a proposed new component. This makes the distinction between packaged fit and bespoke work visible without assuming either approach is inherently more flexible or more dependable.
Compare maintenance scope with the actual hosting arrangement before assuming source access settles operation.
By Spout Team. Prepared with AI-assisted drafting using the linked primary documentation.