Blog
How to brief a software studio for operational systems
A useful brief names the people, the tasks, and the systems already in place. Feature lists without that picture lead to software nobody can own.
The best brief for operational software is not a list of screens. It is a picture of the work: who does it, what they need to finish, and which tools they already live in.
A studio can design from that. It cannot design from a pile of references that only say what the product should look like.
What to put in the first note
You do not need a specification. You need enough for a shared map.
- The people who will use the system, in their own words if you have them
- The tasks that fail today, with one or two examples
- The systems already in place, including sheets and the informal ones
- What must be true after launch for the team to run it without the studio in the room
What can wait
Colour, animation, and a complete module list can wait until the tasks are clear. So can the question of whether the answer is an ERP, an LMS, a CRM, an API, or a smaller custom tool.
If you are not sure what to build, consultation is the brief. Asking for a full build before the work is named usually produces software that is hard to hand over.