How to Write a Software Project Brief: A Practical Template That Saves Time and Money (2026)

"Send us a quote for a site like this one" or "I need a delivery app" — some version of this reaches every software company in Cairo and Riyadh daily. The request is sincere, but it carries none of the information a vendor needs to give you a number they can stand behind. Three quotes come back, oddly far apart, and you cannot tell which one covers what you meant.

The fix is not a huge technical specification or a team of analysts. It is a two-to-four page document called a brief — a project requirements document — explaining what you want to build, why, and for whom. A good brief saves weeks of back-and-forth, makes proposals comparable, and protects you after signing from the argument that begins with "is that inside the scope?"

At Jad Digital we read dozens of briefs a year from clients in Egypt and Saudi Arabia, and we know which lines produce an accurate estimate and which produce a list of questions. This guide is for the owner or project manager, not the developer: the ten sections a brief needs, a template to copy and fill in, clear versus vague requirement lines, and what to expect back.

When a message says "I need a delivery app", the company faces dozens of unanswered questions. Customers only, or drivers too? A dashboard for participating merchants? Cash on delivery only, or cards and wallets? One city, or several with different shipping rules? Each answer changes the size of the work by multiples, not percentages.

An estimator facing the unknown has two options: add a large safety margin, so the quote lands high for invisible reasons, or assume the simplest scenario, so it lands low and change requests start the moment work begins. The second wrecks projects: changing something after the build starts always costs more than deciding it before.

Worse, the quotes stop being comparable. One company understood a single app, another two apps and a dashboard, a third added branding. You think you are comparing like for like; you are comparing three different projects. A brief freezes the assumptions, so proposals differ by method, quality and timing — exactly what you want to compare.

• Weeks of questions and replies before a serious proposal appears.
• Quotes spread far apart for reasons unrelated to how good each company is.
• A timeline built on partial understanding, then delays both sides blame each other for.
• Scope arguments after signing, the most common reason projects sour.
• Features built and never used, because they entered by accident rather than by decision.

You need no more than these ten, and none should be missing. Write each one in the language of your business, not in technical language.

Start with what you want changed in the company, not what you want on the screen. "We get fifty orders a day on WhatsApp and lose half in the noise; we want them arriving structured and trackable" is a business goal. "We want a modern website" is not. A good company proposes cheaper or faster solutions once it understands the goal, and may tell you half your list is unnecessary.

Describe where you are today: an existing site, an accounting system, a page you sell from. That decides whether this is a build from scratch, a rebuild, or an integration job. If you are torn between a website and an app, read app or website: which comes first first.

Write who will use the system, how many distinct roles exist, and what each does. "Customer, sales rep, branch supervisor, accountant, general manager" means five experiences and five permission sets, and role count is one of the biggest drivers of effort in any business system.

Separate external users from internal ones: a customer needs simplicity and few steps; staff need dense information, shortcuts and fast data entry. One design serving both usually serves neither. Add the users you expect in year one and whether they work from phones or desktops, which sets design priority and testing effort.

This is the most important section. Split the feature list into three groups: what the project cannot launch without, what you want next, and what you are merely considering. Only the first group is priced for phase one; the rest still belongs in the brief because it shapes architecture and prevents a build you cannot extend later.

An owner who writes this honestly gets a faster launch and lower cost: the real risk is not price but the size of phase one. A tight phase one launches, earns, and funds what follows with decisions based on real usage, not boardroom guesses.

Instead of "login screen, home screen, products screen", write the journey end to end: "the customer opens the app, searches, adds to the cart, picks a saved address, pays by card, and is notified when the order ships." A journey exposes the hidden steps a screen list never shows — saved addresses, notifications, failure states.

Three to five journeys are enough: the main customer journey, the main staff journey, and the admin journey. Anything beyond that can be handled in the questions call.

