In this guide 6 sections
Pick design only first when the idea is unproven, the budget is tight or you want freedom to choose any developer later. Pick one team for both when the scope is clear, the workflow is known and speed matters more than comparing several quotes. Either way, own the files. Insist on a written handover.
What a design only engagement leaves you with
You pay for research, flows, wireframes, a clickable prototype and a finished screen library, then receive the files and a short handover note. Nothing is built yet. That sounds thin, yet it gives you something concrete to show partners, staff and investors before any code exists or a single database table is designed.
The prototype also becomes the specification, so any developer can quote against the same screens, and the bids become comparable line by line rather than guess by guess. Ask three firms for a price. You will see quickly who understood the work and who guessed at it, and whose quote lists every screen by name and every state of it.
Review the files before the final payment. Open the prototype on a phone and on a desktop, click through the main task, and check that every error message and empty list has a screen.
- Source files in Figma or similar, in your account
- Exported assets, icons and fonts with licences
- Component library and spacing rules
- Written notes on behaviour for each screen
The case for one team doing both
A team that also builds will design with the database in mind, and it knows that a screen with twelve live filters needs indexes. It knows a pretty map costs weeks. Questions get settled in minutes.
Translation loss is smaller too. Hand-offs between companies drop animation notes, error states and empty-list screens, whereas one team carries the intent forward and fixes the design when the build exposes a flaw.
Fewer suppliers is the cost. If the same firm designs and builds, you cannot easily take a screen to a rival, and a weak design may be defended because someone must build it.
Ownership is the deciding clause
Whichever route you choose, read the contract for who owns the working files, not just the exported images, because PNG exports cannot be edited by the next team. Ask whether you receive editable source, the component library and the licence for any fonts or stock icons, plus a list of every third party asset used. Ownership decides the rest.
If one supplier does both, price design as its own line, and keep in writing the right to take the finished screens to another developer. Without that clause the design becomes a hostage, and every later price is negotiated from weakness, whether for a new feature or a renewal.
- Editable source files delivered, not only PDFs
- Design priced separately from development
- Right to hire another developer for the same screens
- Named person for questions after handover
Build cost awareness and the idea that fails
A design-only firm can draw something lovely that takes a year to build, and nobody on the team may notice until the first developer quote arrives. Ask whether the designer has shipped software, and whether they will flag costly items such as offline sync, custom charts, barcode scanning or live maps while sketching. Press for named examples.
Sometimes a prototype kills the idea. Staff cannot find the task. Customers ignore the feature. A spreadsheet would do. Learning that from a clickable prototype costs far less than learning it after the build has been paid for and the launch email has already gone to customers.
A simple way to decide
Ask three questions. Is the problem proven? Is the workflow known? Do you already have a developer you trust, and will you pay for a prototype even if usability testing ends the project? Two yes answers favour design only. Otherwise one team is simpler.
Whatever you choose, agree a checkpoint after the prototype test, with three outcomes named in advance, namely stop, switch supplier or continue. Write it into the plan before the first sketch is drawn, and date it, so that nobody can later pretend the option was never on the table.
Design engagement decision sheet
Two columns sit side by side on a single sheet, headed design only and design with development, so the two routes can be scored line by line. Rows cover file ownership, handover items, quote comparability, the checkpoint after testing and who answers build questions once the screens are signed off. Each row gets a score. A notes cell follows.
Open a blank worksheet to printQuestions owners ask
Can a different company build from my prototype?
Yes, if you own the editable files and the behaviour notes for every screen, and the licences for any fonts or icons inside them. Ask for a handover session in which the designer walks the developers through states, error messages and spacing rules, and record it for later hires.
Does design only cost more overall?
Not necessarily. You may pay for a hand-off meeting and some rework, but you also gain competing quotes and the option to stop before any code is written. Compare totals after the prototype, not before. Keep both figures.
What if the design firm has never built software?
Ask them to review the prototype with a developer before the design is finished, and to note every screen that the developer finds expensive. Simplify any feature that startles the developer. Price it early.
Who owns the intellectual property in the designs?
The contract decides. State that you own all deliverables on payment, including source files and the component library, and list third-party licences separately, so no later invoice reopens the question.