How to Prepare a Custom Software Project Brief
On this page
You do not need a finished technical specification to start discussing custom business software. A clear description of the work and the current difficulties is more useful than a long list of desired screens.
Turn your idea into a usable project brief
Capture one workflow, the systems it touches and the boundary of a useful first release. Leave unknowns open; you do not need a technical specification to start.
- Business outcome and workflow exceptions
- Existing systems, data and reporting needs
- First-release scope, budget and decision owners
Editable text file (.txt)
Fill it in locally using a text editor or your own document. Share a non-confidential summary when you contact us.
A completed first-release brief
This brief for a fictional distributor shows what to record before a technical assessment: one workflow, its exceptions, acceptance checks and open questions. Download the completed version beside the blank template above.
Outcome and owner: give one operations team a shared view of accepted orders and stock exceptions. The client operations owner approves workflow rules and scope. The technical contact supplies documentation and test access without putting credentials in the brief.
Current tools and one integration: retain the CRM and ERP. The proposed connection sends an accepted CRM order to ERP and returns fulfilment status. CRM owns the customer assignment; ERP owns stock and reservations. Whether the APIs support all required changes is still unknown.
First workflow: a coordinator accepts an order, operations confirms availability and the ERP records the reservation. Sales sees the fulfilment status against the same order reference. The first release is limited to one team and warehouse.
Two exceptions: if stock is insufficient, a named operations approver chooses a split or delay. If an acknowledgement is lost after the ERP saves the order, a retry must not create another order. Both exceptions remain visible with a responsible person.
Three acceptance checks:
- With ten available units, a request for four leaves six available. A subsequent request for seven follows the shortage rule while the first reservation is active.
- Deliver the same accepted order twice, including a lost-response retry. Expect one ERP order and an inspectable exchange status.
- A restricted user cannot open or export another team's protected order. An authorised reviewer can reconcile the open-order report with the agreed source snapshot.
Data and reporting: transfer open orders and the customer/product references they need. Historical attachments are deferred. Define an open-order exception report with a named owner, a UTC cutoff and visibility of a delayed source; refresh frequency remains to be agreed.
Exclusions: ledger replacement, manufacturing, additional warehouses, a customer portal and AI actions are outside this release. Testing, permissions and recovery for the included workflow remain in scope.
Budget, timing and operation: budget and target date remain open until the APIs and source sample have been reviewed. The estimate must cover hosting responsibilities, paid support and the transition to the new workflow.
Next decision: use a bounded assessment to verify the connector and field mappings, confirm the first-release boundary and identify unresolved dependencies. The integration example explains the retry behaviour; the ERP pilot sheet turns the proposed checks into a reviewable launch decision.
Describe one process from start to finish
Choose a representative scenario: receiving an order, onboarding a client, approving a document, or preparing an operational report. Record what triggers it, who acts, which tools are involved, and how you know it is complete.
Include an exception. What happens when data is missing, an order changes, an approval is declined, or an external system is unavailable? These cases reveal requirements that a happy-path demonstration can miss.
Bring a map of your current tools
List systems, spreadsheets, document stores, reporting tools, and important external services. Name the person who understands each one. Note available documentation, test environments, exports, and interface access where known.
Separate the tools you expect to retain from those you want to replace. If that decision is open, say so: assessing the options can be part of the next step.
Explain the data you need
Describe customer records, products, orders, documents, transactions, and required history. Identify which records should move and which systems must continue exchanging changes.
Use anonymised or synthetic examples when sharing initial materials. Avoid sending credentials or unnecessary personal information. We can discuss an appropriate way to handle confidential material before it is shared.
Name the decisions behind your reports
Instead of asking only for a dashboard, explain the decision it supports. Who uses it, what measures matter, how are they calculated, and how recent must the data be? Bring an example of an existing report if one is available.
Set first-release priorities
State what needs to work for a first release to be useful and what can follow later. Share timing constraints and their reasons, the budget context, and who will review the work and make scope decisions.
At Horizon Dynamics, full project budgets start at USD 50,000. We use hourly teams or fixed-price modules depending on the scope. The Pricing & Process page explains what these models mean without assuming a single payment schedule for every project.
Know what a paid assessment should produce
A separately agreed assessment needs a decision to support, defined inputs, a fee or capped hours, a schedule, deliverables and acceptance criteria. It can produce a workflow map, first-release boundary, risks, interface questions and cost assumptions. Agree ownership and reuse rights before starting. Read the sample decision brief and acceptance checks; a first conversation alone does not deliver a finished architecture.
Leave with an agreed next step
The first conversation should make the problem, priorities, and main unknowns clearer. The next step might involve examining data, mapping a workflow, reviewing an interface, or defining a module in enough detail to estimate it.
Build a sample configuration in Solution Studio if trying modules helps explain your idea, or send your project context directly.
