What Information Should You Give a Software Development Company?

Start with one page. Say what the business sells, how many people work in it, and which specific problem the software should remove, using plain words rather than technical requirements or feature lists. Context matters more than detail. Good context lets the vendor ask sharper follow-up questions in discovery, such as who approves orders, where stock is counted, and which spreadsheet currently holds the customer list.

Describe the problem, not the solution. Saying that you lose track of which purchase orders still await supplier confirmation tells a vendor far more than saying you need a dashboard. The first invites a proposal. The second fixes the answer before anyone has examined the question, and the vendor then builds a screen that nobody actually opens on a busy Monday morning.

Plain wording works best. Write for a reader who has never visited your shop floor, because the first person to read the brief is often a project manager, not a developer.

Exceptions are what briefs miss. List who uses the software, what each role does daily, and which steps change when a customer cancels midway, a discount code fails, or two staff edit one record. A vendor who hears only the happy path will build software that looks right in a demo and breaks during the first week of real use.

Take a retail chain’s loyalty scheme. Earning and redeeming points takes one line, but the build depends on what happens to points after a return, a changed phone number, or a purchase at another store. Name them early, even roughly. Rough answers written before quoting save weeks of rework, because every unanswered question becomes a change request once the vendor has priced and scheduled the original scope.

Ask the people who do the work. A dispatcher, a storekeeper or an accounts clerk will name exceptions the owner has forgotten, and ten minutes with each of them is worth a page of requirements.

Show the real data shape. Anonymised or synthetic samples that keep the SKU codes, date formats, duplicate customers and half-filled fields serve a vendor’s design and migration planning without exposing a live customer record.

Add every existing system the new software must connect to, and note how each one exposes its data: through an API, a file export, or not at all. Integrations found mid-build are a common cause of schedule slips, because they are expensive to retrofit into an architecture that was never designed around them.

Give a budget range. Without one, vendors guess, and they either overshoot the scope or undercut the price to win the work and recover the difference through change requests later. Naming a ceiling is not weakness.

Settle ownership before work starts. Write down which party owns the source code, the hosting account and the domain, and what support you expect after launch, including response times for urgent faults. Later they get harder. Once the vendor is the only person who understands the system, every term becomes a negotiation on their schedule instead of yours.

Ask for assumptions in writing. A quote that lists what it excludes, such as data migration, training and hosting set-up, lets you compare vendors honestly instead of comparing the lowest headline number.

Grant the narrowest access. Use a scoped developer account instead of the master admin login, a staging copy instead of production, and read access until the vendor genuinely needs to write. Most platforms already support it.

This is not distrust. A credible vendor expects scoped access and will not ask for broader credentials than the task requires, because a leaked password hurts both sides of the contract.

Keep a log of grants. Keep a simple record of who received which login, on what date, and when it should be withdrawn, so access ends when the work ends rather than lingering.