About the Author:
Boris Sage is the Principal Consultant at DesWave, a design and development agency helping businesses build websites, e-commerce platforms, and brand identities that convert visitors into customers.
Most weeks I spend half my time on calls with business owners who need an app or a website built. Restaurant groups, contractors, jewelers, clinics, small manufacturers. The other half I spend with the designers and developers who want that work.
The gap between what those two groups think happens in a pitch is wider than almost anyone realizes.
Designers believe the strongest portfolio wins the project. Scroll the popular feed on any given day and you will find a hundred studios capable of executing almost any brief that lands in front of them.
I have watched a lot of projects get awarded, and craft is almost never what decides it. The work gets you considered. Something else closes it, and most designers never find out what that something else was, because clients rarely tell you why you lost.
Here is what I see from the middle seat.
1. They want to know the risks of hiring you.
This is the hardest one for designers to accept, so I will be blunt about it.
Most small and mid-sized business owners cannot evaluate design. They cannot tell considered typography from adequate typography. They cannot see the spacing decisions you agonized over. When they look at three portfolios, all of them look good, because they are curated by definition.
What they are actually comparing is the designer against the risk of the whole thing going wrong. They have heard the stories. The agency that went quiet for six weeks. The site that launched broken. The developer who disappeared with the deposit and the domain credentials.
So the thing they are evaluating, whether or not they could articulate it, is confidence that you will finish.
You are not selling design. You are selling the removal of risk. Everything in your pitch either adds to that or takes away from it. A gorgeous case study with no mention of timeline adds nothing. A plainly written explanation of what happens when the client changes their mind halfway through adds a great deal.
2. They want a proposal that doesn’t leave anything to guess.
I read a lot of proposals that lost, trying to figure out what went wrong. The failures repeat.
- Scope written so loosely that the client cannot picture what they are buying. “A modern, responsive website with a clean user experience” describes nothing. The client reads it and quietly wonders whether they are getting five pages or fifteen.
- No timeline, or a timeline with no dependencies attached. Every project I have seen go badly started at handoff, not during the work. If your proposal does not say what you need from the client and by when, you have handed them a deadline they did not agree to and cannot meet.
- No process for change. Clients change their minds. Every single one. A proposal that pretends otherwise reads as either naive or as a trap, and both readings cost you the deal.
- Pricing with no structure underneath it. A single number with nothing supporting it invites negotiation. A number broken into components invites conversation, which is a much better place to be.
Clients do not read your proposal looking for reasons to hire you. They read it looking for reasons to be nervous. Write it accordingly.
If you want to see how this plays out in practice, the project briefs clients post here are worth reading closely. Not to get hired, necessarily, but because the way a client describes their own problem tells you exactly what they are afraid of.
3. They want to see their vision, but better.
The strongest pitch is the one where the client hears their own idea described back to them better than they did.
We worked on a product called AURA, a dating app. The brief could have been read as a feature list, and if we had read it that way, we would have built something competent but forgettable, as there are a hundred competent dating apps right now.
What we understood early was that the client was not trying to build another dating app. They were trying to change how the experience of dating feels. The vision was not built on endless swiping or appearance-first interaction. It was about curiosity, emotional connection, and a sense of intimacy arriving before attraction.
Once that landed, the work stopped being a design problem and became a much clearer one. We stopped asking what a dating app should look like and started asking how this experience should make someone feel. That single shift decided the visual language, the interaction model, the onboarding sequence, the profile experience, and the animation timing down to the smallest transitions.
The principle scales down to far more ordinary projects. A restaurant owner asking for a loyalty feature is rarely asking for a loyalty feature. They are asking how to make people come back on a Tuesday. A contractor asking for a quote form is asking how to stop losing jobs to whoever answered the phone first.
Clients brief you on the solution they imagined. Your job is to find the problem underneath it. The designer who does that is no longer a vendor being compared on price.
4. They want to know the cost, the real one.
This is the part of the process where most deals quietly break, and it breaks because almost nobody in this industry talks about numbers in public.
I want to be clear that what follows is market observation, not a rate card. Every project is different and any range is a starting point for a conversation, not a quote.
Where mobile app work actually sits
For a genuinely basic single-platform build, the realistic floor sits around $20,000. That buys one job done well rather than a platform. A handful of screens, a standard login rather than a custom authentication system, and a managed backend rather than custom infrastructure.
A restaurant group building a reservation flow, a menu, and a simple loyalty tracker lives comfortably in that territory, typically wrapping in four to eight weeks. What it does not include: multiple user roles, payments, an admin dashboard, or anything touching compliance.
Once you add those things, you are in a different tier entirely, and it climbs quickly. Bespoke interface work, live integrations with mapping or payment providers, user-generated content, and a backend that holds real business logic rather than storing records.
Anything financial sits here by default. A banking product like MONEXA carries verification, transaction handling, and security requirements that never appear on a feature list but consume a serious share of the build. That range runs from roughly $50,000 to $150,000, and it stretches further when the integration list grows.
Two things surprise nearly every buyer, and both are worth saying out loud early rather than defending later.
- Testing and QA typically consume 15% to 25% of total development hours. On any meaningful build, that is a substantial share of the budget spent on something that never appears as a feature anyone can point at. It is also the single worst place to economize.
- Maintenance runs around 15% of the build cost every year, indefinitely. An app is not a deliverable, it is a thing that has to be kept alive against operating system updates, dependency changes, and security patches. Clients who are not told this at the start feel ambushed by it in month eight.
Single platform, both platforms, and the question everyone conflates
When a buyer asks whether they need iOS and Android, two separate questions get answered as one. How many platforms you cover is a scope question. Whether you build native or cross-platform is an architectural one. They move the budget in different ways and they deserve separate conversations.
On scope, covering both platforms costs more than covering one, but less than most buyers assume. Discovery, user experience architecture, most of the visual design, the backend, and project management are all shared. Only the client-side implementation genuinely duplicates. The premium for a second platform is real, and it is nowhere near a doubling.
On architecture, the honest position is the one most developers will already give you: native costs more than cross-platform, and on the right project it is worth the difference. A single cross-platform codebase lands well below two separate native builds at launch, and the gap widens across the ownership window, since you are maintaining one codebase instead of two.
Native holds a genuine edge on performance-critical work, deep hardware access, and platform-specific interaction feel. Some products need that. Most do not, and the buyers who pay for it without needing it are usually the ones nobody told there was a choice.
Say the number early. The client who hears a range on the first call and keeps talking is a real prospect. The one who disappears was never going to sign, and you have saved yourself three meetings.
None of this is guesswork. I have written up the full scoping process we use at DesWave, including how we break down screens, map wireframes, and decide which dashboards a project actually needs.
5. They want to know why they should act now.
Losing to a competitor is the outcome designers imagine. It is not the common one.
Most often, nothing happens at all. The client does not choose someone else. They stall. Doing nothing feels safer than being wrong about a large decision, and an outdated website is a problem they have already survived for three years. If your pitch only argues that you are the better choice, you have not given them a reason to move now. The pitch has to name what standing still is costing them this quarter.
Sometimes the wrong person said yes. At a small business scale, this rarely looks like a buying committee. It is a business partner, a spouse, a co-owner who was not on the call and got the pitch relayed to them secondhand by someone who is no longer as excited as they were. If you only ever speak to one person, your proposal is being presented internally by an amateur. Ask early who else is part of the decision, and offer to meet them.
And often, the number in their head was never real. A surprising share of prospects arrive believing an app or a website should cost a few hundred dollars, usually because somebody knows somebody who got one built cheaply. When the actual quote lands, the response is almost never pushback. It is silence. Negotiating would require saying out loud that their expectation was never grounded, and most people would rather vanish than have that conversation.
That last one is not a pricing problem. It is an education problem, and it is solvable, but only if you address the gap before you send the number rather than after.
Give them what they’re asking for, even if they don’t know it yet.
The designers and studios winning small and mid-sized business work right now are not the ones with the strongest feed. They are the ones who made the buyer feel understood, wrote a proposal that reduced anxiety instead of creating it, and said the difficult numbers out loud before anyone had to ask.
None of that is a design skill in the traditional sense. All of it is learnable, and almost nobody is doing it.
Find more Community stories on our blog Courtside. Have a suggestion? Contact stories@dribbble.com.
