--- title: "What to Prepare Before Hiring Someone to Build Your Website or Software (With a Brief Template)" url: https://phatdev.net/en/blog/brief-before-hiring-developer lang: en updated: 2026-10-21 alternate: vi: https://phatdev.net/vi/blog/brief-before-hiring-developer markdown: https://phatdev.net/en/blog/brief-before-hiring-developer.md --- # What to Prepare Before Hiring Someone to Build Your Website or Software (With a Brief Template) > Most troubled projects start with fuzzy requirements. Six things to think through before you talk to a developer, plus a short brief template to copy and fill in. Categories: Frontend | Published: 2026-10-21 | Level: Beginner | 5 min read Tags: brief, freelance, requirements, planning, website Imagine a shop owner writing to a web developer: "I need a website to sell things. How much and how long?" The developer asks a few questions and the owner has not thought about any of them. The two sides trade quotes for three weeks, and halfway through the build the owner says, "oh, I also need appointment booking." Price and timeline both blow up. Nearly every troubled project I have seen shares one root: the requirements were fuzzy from the start. Writing a short description (called a brief) before you hire anyone for a website or software saves money and time on both sides. This post covers what to think about, and gives you a template to copy. ## What a brief is, and why you need one ![A project blueprint: goal, users, two feature columns, calendar and budget](https://phatdev.net/uploads/blog/brief-before-hiring-developer/map-1920.webp) A brief is like the rough sketch before building a house. You do not need to know the brick type, but you should be able to say how many rooms, how many people will live there, and what the budget is. Without that, every builder guesses, each guesses differently, and the quotes end up far apart. A brief does not need to be long. One page is enough. What matters is that you have thought through the questions below before you talk to a developer. ## Six things to think about first ### Goal What is this website or software for, in terms of your actual work? A good answer is something measurable: "take orders online", "let customers book instead of calling", "stop retyping data into Excel". "A beautiful, professional site" is not enough to build from. ### Users Who will use it, on a phone or a computer, and how comfortable are they with technology? A website for retail customers is very different from an internal tool for warehouse staff. If you can, describe one real situation: "a 45-year-old customer who usually orders in the evening on her phone". ### Must-haves and later This is the part people skip most, and the one that saves the most. Make two columns: without it the product is unusable (must-have), and nice to have but fine to add later. The first version should contain only the first column. The second column waits until you have seen real users. ### Examples you like Send two or three sites or apps you like, each with one sentence about what you like ("their product filter", "the homepage has little text"). Include one you dislike and say why. A few links tell a developer your taste far faster than pages of description. ### Budget and timing Be honest about the range you have, and about any deadline (for example, it must be live before the holiday season). Many people avoid naming a budget because they fear the quote will land right at it. In practice, knowing the budget lets the developer propose a scope that fits, instead of a plan you cannot afford. Also count the monthly costs after launch, such as domain, hosting and maintenance. ### Who approves Who makes the final call, and if several people have opinions, who merges them into one? Projects are often slow not because the code is hard but because five people pull in five directions. Pick one approver and agree on the checkpoints in advance. ## A short brief template to copy Paste this into a note, fill it in, and send it to the developer. Where you do not know, write "not sure"; that is useful information too. ``` 1. About: business name, what you sell, to whom. 2. Goal: once it is done, what will be different? (one to three measurable points) 3. Users: who, on what device, one concrete example person. 4. Must-have in version one: ... 5. Later: ... 6. Examples: link 1 (what I like), link 2 (what I like), link 3 (what I dislike). 7. Existing material: product list, logo, photos, Excel files, old site... 8. Budget range: ... ; acceptable monthly running cost: ... 9. Deadline: ... ; why it matters (if it does): ... 10. Final approver: ... ; checkpoints that need approval: ... 11. Contact: name, phone/chat handle, best time to call. ``` ## Common mistakes Some people send a very detailed brief about colors and fonts but never say what the site is for. The developer delivers something good looking that does not answer "how do customers actually buy?". Some list twenty features and mark all of them "required". When everything is required, nothing is prioritized, and the quote tends to shock. Force yourself to cut until only the truly needed items remain. Some have not prepared content: product photos, articles, a logo. A finished frame with no content cannot launch. Ask early who provides the content and when. Finally, ownership. Ask whose name the source code, the domain and the hosting account are under, and what you receive when the project ends. It is a reasonable question and nobody should be offended by it. ## For those on the developer side If you are a developer receiving a brief, the early investigation before quoting has a name: the discovery phase. The UK government digital service describes it clearly: understand the users, understand the problem, then pick a solution ([How the discovery phase works](https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works)). A one hour conversation built on the template above usually gets you a much tighter quote. ## What to do next Spend half an hour filling in the template, even if you are not sure you will hire anyone. Just writing it down shows you where you have not thought things through. If you are torn between a ready-made platform and custom work, [WordPress or Custom Code: Which Should You Pick for Your Website?](https://phatdev.net/en/blog/wordpress-or-custom-code) can help you choose. Once you have a brief, you can send it to me through the project request form on phatdev.net. It does not have to be complete; I will ask for the rest step by step. ## References - [GOV.UK Service Manual - How the discovery phase works](https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works) ## Related posts - [WordPress or Custom Code: Which Should You Pick for Your Website?](https://phatdev.net/en/blog/wordpress-or-custom-code.md) - [Monthly Website Maintenance: What It Includes and Why Neglect Costs More](https://phatdev.net/en/blog/website-maintenance-monthly.md) - [Next.js 14 App Router: Where It Bites in Production (Server Actions, Cache, Deploys)](https://phatdev.net/en/blog/nextjs-app-router-server-actions.md)