Custom software is most useful when an organization's important workflow needs behavior that available products cannot economically supply. Begin by describing the work and testing available options. A clear workflow, a small acceptance example and an ownership plan give a development team something concrete to estimate and deliver.
This guide is for the person commissioning an internal tool or customer-facing service. Its outcome is a project brief that supports a build, buy or configure decision, followed by a first usable release. Download the project brief and fill it with observed work rather than a list of desired screens.
Describe the job before the interface
Consider a fictional repair business whose staff receive a device, record its serial number, get approval for a repair and notify the customer. Its current problem is duplicate intake records and uncertainty about who approved each job. “We need a dashboard” leaves both problems unresolved. A better starting statement is: “Staff need one traceable repair record from intake through collection.”
Observe one ordinary case and one exception with the people doing the work. Record what arrives, who makes a decision, what evidence they need, and what leaves the process. Include cancellations, missing information and corrections. Measure a baseline using the same definition you plan to use after release—for example, duplicate records per 100 intakes over a stated period. These are proposed measures for this fictional example, not industry benchmarks.
Compare three delivery routes
| Route | Strong fit | Evidence to obtain before choosing |
|---|---|---|
| Buy an existing product | The core workflow is common and can follow the product's conventions | Trial the real exception cases; inspect export and integration options |
| Configure or extend a platform | Most behavior exists and a few controlled differences matter | Prototype the hardest extension; price ongoing platform and maintenance dependencies |
| Build a custom application | Distinct workflow or integration requirements justify ownership | Demonstrate a small complete transaction; identify the team that will operate and change it |
Ask each candidate to perform the same acceptance examples with fabricated records. A feature checklist can show that a product has “approvals”; a trial shows whether approval remains traceable after a repair is revised. Document each gap and whether the business can reasonably change its process to close it.
Compare costs over a shared planning horizon. Include discovery, implementation, subscriptions, hosting, support, security updates, data migration, training and eventual exit. Use ranges tied to assumptions. A low implementation quote can still require significant operating effort, while a recurring subscription may include work your team would otherwise own. Request explicit prices and scope from candidates; this guide supplies no market quotations.
Turn a requirement into an observable test
For the repair desk, one acceptance example could be:
- Given an open repair with serial number
DEMO-104, an authorized intake worker submits another intake with that serial number. - The application presents the existing repair and asks the worker to review it.
- The worker can cancel or create a separate repair with a recorded reason, according to the agreed policy.
- The audit record identifies the worker, time and resulting repair identifier.
The example settles several design questions: whether duplicates are always prohibited, who can make an exception, and what evidence must remain. Write examples for ordinary intake, missing serial numbers, correction of an error and unavailable external services. Use invented identifiers in prototypes.
Set performance expectations in context. “Fast” becomes “the intake search completes within an agreed time for a stated number of concurrent staff and records.” The team then has a testable target and a dataset to use. Choose the actual thresholds with the people operating the service.
Deliver one complete path
Make the first release a small path through the whole system: a worker signs in, creates a repair, records approval and retrieves that record. This tests storage, permissions and deployment alongside the interface. Review working behavior with users frequently. The Agile Manifesto principles emphasize frequent delivery and feedback; the practical value here is discovering a mistaken workflow while it is still inexpensive to change.
Keep a decision log for deferred features. Record the reason, affected users and evidence that would move a feature into scope. That prevents every review from reopening the same discussion and helps a new team member understand the release boundary.
Make ownership part of acceptance
Before relying on the application, identify who holds the source repository, production accounts, domain, dependency inventory and deployment instructions. Assign responsibility for responding to incidents, installing updates, approving access and verifying backups. Ask the delivery team to demonstrate restoring a test copy and deploying a documented change from the repository.
Agree on data export format and exercise it with the prototype. A readable export plus a data dictionary makes future transitions easier. Record third-party licenses and the rights to custom code in the project agreement, with appropriate professional review for the actual contract.
Use the downloaded brief as a review record: baseline, options tested, acceptance examples, first-release boundary, operating owner and exit plan. If integration is the main uncertainty, the Jitterbit integration planning guide shows how to examine mapping, failure and duplicate delivery before committing to a workflow.