State whether the product is Arabic only, English only, or bilingual with a layout that flips right to left. Bilingual is not a toggle: it means double the content, a design that works in both directions, and Arabic search that behaves correctly.

Give the volume, not just the type: how many pages, how many products and attributes, whether you have photography or need a shoot. Say who writes the copy, who supplies images, and by when — the most common reason a finished project waits months to launch.

Name every external system the project must connect to. Payment gateways in Egypt such as Fawry, Paymob and InstaPay; in Saudi Arabia Mada, Apple Pay and instalment services like Tabby and Tamara. Your shipping carriers. Your accounting system. The Egyptian Tax Authority e-invoicing system, or ZATCA e-invoicing requirements if you sell in the Kingdom — details there change, so confirm your current obligations on the authority's own portal.

Every integration is a separate work item with its own documentation, credentials, tests and failure cases. Naming them prevents the biggest financial surprise after signing.

The part the client sees is usually half the project or less. Write what you want to manage yourself: products, prices, offers, users, content. Then list the reports you will genuinely open every week, not every report you can imagine. One report that gets read beats twenty nobody opens, and each extra one costs build and test time.

Say whether a date cannot move: an exhibition, the Ramadan season, the start of a school year, a branch opening. A hard date changes how phases are cut, forcing a smaller launch on the date and expansion after it. If there is no hard date, say so plainly — honesty buys a better plan than invented urgency.

The question everyone hesitates over. The answer is yes: give an approximate range without revealing your ceiling. Not because the company will take whatever you declare, but because the same project can be built at several depths, and a range tells the estimator which to propose instead of guessing. With no signal, you may get a proposal far larger than you need, or far smaller than your goal requires.

If you are unsure what drives cost, read what determines mobile app cost in Egypt and the factors behind website design cost in Saudi Arabia first, so your range rests on understanding rather than a guess.

Write how you will know the project worked three months after launch: orders from the new channel, checkout completion rate, time to process one order, phone calls that stopped. Then say who operates the system after handover and whether you need training, maintenance and support. A project delivered without an operating plan quietly stops working.

Copy these lines into a document and complete them in ordinary language. Two pages is enough.

• Company, activity and target market: ...
• The business goal in three lines: ...
• Current situation: existing site, app or system, and what is wrong with it.
• Type of project: brochure site, online store, mobile app, business system, subscription platform.
• Roles and users: the list of roles and what each one does.
• Must-have features for launch: a short, decided list.
• Features deferred to the next phase: a completely separate list.
• Key journeys: three to five journeys written as steps.
• Languages and content: which languages, how much content, and who supplies text and images.
• Required integrations: payments, shipping, accounting, e-invoicing, WhatsApp, any existing system.
• Admin panel: what you manage yourself and which reports you read weekly.
• Hard date, if any: and the reason for it.
• Approximate budget range: without exposing a ceiling.
• Success metrics after three months: specific numbers or behaviours.
• After launch: who operates it, and whether you want training and maintenance.
• Visual references: links to sites or apps you like, with the reason for each.

The difference between these two styles is the difference between an accurate quote and a guess.

The clear lines are not technical. They are ordinary business sentences that settle a decision otherwise left to guesswork. The test: if two people can read a line and understand it differently, it is vague.

• Vague: "user management system". Clear: "three roles: a general manager who sees all branches and edits prices, a branch supervisor who sees only their branch's orders, and a rep who sees only their assigned orders. Only the manager can delete an order."
• Vague: "the site should be fast". Clear: "the home and product pages must open quickly on a mobile connection, and the site is designed for phones before desktops."
• Vague: "payment integration". Clear: "card payment through one gateway we choose together, plus cash on delivery, with a receipt sent to the customer automatically."
• Vague: "reports". Clear: "a daily sales report by branch, a monthly report by product, and a report of stock approaching depletion."
• Vague: "a distinctive design". Clear: "we have a brand identity and will send the files; we want a direction close to these two sites, for these reasons..."

