Why the brief matters
A vague brief gets a vague quote, and a vague quote is where budget blowouts start. The developer guesses, prices the guess, and the gap between what you meant and what they built turns up as change requests halfway through. A page or two of clear thinking before you talk to anyone saves you both money.
It does not need to be polished. Bullet points, a few sketches and honest answers are worth more than a twenty-page document. Here is what Applicable asks for.
1. Your business in a paragraph
What you do, who you do it for and what makes you different. If you are starting something new, describe the market you are entering. A developer who understands the business makes better decisions about the hundred small things a brief never covers.
2. What the site or app must achieve
Not features. Outcomes. "More enquiries from commercial customers." "Stop staff re-keying job sheets." "Let members renew online without phoning us." Write down the problem you are solving and how you will know it has worked. This becomes the yardstick every decision in the project is measured against.
3. Who will use it
List each type of user and what they need to get done. A simple format works: "A site foreman needs to submit a safety check from a phone with one hand." "A customer needs to find their last invoice without calling us." These user stories shape the design more than any other input, and they are the first thing Applicable turns into wireframes.
Look at how competitors and similar businesses handle the same thing, and note what you like and what annoys you.
4. How users move through it
Sketch the journey. What does a new customer see first, and what do you want them to do next? What screens does a staff member go through to complete a job? Hand drawings, a photo of a whiteboard or a numbered list are all fine. If you cannot picture it yet, say so; Applicable can produce wireframes and a clickable prototype in the scoping stage.
5. Which features matter most
List what you want, then rank it. Mark the features the first version cannot launch without, the ones that would be good soon after and the ones that are nice to have. A ranked list lets the developer price a first release you can afford and a roadmap for the rest, instead of pricing everything and scaring you off.
6. The things people leave out
The five items above come from a brief guide Applicable wrote some years ago. Since then, the things that most often derail a project are the ones nobody thought to include.
- Budget bracket. You do not have to give a number, but a bracket saves everyone time. Applicable will tell you early whether it fits.
- Deadline and why. A trade show, a season, a contract start. A real date changes how the work is staged.
- Systems it must connect to. Your accounting package, CRM, booking tool, payment provider or industry database. Every integration is scoped and priced, so name them all.
- Content. Who is writing the words and taking the photos? Content is the most common cause of a late launch.
- What exists now. Your current site, its address and what you like and dislike about it. Any data that needs to come across.
- Ownership and hosting. State that you expect to own the code, the content and the hosting accounts. Applicable works this way by default; not every vendor does.
- Who decides. Name one person who can sign off. Projects with a committee and no decider run long.
What happens next
Send the brief and Applicable will book a scoping call. On that call we listen, ask questions and give you a ballpark bracket: websites run NZ$4,000 to NZ$50,000+ plus GST and custom web applications up to around NZ$250,000, depending on scope. If it fits, scoping follows, and it ends in a written scope, a fixed price and a timeline. Changes after that are quoted in writing before they are built.
Libby May, a marketing consultant who has worked with the team, said: "Working with John and the team at Applicable is a real pleasure. He listens to what you want." A good brief is how you make sure there is something clear to listen to.
Key takeaways
- A brief for a web developer should cover your business, the outcome you want, who will use it, how they move through it and which features matter most.
- Add a budget bracket, a deadline, every system it must connect to, who is writing the content and who signs off.
- A ranked feature list lets a developer price a first release you can afford and a roadmap for the rest.
- Applicable gives a ballpark on the first call and a fixed-scope quote after scoping, with changes quoted in writing.