How to write a software project brief that gets a useful proposal

Most weak proposals are answers to weak briefs. When a provider is given a feature list and a deadline, it can only reply with a feature list and a number, and you end up comparing documents that describe different projects. A good brief is short, specific about the outcome and honest about what is still unknown. It is the cheapest hour you will spend on the project.

OutsourcingVN is operated by Netbase JSC. We read briefs for a living, so this page is written from the receiving end: it describes what makes a brief answerable, not what makes it impressive. Use it with any provider you are approaching. For the wider decision about buying an accountable outcome from a remote-first team, start with our buyer guide to outsourcing a software project.

What a brief is for

A brief does three jobs. It lets a provider decide whether to bid at all, which saves everyone time. It gives every provider the same starting point, so the proposals you receive are comparable. And it forces you to agree internally on the outcome and the decision owner before an outside party starts asking.

It is not a specification. You are not describing how the system works; you are describing what has to be true when it is finished, and what constrains the route there.

A copyable outline

Paste this, fill it in, delete what does not apply:

• Project name and one-line summary
• Outcome: what will be true when this is done
• Why now: the driving event and any hard date
• Today: current system, users, technology
• In scope: capabilities, as a short list
• Out of scope: what this phase deliberately excludes
• Integrations: system, owner, documentation available or not
• Data: sources, volumes, migration or cleaning needed
• Constraints: technology, hosting and residency, security, compliance, procurement
• Decision owner: name, role, availability
• Other people involved: subject-matter experts and their availability
• Timeline: desired date, immovable date
• Budget: approved envelope or range, or "to be advised by proposal"
• Selection: criteria, steps, dates
• At handover we expect: deliverables and ownership
• Open questions: what you do not know yet

That last line matters more than it looks. A brief that admits three unknowns gets a better proposal than one that pretends there are none, because the provider can plan for them instead of discovering them.

How much detail is enough

Aim for one to three pages. Enough that a provider can judge feasibility and risk; not so much that you have pre-designed a solution and removed the provider's ability to improve it. If you have a longer specification, attach it and keep the brief short, saying which parts of the specification are settled and which are proposals.

Write it in the working language of the engagement. Netbase delivery communication is in English, which is also how proposals and status reports are written, and that is the norm across most international providers. If key documents exist only in another language, say so early, because translation and interpretation are project work.

Where a real-time conversation is needed to settle something, plan for it deliberately rather than assuming it will happen. The Hanoi office works Monday to Saturday, 9:00 to 18:15 Vietnam time, which is UTC+7, and our guide to time-zone collaboration explains how overlap is usually arranged.

Common mistakes

• A feature list with no outcome. It produces a quote for building the list, whether or not the list solves the problem.
• No named decision owner. Everything slows down and the estimate grows to cover the delay.
• Hidden integrations. They surface in week three and change the plan.
• A deadline with no reason. Providers cannot tell which dates to design around.
• Sending different briefs to different providers. The proposals then cannot be compared, which defeats the exercise. Our comparison of software outsourcing companies depends on a single brief going to everyone.
• Asking for a fixed total on an undefined scope. Something has to be defined before it can be fixed. Most of our projects are agreed as fixed-scope contracts with an agreed total after discovery, and milestone-based arrangements are also available, which is a deliberate sequence rather than a formality. The engagement models page explains the options.

What happens after you send it

At Netbase, a brief enters a lifecycle that starts with discovery and strategic alignment, then team assembly and architecture planning, before any build work is agreed. Requests sent through the OutsourcingVN contact and project request forms are emailed to our project and sales mailboxes and stored in the site administration database, and a person reviews every project brief and replies within two business days, Monday to Saturday, Vietnam time. You can also reach us through the contact page.

Expect the first reply to contain questions. A provider that returns a number without asking anything has either done this exact project before, which they should say, or has not read the brief. Our project delivery page describes what happens after a proposal is accepted, and our Work records show the kind of scope we have delivered, with the limitations stated. The custom product engineering and AI workflow automation pages describe the two services those records sit under.

Before you send the brief, it is worth running the provider itself through our due diligence checklist. The methodology page explains how we source and review everything published here.

Have a brief ready?

Submit a project using the outline above, and a person will read it and reply with questions or an approach. OutsourcingVN is operated by Netbase JSC and is Netbase's own outsourcing-services platform.

Related services and solutions