The buyer's guide — first-timer's edition
Most app projects go wrong in decisions made before any design starts. This is what to settle first.
The most expensive mistake in app projects is building version one as though it were version three. Every feature you add before you have real users is a feature you may delete after you have them.
Settle what the first release exists to prove. That it works technically. That people will use it. That they will pay. Each of those implies a different, much smaller build than “the app we eventually want,” and studios scope dramatically differently against a proof and a product.
Studios need to know four things and most briefs omit all four. Do you have engineering in house, and at what level. Do you have an existing codebase, and can they see it. Do you have a design system or brand guidelines. Do you have users already, and can the studio talk to them.
The answers change the shape of the engagement more than the feature list does.
iOS only, Android only, both, or web as well. Each addition is real cost, not a checkbox. Most products should launch on one platform and expand once they know the thing works.
If you want both from day one, expect a cross-platform recommendation and be ready to hear why. Studios that agree to whatever you ask without discussing the trade are not doing you a favour.
Withholding budget is standard practice and a false economy. Studios scope blind, propose engagements at the wrong scale, and everyone loses weeks.
App budgets span an enormous range, from a scoped design engagement in the tens of thousands to a consultancy programme in the high six figures. Naming a range means the proposals you receive are comparable.
If you do not know what your problem typically costs, say so and ask early. Most studios will tell you honestly rather than waste a pitch cycle.
Every studio you add costs you time and costs them unpaid effort. Wide pitch lists produce shallow proposals from teams who correctly calculate their odds.
The four types on the home page price and behave differently. Design-led studios that build. Engineering-led studios with design attached. Global consultancies. Small senior teams.
Shortlist within one type. A twelve-person studio and a consultancy quoting the same app will differ by an order of magnitude, and comparing those proposals side by side tells you nothing except that they are different companies.
This takes fifteen minutes and eliminates candidates faster than anything else. Look up the apps in the case studies. Confirm they exist, check the last update date, read recent reviews, and see whether the company still operates.
Then ask what the studio actually did. Large apps have many contributors, and designing one flow of a well-known product is different from building it.
Portfolios outlast staff. If a specific project is your reason for calling, ask who led it, whether they are still employed, and whether they would be on your account.
Everyone's portfolio looks good. Process is where studios differ and process questions get more honest answers.
Worth asking: How do you decide what stays out of version one. What happens when engineering says a design cannot be built as drawn. How do you handle a client who wants to add scope mid-build. Walk me through a project that went badly and what changed afterwards.
That last question is the most useful one available. Candid answers indicate both experience and a willingness to be straight with you later.
Request empty states, error handling, loading behaviour, permission prompts, and settings. Studios that have shipped will have them and will be pleased to be asked. Studios that have not will offer more hero shots.
Named people, their role, roughly what share of their time you get, and what else they are working on. Ask what happens if that person leaves mid-project.
Small studios that cap concurrent work are structurally protected here. Larger firms may staff excellently, and the only way to know is to ask specifically and get the answer in writing.
Speculative screens reward studios willing to guess before understanding the problem. Ask for relevant case studies, a proposed process, a named team, and a point of view on your specific situation. If you genuinely need to see thinking applied to your product, pay for a discovery phase and pay everyone who participates.
The question that matters most is where the studio's responsibility stops. Design only, design through to handoff, design plus build, or design plus build plus store submission. Proposals are frequently ambiguous here and the ambiguity always costs the client.
Commonly scoped separately and commonly assumed included: QA and device testing, App Store and Play Store submission, analytics implementation, accessibility work, backend or API work, and post-launch support. Ask about each explicitly.
What counts as a round, what happens when you need more, and at what rate. Vague revision language is the most reliable source of friction in the second half of a project.
Every timeline assumes you respond to feedback promptly and approve on schedule. Add contingency for your own side, plus store review, plus the fact that legal will take longer than anyone budgets.
Confirm that source code, design files, and full rights transfer on payment. Check what the studio retains, usually portfolio rights, which is normally reasonable.
Apple Developer and Google Play accounts must be yours. Apps published under an agency account are painful to transfer and occasionally impossible.
Libraries, SDKs, fonts, and stock assets carry their own terms. Some are free for development and chargeable at scale. Get the list.
Not at handover. You should be able to see the code as it is written, and a studio unwilling to allow that is telling you something.
What happens in the first ninety days when bugs surface. What is warranty and what is billable. Agree this before launch rather than during an incident.
What happens if you stop at the end of design, and what you receive. Much easier to agree upfront than mid-dispute.
The first release teaches you what the product should have been. Most meaningful design happens after real users arrive, so budget for iteration rather than treating the store listing as completion.
Analytics and crash reporting have to be in place at release or the first weeks of data are lost. Confirm this is in scope.
Rejections happen, often over metadata, privacy declarations, or subscription mechanics rather than anything in the design. Build a buffer.
A bug ships until the next release passes review and users update. This is the argument for spending more on QA than feels comfortable.
Documentation, architecture notes, and a walkthrough with whoever maintains it next. Studios that treat handover as an afterthought leave you dependent on them.