Revision: revised with a build-or-buy decision matrix, a worked approval example and a practical discovery and handover checklist.
Bespoke software means custom software built for a particular organization's needs. The useful question is which part of your work justifies building and maintaining an application. An unusual approval rule, customer experience or connection between systems may justify custom development. A familiar process with suitable existing tools may not.
Custom software is not inherently cheaper, more secure or more scalable. Those outcomes depend on scope, implementation and ongoing operation. The framework below is our recommended way to compare options before commissioning a project; the worked example is hypothetical, not a client result.
Compare four approaches before choosing a development project
Start with a real task and representative sample data. Ask the same people to complete it in each shortlisted approach. Include an exception, a permission boundary and a data export. A feature checklist alone will not show whether a tool supports how work actually gets done.
| Approach | Consider it when | Evidence to request | Ongoing responsibility |
|---|---|---|---|
| Buy | A product supports the essential workflow without substantial changes. | Complete the task in a trial, including roles, exports and exceptions. | Account administration, training, subscriptions and vendor changes. |
| Configure | Supported fields, forms and rules can close the remaining gaps. | Demonstrate the configured workflow and document its limits. | Maintain configuration, permissions and compatibility with product updates. |
| Integrate | Existing tools work individually but people repeatedly move data between them. | Prove the required interfaces, field ownership and recovery from failed transfers. | Monitor synchronization, credentials, API changes and reconciliation. |
| Build | Essential behavior remains unsupported, or controlling that behavior is central to the service. | A tested prototype, bounded first release and named operating owner. | Maintain application code, infrastructure, dependencies, security and support. |
These approaches can be combined. A custom client portal might use an existing accounting product and identity provider. Define where each system remains authoritative: building a portal does not require rebuilding accounting. Include migration, training, support, hosting and exit work when comparing ownership costs over the same period.
Worked example: approving a client's revised deliverable
Imagine a small design studio that sends documents to clients for approval. Email replies sometimes refer to an older version, and project managers cannot easily establish what was approved. The proposed outcome is a traceable decision on a specific version, with fewer manual follow-ups. Measure the current problem before claiming an improvement.
Assume three candidates: a purchased portal, that portal with supported configuration, and a custom approval screen connected to the studio's existing project tool. These are approaches to test, not claims about a named vendor. Evaluate all three using the same document, two client accounts and a replacement version.
| Criterion | Purchased portal | Configured portal | Custom screen and integration |
|---|---|---|---|
| Version-specific decision | Test whether approval names the exact uploaded version. | Prove a configured rule prevents ambiguous approval. | Specify a version reference and test replacement after approval. |
| Client access | Try accessing another client's document. | Repeat after changing roles and folder rules. | Test every document and decision endpoint for the same boundary. |
| Project handover | Check the supported project connection or record the manual step. | Test configured automation and its failure visibility. | Test a failed transfer, retry and duplicate delivery. |
| Exit and continuity | Export documents and decisions; inspect what is missing. | Include custom fields and configuration in the exercise. | Restore files and decision records, then rebuild from the repository. |
If the purchased portal passes all essential checks, custom development has not earned its additional ownership burden. If configuration closes the gaps, document it and pilot that option. If only a custom screen can meet an essential rule, build that narrow part and keep the existing project tool. A missing convenience feature should not automatically become a requirement to replace everything.
An acceptance example is: “When the client approves document version 3, the decision records that version, the actor and the time. Uploading version 4 requires a new decision. A different client's user cannot view either version.” Agree this behavior before comparing demonstrations.
Make discovery produce something you can use
Discovery should reduce specific uncertainties and leave usable decisions. For the studio example, request these outputs before approving the first implementation scope:
- Workflow map: who uploads, reviews, approves, requests changes and handles an unanswered request.
- Requirement list: the business outcome, required behavior and acceptance check, with a named decision owner.
- Data and access map: client boundaries, document versions, decision history, retention and export needs.
- Prototype: the approval and revision journey, reviewed by someone who will use it.
- Integration evidence: a small proof that the existing project tool exposes the required interface and permissions.
- Release proposal: included work, exclusions, assumptions, unresolved questions and the pilot plan.
Our business versus functional requirements guide separates the desired outcome from application behavior. Use the functional versus technical requirements guide to connect that behavior with implementation constraints. The software requirements template gives you a shared starting document.
Bound the first release and expose estimate assumptions
For this example, include authenticated client access, document versions, approve/request-changes actions, a decision history, notifications and one project integration. Exclude document editing, electronic signatures, payment collection, native mobile apps and replacement of the project system. “Client portal” is a category, not an agreed scope.
Record assumptions that affect effort: supported file types and sizes, expected users and concurrent activity, source-data quality, authentication method, integration access, accessibility needs and who supplies content. An estimate should identify what has been inspected and what still depends on a prototype or external access.
Compare proposals against the same scope. Check whether testing, deployment, data import, documentation, user training and initial support are included. Ask for uncertainty by work area rather than treating one total as equally reliable throughout. Changes to a rule or dependency should produce an explicit scope and estimate decision before further work.
Assign a business owner who can resolve questions. Developers cannot independently decide whether an old approval remains valid, who may override it or how long a document should remain accessible. Unanswered business rules are project dependencies just as much as missing API credentials.
Deliver a complete workflow, then expand
- Prove the uncertain parts: test document access, version behavior and the integration using safe sample data.
- Build one complete journey: upload a version, request review, record a decision and show its result to the project manager.
- Exercise exceptions: revoked access, replaced documents, concurrent decisions, failed notifications and unavailable integrations.
- Pilot with a small group: record confusion, manual workarounds and support requests against the agreed outcome.
- Release with an operating plan: rehearse recovery, train the owner and document when to pause or reverse the rollout.
Review working software with the sample tasks throughout delivery. Separate a defect against an accepted rule from a useful new idea. Track new ideas for an explicit priority decision so the first release remains achievable. A complete, usable approval journey is stronger evidence of progress than several unfinished dashboards.
Establish control of code, data and operation
Do not assume “bespoke” automatically means unrestricted ownership of every component. Clarify which code and assets will be delivered, which are third-party dependencies, and what licenses or subscriptions the operating team will need. Record who controls the repository, domain, hosting, deployment accounts and integrations, with appropriate access for the people maintaining them.
For data, specify usable exports, attachment retrieval, account closure and retention behavior. Distinguish a database backup from an export a business user can understand. Decide who can request deletion or restore data and how those actions are recorded. These are operating requirements to settle before launch.
A useful handover contains setup and deployment instructions, configuration requirements, data relationships, role rules, automated checks, monitoring, backup and restore procedures, known limitations and a support contact. Have a second authorized operator follow the instructions in a separate environment. Repository access alone does not demonstrate that someone else can run the application.
Plan maintenance before approving the build
Name an owner for dependency updates, infrastructure, access reviews, failed jobs, backups and integration changes. Set a support window and escalation route that the business can actually sustain. Distinguish fixing a defect from adding a feature, and decide how maintenance work competes with the product backlog.
Schedule recovery exercises and review whether the software still serves its original purpose. Custom software can become difficult to change when knowledge sits with one person or operating work is unfunded. An existing product also needs administration and an exit plan; compare those responsibilities directly.
Our Corcava case study is a separate example of our product work. It is not the hypothetical approval portal described here. For a proposed application, our custom software development service starts with workflow, scope and delivery responsibilities. Bring one difficult task, representative data and the tools you already use; those make the first decision concrete.