A $5,000 project brief looks the same from both sides of the conversation and means something different to each of them.

The client sees a website, an app, a product. Something finished and working. The developer sees architecture decisions, third-party integrations, revision cycles, and deployment infrastructure that the client has not thought about yet because those are not their job.

Neither person is wrong. The problem is that both people are right about different things, and no one has named the gap before the invoice arrives.

What the client's mental model includes

The client's version of the project is the Figma file. Or the competitor's website they screen-recorded and emailed over. It is the visible surface: the pages, the colors, the features they will demo to their co-founder.

Their mental model does not include: the authentication system behind the login button, the data schema that makes the dashboard work, the email verification flow, the mobile responsiveness that was not in the mockup, the loading states for slow connections, or the error handling for the API call that fails one time in twenty.

None of these are unreasonable omissions. They are omissions made by someone who does not build software for a living.

What the developer's mental model includes

The developer's version of the same project is a stack. Authentication library. Database schema. State management approach. Deployment pipeline. Environment variables. Third-party services and their billing implications.

A "contact form with email notifications" is a Resend API account, a domain verification, a server action, an error state, a spam prevention decision, and a fallback for when the email service is down. That is before mobile responsiveness.

None of that is visible in the brief. All of it is real work.

Where the $5k goes in practice

On a typical SaaS landing page with one authenticated feature — a dashboard or a form submission flow — the breakdown looks roughly like this:

Design implementation from Figma is the part both parties agree exists. It takes maybe 40% of the time on a well-spec'd project.

The authentication and user management layer — login, registration, password reset, session handling, protected routes — takes another 20%. It is invisible to the client until it is broken.

Third-party integrations — payments, email, analytics, file storage — take a further 20%. Each one has an account setup, a webhook, an error state, and a test run in production.

The remaining 20% is everything that was not in the brief: responsive edge cases, performance, cross-browser testing, deployment, DNS, and at least one revision cycle where something visible changed.

That is a $5k project. It is not a Figma-to-code translation. It is a product.

The conversation that prevents the problem

The gap closes with one question asked before the project starts: "What does 'done' mean to you, specifically?"

Not "what features do you want." What does done mean. The answer tells you whether the client has thought about the authentication layer, the mobile version, the error states, the deployment. If they have not, that is the conversation to have — before it becomes a revision dispute.

A project scope that the client writes is more useful than one the developer writes. They will include only what they have imagined, which surfaces the gaps. Filling those gaps in a document is less expensive than filling them after a delivery call.

The anti-pattern to avoid

The anti-pattern is quoting based on the Figma file. The Figma file shows the happy path, one screen size, and zero error states. Quoting based on it guarantees that the work exceeds the estimate.

The correct input for a quote is the Figma file plus a written feature list plus one discovery call where you ask what "done" means. Together those three give you a project. Separately, the Figma file alone gives you a number that will be wrong.

Conclusion

$5k projects fail because both parties are pricing the part of the project they can see. The fix is naming the invisible parts before the work starts, not after the invoice does.

Summary

Clients price the visible surface — pages, features, interactions they can demo. Developers price the invisible infrastructure — auth, integrations, error states, deployment. The gap between those two models is where disputes live. The fix is a single question asked before work begins: what does done mean specifically? Quote from a feature list and a discovery call, not from a Figma file. The Figma file shows the happy path; the project includes everything else.