October 26th, 2026 at 11:16 am
By Ronak Shah, Nordstone | Last updated: October 2026
A good brief for a design-only or MVP-only project names one goal, one audience, an explicit not-now list and the exact deliverables you expect back. Design briefs should specify screens, fidelity, accessibility and handover files. MVP briefs should name the riskiest assumption to test and the smallest build that tests it.
TL;DR
- Pick the narrowest brief: a design-only brief answers what it should look like and how it works; an MVP-only brief answers whether real people will use it.
- Six sections: goal, users, scope in and out, deliverables, constraints, and ownership and sign-off. Our brief template covers the full-build version.
- Design-only essentials: fidelity, platforms, WCAG 2.2 accessibility target, and the exact handover files.
- MVP essentials: one riskiest assumption, one success measure, a must-have list and a not-now list.
- Ownership: UK copyright in commissioned work belongs to the author unless the contract says otherwise, and an assignment must be in writing.
- Timing: GOV UK says around four to eight weeks is typical for a discovery, and alphas tend to last six to eight weeks; treat these as public-sector norms.
What is a design-only or MVP-only brief?
Both are deliberately narrow. A design-only brief commissions the experience and interface of an app, such as flows, screens and a clickable prototype, without any development. An MVP-only brief commissions the smallest working version of your product, built to test one assumption with real users. Neither promises a finished, launch-ready product, and that is the point.
They deserve their own brief because the usual full-build brief asks the wrong questions. It lists every feature and platform you might ever want, when what you need is a sharp answer to one question. Our app development brief template is built for the full job. This article is for the narrower ones, the kind where a vague brief leaves an agency guessing and you paying for the guesses.
Image 1: choose the narrowest brief that answers your biggest question.
When does a design-only or MVP-only project make sense?
Design-only makes sense when you are not ready to build but need something concrete: to test the idea with users, to show investors, or to get comparable quotes from developers working from the same drawings. It is also sensible if you have a developer or an in-house team and need the design skills they lack.
MVP-only makes sense when the design is settled enough and the open question is behavioural: will customers sign up, book, pay or come back? If you are still unsure that anyone wants the product, do cheaper work first. Our guide to validating your app idea and the free tools for planning and building your app cover what you can do before you commission anything.
The public sector has a useful way to think about it. GOV.UK’s Service Manual describes a discovery phase for understanding the problem, in which you should not start building, followed by an alpha, in which you build prototypes just complex enough to test ideas and expect to throw away most of the code. A design-only project resembles an alpha, because the output is something to test and learn from. An MVP is a step further on, because it is a working product in real hands. It helps to know which one you are buying.
How do you brief a design-only project?
Be specific about the finish line. Start with the goal in a sentence: what the designs are for and who will use them, whether that is user testing, a funding pitch or a developer handover. Then describe the users and the two or three journeys that matter most, such as signing up, booking and paying. Agencies design better when they know the jobs the app does, not a list of screens.
Say what is in scope and what isn’t. Name the platforms, because iOS and Android have their own conventions, set out in Apple’s Human Interface Guidelines and Google’s Material Design. Say whether you want a web app, a mobile app or both. List the screens or journeys you expect, and write a short not-now list of things that can wait, so nobody quietly designs the admin dashboard you do not need yet.
Specify fidelity. Wireframes show structure and flow cheaply. High-fidelity screens show the real look and feel. A clickable prototype lets users try it. Each step costs more, and many founders need only some of them, so say which.
Set an accessibility target. WCAG 2.2 became a W3C Recommendation on 5 October 2023, according to the W3C announcement, and extends 2.1 with nine further success criteria. Asking for AA conformance in the brief is far cheaper than retrofitting later. For public-sector clients, level AA is a legal expectation, but check the version: the regulations were written around WCAG 2.1 AA, GOV.UK’s accessibility team said the latest published version would become the expected standard, and some departments, such as the Department for Education, now state 2.2 AA outright. Ask your client which version their contract names.
Finally, say exactly what you get back. A Figma file with organised pages, a prototype link, exported assets, a simple component library, annotations explaining behaviour, and a short handover call are all reasonable. If you want the designer to review the finished build against the designs, put that in writing too.
How do you brief an MVP-only project?
Start with the riskiest assumption, not the feature list. Ask what would have to be true for this business to work, and what you are least sure about. It might be that restaurants will upload their own menus, or that commuters will pay for a monthly pass. The MVP exists to test that, and everything else is optional.
Next, pick the success measure. Something like “30 businesses complete onboarding in six weeks” gives the build team a target and gives you an honest answer afterwards. Without it, an MVP drifts into a half-finished product that proves nothing.
Then draw the boundary. Write a must-have list that is short enough to scare you, and a not-now list that is longer. Say which platforms the MVP runs on; starting with a web app or one native platform is usually enough, and adding a second native platform can add 70% to 90% according to Nordstone’s UK cost guide. Name integrations, such as payments or maps, and say what can be manual. A founder emailing confirmations by hand is cheaper than building automation before demand is proven.
Cover the unglamorous parts. If you hold personal data, say so, and ask how it will be stored and protected. Define acceptance criteria, the plain tests that decide whether a feature is done. State what support you expect after launch, because an MVP in front of real users will break in ways testing missed.
If you are building a two-sided product, the marketplace app cost guide explains how to stage the work so the first version stays small.
What should every narrow brief include?
Six things, whatever the project type, set out below. Short is fine; vague is expensive.
Image 2: six sections every narrow brief needs.
The table shows how the emphasis shifts between the three kinds of brief.
| Design-only brief | MVP-only brief | Full build brief | |
| Question it answers | What should it look like and how should it work? | Will real people use it? | How do we launch and scale it? |
| Main deliverable | Flows, screens, prototype, handover files | A small working product | A complete product with support |
| Most important thing to specify | Fidelity, accessibility, handover format | Riskiest assumption and success measure | Full scope, integrations, QA and support |
| Biggest risk | Designs nobody can build to budget | Building features nobody needs | Cost and timeline growth |
| Ends when | Designs are accepted and handed over | You have evidence to keep, change or stop | The product is live and supported |
Who owns the work, and what should you put in writing?
This is the section briefs most often skip. Under UK law, copyright in commissioned or freelance work generally belongs to the author unless the contract says otherwise, and the British Copyright Council notes that an assignment must be in writing. So a designer who delivers a beautiful set of screens can legally keep the rights unless you have agreed a transfer.
Put in the brief that you will own the final designs, or the MVP code, on payment, and ask for a licence to any pre-existing components, fonts or stock images used. Check who holds the design files and the accounts. Our guide on who owns the code covers the same ground for development, and our list of questions to ask an agency before signing gives you the follow-ups.
What mistakes make these briefs go wrong?
The most common is asking for everything. A brief for an MVP that lists thirty features will be priced as a full build, and it will take as long as one. The second is describing solutions rather than problems: “a chat screen like WhatsApp” tells a designer little about what your users need to achieve.
Other regulars: no success measure, so nobody can say whether the MVP worked; no handover requirements, so the designs arrive in a form developers can’t use; no accessibility target; and no agreed way to handle changes, which becomes a dispute once scope inevitably moves. Ask each agency how change requests are priced before you sign.
It also helps to choose the right kind of supplier. Our comparison of in-house vs agency vs freelancer will help you decide who should do a narrow job like this.
How much does a design-only or MVP-only project cost?
It varies with scope, but narrow briefs help you control it. For an MVP, Nordstone’s lean-MVP band is £25,000 to £65,000 for a deliberately narrow first version. The wider bands for whole apps are simple at £15,000 to £30,000, medium at £30,000 to £70,000 and complex at £70,000 or more, with annual maintenance typically 15% to 20% of the initial build. The full breakdown is in our guide to how much it costs to build an app in the UK.
Design-only work has no published Nordstone price band, so here is what drives the price. Cost follows the number of journeys and screens, the fidelity (wireframes, high-fidelity screens or a prototype), the number of platforms, whether you want user research and testing, whether you need a reusable component library, and how much handover support you expect. For a sense of scale, IT Jobs Watch reports a median UK contractor day rate of £447 for UX designers, across 77 quoted rates in the six months to 26 October 2026. At that rate, a small project taking one designer 15 to 30 days would cost roughly £6,700 to £13,400 before agency overheads, project management, research or a second specialist. That is an illustration from contractor pay, not a quote or a Nordstone price, so ask for a fixed price tied to the deliverables list in your brief.
When the MVP is ready for the stores, our App Store and Google Play launch guide covers what comes next.
Frequently asked questions
What is a design-only app project?
What is an MVP-only project?
What should a design-only brief include?
What should an MVP brief include?
How long do discovery and design take?
Who owns the designs if I commission design only?
Can I hire one agency to design and another to build?
How much does an MVP cost in the UK?
Want a second pair of eyes on your brief?
If you have a draft, send it over and we will tell you what is missing, what could be cut and how the budget compares with UK benchmarks. Start with our short fill-in brief template for design-only and MVP-only projects, or use the full app development brief template for a complete build, and then get in touch with Nordstone.
