The Three Pricing Models (and Which Wins)
Six years ago I charged $15/hour for WordPress sites. Today I charge fixed project rates starting at $2,500 for basic sites and $8,000+ for SaaS MVPs. The revenue difference is not because I work faster (I do, but that is not the main factor) — it is because I changed my pricing model.
There are three pricing models in web development: hourly, daily rate, and fixed project price. Hourly billing feels safe because you always get paid for time worked. In practice, it caps your income, punishes efficiency, and creates adversarial client dynamics around every hour you log. Daily rate billing is better — more predictable — but still ties your income to time.
Fixed project pricing decouples your income from time. When you can estimate projects accurately (which comes with experience) and deliver them efficiently (which comes with a repeatable process), fixed pricing lets you earn $150-250/hour equivalent while charging clients a predictable, outcome-based price they can budget for. This is the model I use for all full-stack development projects.
Calculating Your Real Minimum Rate
Before you can price anything, you need to know your minimum viable rate — the hourly equivalent below which you cannot profitably operate. Most developers calculate this incorrectly and leave significant money on the table.
The correct calculation:
# Real minimum rate calculation
Annual target income: $60,000
Income tax (estimate 25%): +$20,000
Business expenses (tools, software, internet): +$5,000
Health insurance / benefits: +$5,000
----------------------------------------
Required gross revenue: $90,000
Billable hours per year:
52 weeks × 40 hours = 2,080 hours
Minus vacation (3 weeks) = -120 hours
Minus sick/admin time (20%) = -416 hours
----------------------------------------
Realistic billable hours: 1,544 hours
Minimum hourly rate: $90,000 / 1,544 = $58.30/hour
This is your floor. Anything below $58/hour (in this example) means you are not covering your costs and taxes. Most new freelancers use their target income as the numerator and 2,080 hours as the denominator — this underestimates the real rate by 30-40% before factoring in taxes.
In the Philippines context: if your target income is ₱1,200,000 per year ($20,000 USD at 60 PHP/USD), after taxes and business expenses your minimum rate is around $15-18/hour for local clients, or you price in USD for international clients where $40-80/hour is competitive and sustainable.
Value-Based Pricing in Practice
Value-based pricing sets your price relative to the value the client receives, not relative to your cost or time. It requires understanding what the project is worth to the client — which requires asking the right questions in discovery.
The key questions to ask during your discovery call:
"What does this project replace or enable for your business?" A $5,000 website that replaces $2,000/month in marketing spend pays for itself in 2.5 months. Price accordingly.
"What is the cost of not doing this?" If the client is losing customers to a competitor because their site is slow and ugly, the cost of inaction is ongoing revenue loss. The project value includes preventing that loss.
"What does success look like to you in 12 months?" The answer quantifies the outcome you are being hired to produce. A client who says "if this works, we should be booking 30% more jobs" is telling you the project is worth 30% of whatever revenue increase that represents.
Value pricing example: A client tells you their existing site generates 5 leads/month. They expect a redesign to triple that to 15 leads/month. Their average project value per lead is $3,000 and they close 30%. The 10 additional leads per month × 30% close rate × $3,000 = $9,000/month in additional revenue. A $12,000 website pays for itself in 6 weeks. Charging $4,000 for the same project is leaving money on the table.
Pricing by Project Type
| Project Type | Typical Range (USD) | What Drives Price |
|---|---|---|
| Basic WordPress site | $1,500–$4,000 | Number of pages, custom design vs. theme |
| WooCommerce store | $3,000–$8,000 | Product count, payment integrations, custom logic |
| Custom Next.js site | $4,000–$12,000 | CMS integration, animations, performance requirements |
| SaaS MVP | $8,000–$25,000 | Feature scope, auth complexity, Stripe integration |
| AI chatbot / RAG system | $5,000–$15,000 | Data complexity, integration points, custom training |
| Chrome extension | $3,000–$10,000 | Feature count, AI integration, Store submission |
| Monthly retainer | $800–$3,000/mo | Hours included, response time SLA, priority access |
These are not my exact rates — they are market ranges based on what quality developers charge. Where you sit in these ranges depends on your portfolio strength, client type (local vs. international), and your ability to articulate value during sales conversations.
Writing Proposals That Win
A proposal is a sales document, not a specification. Most developers write proposals that describe what they will build. Winning proposals describe the outcome the client will achieve.
The structure that works for me:
Understanding (1 paragraph): Restate the client's problem in their words. This shows you listened and helps them confirm you understood correctly. "Based on our conversation, your current website generates 5-10 leads per month but your target is 30+ to hit your growth goals."
Recommended solution (1-2 paragraphs): What you are building and why each element serves the client's goal. Not a feature list — a narrative about how the solution solves the problem.
Investment (clear, no hourly breakdown): One number with what it includes. Providing hourly breakdowns invites clients to negotiate individual line items. Present a fixed project price.
Timeline: Clear milestones with dates. Clients value predictability as much as quality.
What you need from them: What input, approvals, and access you need and when. This sets expectations and creates shared accountability.
Handling Scope Creep and Change Requests
Scope creep is the #1 profitability killer for fixed-price projects. The solution is not to avoid it — client needs change and that is legitimate — but to have a clear, comfortable change request process from day one.
In every proposal I include this paragraph: "This project is scoped for the features listed above. Any additional features or changes to the defined scope will be quoted as separate change requests before work begins. Small adjustments within the spirit of the agreed scope are handled as goodwill. Significant additions are change orders."
When a client requests something out of scope, the script is simple: "That is a great addition. It falls outside the current scope, so let me put together a brief change order for your review. It usually takes me [X hours] and would be [Y dollars]. Want me to proceed?" This script normalizes change orders without making them feel punitive. See more about how I structure client projects in my about page and contact me to discuss your project.