You do not need a technical specification
It does not pay to wait with a first message until you have “everything written down”. That can mean months of delay and a document full of database tables we would go through again anyway. There is no need. You can describe how the work gets done today and where it gets stuck better than anyone. Turning that into screens, roles and rules is our job.
So a good brief is not a feature list. It is a description of how the business runs: who does what, where information gets lost and what should change. From that we can propose a scope and estimate a price. From a list like “login, dashboard, export” we cannot, because the same words mean something different in every company.
What helps most in a first message
How you do it today
Describe one job, order or request from start to finish. Where it comes from, who picks it up, where it gets recorded, when it is invoiced and when it is done. Plain words, bullet points are fine. This is usually where it shows where time is being lost.
Who works with it
List the people and their roles: who creates records, who approves, who only needs an overview, and whether a customer or supplier should see into the system too. The number of roles is one of the things that affects scope the most, because each role means its own view, its own permissions and more situations to test.
What gets retyped by hand
Where the same detail is typed twice. From an email into a spreadsheet, from the spreadsheet into invoicing, from an order into stock. If you roughly know how many hours a month it takes, say so. It helps decide what to build first.
Sample documents and spreadsheets
The spreadsheet you track jobs in today, a sample invoice, a handover form, a form your customers fill in. Personal data blacked out or made up is fine. One real spreadsheet tells us more than a paragraph of description: what you record, in what format and how much of it there is.
What the first version must do and what can wait
Split your wishes into two piles. The first holds what the tool makes no sense without. The second holds what would be nice to have. It does not have to be final, but without this split a first version easily grows into the whole system and the benefit arrives later.
Connections to what you already use
Just name the systems: invoicing, accounting, stock, e-shop, calendar, CRM. You do not need to know whether they have an API. If a system has an interface or an export, a connection is usually possible. With older systems we check up front and tell you what works and what does not.
Budget and deadline
Even a rough frame helps. If we know you have set aside roughly this much and need it before the season, we will propose a first version that fits, instead of pricing up the ideal state. If the deadline is fixed because of something outside the project, such as the start of a school year or a new branch, tell us why.
Who decides
One person who approves the design and has the final say. Comments from five people without a shared position make every round more expensive. We do want people from operations involved in the design, since they will work in the application. But a decision needs one name.
Checklist before your first message
You do not have to fill in everything. What you do not know, we will ask about. But every point you answer shortens the way to an estimate.
- In one or two sentences: what is not working today and what result you need.
- How one job or order moves through the company from start to finish.
- A list of roles: who creates, who approves, who only reads, whether customers get access.
- Where details are retyped by hand and roughly how much time it costs.
- A sample spreadsheet, document or form you work with today.
- What the first version must do and what can wait.
- Systems the application should connect to: invoicing, stock, e-shop, calendar.
- A budget frame and a deadline, and why the deadline is fixed if it is.
- Who decides on your side and approves the design.
A good brief does not describe an application. It describes the day of the person who retypes spreadsheets today.
How a description turns into a list of screens and roles
We prepare questions from your message and in the first call we go through your operations with you step by step, looking for the places where time gets lost. The output of this first phase is a list of screens and roles: who logs into the application, what they see on each screen and what they can do there.
Only then comes interface design. We design the screens first and write code afterwards, because a change in the design is an order of magnitude cheaper than a change in a finished application. Development then runs in functional parts, and after each stage you get an agreed output to comment on or try out.
That is how our own internal WCRM started. We tracked leads in a spreadsheet and after a few hundred records it stopped being enough. Nobody could see who had called whom and what should happen next. Not a feature list but that sentence was the brief.
What you do not need to write
- Technology. We do not start with it. First we look at what a person in your operations needs to get done, and only then choose the tools.
- Screen designs. A sketch on paper helps if you have one. You do not need to make one for us.
- A data model. Just show us what information you work with. We design the structure.
- A complete list of exceptions. They come up while we walk through your operations and in the first weeks of use.
What next
If you want to know first what amounts we are talking about, the calculator works out an indicative range. A first version of an application with one role and one main workflow starts there at 53,000 CZK excluding VAT. What drives the rest is covered in How much does a custom application cost?
More on how the collaboration runs is on the Custom applications page. And when you have at least a few points from the checklist, write to us. We will get back to you within two working days and suggest the next step.
