How to brief a custom application without writing a technical specification.

A development brief does not need to begin with a database diagram. It needs to explain a job that someone should be able to complete and the result your business needs from it.

The aim of the first brief is to make the project discussable. You can leave technical choices open while being precise about the work the application must support.

Begin with a user and a task

“Build a portal” names a type of software. “Let an approved customer submit a service request and see its progress” describes a useful first workflow.

Name the user, the action and the outcome. Then identify who handles the other side of the process. In this example, a staff member needs to review the request and update its status. That means the brief already contains two different roles and a shared record.

Avoid starting with “an app for everyone”. Different users may need different permissions, screens and information. Decide which role matters most in the first release.

Explain what happens today

Describe the current steps in ordinary language. Perhaps a customer emails information, a staff member copies it into a spreadsheet and another person sends a progress update. State where confusion or repeated effort occurs, without assuming the software will solve every surrounding problem.

A redacted example of the current form or record can be more useful than a polished presentation. Remove personal information and confidential details before sharing it.

Describe one complete journey

Follow a representative record from beginning to end. What starts it? Which information is required? Who makes the next decision? What marks it as complete?

Include one or two important exceptions. A request may be incomplete, a reviewer may reject it or a user may need to correct a mistake. Those cases help distinguish a working application from a demonstration of the ideal path.

You do not need to invent every rare event at this stage. Concentrate on the exceptions that would stop the main workflow from being useful.

Name the data and dependencies

List the important records: users, requests, products, bookings, files or another set of information. Explain where they come from and who is responsible for maintaining them.

For an integration, name the other service and provide its documentation when available. “Connect to our CRM” leaves major questions open. The useful detail is which record should move, in which direction and after which event.

Identify whether designs, product content, account access or business rules are already available. Missing materials are not automatically blockers, but they need an owner and a place in the plan.

Define the first useful version

Separate the core delivery from later ideas. A first portal might support creating a request, reviewing it and showing the status. Messaging, advanced reporting and a mobile app could be later discussions rather than unspoken requirements of the first build.

This is not an instruction to build something incomplete. The chosen workflow should work from beginning to end. The boundary is between complete workflows, not between an attractive screen and the logic it still needs.

Write an acceptance example

Try a sentence someone could test:

An approved customer can submit a request, see its status after signing in and view only their own requests. An authorised staff member can update the status, and the customer sees that change.

This is an illustrative requirement, not a description of an existing client project. It makes the expected behaviour much clearer than “a modern, secure portal”. The eventual scope can refine the permissions and edge cases.

Add practical constraints

State your desired timing, whether it is a preference or a fixed external date, and the budget range where known. Name the person who can approve decisions and explain how designs or feedback will be supplied.

Describe release and handover expectations too. Who will own the hosting and accounts? Does another developer need to receive the code? These questions affect the delivery even when they do not appear on a screen.

A brief you can use

We want to build: the application or workflow. The main users are: the people and roles. They need to: the main task and completed result. Today this happens through: the current process. The first version must include: the essential complete workflow. It needs to connect to: the known systems and documentation. We already have: designs, content, accounts or example data. Still undecided: questions to resolve. Timing, budget and decision-maker: the practical constraints.

Use a few clear sentences for each part. The brief is a starting point for defining the project, not a test you need to pass before speaking with a developer.

Discuss a custom web application or send your brief.