How to brief a software shop so quotes mean something
Vague briefs get vague quotes. A clear one-page brief gives a shop enough to estimate honestly, and gives you a way to compare proposals that are actually talking about the same job.
Vinerals TechnologiesWorkshop notes
Most first-time buyers of custom software send the same thing: a paragraph in an email, a slide deck from a strategy session, or a feature list copied from a competitor’s website. Then they wonder why one shop quotes $45,000 and another quotes $280,000 for what sounds like the same project.
The quotes are usually both sincere. They are just answering different questions. A vague brief forces every shop to guess at the parts you left out, and guessing is where the spread comes from.
A good brief does not need to be long. One page, maybe two if integrations are messy, is enough to get estimates you can compare. This piece walks through what belongs in that page, and ends with an outline you can copy and fill in before your next conversation.
What a one-page brief is trying to do
The brief is not a contract and not a specification. It is a shared picture of the job: who uses it, what they need to get done, what cannot change, and what success looks like. Enough detail that a senior person can estimate without inventing your business.
You are not trying to design the software. You are trying to describe the problem clearly enough that someone else can propose a shape for the solution. The best briefs we receive read like a letter from a thoughtful operator, not like a requirements document written by committee.
Context in three sentences.
What your company does, why this project exists now, and what happens if you do nothing for another year.
The job in one sentence.
Not a product name. The work the software has to make easier. “Help our field team log inspections and sync them to billing” is a job. “We need an app” is not.
Who touches it.
Roles, not org chart titles. How many people, how often, on what devices, in what language.
What you already have.
Spreadsheets, SaaS tools, paper forms, a half-finished prototype. Include the good, the bad, and the thing everyone secretly uses instead of the official system.
Timeline and budget range.
Even a wide band helps. “Need something usable before harvest season” and “roughly CAD $80k to $120k” tell us more than “ASAP” and “best price.”
Users, jobs, constraints, and non-goals
This is the heart of the brief. Get specific here and the rest of the quote gets honest.
Users and jobs
List the people who will use the system and the main thing each group needs to accomplish. Two or three groups is normal. More than five usually means the project is actually three projects wearing one coat.
Warehouse lead.
Receives shipments, assigns locations, prints labels. Uses a tablet on the floor, often with gloves on.
Account manager.
Checks stock levels before promising delivery dates to customers. Desktop, twice a day.
Owner.
Weekly summary of what moved, what is stuck, what is costing money. Phone, Sunday evening.
That level of plain detail changes an estimate. Gloves on a tablet means bigger touch targets. Sunday phone use means a simple summary view matters more than a dense dashboard.
Constraints
Constraints are the walls of the room. They are not complaints. They are facts the software has to live inside.
Regulatory.
Law 25, PCI, sector rules, export documentation. Name the ones that apply.
Technical.
Must run on iPads you already own. Must work offline in areas with no cell signal. Must stay inside Canada.
Organizational.
Only one person knows how the current spreadsheet works and they retire in March. Training has to be simple enough for seasonal staff.
Commercial.
Cannot replace the accounting system this year. Must connect to it.
Non-goals
Non-goals are underrated. They stop scope from swelling in the first meeting. Be explicit about what this project is not trying to solve.
Not a customer portal in v1.
Internal tool first. External access is a later phase.
Not replacing the CRM.
Read contact data from HubSpot. Do not rebuild pipeline management.
Not mobile-native for every role.
Field team gets mobile. Office team stays in the browser.
Shops that read non-goals breathe easier. It signals you have thought about phasing, which is one of the strongest signs a project will go well.
Integrations and data realities
Integrations are where estimates go to die, usually because nobody described them until week three. Put them in the brief upfront, warts and all.
Name every system it must talk to.
QuickBooks, Shopify, a custom Access database from 2008, a supplier’s portal with no API. List them all.
Say which direction data flows.
One-way import, two-way sync, nightly batch, real-time. “Connected to X” is not enough.
Describe the data you have today.
Where it lives, how clean it is, how much history matters. “About 40,000 rows in Excel, inconsistent product codes” is useful. “We have data” is not.
Note access you already have.
API keys, admin logins, vendor contacts. Or say honestly that you will need help getting access.
Call out the scary one.
Every project has a system nobody wants to touch. Name it. The shop would rather know before quoting.
If you are not sure whether an integration is possible, say that too. “We need orders from System X, we do not know if they offer an API” is a fine line in a brief. It tells the shop to budget discovery time instead of pretending the connection is trivial.
Success metrics that are not vanity
“We want it to be user-friendly” is not a success metric. Neither is “modern” or “scalable.” Those words are fine in conversation. They do not help anyone estimate.
Useful metrics tie to behaviour you can observe within a few months of launch.
Time.
“Field inspections logged the same day instead of batched on Fridays.” “Quote turnaround drops from three days to one.”
Errors.
“Billing disputes on wrong quantities drop by half.” “Fewer manual corrections in the warehouse log.”
Adoption.
“All six field techs using it daily within six weeks of launch.” “Managers stop maintaining the shadow spreadsheet.”
Visibility.
“Owner can see stuck orders without calling three people.” “Inventory accuracy within five percent during monthly counts.”
You do not need perfect baselines. Rough is fine. “We think it takes about two hours per batch now” is enough for a shop to understand whether the project is worth the investment.
Metrics also protect you later. When scope creep shows up dressed as a small request, you can ask whether it moves the number you cared about. If it does not, it waits for phase two.
What makes quotes hard to compare
Even with a good brief, proposals arrive in different shapes. A few things to watch when you line them up side by side.
Different assumptions about who provides what.
Design, content, API access, training, hosting. One quote includes them, another treats them as extras.
Different definitions of “launch.”
A demo on a laptop is not launch. Launch is users doing real work on production data.
Different phase boundaries.
If one shop includes the integration and another parks it in phase two, the headline numbers are not comparable until you align the phases.
Different risk buffers.
A low quote sometimes means optimism. A high quote sometimes means someone has seen your messy data and priced honestly. Ask what would push the number up or down.
Send the same brief to every shop. Ask each to answer the same five questions: what is in scope, what is out, what they need from you, what they are unsure about, and what happens after launch. That alone eliminates a lot of theatre.
A template you can copy
Paste this into a doc and fill in the brackets. One to two pages when you are done is the right length.
1. Company and context
[What you do] · [Why this project now] · [Cost of waiting another year]
2. The job (one sentence)
[The work this software should make easier]
3. Users and what each needs to do
[Role] · [Main tasks] · [Device / environment] · [How often]
4. What exists today
[Tools, spreadsheets, manual steps, workarounds people actually use]
5. Integrations and data
[Systems to connect] · [Direction of data flow] · [Data quality and volume] · [Access you have or need]
6. Constraints
[Legal / technical / organizational walls the build must respect]
7. Non-goals (v1)
[What this project is explicitly not solving yet]
8. Success metrics
[Time saved, errors reduced, adoption target, visibility gained. Rough baselines welcome.]
9. Timeline and budget band
[Hard dates if any] · [Rough CAD range you are prepared to discuss]
10. Questions for the shop
[What you are unsure about and want honest counsel on]
Attach screenshots, a sample export, or a photo of the paper form if you have them. Visual context saves a round of questions.
A brief will not get you identical quotes. Projects have unknowns, and good shops price risk differently. What it will get you is proposals that describe the same job, so you can compare craft and honesty instead of comparing guesses.
We build software by hand for SMEs, and the conversations that start with a clear brief tend to be the ones that end well. If you have a draft and want a plain read on what is missing before you send it out, we are glad to look it over. Bring the one-pager. We will start there.