Most post-delivery disputes are not about the main feature but about what happens when things go wrong. One line on each of these saves weeks of argument later.

• Cancellations and refunds: who cancels, up to which stage, and what happens to stock, the invoice and the credit note.
• Failed payments: does the order stay pending, for how long, and who follows it up.
• Stock running out mid-purchase: is the order blocked or accepted pending resupply.
• Notifications: who is alerted on each event, through which channel, and whether WhatsApp messages are required.
• Legacy data: will records be migrated from an existing system or Excel files, and in what condition.
• Connectivity loss: must part of the system work offline and sync later.
• Sensitive permissions: who can edit prices or delete records, and do you need an audit trail.

Vagueness hurts, but detail in the wrong place hurts too. Do not mandate specific technologies unless you have a real reason, such as an in-house team that will maintain the system; the stack is the company's responsibility and it should justify its choice. And do not turn the brief into a thirty-page screen-by-screen specification before picking a partner — analysis-phase work that usually gets rewritten.

Do not ask for everything in phase one thinking it saves money. A system that tries to do everything on day one arrives late, launches loaded with features nobody requested, and burns the budget before the idea proves itself.

A serious company reads the brief and asks for a short questions call — a good sign, not a bad one. After it you receive a proposal restating the project in its own words, defining scope item by item, splitting it into phases, and setting out durations, delivery, review rounds and payment stages.

The agreed scope then moves into the contract as an annex. This is where the brief protects you: any later request outside it is priced as a known change rather than fought over. Ask too for clear clauses on ownership of the code, database, hosting and domain after handover. The criteria for choosing the partner are covered in seven criteria to settle before signing the contract.

• Specific clarifying questions, not an open-ended meeting with no preparation.
• A proposal to shrink phase one if it is too big, rather than agreement with everything.
• A written, itemised scope that also states explicitly what is out of scope.
• A phase and deliverable plan, not a single overall duration.
• A clear list of what the company needs from you: content, images, accounts, decisions.

A transport company wanted a driver app, a customer app and an operations dashboard. The first brief was two lines. Rewritten properly, phase one turned out not to need a customer app at all: the customers were companies dealing through account reps, and the value sat in the driver app and dashboard. The project shrank to a third of its assumed size and launched in season — otherwise half of it would have been built and never used.

A retailer wrote that he wanted "an online store". The section that changed everything was integrations: inventory in an existing accounting system, two carriers with different rates per governorate, and invoices that had to reach the e-invoicing system. Those three lines turned a simple storefront into a store wired into operations — far better discovered before pricing than a month after.

A founder had an idea for a subscription platform serving one sector. The brief works differently here: what matters is not the feature list but the smallest testable version, how a user signs up and pays, and what happens when a subscription lapses. That section alone prevented three modules from being built before anyone proved customers would pay.

• Describing the solution instead of the problem. Say what you want fixed and let the solution be discussed.
• A feature list with no priorities. If everything is essential, nothing is.
• Hiding existing systems. The legacy system always surfaces; better before pricing than after.
• Ignoring who supplies the content. A technically finished project can wait months for copy.
• Copying a brief for a completely different product. References help; copying drags you into someone else's project.
• Leaving out dates and seasonality. Planning with no hard date is how a whole season gets missed.
• Sending a different brief to each company. The quotes stop being comparable and you are back where you started.
• Not naming the decision-maker on your side. A project with three conflicting approvers stalls in the review rounds.

When a brief reaches us we start with a short session converting goals into a written scope and phases, and we usually propose cutting phase one so you reach launch sooner. That is how we approach web and systems development, because a project that launches early and improves on real data beats a perfect one that never ships. If you have no brief yet, send what you have through our contact page and we will help you write it in the first meeting.

And if you are still choosing a partner, our pillar guides on choosing the best software company in Egypt and choosing a software company in Saudi Arabia cover evaluation criteria, references, ownership and contracts in detail.