You have two or three proposals on the table, the numbers are far apart, and every deck is full of beautiful screens. The checks that separate them are not in the screens. Ask for a live product you can open yourself, ask who will sit on your project by name, and read the ownership clause before anything else. Those three take an hour and tell you more than a month of meetings.
This guide is written by an agency, so run it on us too. Every check below applies to Snaabble exactly as it applies to any firm sending you a quote, and the guide says plainly where a freelancer or your own employee would serve you better than an agency would.
What you are actually buying, and why it differs from hiring developers
A UI/UX design agency does not hand you a working product. It hands you the decisions the product will be built on, plus the files that carry those decisions: an understanding of your users, the order of information and screens, wireframes, final interfaces with every state, a clickable prototype, and a handoff package a developer can build from without guessing.
That makes the selection criteria different from the ones you use elsewhere. When you pick a software development company you ask about the legal entity, invoicing, hosting and data migration. When you pick a mobile app company you ask about store accounts and payment gateways. Here the questions are about research before pixels, about the screen states nobody puts in a pitch deck, and about where the Figma file lives after the final payment.
Design and development may be one firm or two. If they are two, ask each of them on day one who owns the gap between them, because that gap is the single most expensive thing in a digital product project.
Read the portfolio with three questions
Portfolios are built to impress you. Dribbble itself began in 2009 as an invite-only place where designers posted work for each other to comment on, and dropped the invitations in 2021 (Dribbble's about page). It is a showcase among designers, not a record of what shipped and worked. A single shot is selected, polished and posted without context, which is entirely fair, but it proves nothing about a team's ability to deliver a product that functions.
Three questions close the distance.
Where is this product now? Ask for a live link: a site you can open, or an app on the App Store or Google Play. Open the store listing and look at the publisher name and the last update date. A product untouched for two years is not necessarily a failure, but it does mean the design you are admiring has not been stress-tested by long use. If the work sits under an NDA, ask for a screen-share walkthrough instead of images.
Which part did this firm actually do? Portfolio work is often shared: one team did the research, another drew the interfaces, a third wrote the code. For each project, ask exactly which part they delivered: research, wireframes, UI, the design system, or the handoff. Then ask who on the current team worked on it.
Show me an ugly screen. This is the most revealing question on the list. Ask to look together at an error screen, an empty list before any data exists, a table with twenty columns, a ten-field form, and a screen in real Arabic where a long name overflows the button. These never appear on Dribbble because they are not pretty, and they are exactly what your staff and customers will look at every day.
Watch the share of "concept redesigns" in the portfolio too: unsolicited restyles of a famous app. Those are skill exercises. There is no client, no real business constraint, and no measurable outcome. If half the portfolio looks like that, you are looking at a team that can draw and has not been tested on a real engagement.
Signals worth stopping for, before the contract
| Signal | Why it matters |
|---|---|
| A final price in the first call, with no questions asked | Anyone who did not ask about screen counts, roles and use cases priced by guesswork, and will recover the difference later from scope or from delivery quality |
| No research or discovery phase in the plan | Going straight to interfaces means the assumptions get tested after the code is written, the most expensive moment to find a mistake. See user research methods for a reasonable minimum |
| A portfolio made entirely of concept redesigns | Visual skill with no delivery record |
| Refusing to connect you with a single past client | Confidentiality explains withholding names, not refusing every reference |
| The team that pitches is not the team that delivers | Common and acceptable when stated up front; the problem is finding out after you sign |
| "Unlimited revision rounds" | Either the price already carries them, or the rounds will quietly stop at a limit nobody wrote down |
| "We'll hand over the Figma files," with no further detail | A Figma file can be handed over in four different ways, three of which leave you without real control. That is the next section |
The questions to ask before you sign
Put these in writing and ask for the answers to land in the contract or its annex, not in meeting minutes.
| Question | The answer that should reassure you |
|---|---|
| Who works on this project, by name, and at what share of their time? | Names and roles, an approximate allocation, and disclosure of anything that will be subcontracted |
| What are the deliverables at the end of each phase? | A specific list: how many screens and which states, a prototype, a component library, a handoff file |
| Who owns the source files, and where will they live? | A written assignment of rights, and the file moved into a workspace under your company's name |
| How many revision rounds are in the price, and what does an extra round cost? | A number per phase, a published price for extra rounds, and a definition of what counts as a round |
| What happens if delivery is late? And if I am late reviewing? | An obligation on both sides: a written window for your feedback, and a clear effect of delay on schedule and payments |
| How is the work handed to developers? | A practical description of what the programmer receives, who answers their questions during the build, and for how long |
| What do I receive if the project stops halfway? | Everything completed up to the last paid milestone, in a format you can open without a subscription of theirs |
The fifth question is the one people forget, and the most honest. The commonest reason design projects run late sits on the client side: feedback that slips by two weeks, and a change of mind from someone who was not in the early meetings. A firm that asks you for a written review window knows its craft. A firm that promises a schedule while asking nothing of you is selling a schedule that will not hold.
Snaabble provides a tailored technical assessment to define the right stack & exact budget.
"The files are yours": what makes that sentence true
Almost every proposal says it. What it is worth depends entirely on what follows it in the contract.
Legally. In Egypt, Article 149 of Egypt's intellectual property law, Law 82 of 2002 requires that an author's transfer of economic rights be certified in writing, with an explicit and detailed indication of each transferred right, its extent, its purpose, and the duration and place of exploitation. The same article adds that the author remains the owner of every economic right not explicitly assigned, and that permission to exploit one right is not permission to exploit another. So a blanket line such as "designs belong to the client" is weaker than it sounds. The annex that enumerates exactly what transfers is what protects you.
In Saudi Arabia, a new Copyright Law was published in Umm Al-Qura on 13 February 2026, replacing Royal Decree M/41, and takes effect 180 days after publication, around mid-August 2026 (Gowling WLG analysis, 30 March 2026). One provision matters directly here: work created by an employee that relates to the employer's activities belongs to the employer, whereas work by an outside party reaches you only through a written assignment. If your contract sits in the Gulf, have a lawyer review it against the new law.
Technically. Legal ownership does not open a file for you. In Figma, the person who creates a file is its owner, and transferring ownership cannot be undone. The part that surprises people: transferring ownership does not move the file. Moving it is a separate action. Transferring a Figma Design file also requires a Full seat (Figma's documentation on transferring ownership).
The detail in that same page worth reading twice: when a Figma account is deleted, the files in that account's drafts are deleted too, regardless of who owns them. A designer who leaves the agency and closes their account can erase your work while you believe it is yours.
So ask for three things together at handover: a written assignment of rights in an annex, the file physically moved into a Figma workspace under your company's name rather than merely shared by link, and a saved .fig copy on your side. Each one closes a gap the other two do not.
What developers actually receive
"Developer handoff" is a loose phrase with a checkable meaning. Nielsen Norman Group describes a design spec as two parts: the design file itself, and a development issue carrying the goal, the use case and the requirement the design solves, covering interaction flows, behaviour and appearance (Creating Design Specs for Development, June 2025). A file on its own is not a spec.
Then ask about a cost line most proposals drop: the tools needed to read the work. A free viewer in Figma already gets basic inspection: measurements, property values, exported assets, and generated snippets for CSS, iOS and Android. Full Dev Mode, with annotations, ready-for-development status, version comparison and links to tools such as GitHub, is available on paid plans and needs a Full or Dev seat. According to Figma's pricing page (in USD, accessed 22 September 2026), a Dev seat on the Professional plan is $12 a month and a Full seat $16; on the Organization plan, billed annually, they are $25 and $55. Small money, but it usually surfaces on the first day of development, so settle it in the proposal.
Ask about screen states before anything visual: loading, empty, error, lost connection, and the long Arabic string that breaks the layout. If they are missing, the developer will invent them, and you will pay for that in a later correction round. And if the product will keep growing with new screens after launch, ask for a design system rather than a stack of finished screens.
Agency, freelancer, or an in-house hire
| Agency | Freelancer | In-house | |
|---|---|---|---|
| What you actually pay for | A project price covering management and more than one role | A project or hourly rate, usually lower | A fixed monthly salary regardless of workload, on top of employment obligations and tool licences |
| The main risk | Your project is staffed by a team other than the one that pitched | One person: illness or a busier client stops everything | Paying a salary for months without enough design work, or losing the context when they resign |
| Ownership | Needs an explicit written assignment | Needs an explicit written assignment | Strongest: employee work related to the company's activity vests in the company |
| When it fits best | A new product with a defined scope and a deadline, needing research, interfaces, a design system and handoff at once | A bounded task: extra screens inside an existing design system, a landing page, or one flow to improve | When the product changes weekly and design is a continuous function rather than a project that ends |
Read that table plainly: if what you need is one landing page a quarter, an annual agency retainer is wasted money. Find a good freelancer and keep them. If you run a live product that changes every week and generates a steady stream of screen requests, an agency will be slower and dearer than a designer who sits with you and remembers why each decision was made, and you should hire. An agency earns its price in the third case: a project with a start and an end that needs a researcher, a UI designer, someone to build the design system and someone to run the handoff at the same time, and does not justify hiring four people.
There is a fourth arrangement people overlook: an agency builds the foundation and the design system in a bounded project, then a freelancer or a single employee keeps building on it. That costs less than an annual retainer and carries less risk than starting with one designer and no foundation.
Clauses to put in the contract
The following is an editorial recommendation, not a standard attributed to any body:
| Clause | What it should say |
|---|---|
| Scope | Screen counts and states, roles, languages and platforms, plus an explicit list of what is out of scope |
| Revision rounds | Rounds per phase, a definition of what counts as a round, and the price of an extra one |
| Acceptance criteria | When a phase is finished: which screens, in which states, tested on which devices, and in real Arabic |
| Payments | Tied to deliverables you inspect and approve, not to dates on a calendar |
| Ownership and handover | Rights assigned in writing with an enumeration of what transfers, the design file moved into a workspace in your company's name, and a saved copy on your side |
| Mutual deadlines | Their delivery window, your feedback window, and the consequence of missing either |
| Exit | What you receive if the project stops, in what format, and within how many days |
| Confidentiality | An NDA before you share your data or your commercial numbers |
And do not compare prices until the scopes match. The cheapest proposal usually assumes fewer screens, fewer states and fewer rounds, and you will pay the difference later at out-of-scope rates. To break down the cost lines themselves, see our UI/UX design cost guide.
Before you sign
Take the checks in this order: a live product you open yourself, an ugly screen you look at together, the names of who will deliver, the ownership clause with its annex, then rounds and mutual deadlines. If a proposal fails the first check, no later clause will rescue it.
And if you conclude that what you need is not an agency at all, that is a correct decision, not a retreat.
If your project is the kind that needs research, interfaces and developer handoff at the same time, send your idea to the Snaabble team through the UI/UX design services page. You will get an initial plan with a time and cost estimate within 24 hours, free and with no commitment. And run the full checklist on us.
Sources
- Egyptian IP Law 82 of 2002, Article 149 · WIPO Lex (accessed 22 September 2026)
- Saudi Arabia Copyright Law 2026 · Gowling WLG, 30 March 2026
- Transfer ownership of files or folders · Figma Learn
- Guide to Dev Mode · Figma Learn
- Figma pricing page (accessed 22 September 2026)
- Creating Design Specs for Development · Nielsen Norman Group, June 2025
- About Dribbble
