A Clear Brief for a Business Website or Web Application

Say which product you are buying

Start with the type of product, in one sentence. A public website helps someone understand an offer and take a next step. A web application helps an authorised person complete work on a shared record. A shop sells and tracks an order. Many businesses need more than one of these over time. The brief should say which one is first.

If you are unsure, describe the hour of day and the person. A prospective client reading on a phone at night is a website problem. A coordinator assigning jobs at 8:00 AM is an application problem. A driver updating a job from a site is often a mobile problem, and it should be named as such rather than hidden inside a responsive page. Custom web development can cover the first two. Do not force the third into the same brief unless you are ready to fund it.

One sentence that prevents the wrong quote

Write: “This first release is for [who], so they can [do what], without [the workaround they use today].” If you cannot fill the brackets, you are not late. You are early, and the right first purchase may be a discovery workshop rather than a build. Say that in the brief. A competent firm would rather narrow the work than invent users you did not mention.

The six points worth writing down

You can answer these in a page. Completeness matters more than polish. Bullet points are better than a long narrative that never reaches the constraint.

• The user, and what they are trying to finish
• The evidence of the problem: a site, a spreadsheet, a queue, or a report you do not trust
• The systems that must stay, including payments, finance, or industry tools
• What is out of scope for the first release, written on purpose
• The date that matters, and the consequence of missing it
• Who can approve a change, and how quickly they can do it

Add examples where you have them. A competitor you respect is useful if you say what you respect. The navigation, the tone, and the speed are different compliments. “Make it like them” is not a brief. “Their service pages explain one offer each” is a brief.

Budget as a range, not a test

A range tells the firm how to shape version one. Hiding the range to see what comes back usually produces a proposal aimed at a different project than the one you can fund. If you have a ceiling, share it. If you do not, say so, and ask for two sizes: a smaller release you could use, and the release you described in full. Those two figures teach you more than one blended number.

Ask the quote to repeat your exclusions. A price that restates what it will not do is easier to compare than a price that only lists features. Two firms can both be honest and still differ. They cannot be compared if one has included content, migration, and training and the other has assumed you will handle all three.

Separate the public site from the system behind it

Companies often write one brief because the brand feels like one thing. The work is still two shapes. The public site needs a clear offer, fast pages, and a path to enquire or buy. The system behind it needs roles, records, and a way to handle the exception. Put them in two sections even if you hope to buy them together.

For the site, list the offers that deserve their own page and the proof you can publish. For the application, list the record and the states it moves through. If you only know the site, do not invent application features to look thorough. A padded brief is how custom software development gets scoped around work nobody will use.

Search belongs in the site section. Name the services and cities you want to be found for, in language a customer would use. A business that serves Melbourne and also works nationally should say both. A page can rank for a real offer. It will not rank for a phrase that was added after the page was written around a different idea.

How the brief should travel

Send the brief before the call if you can. The meeting is then spent on judgement, not on collecting facts you already know. Invite the person who will approve the work. A briefing given by someone who must check every answer later will be repeated, and the quote will slip.

Ask for the reply in the same structure: what they understood, what they would build first, what they would challenge, and what they need from you. A partner who only sends a price has not used the brief. A partner who rewrites your goal without saying so has started a different project. The portfolio can show that they have shipped a similar shape. The reply to your note shows whether they understood this one.

Keep the brief alive after you start. When a new request appears, add it to the note and mark it as later or as a change. Teams that work across time zones, including a Melbourne owner and an Islamabad studio, rely on that written record more than on memory of a call. TechnAre treats the brief as the thing both sides edit, not as a form that is filed and forgotten.

A one-page brief is enough to begin

Write the product type, the user, the task, the systems you will keep, and the items that are later. Add a date and a budget range if you have them. That is enough for a serious conversation about a website or a web application.

You can send that page through the contact page, or use it to frame a look at the relevant services. TechnAre will tell you if the brief is ready to estimate, and what single fact would make the estimate sharper.