What to put in a web project brief

Most slow web projects are not slow because the pages are hard. They are slow because the first document tried to describe a whole company and never said what the site is for. A brief that a studio can estimate from fits on a few pages. Start with the visitor. Who arrives, what they already know, and what they should be able to do before they leave. A shop, a signed-in portal, and a corporate site are different products even when they share a logo. Then name the job of the first release. One sentence is enough: take payment for a catalog, publish articles the team can edit, or give a customer a view of their orders. Everything that is not required for that sentence can wait. Waiting is not a lack of ambition. It is how a first release stays small enough to finish. List the systems the site must talk to. Payments, a stock feed, a CRM, an ERP, or a login you already run. If a system is “maybe later”, say so. An integration that appears in week six changes the shape of the work more than a new colour does. Say how content will be maintained. If the marketing team publishes every week, the CMS is part of the product. If a developer will be the only person who edits pages, a lighter build is fine. WordPress, Drupal, and Joomla are reasonable when publishing is the job. React and Next.js are reasonable when the product is an application. They are not interchangeable preferences. Close with how you will recognise a good launch. A page that loads cleanly on a phone, a form that reaches the right inbox, an order that appears in the system you already use. Measurable does not have to mean a dashboard. It means someone can check the result without an argument. Sayra Tech takes web work from a single-page application through to a larger commerce or portal build, including the APIs those sites depend on. Bring the visitor, the first job, and the systems. The rest of the brief can be filled in together.