You do not need a list of technologies, finished screen designs or a lengthy specification for your first conversation with us. Start with the situation you already understand: what makes work difficult in your business today, who takes part in the process, where the information is kept and what should change after the new system is introduced.
This first description does not have to settle every detail. It should help you organise the need and help us ask the right questions, identify uncertainties and propose a sensible next step.
Begin with the problem, not the name of a system
Statements such as “we need a CRM” or “we want an order management app” say little about the work that actually takes place. The same label might mean a simple register, an integration between several tools or a larger system with different roles and exceptions.
Begin with a specific difficulty:
Customer enquiries arrive by email. Sales staff copy the details into a spreadsheet and call the warehouse to check stock. It is difficult to see who is preparing the reply or whether they are using the current price.
You do not need to suggest the solution at this stage. Describe the situation in your own words. This allows us to understand the source of the problem before trying to fit your business to an arbitrary product label.
Show us how the process works today
Describe an ordinary working day. Begin with the event that starts the process and end with the result received by an employee or customer.
The following questions are useful:
- Where does the enquiry, order or other information come from?
- Who takes the first step, and who receives the work next?
- Which spreadsheets, messages or applications do people use?
- Where is information copied or checked again?
- What marks the end of the process?
- What happens in an unusual case?
Exceptions matter. A standard order may move smoothly while the process stops when an item is unavailable, a price changes or customer details are incomplete. If you describe only the simplest route, the first version of the software may miss the work that consumes the most time.
Describe an outcome that can be checked
Instead of designing buttons, explain what the user should be able to do after the change.
For the example above, a useful outcome might include:
- keeping every enquiry in one place;
- seeing who is responsible for it;
- using one current source of prices;
- preparing a quotation draft without copying the same information again;
- identifying cases that are waiting for a decision.
“The system should be easy to use” is not yet an acceptance criterion. A more useful statement is: “a salesperson can see the status of an enquiry and does not have to re-enter information supplied by the customer”.
The outcome does not have to be expressed as a number. It should, however, describe a change that a user can notice and verify during their work.
Name the users and access boundaries
We do not need a list of employees. Roles, approximate user numbers and the most important differences in access are enough.
For example:
- a salesperson creates and updates their own quotations;
- a manager can see the work of the whole team;
- warehouse staff confirm availability but do not change commercial terms;
- an administrator manages accounts and settings.
Tell us whether people work on desktop computers, phones, tablets or warehouse terminals. This affects how the system should be operated, but it still does not require you to design the interface.
Tell us where the data and existing tools are
Explain where the required information is kept today. It may be in a spreadsheet, an inbox, a paper document, accounting software, an online store or an existing application.
If the new system needs to exchange data with another solution, include:
- the name or purpose of the existing system;
- the type of information required;
- the expected direction of the data flow;
- whether API documentation or a contact for the software producer or administrator is available.
“We do not know whether the system has an API” is a useful answer. It identifies something that must be checked before the integration scope can be confirmed.
Do not paste passwords, tokens, API keys, database copies or real customer or employee data into the brief. It is enough to name the type of information, such as contact details, financial documents or data that requires restricted access.
Separate the first stage from later ideas
A list on which everything is essential does not help anyone make a decision. Divide the requirements into two groups:
- the scope required for one important process to work from beginning to end;
- functions that can be added after the first stage has been tested.
In the example, the first stage might cover the enquiry register, statuses, roles and quotation drafts. A customer portal, payments and extensive reporting can wait if they are not needed to achieve the first useful outcome.
Keep simpler options open as well. If a structured form, a shared template or better use of an existing tool solves the problem, custom software does not have to be the first choice.
Record constraints and open questions
A useful brief does not pretend that every decision has already been made. It should also state what remains unknown.
Include:
- an important business date and the reason behind it;
- an indicative budget, if one has been set;
- the person responsible for the decision;
- the role of the person who understands the day-to-day process best;
- questions that you or your team cannot yet answer.
A date is not a delivery promise. It does tell us whether the project is linked to a sales season, the end of a contract, a regulatory change or another event that must be considered during planning.
Example: from a broad idea to a useful brief
The following example is fictional. It shows what a description sent to us might look like; it is not the confirmed scope of a real implementation.
Broad idea:
We need a system for preparing quotations.
Problem and context:
Enquiries arrive in a shared inbox. Sales staff copy details into their own spreadsheets, so more than one person may begin working on the same case. Prices and stock are checked in a separate application.
Current workflow:
A salesperson reads the message, records the customer details in a spreadsheet, contacts the warehouse, selects prices from another file and prepares a quotation in a document. Products requiring an individually confirmed price are an exception.
Expected outcome:
Every enquiry has one record and one owner. The salesperson can see its status, use the current source of data and prepare a quotation draft without re-entering information.
Users and roles:
Sales staff manage their own enquiries, the manager can see the whole team and warehouse staff confirm product availability.
Data and integrations:
Enquiry data is held in email and spreadsheets. Product data is stored in the stock system. The availability of its API must be confirmed with the software producer or administrator.
First stage:
An enquiry register, assignment of responsibility, statuses, roles and quotation drafts.
Later:
A customer portal, extensive reporting and payment handling.
Constraints and questions:
The business would like the solution ready before the next sales season, but feasibility by that date requires assessment. The method of retrieving prices and the handling of non-standard quotations remain open.
This is still not a technical specification. It is enough for us to discuss the real workflow with you, identify risks and agree what needs to be checked before an estimate can be prepared.
What you do not need to decide on your own
Before the first conversation, you do not need to choose:
- the programming language or architecture;
- the server, database or framework;
- the exact design of every screen;
- the technical method for each integration;
- the final price and delivery date;
- the full scope of every later stage.
If you want us to develop an existing application, its code, dependencies and deployment process may need a separate review. If a paid analysis is required to define a reliable scope, we agree it separately before it begins.
This article helps you prepare the first description. If your scope is already clear and you are moving on to people, data and acceptance arrangements, read How to prepare a company for a new system or web application.
What we do with your description
At Domin Software, we first check the relationship between the problem, current workflow and expected outcome. We ask about exceptions, data, user roles and dependencies on existing tools.
We can then indicate whether the next step should be a small, more precise scope, a review of an existing application, an integration check or a division of a larger project into stages. The brief alone does not determine the technology, price or delivery date.
Our software development services cover application development, integrations and new business software.
Build your description with the project brief builder
You do not have to begin with a blank document. The project brief builder guides you through five steps and organises your answers into seven sections.
Every field is optional. The result is created locally in your browser, with no account, AI model or automatic submission. You can copy it, download it as Markdown or print it to PDF.
If you decide to start a conversation with us, a separate button transfers the brief into an editable contact form. Nothing is sent until you submit the form yourself.
Primary CTA: Build your project brief
If you already have your own description, you can also contact us directly.