How to Buy Custom Business Software

Describe the job. Test an existing product. Compare proposals against the same brief.

One Job, One Brief, Several Possible Answers

Before asking someone to build business software, describe a job your team needs to finish and the result someone can check. Use that description to try an existing product, its settings or a connection between tools. Take any specific unmet requirement into a proposal comparison.

A workable answer might be an existing feature, a configured product, an integration, custom software or a change to the process. A polished demo alone cannot settle that choice. Ask intended users to carry out the same task with the same exception in each option.

Copy the Buying Brief

Copy these prompts into your own document and share the same version with every option you consider. No form or email is needed. Keep an unanswered field as not yet known, with a person responsible for finding out.

Need and users: What job needs to finish? Who does it, who uses the result and who decides exceptions? [Write here.]
Inputs and output: Which records start the job? What must the saved result contain, and where must it be available? Attach a permitted sample. [Write here.]
Exception and control: Name one case that must be stopped or handled differently, what remains unchanged and the person who resolves it. [Write here.]
Constraints: Which existing systems stay? Who may read, change or approve records? Which permitted access or integration still needs evidence? [Write here.]
Observable acceptance task: Give the same sample inputs and exception to each option. Write the expected saved result, the steps a user will repeat and who accepts it. Record partial or failed steps as such. [Write here.]
Operating responsibility: Who maintains settings/code, notices failures and handles the manual route? What access, operating instructions and recovery evidence are still needed? Use not yet agreed where appropriate. [Write here.]
Option evidence and decision: For each option: proposed work and exclusions; evidence seen, by whom and when; unanswered questions and their owner; setup and ongoing costs if quoted, otherwise unknown. Choose, clarify or defer, with a reason and the next check. [Write here.]

Filled Brief — Shared Inspection Kits

Synthetic example. The business, records and comparison below are invented. No real product or supplier was tested. This is a reservation job using explicit rules; it does not require AI.

Need and users: Staff request a shared inspection kit. The equipment coordinator confirms its booking and settles conflicting requests. The team needs one usable reservation record instead of competing messages.
Inputs and output: Kit KIT-A; request R1 for 09:00–11:00 and request R2 for 10:00–12:00 on the same fictional working day. Save each request ID, kit, interval and status in a reservation list the coordinator can view and export.
Exception and control: R2 overlaps confirmed R1. Flag R2 for the coordinator; leave R1 unchanged and never create two overlapping confirmed bookings. The coordinator may reschedule R2 to 13:00–15:00.
Constraints: Staff may request but cannot confirm bookings. The coordinator can confirm or reschedule. Retain the current staff sign-in system; permission to connect it is not yet known. Accounting stays outside this job. Tests use these synthetic records, with no customer or staff personal data.
Observable acceptance task: A staff user submits R1; the coordinator confirms it. Submit overlapping R2 and inspect the conflict without changing R1. Check that a staff user cannot confirm it. Have the coordinator move R2 to 13:00–15:00 and confirm it. View and export both request IDs, final intervals and statuses. The coordinator checks each saved result; an omitted step remains unverified.
Operating responsibility: The coordinator owns booking decisions and keeps a manual reservation log while the option is unproven. A person responsible for technical operation, sign-in access, recovery procedure and support arrangements are not yet agreed.
Option evidence and decision: Compare the existing-product option and custom proposal below using this exact task, including the staff restriction and overlap. Keep proposed features separate from observed behavior. Costs and unprovided operating evidence remain unknown.

Compare Evidence Against That Same Task

Fictional comparison assumptions, not vendor findings. Imagine receiving the following materials. The supposed demonstration and proposal exist only inside this illustration; they are not completed tests or promises about available products.

Option A: configure an existing reservation product

Proposed work: Configure its booking rules and user roles for the filled brief. Keep the coordinator's reservation list. Staff sign-in connection is subject to checking; replacing accounting is excluded.
Assumed evidence: Suppose the coordinator has seen R1 saved, overlapping R2 flagged with R1 unchanged, then R2 rescheduled to 13:00–15:00 and both IDs exported. Those steps cover only part of the task.
Still unknown: The demonstration used a coordinator account throughout: a staff user's inability to confirm was not tested. Current staff sign-in access, operation and recovery arrangements and setup and ongoing costs are unverified.
Next evidence: Repeat the task with the intended staff and coordinator roles. Ask a qualified technical reviewer and the sign-in administrator to check permitted access and the proposed connection. Name an operating owner and obtain the missing cost and operating answers.

Option B: a custom reservation proposal

Proposed work: A reservation screen, explicit staff/coordinator roles, overlap validation and an export containing the same fields. Staff sign-in connection is subject to checking; replacing accounting is excluded.
Assumed evidence: Suppose the proposal includes screens and a written rule that R2 cannot overlap confirmed R1. There is no running demonstration with these inputs. A stated rule is a proposal, not a passed acceptance task.
Still unknown: Every saved-result and role step of the same task, current staff sign-in access, operation and recovery arrangements and setup and ongoing costs remain unverified.
Next evidence: Ask how the supplier would demonstrate the exact task, including R1 unchanged, staff confirmation blocked and rescheduled R2 exported. Obtain qualified technical review of the approach and access assumptions. Identify who will operate it.

Make the Decision Follow the Evidence

For this fictional brief: clarify Option A, defer selecting Option B. Option A has some assumed task evidence and one specific role check to finish. Option B has proposed behavior but no demonstrated task. Neither is ready for production use under the stated constraints. Keep the coordinator's manual log while those questions remain open.

If the existing product passes the whole task and the access and operating questions are resolved, configuration is a credible choice. If a tested limitation prevents a required step, record that precise gap before considering an integration or custom work. A missing sign-in proof is an unanswered question for both options; custom code does not settle permission to access a system.

A buyer can repeat the task and inspect the saved records. Ask a qualified technical reviewer to assess code quality, integration feasibility, security and recovery separately. A booking demonstration does not establish security, successful restoration or legal ownership. Keep those decisions separate and resolve them before relying on the system.

Use the same brief again when an answer changes: retain the evidence and unknowns, then record why you chose, clarified or deferred. For a system already in use, consider improving what you have. For detailed engagement choices, compare the alternatives; for ownership and transition terms under ClearSummit's agreement, read Trust and how we work.

To discuss an unresolved step, tell us the job, the systems involved and what remains unverified.

Further reading: Digital.gov's acquisition guidance discusses testing existing products against user needs, and 18F's buying guide connects required results and constraints with evaluation evidence. Both address US government procurement; their contract and regulatory requirements are not a checklist for every business purchase.