Software Project Brief: What to Prepare Before Contacting a Software House
November 13, 2026
The short answer: before contacting a software house, prepare six things: the problem you want solved, who will use the system, how work flows today, must-have versus nice-to-have features, systems it must connect to, and your timeline and budget range. A tidy brief produces more accurate quotes, shorter discussions, and far fewer misunderstandings. This guide is for business owners and managers in Solo, Indonesia, who are weighing custom software development and don't need a technical background.
Why the Brief Shapes the Quote
Two vendors can quote wildly different amounts for the same "sales app". The cause is usually assumptions, not hourly rates. One assumes reports can be simple tables; another assumes you want charts and Excel export. Without a brief, those assumptions surface mid-project, when changing them costs the most.
A brief doesn't need dozens of pages. One to three honest pages beat "we want an app like our competitor's".
Six Parts of a Useful Brief
1. The problem, not the features
Start with the pain. "Warehouse stock rarely matches the store's records" is more useful than "we need an inventory module". From the problem, developers can propose something simpler or better suited than the feature list you imagined. Note the impact too: wasted time, stock gaps, late orders. No dramatic numbers needed, just what you actually experience.
2. Who will use it
List the roles: admin, cashier, warehouse staff, owner, customer. For each, note what they need to see and do. This directly affects the number of screens, access rights, and whether you need a mobile app or a web app is enough.
3. How work flows today
Describe the current process, including the "unofficial" parts: spreadsheets, WhatsApp groups, paper notebooks. Attach real samples: photos of receipts, screenshots of Excel files, the report formats you use. Real samples reveal exceptions that are easy to forget, like special discounts for regular customers or partial returns.
4. Must-haves and nice-to-haves
Split features into three groups: needed in the first release, should have, and can come later. This split is what makes phased development possible. On a tight budget you can start with a small first version and expand, as covered in our article on MVPs.
5. Systems it must connect to
Note what you already use: accounting software, POS machines, marketplaces, payment gateways, WhatsApp, or legacy data that must be migrated. Integrations and data migration are often the hardest items to estimate, so the earlier they are mentioned, the more honest the quote.
6. Timing, budget, and decisions
State when the system should ideally go live and what drives that date (peak season, a new branch). On budget, sharing a range beats hiding it, because the vendor can shape the scope to fit. Also name who approves deliverables on your side. Projects where decisions wait on many people tend to slip.
A Short Sample Brief
| Section | Example entry |
|---|---|
| Problem | Stock across 2 warehouses is tracked in separate Excel files and often mismatches at stock-taking |
| Users | Warehouse admin (data entry), owner (reports), sales (check availability) |
| Current flow | Incoming goods logged by hand, then compiled weekly by the admin |
| Must-have | Log goods in/out, stock per warehouse, discrepancy report |
| Nice-to-have | Low-stock alerts, barcode scanning |
| Integrations | Export to the accounting software already in use |
| Timing | Ready before peak season; one named decision-maker |
This only illustrates the format. Fill it in for your own business.
Common Mistakes
- Writing a solution with no problem. "Build us something like X" rules out better-fitting options.
- Hiding exceptions. Special cases left unmentioned appear during testing and add work.
- Everything is a must-have. If everything is priority one, nothing can wait and scope balloons.
- Forgetting frontline users. A system the owner approves but staff find awkward gets abandoned.
- Not preparing data. Messy legacy data needs cleaning, which takes time from both sides.
- No single owner. Revisions without one decision-maker wreck schedules.
If You Don't Have All the Answers
That's normal. Many businesses know their problem clearly but not the solution. In that case, the discovery or analysis phase at the start of a project exists to sort out requirements together. A half-finished brief is still much better than none, because the conversation can go straight to what matters. For cost context, see our article on factors affecting software development cost, and for choosing a partner, our guide to choosing a software house.
Talking with Evetech
Evetech Solution is a software house based in Solo (Solo Baru, Kota Surakarta). We build custom web and mobile applications, corporate websites, and AI assistants for company websites, following a process of discovery and analysis, UI/UX design, development, testing with regular feedback, release, and refinement. If you only have rough notes, bring them to a free consultation via the contact page at evetechsolution.com or WhatsApp. We'll help shape them, and if custom software isn't needed yet for your situation, we'll say so plainly.
FAQ — Software Project Brief
Do I need a written requirements document before a consultation? No. Short notes on the problem, the users, and samples of the documents you use today are enough to start. The rest can be refined together during analysis.
Should I tell a software house my budget? Ideally share a realistic range. The vendor can then propose a scope that fits instead of a quote far from your reality. Actual cost still depends on scope and complexity.
How long does it take to prepare a brief? For small to mid-sized businesses, usually a few days, mostly spent collecting sample documents and asking the staff who will use the system. There is no fixed figure because it depends on process complexity.
What if requirements change mid-project? That's common. What matters is agreeing how to handle it: small changes are discussed in regular check-ins, while larger additions are estimated separately. Phased development reduces the risk.