[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"site-version":3,"blog-doc-en-brief-per-sviluppatore":4},"2.2.0",{"id":5,"title":6,"body":7,"category":312,"credit":313,"date":316,"description":317,"extension":318,"faq":319,"image":332,"imageAlt":333,"keyword":334,"meta":335,"navigation":336,"path":337,"related":338,"seo":340,"seoTitle":341,"service":342,"slug":343,"stem":344,"tags":345,"__hash__":351},"blog\u002Fen\u002Ftips\u002F2026-10-15-brief-per-sviluppatore.md","How to write a brief for a developer: requirements, constraints and acceptance criteria",{"type":8,"value":9,"toc":289},"minimark",[10,14,19,22,26,31,34,38,41,45,48,52,55,74,78,81,85,94,98,101,105,108,112,115,119,178,182,185,189,239,246,250,253,256,260,263,266,269,273,276],[11,12,13],"p",{},"Two developers given the same vague brief will produce two incomparable quotes, because each filled the gaps with their own assumptions. A brief exists to reduce assumptions: not to describe the solution, but to define the problem, the constraints and how everyone will know the work is done. I write this from the point of view of someone who receives briefs every week, mostly from agencies.",[15,16,18],"h2",{"id":17},"problem-not-solution","Problem, not solution",[11,20,21],{},"The most frequent mistake is a brief describing the implementation: \"we need a plugin that does X\", \"we want an app\". It is better to start from a measurable goal and the context: who uses the system, what problem they have today, what should happen afterwards. The technical solution is the developer's job, and a brief that imposes one often imposes the wrong one.",[15,23,25],{"id":24},"the-sections-you-need","The sections you need",[27,28,30],"h3",{"id":29},"context-and-goal","Context and goal",[11,32,33],{},"Who the end client is (if an agency is writing), what they do, why the project starts now. A verifiable goal: \"reduce phone calls about opening hours\", not \"improve communication\".",[27,35,37],{"id":36},"users-and-roles","Users and roles",[11,39,40],{},"Who will use the system and with what permissions: visitors, registered customers, editors, administrators. Every extra role is extra complexity, and it is good to know upfront.",[27,42,44],{"id":43},"functional-requirements-prioritised","Functional requirements, prioritised",[11,46,47],{},"A list of features split into essential, important and nice-to-have. This split makes it possible to estimate a minimum scope and to think in phases rather than all or nothing.",[27,49,51],{"id":50},"non-functional-requirements","Non-functional requirements",[11,53,54],{},"These are almost always missing and they cause the arguments at the end of a project:",[56,57,58,62,65,68,71],"ul",{},[59,60,61],"li",{},"performance targets (for example \"good\" Core Web Vitals on the main templates);",[59,63,64],{},"accessibility level (WCAG 2.1 AA or 2.2 AA);",[59,66,67],{},"languages and translation workflow;",[59,69,70],{},"supported browsers and devices;",[59,72,73],{},"security and privacy requirements, including the personal data processed.",[27,75,77],{"id":76},"existing-systems-and-integrations","Existing systems and integrations",[11,79,80],{},"What already exists: site, hosting, domain, management system, CRM, payment platform. For each integration: is there a documented API? Who provides access? Is there a test environment? An undocumented integration is the number one cause of overruns.",[27,82,84],{"id":83},"content-and-materials","Content and materials",[11,86,87,88,93],{},"Who supplies copy, images and translations, and when. If the design exists, in what format and how complete: a Figma file with components and states is very different from three static screens (I cover this in ",[89,90,92],"a",{"href":91},"\u002Fen\u002Ftips\u002Ffigma-to-wordpress-with-design-tokens","From Figma to WordPress",").",[27,95,97],{"id":96},"timing-budget-decisions","Timing, budget, decisions",[11,99,100],{},"Real deadlines and why (an event, a campaign), a budget range, and who approves. A single decision-maker shortens projects more than any technical choice.",[27,102,104],{"id":103},"ownership-and-handover","Ownership and handover",[11,106,107],{},"Who owns the code, where the repository lives, who holds the accounts (hosting, domain, stores), what is delivered at the end: documentation, access, staging environment.",[27,109,111],{"id":110},"acceptance-criteria","Acceptance criteria",[11,113,114],{},"How you establish that the work is complete. For each essential feature, a verifiable sentence: \"a registered user sees only their own bookings\", \"the form submits the request and shows a confirmation even without JavaScript\". They are the technical contract between the parties.",[15,116,118],{"id":117},"a-template","A template",[56,120,121,128,133,138,143,148,153,158,163,168,173],{},[59,122,123,127],{},[124,125,126],"strong",{},"Context and measurable goal:"," …",[59,129,130,127],{},[124,131,132],{},"Users and roles:",[59,134,135,127],{},[124,136,137],{},"Essential \u002F important \u002F nice-to-have features:",[59,139,140,142],{},[124,141,51],{}," (performance, accessibility, languages, security): …",[59,144,145,147],{},[124,146,77],{},", with documentation: …",[59,149,150,127],{},[124,151,152],{},"Available content and design:",[59,154,155,127],{},[124,156,157],{},"Deadline and reason:",[59,159,160,127],{},[124,161,162],{},"Budget (range):",[59,164,165,127],{},[124,166,167],{},"Decision-maker:",[59,169,170,127],{},[124,171,172],{},"Ownership of code and accounts:",[59,174,175,127],{},[124,176,177],{},"Acceptance criteria:",[15,179,181],{"id":180},"how-to-read-the-replies","How to read the replies",[11,183,184],{},"A good quote sends the brief back with questions, explicit assumptions and exclusions. I would be wary of anyone who replies within an hour with a flat figure on a complex project: they have not read it, or filled the gaps their own way. Comparing quotes only makes sense if the assumptions are the same.",[15,186,188],{"id":187},"the-most-common-mistakes","The most common mistakes",[56,190,191,197,203,209,215,221,227,233],{},[59,192,193,196],{},[124,194,195],{},"Describing the solution instead of the problem",": \"we need a plugin\", \"we need an app\", without saying what for.",[59,198,199,202],{},[124,200,201],{},"No priorities",": every feature looks essential, and the estimate becomes all or nothing.",[59,204,205,208],{},[124,206,207],{},"Missing non-functional requirements",": speed, accessibility and languages discovered at the end.",[59,210,211,214],{},[124,212,213],{},"Integrations taken for granted",": \"it connects to the management system\", without knowing whether it has an API.",[59,216,217,220],{},[124,218,219],{},"Content \"on its way\"",": copy and images arriving when the project is finished and changing the layout.",[59,222,223,226],{},[124,224,225],{},"Too many decision-makers",": every review opens a new round of opinions.",[59,228,229,232],{},[124,230,231],{},"Budget left unsaid",": the developer proposes a solution out of scale, one way or the other.",[59,234,235,238],{},[124,236,237],{},"Deadlines without a reason",": an arbitrary date prevents thinking in phases.",[11,240,241,242,245],{},"If the project is still vague, the most honest choice is a separate, paid ",[124,243,244],{},"analysis phase"," that produces the brief and a reliable estimate. It costs little compared with the project and greatly reduces risk for both sides.",[15,247,249],{"id":248},"an-acceptance-criterion-you-can-test","An acceptance criterion you can test",[11,251,252],{},"\"The user sees only their own bookings\" is a start, but the test must include the APIs. We prepare two test accounts: A creates a booking; B tries to read and change it using its identifier directly. The server must refuse both operations, even if B knows the endpoint address. Hiding the button is not access control.",[11,254,255],{},"For performance requirements I distinguish a field target from a test before launch. The brief must specify pages, devices, network conditions, metric and measuring method. A lab score is not the same as the Core Web Vitals of real visitors; without enough traffic you need a declared provisional criterion, followed by monitoring in production.",[15,257,259],{"id":258},"my-take","My take",[11,261,262],{},"The best brief I receive is the one that admits what it does not know. Working mostly with agencies, I prefer a short document with clear goals and constraints to a long specification that already describes the solution. Then I work in previews: every week an online version you can review (with Netlify every change generates one), so the brief is checked against the real product, not on paper.",[11,264,265],{},"And I always ask for ownership of code and accounts to be put in writing: not out of distrust, but because it is the question that, asked late, causes the most trouble.",[11,267,268],{},"For me, an honest brief is worth more than a perfect specification.",[15,270,272],{"id":271},"why-work-with-me","Why work with me",[11,274,275],{},"I have been receiving briefs from agencies for many years: since 1999 I have delivered more than 300 projects and I work with more than 30 agencies, from Rome and remotely. I answer a brief with questions, explicit assumptions and a phased estimate, not a flat figure.",[11,277,278,279,283,284,288],{},"If you have a project to set up, ",[89,280,282],{"href":281},"\u002Fen\u002Fcontact","get in touch",": in a call of about 20 minutes we turn the idea into a brief that holds up. The service is in ",[89,285,287],{"href":286},"\u002Fen\u002Fservices\u002Fcustom-software-development","Custom software development",".",{"title":290,"searchDepth":291,"depth":291,"links":292},"",2,[293,294,306,307,308,309,310,311],{"id":17,"depth":291,"text":18},{"id":24,"depth":291,"text":25,"children":295},[296,298,299,300,301,302,303,304,305],{"id":29,"depth":297,"text":30},3,{"id":36,"depth":297,"text":37},{"id":43,"depth":297,"text":44},{"id":50,"depth":297,"text":51},{"id":76,"depth":297,"text":77},{"id":83,"depth":297,"text":84},{"id":96,"depth":297,"text":97},{"id":103,"depth":297,"text":104},{"id":110,"depth":297,"text":111},{"id":117,"depth":291,"text":118},{"id":180,"depth":291,"text":181},{"id":187,"depth":291,"text":188},{"id":248,"depth":291,"text":249},{"id":258,"depth":291,"text":259},{"id":271,"depth":291,"text":272},"Software development",{"name":314,"url":315},"Swanky Fella","https:\u002F\u002Funsplash.com\u002F@swankyfella","2026-10-15","A brief that produces reliable estimates: goals, functional and non-functional requirements, integrations, environments, code ownership and acceptance criteria. With a template.","md",[320,323,326,329],{"q":321,"a":322},"How long should a brief be?","As long as it takes to make estimates comparable. Two well-written pages are worth more than twenty generic ones: what matters is that goals, constraints and acceptance criteria are explicit.",{"q":324,"a":325},"Should I state the budget?","Yes, even as a range. Without a budget the developer has to guess the level of solution: the same request can be answered with a ready-made theme or a custom application, and the estimates will not be comparable.",{"q":327,"a":328},"What are non-functional requirements?","The qualities the system must have beyond its features: performance, accessibility, security, languages, supported browsers, availability. They are the ones most often missing from briefs and most often behind disputes.",{"q":330,"a":331},"What if I do not yet know what I need?","You run a separate, paid analysis phase that produces the brief. It is more honest than a fixed price on an undefined project.","\u002Fimages\u002Ftips\u002F2026-10-15-brief-per-sviluppatore.jpg","Pen resting on an open book","developer brief",{},true,"\u002Fen\u002Ftips\u002F2026-10-15-brief-per-sviluppatore",[339],"white-label-agenzia-sviluppatore",{"title":6,"description":317},"Developer brief: template with requirements and constraints","app-su-misura","web-developer-brief-template","en\u002Ftips\u002F2026-10-15-brief-per-sviluppatore",[346,347,348,349,350],"brief","development quote","requirements","acceptance criteria","agencies","TcufQ8Wlqld3Ga2oIPIZ3N5icUC5nmuuHYoi8lAKq68"]