Pricing work
"How we price projects on complexity and value instead of hourly estimates."
Why this exists
Hourly billing rewards slow work and pits our incentives against the client's. We bill fixed-scope packages or flat weekly sprints. The client gets cost certainty, and we get rewarded for shipping fast.
Operational Flow
Determine project value: Find the scale of the client's business problem to set a value baseline.
Calculate base cost: Estimate the engineering weeks needed to deliver the scope.
Add a risk premium: Price legacy integrations, messy API docs, or strict compliance higher.
Structure milestone payments: Invoice a 50% deposit upfront and tie the rest to deliverables.
Standardize weekly pricing: Bill open-ended sprints at a flat $12,000 per week.
What good looks like
- Delivering a $30,000 project in two weeks because we reused our own libraries.
- The client pays the deposit without negotiating because they want a fixed price.
- Pricing legacy systems higher upfront to protect our margins from integration delays.
What NOT to do
- Don't give hourly estimates. Offer weekly sprint rates instead.
- Don't drop the price in negotiations without cutting scope.
- Don't write a line of code before the 50% deposit clears.
We spent our first year logging fifteen-minute blocks on Toggl and arguing over whether a database refactor should take four hours or six. It was a miserable way to work. We realized hourly billing penalized our efficiency. If we fixed in ten minutes a bug that took others three days, we made less money. That is why we switched to value-based and flat weekly pricing.
Price the problem, not the hours. When you charge for the solution, the client gets certainty and you get the space to build it right. If they want to buy hands by the hour, send them elsewhere.