What should be written down before buying software?

Start with the work you need to improve

A software demonstration can make the future look orderly. The business still needs to define the work, people, information, decision rights, cost, risk, and exit before it can judge whether the product fits.

Give yourself a basis for comparison

Write the problem in observable terms. Name the users, required records, current steps, desired result, integrations, permissions, security needs, full cost, implementation work, proof of success, and exit plan. Compare products against that record.

Describe the present work

Record what triggers the work, who performs it, which systems or documents are used, where delays occur, and how completion is verified. Measure frequency, time, errors, missed work, and customer or financial consequence when evidence exists.

“We need automation” does not name a result. “Two people spend six hours each week matching 150 deposits to invoices, and 12 items remain unresolved after five business days” can be checked before and after a change.

Name the required result

State what the product must allow a person to do. Separate required functions from preferences. Include the records that must remain authoritative, who may see or change them, what history must be retained, and how exceptions are handled.

Count the full work and cost

Subscription price is one part. Include setup, migration, cleanup, configuration, integration, training, support, hardware, payment fees, increased rates after an introductory period, internal administration, and the cost of leaving.

Ask who will own the implementation. A vendor can provide software and services. The business still owns decisions about its data, responsibilities, and acceptable result.

Review data and access

List the information the vendor will receive, where it is stored, who can access it, how access is removed, how backups work, and what can be exported. The FTC advises businesses to address vendor security in writing, restrict access to what is needed, require appropriate safeguards, and understand updates and remote access. NIST's small-business guidance begins with identifying the assets and services the business needs to protect.

The required review depends on the data and business. Customer payment data, health information, employee records, government identifiers, and confidential commercial information can create different duties.

Plan the exit before entry

Ask what data can be exported, in which format, at what cost, and how long it remains available after termination. Identify records or workflows that would be difficult to move. Note contract terms, renewal dates, notice periods, and deletion procedures.

Compare two scheduling products

A company wants new scheduling software because shifts are changed through messages. Its written requirement says managers must publish one approved schedule, staff must see only their location, changes need a named approver, and the record must show who changed what and when. Payroll export is required. Customer data is not.

One product has a lower subscription but lacks change history and needs manual payroll entry. Another costs more but meets the required record and export. The comparison can now address the real work instead of counting features.

Work out the cost of the first year

Consider two fictional offers for that scheduling business. Both meet the essential requirements after testing. Product A costs $60 a month and needs $600 of setup; Product B costs $110 a month and needs $300 of setup. Assume the business values the staff time spent administering either product at $25 an hour.

The lower subscription produces a higher total in this example. That result depends on the time estimates being realistic. If Product A actually requires only one hour a month, its total falls to $1,620. Ask the people doing the trial to record the time instead of accepting a sales estimate.

The time allowance may represent work reassigned within existing salaries rather than an additional cash payment. Keep the cash budget and the value of time separate. Neither total includes every possible cost: add migration, tax, hardware or other charges if they apply. A cheaper total cannot compensate for a failed essential requirement.

Give the trial a real task

Use fictional staff and shifts to publish a schedule, change a shift, check who can see it and export the payroll information. Have the person who will use the product perform the task. Record where they needed help and whether the exported data retained the information you require.

For this example, success means that staff see the correct location's approved schedule, an authorized manager can change it, the change history identifies the action, and the payroll export matches the test shifts. A failure on an essential item is a reason to resolve the gap before purchasing. A prettier demonstration is not evidence that the gap has gone away.

A solo business may need a much smaller trial: enter one representative job, create its invoice, find the record again and export it. The amount of testing should reflect the work and information at risk. Avoid adding approval steps that nobody in that business needs.

What to do next

Write a one-page purchasing record before the next demonstration. Use the same requirements for every vendor. Ask for a bounded trial using representative, non-sensitive data. Decide in advance which result will justify purchase and which failure will stop it.

Sources

• National Institute of Standards and Technology, Cybersecurity Framework 2.0 for Small Business. Checked September 18, 2026.
• Federal Trade Commission, Cybersecurity for Small Business. Checked September 18, 2026.