Pricing is the thing almost nobody teaches you, and the thing that quietly breaks the most freelance and small-studio projects. Here's how we think about the three common models, and what we actually do.
Hourly Punishes You for Getting Faster
Hourly billing feels safe when you're starting out — you get paid for every hour, no risk of underquoting. But it has a strange side effect: the better and faster you get at your craft, the less you earn per project, since you need fewer hours to deliver the same result. It also puts clients in the position of watching the clock instead of trusting the outcome.
Flat Fee Forces Real Scoping
A flat fee shifts the risk but forces discipline: you have to actually scope the project properly before quoting, because any gap in that scope comes out of your margin. Done well, this is the healthiest model for both sides — the client knows the exact cost upfront, and you're rewarded for efficiency instead of penalized for it.
Value-Based Pricing Needs a Track Record First
Pricing based on the value you create — a percentage of revenue lift, for example — sounds appealing but is genuinely hard to do credibly without a track record of similar results to point to. It's worth growing into once you have real case studies with real numbers behind them, not something to start with on your very first project.
Always Price the Unknown Separately
Whatever model you use, separate the known scope from anything uncertain — a redesign is usually well-scoped, but "we'll figure out the integration once we see their API" is not. Quote the known part as a flat fee, and handle the uncertain part as a change order or a capped hourly block, so neither side eats the risk of the unknown.
What We Actually Do
Most of our own projects are flat fee, scoped properly upfront after a real conversation about what's actually needed, with change orders for anything that comes up outside that scope. It's the model that's kept pricing arguments off almost every project we've run.
There's no universally "correct" model — but whichever one you pick, the project that goes wrong is almost always the one that was never properly scoped in the first place.