By Mehdi HassanHow can a startup test a design and development partner before committing?
The most reliable way to test a design and development partner is a short, paid trial on real work from your product. A portfolio shows what a team made for someone else under different constraints. A trial week shows how they handle your users, your codebase and your feedback, which is what you're actually buying.
Calls and proposals tell you whether a team can sell. A trial tells you whether they can ship. For founders choosing a partner for version one, our guide to what a good MVP development agency delivers covers the wider selection process, and our MVP design and development guide explains the build itself.
- Designify trial week, fixed price
- $1,000
- Design and development before you commit
- 1 week
- Retainer if the trial works
- $6,000/mo
What should a trial week with a design agency prove?
A trial week with a design agency should prove four things: the team understands your users and product, they ship real output inside the week, they communicate clearly without you chasing them and their work holds up when built. Write these down before day one so you judge the trial against criteria, not a feeling on Friday.
Criterion | What good looks like | Red flag |
|---|---|---|
Product understanding | Sharp questions about users, the core flow and constraints | Starts designing before asking anything |
Shipped output | Working screens or code you can click by the end of the week | Only mood boards and a plan |
Communication | Daily updates, decisions explained, blockers raised early | Silence until a Friday reveal |
Quality in code | Matches the design, handles states, readable structure | Pixel-perfect mockups that break when built |
Judgment | Pushes back on scope with reasons | Agrees to everything |
Fit | You'd happily work with them weekly | Every call feels like a negotiation |
If you want a more detailed scoring sheet, our one-week design trial scorecard breaks each criterion into checks you can tick during the week.
What makes a good trial week task?
A good trial task is small enough to finish in a week, real enough that the output is useful and central enough that it reveals product judgment. The best tasks sit on your core flow, where design and engineering decisions both matter.
- Redesign and build one step of onboarding. Shows how they think about activation, copy and states.
- Design and ship an empty state that activates users. Small, high-impact and easy to judge.
- Turn a messy screen into a clean, built component. Reveals craft and how they work in your codebase.
- Prototype a new feature's core interaction. Good if you're testing product thinking more than build speed.
- Fix the most-complained-about flow. Real pain, real users, a clear before and after.
How should you run the week day by day?
Run the trial week with a kickoff on day one, short daily check-ins and a review on the last day against your written criteria. The structure below keeps it focused and makes the decision at the end straightforward.
Before day one: brief and access
Share the task, the success criteria, any user research and access to Figma, the repo and analytics. Missing access is the most common way trial days get lost.
Day one: kickoff
A focused call on the users, the problem and constraints. Note the quality of their questions. A good team leaves with a clear plan and a list of assumptions to check.
Days two to four: work in the open
Expect a short update each day with what's done, what's next and any decision they need from you. Reply quickly; slow founder feedback is the main thing that weakens a trial.
Day four: mid-trial review
Look at work in progress. Give honest feedback and watch how they take it.
Day five: handover and review
Walk through the output: designs, built code or both. Score it against your criteria while it's fresh.
For a deeper look at the mechanics, including contracts and IP, see how to run a paid trial week with a design agency.
What can a one-week trial realistically ship?
A one-week trial can realistically ship one focused piece of product work: a redesigned and built flow step, a set of components in code or a tested prototype of a new feature. It can't ship an MVP or a full redesign, and a team that promises that in a week is telling you something about their judgment.
The output depends on what's already in place. A team working in an existing codebase with a component kit can get further than one starting from nothing. If the trial is aimed at a marketing site rather than a product, what a trial week can realistically ship for a website sets expectations.
Hypothetical example: a trial week brief for a SaaS onboarding step
For example, suppose a founder runs a reporting tool where many new users sign up and never connect a data source.
The brief: redesign and build the connect-your-data step. Success criteria: the team asks about which sources users connect first, delivers a built version behind a flag by Friday, includes empty, loading and error states, and explains their decisions in writing.
Day one, the team asks for recent support tickets and session recordings. By day three there's a working version with a sample-data option for users without a source ready. On day five the founder reviews the code, tries the flow on a phone and scores each criterion. Whether they continue is now a decision based on evidence.
How do you judge the result and decide?
Judge the result by scoring each criterion you wrote before day one, then ask one question: would you want this team on your product every week? If the scores are strong and the answer is yes, commit. If the output is good but the working style frustrated you, that frustration will grow over months.
Pros
- Real evidence of quality and speed on your product
- Low cost compared with a wrong long-term hire
- Useful output even if you don't continue
- Reveals communication style before it matters
Cons
- One week can't show long-term reliability
- Needs your time for kickoff, feedback and review
- A small task may not test every skill you need
- Some strong teams don't offer trials at all
Compare the trial against the alternatives you're weighing. Our breakdown of in-house product team vs a design-and-dev studio and the cost of one team vs two vendors help put the decision in context.
Who is a trial week not right for?
A trial week isn't right if you need a fixed deliverable with a known scope, such as a single landing page or a brand sprint, because a fixed-price package already caps your risk. It also isn't useful if you can't give the team real access or timely feedback during the week.
And if you're comparing many agencies at once, running parallel trials costs a lot of your time. Shortlist on fit and references first, then trial one or two. A trial is a final check, not a way to start a search.
