How to Brief a Developer: Template for Small Jobs

Most of the questions a developer asks before quoting have little to do with code. Where is the site hosted? Who has the logins? Which version are you on? How will you decide the job is done? Only you know the answers.

When those answers trickle in over three emails, one of two things happens. The developer moves on to a client who was quicker. Or the quote includes a fat buffer for everything that stayed vague. Both cost you money.

What a developer needs before they can quote

Every quote is an estimate made under uncertainty. The less uncertainty you leave, the smaller the safety margin a careful developer adds. For small jobs, nine pieces of information cover nearly everything:

1. Goal: the problem, not your idea of the solution. “Paid orders should reach our accounting software without retyping” beats “build me an API”.
2. Current setup: platform and version, hosting provider, relevant plugins or services. A screenshot of the system info page saves an email.
3. Desired result: what will be different afterwards, described from a user’s point of view.
4. Acceptance criteria: one or two sentences someone can check. There are plenty of acceptance criteria examples you can adapt.
5. Out of scope: what is explicitly not included. This line prevents more arguments than any other.
6. Access: what you can provide and how. Our guide on how to share passwords with a developer covers the safe way.
7. Deadline: when it must be done, and why. A real reason (a launch, a trade show) gets taken more seriously than “asap”.
8. Budget range: a band is fine.
9. Contact: who answers questions and who signs off. If those are two people, name both.

If the job is fixing something broken, a proper bug report replaces fields two and three.

Copy-and-paste developer brief template

Paste this into an email or a shared doc. Leave fields empty and mark them “don’t know” rather than guessing. Honest gaps can be priced. Wrong information can’t.

Subject: Quote request – [short name], needed by [date]

1. Goal
   Why does something need to change? (1–3 sentences)

2. Current setup
   Platform/version:   e.g. WordPress 6.x with WooCommerce, PHP version per host
   Hosting:            provider, plan, who holds the account
   Connected services: e.g. Stripe, Mailchimp, Xero, QuickBooks

3. Desired result
   What should a user be able to do or see afterwards?

4. Acceptance criteria
   Done means ... (testable, with example values)

5. Out of scope
   e.g. redesign, copywriting, translation, training

6. Access
   Admin account / SFTP / staging site available? How will I share it?

7. Deadline
   No later than ... because ...

8. Budget range
   roughly ... to ... (excl. VAT/sales tax)

9. Contact
   Questions: name, phone / Sign-off: name

The template fits on one page on purpose. Three pages of prose get skimmed. Short and specific gets read.

Example: turning one line into a usable brief

Plenty of requests start like this: “Our contact form has stopped working, can you fix it quickly?” Nobody can price that honestly. Is it the host’s mail server, a plugin update, the spam filter? Each cause means different work.

The same request using the template:

• Goal: messages sent through the contact form should reach our inbox again.
• Current setup: WordPress with Contact Form 7 on shared hosting. Since a plugin update two weeks ago no emails arrive, although the form still says “Thank you for your message”.
• Acceptance criteria: three test messages from three different addresses arrive at hello@ within five minutes and none land in spam.
• Out of scope: new form design, extra fields.

Now a developer can say: probably mail sent via PHP’s mail function instead of SMTP, switching and testing takes about one to two hours. That is an estimate you can hold against a second quote.

1. Write down the problemWhat happens, since when, who notices? Add a screenshot.
2. Fill in the templateNine fields, mark unknowns as don't know.
3. Send the same brief to two developersAnswer questions for both, so the quotes stay comparable.
4. Check the quotesAre your acceptance criteria in there? Is it clear what is excluded?
5. Confirm in writingAn email with scope, price, deadline and sign-off is enough.

Three phrases that push quotes up

Some words in a brief make developers add a risk premium on the spot. Not out of greed, but because those words leave the size of the job open.

“Like Amazon does it.” That comparison hides years of engineering. Describe the one feature you like, with a screenshot.

“Just a small tweak.” Whether something is small depends on the code, not on the wish. Drop the word and describe the result.

“Should be scalable for later.” Scalable for what? If you already know a second payment provider is coming next quarter, write exactly that. If you don’t, cut the sentence. Building for unknown future requirements is the most reliable way to pay for code nobody ever uses.

Fixed price or hourly: say what you expect

Your brief should hint at how you want to pay. For a clear job in a system the developer knows, a fixed price is comfortable for both sides. For a bug nobody has diagnosed yet, hourly billing with a cap is more honest, because nobody can know whether it takes one hour or eight.

Say which you prefer, or ask the developer to suggest one. Our comparison of fixed price vs hourly walks through both with numbers. Whatever you choose, ask for the billing increment and any minimum charge per job. Those two details matter more on small jobs than the headline rate.

Get these done before the developer starts

On small jobs, preparation can eat a noticeable share of the billed time, and much of it is work you can do yourself. Every hour the developer spends waiting for access or taking a backup ends up on the invoice. For context, the median rate German freelance software developers ask for is €90 an hour, according to a September 2026 analysis by the project platform freelancermap. Our article on the freelance developer hourly rate breaks down the numbers.

• Fresh backup of files and database exists
• Separate user account created for the developer, no shared admin password
• Acceptance criteria written as one or two testable sentences
• List of what is explicitly out of scope
• Deadline stated with a reason
• Budget range given
• Named contact for questions and for sign-off

The backup is the item people skip most often. Our step-by-step on how to back up a website shows how to take one and check that it actually restores.

When a small job is really a project

There are warning signs. The brief no longer fits on one page. More than two outside systems are involved. Or every quote comes back far above what you thought of as a quick job, and all the developers explain it the same way.

That is the point to stop slicing the work into ever smaller tickets and plan it properly once. If you want a team that builds web applications and integrations and also runs them afterwards, OnlineBuilders offers a free technical first consultation.

For everything smaller, the next step is simple: take the template above, fill it in for the job on your desk today, and send the identical version to two developers. Their replies will quickly show you who actually read it.

Questions people ask

How long should a developer brief be?

For a small job, one page. Long briefs get skimmed, and the details that matter get lost between paragraphs about company history. If you can't fit the job on a page, it may not be a small job.

Should I tell the developer my budget?

Yes, as a range. Budget tells the developer whether you want a quick fix or something built to last. Without it, quotes for the same job can differ by a factor of three or four and are hard to compare.

Should I pay for a quote?

For a clear, simple job, no. For anything that needs the developer to read unfamiliar code first, paying for an hour or two of discovery is fair and usually gets you a more reliable fixed price afterwards.

How many developers should I ask?

Two is enough for jobs under a day of work. More quotes cost you time answering questions without improving the decision much. What matters is that everyone gets the same brief.