PriceProof.io - why should slow work pay more than fast work? {rate * time} formula isn't fair

Source: Dev.to

The Problem

Someone asked me to quote a project recently, and I realized I had no good way to do it.
The standard formula is rate × time, right? But that feels broken.

• If I’m experienced and finish the work in a week, I get paid less than a junior who drags it out for two months.
• The value delivered is the same, and my work might even be higher quality.

How do you explain that to a client? “Pay me more because I’m faster” sounds backwards.

What I Wanted

A way to show value beyond just hours. Factors that matter:

• Complexity of the task
• Experience level of the developer
• What’s actually being built (e.g., two “simple contact forms” can differ dramatically if one needs custom validation, anti‑spam, CRM integration, etc.)

I wanted pricing to be transparent about all these factors, not just “40 hours × $100”.

The Solution: priceproof.io

I built priceproof.io, a tool that generates detailed breakdowns of what goes into a project estimate.

• Input: features, complexity factors, timeline constraints.
• Output: a PDF that explains the reasoning, e.g.:
  • “This feature is complex because X”
  • “This integration takes longer because Y”
  • “Experience level affects quality here”

Technical Details

• Built with Next.js 14, hosted on Vercel.
• All client‑side PDF generation using react-pdf.
• The calculation engine is the open‑source rules engine fast‑decision: . It lets you define pricing rules cleanly without spaghetti code.

Current State

• The app works but is rough around the edges—functional enough to test the concept.
• You can try it at . It takes a few minutes to generate a sample breakdown.

What I’m Wondering

• Does this pricing approach make sense, or is the classic rate × time model actually fine?
• If you do project work, do you think showing complexity factors helps, or does it overcomplicate things?
• I’m trying to determine whether this is a real problem or just a personal annoyance.

Honest feedback appreciated—if the concept is flawed, I’d rather pivot now than build more on top of it.