How to Price Software Development Services: What I've Learned

TL;DR

Software development pricing is the thing most developers get wrong for years before they figure it out — myself included. I spent my first year charging hourly, underpricing projects, and attracting clients who treated me like a commodity. Now I price projects between $8,000 and $80,000 depending on scope and business impact, with retainers starting at $5,000 per month. I am based in Sri Lanka, I serve clients in the UK, US, and EU, and I do not compete on being cheap. This article breaks down my exact pricing structure, how I calculate project prices, what happens on the discovery call, when I walk away from a budget, and how I think about pricing as a developer from a developing country. If you are a developer trying to figure out your rates, or a client trying to understand what good development actually costs, this is the most honest breakdown I can give you.

Stop Charging Hourly

The single biggest pricing mistake I made was charging by the hour. I did it for almost a year. It felt safe — you track your time, you send an invoice, the math is simple. But hourly billing has a fundamental problem: it punishes you for being good at your job.

When I started out, a feature that took me 20 hours to build might take someone else 60 hours. As I got faster, my effective rate went down. I was literally earning less money as I became more skilled. That is broken incentive design.

Hourly billing also creates a trust problem. Clients wonder if you are padding hours. You wonder if you should track the 15 minutes you spent thinking about their architecture in the shower. The whole relationship becomes about time surveillance instead of outcomes.

Here is what I learned: clients do not care how many hours you spend. They care about what they get. A startup founder does not want to buy 200 hours of development. They want a working product that can acquire users and raise funding. Those are two completely different things to sell.

I switched to project-based pricing in early 2023 and my revenue doubled within four months. Not because I was working more — I was actually working less. But I was pricing based on the value of the outcome, not the cost of my time.

The only scenario where hourly still makes sense is genuine consulting — when a client needs a few hours of my time to review their architecture, audit their codebase, or help them make a technical decision. For that, my rate is $150 per hour with a two-hour minimum. But for building anything, hourly is off the table.

Value-Based Pricing for Developers

Value-based pricing means your fee is proportional to the value the client receives, not the cost of your labor. This is not a new idea — lawyers, consultants, and designers have been doing it for decades. Software developers are just slow to catch on.

Here is a real example. A client came to me wanting a custom dashboard that would replace three separate tools their team was using. They were paying $2,400 per month for those tools across 15 seats. Over two years, that is $57,600. My price for building and deploying a custom solution: $35,000. The math sold itself. They were saving money from month fifteen onward, and they owned the tool outright.

Another example. A startup needed an MVP to raise their seed round. They were targeting a $1.5M raise. My fee for building the MVP and the pitch demo: $12,000. In the context of a $1.5M raise, that is a rounding error. They closed the round, by the way.

The formula I use is simple:

Project Price = (Client's Expected Value) x (10-20%)

If a project will generate $100,000 in value over the first year — through revenue, cost savings, or fundraising — a $10,000 to $20,000 fee is reasonable. If it will generate $500,000 in value, a $50,000 to $80,000 fee is reasonable. The client should always feel like they are getting a return that far exceeds their investment.

This only works if you can have honest conversations about business outcomes during the discovery call. If a client cannot articulate the value they expect from the project, that is a red flag — either they do not understand their own business well enough, or the project does not have clear ROI. Both are reasons to proceed carefully.

My Pricing Structure — Full Transparency

I am going to share my actual pricing tiers because I think the industry needs more transparency and less "contact us for a quote" mystery. Here is how it breaks down as of 2024:

Tier 1: Focused Build ($8,000 - $15,000)

Single-feature products. Landing pages with complex functionality. MVPs with one core workflow. Internal tools. Typical timeline: 1-3 weeks. This is where most startup clients land. You get clean architecture, responsive design, deployment, and a product that works.

Tier 2: Full Product ($15,000 - $40,000)

Multi-feature applications. SaaS platforms. E-commerce with custom logic. Marketplace MVPs. Typical timeline: 4-8 weeks. This includes authentication, database design, admin panels, integrations, and production-grade infrastructure. Most of my project work falls here.

Tier 3: Complex Systems ($40,000 - $80,000)

Enterprise applications. Platforms with real-time features. Web3 dApps with smart contracts. Multi-tenant SaaS. Typical timeline: 2-4 months. These projects involve architectural decisions that will live for years, so the code quality standard is non-negotiable.

Consulting: $150/hour (2-hour minimum)

Architecture reviews, code audits, technical due diligence, CTO-as-a-service sessions. This is advisory, not building.

Every project includes a fixed price agreed before work starts, a clear scope document, and milestone-based payments. No surprises. No change orders that silently inflate the budget. If scope changes — and it often does — we renegotiate openly before I write a single additional line of code.

How I Calculate Project Prices

I do not pull numbers out of thin air. Here is the actual process I go through for every project:

Step 1: Scope the work. Break the project into features. Break each feature into tasks. Estimate effort for each task. I use t-shirt sizing — Small (1-2 days), Medium (3-5 days), Large (1-2 weeks) — because precise hour estimates on creative work are theater.

Step 2: Calculate base cost. Total the estimated days and multiply by my internal day rate. This gives me a floor — the minimum I need to charge for the project to make financial sense.

Step 3: Assess value to client. What will this project be worth to them? How much revenue will it generate? How much will it save? What is the cost of not building it? This is the ceiling.

Step 4: Price between floor and ceiling. The final price lands somewhere between cost and value. Early in a client relationship, I price closer to the floor to build trust. For repeat clients where I have proven ROI, I price closer to the ceiling. For projects with massive upside potential, I sometimes propose a lower base price plus a success fee or equity component.

Step 5: Add the complexity multiplier. Some projects look simple but have hidden complexity — third-party API integrations with poor documentation, legacy system migrations, real-time requirements, regulatory compliance. I add 15-30% for projects with significant unknowns. Clients appreciate the honesty when I explain why.

Here is a concrete example. A UK-based fintech client needed a customer portal with Stripe billing, role-based access, and a reporting dashboard. Scope estimate: 35 developer-days. Base cost at my internal rate: roughly $17,500. Client value assessment: they were replacing a manual process that cost them $8,000 per month in staff time. Annual value: $96,000. My price: $28,000. That is 29% of first-year value — well within the range. The client said yes in under 24 hours.

The Discovery Call That Sets the Price

Every project starts with a discovery call. This is not a sales pitch. It is the most important meeting in the entire engagement because it determines whether we should work together and what the project should cost.

My discovery call has a structure:

First 10 minutes — Listen. The client describes what they want. I take notes. I do not interrupt. I do not start solutioning. Most developers jump straight into "here is how I would build this" and miss the actual problem the client is trying to solve.

Next 15 minutes — Ask questions. Not technical questions. Business questions. Who are your users? What do they do today without this product? How will you measure success? What happens if we do not build this? What is your timeline driven by — a funding round, a contract deadline, a competitive threat? These answers determine the price more than any technical spec.

Next 10 minutes — Technical assessment. Now I ask about integrations, data sources, user volumes, compliance requirements. This is where I identify complexity multipliers.

Last 10 minutes — Set expectations. I give a ballpark range on the call — not a final price, but a range so the client knows immediately if we are in the same universe. "Based on what you have described, I would estimate this falls in the $20,000 to $30,000 range. I will put together a detailed proposal within 48 hours." If their budget is $5,000, we both save time by knowing that now.

I send a formal proposal within two business days. The proposal includes: project overview, scope breakdown, timeline with milestones, fixed price, payment schedule, what is included, what is explicitly excluded, and assumptions. The exclusions list is just as important as the inclusions — it prevents scope creep before it starts.

When to Say No to a Budget

This took me two years to learn: not every client is your client. Some projects are wrong for you, and the fastest way to identify them is through budget.

I say no to a budget when:

The budget is below my floor. If someone needs a $40,000 product but has a $5,000 budget, I cannot help them. I used to try — I would cut scope, reduce quality, work faster. Every single time it ended badly. The client was unhappy because they wanted the $40,000 product. I was unhappy because I was doing $40,000 of thinking for $5,000 of pay.

The client is price-shopping. "We have quotes from three other developers in India at $3,000. Can you match that?" No. I cannot and I will not. If price is the primary decision criterion, we are not a fit. I am not the cheapest option and I never will be. I am the option that ships a product that actually works and scales.

The ROI does not justify the build. Sometimes a client wants to spend $25,000 on a project that will generate $30,000 in value. The math does not work. I tell them. I would rather lose a project than have a client who regrets the investment. Referrals come from clients who got 5x to 10x return, not clients who barely broke even.

The scope is undefined. "We need an app. How much?" is not a brief. If a client cannot describe what they want clearly enough for me to price it, we are not ready for a proposal. We are ready for a paid discovery session.

I turn down roughly 40% of inbound inquiries. That number used to bother me. Now I know it means my positioning is working — I am attracting enough leads that I can be selective, and the clients I do take on get my full attention and best work.

Pricing from a Developing Country — The Real Talk

I am based in Sri Lanka. My cost of living is a fraction of what it costs to live in London or San Francisco. And yes, that means I could charge $15 per hour and still live comfortably. A lot of developers in my position do exactly that. I think it is a mistake.

Here is why. When you price based on your cost of living instead of the value you deliver, you are telling the market that your work is worth less because of where you were born. That is not a pricing strategy — it is a race to the bottom that devalues every developer in your country.

My clients are in the UK, the US, Germany, Australia, and the UAE. They are not hiring me because I am cheap. They are hiring me because I build production-grade products with clean architecture, I communicate clearly, I deliver on time, and the end result is indistinguishable from what a top London agency would produce — often better, because I am a single senior engineer who owns every line of code, not a rotating team of juniors managed by a project manager who has never written a line of code.

That said, I am not pretending geography does not matter. It does. A US-based developer with identical skills and experience would likely charge more than I do, simply because the market expects it. I price at the lower end of what a US/UK-based senior developer would charge, which means clients get exceptional value and I earn well above the local market rate. It is a genuine win-win, not a race to the bottom.

The advice I give to every developer in Sri Lanka, India, Pakistan, Nigeria, or any other developing country: stop anchoring your price to your location. Anchor it to your output. If you build software that generates $200,000 in revenue for a client, a $30,000 fee is a bargain regardless of whether you live in Colombo or Copenhagen.

Build a portfolio that proves your quality. Write content that demonstrates your thinking. Price for the value you create, not the rent you pay. The clients who understand this are the ones worth working with.

Retainer Pricing

Not every client relationship is project-based. Some of my best clients are on monthly retainers, and this model works incredibly well for both sides once the first project is complete.

My retainers start at $5,000 per month. Here is what a typical retainer includes:

$5,000/month — Maintenance and Growth. Up to 40 hours of development per month. Bug fixes, feature additions, performance optimization, security updates. Priority response within 4 hours during business days. Monthly progress report. This is ideal for startups that shipped their MVP with me and need ongoing iteration.

$8,000-$12,000/month — Fractional CTO. Everything in the lower tier plus architecture decisions, technical strategy, code reviews, hiring support, and vendor evaluation. I join standups 2-3 times per week. This is for startups that need senior technical leadership but cannot justify a full-time CTO salary.

Retainers work because they align incentives. I want the product to succeed because my revenue depends on the client staying in business and growing. The client gets consistent access to someone who knows their codebase deeply instead of onboarding a new freelancer every quarter.

The minimum retainer commitment is three months. I have clients who have been on retainer for over a year. The longest relationships are always the most productive because I understand the business deeply enough to make technical decisions autonomously.

I do not do retainers without a completed project first. The first project is where we learn if we work well together. If the communication is smooth, the expectations are aligned, and the output is strong, the retainer conversation happens naturally.

Price Anchoring and Proposals

How you present your price matters almost as much as the price itself. I learned this the hard way — I used to send a single number in an email and wonder why clients ghosted me. Now I use a structured proposal with deliberate price anchoring.

Every proposal includes three options:

Option A — The Full Vision. This is the comprehensive build — everything the client described plus the things they did not think of but should have. This is the highest price and it anchors the conversation. If the client wants a dashboard, Option A includes the dashboard, an admin panel, API integrations, automated reports, a mobile-responsive design, and premium support for 90 days post-launch.

Option B — The Recommended Build. This is what I actually think they should build. It covers the core requirements with smart trade-offs. 80% of clients pick this option. It is the sweet spot between ambition and pragmatism.

Option C — The Essentials. The stripped-down version. Core functionality only. No bells, no whistles. This exists to make Option B look like a great deal — because it is.

Here is the psychology: if I send a single price of $25,000, the client's only mental comparison is "$25,000 versus $0." That feels expensive. But if I present Option A at $45,000, Option B at $25,000, and Option C at $14,000, suddenly $25,000 feels reasonable. The client is comparing my options against each other, not against doing nothing.

I also include a timeline for each option. Speed matters to most clients, and seeing that Option C ships in two weeks while Option A ships in eight weeks helps them make a decision that accounts for time-to-market, not just budget.

One more thing: I never negotiate on price. I negotiate on scope. If a client says "I love Option B but my budget is $18,000," I do not drop my price. I adjust the scope until it fits $18,000 while still delivering a coherent, valuable product. This protects my rates and gives the client a clear understanding of what their budget buys.

Key Takeaways

• Stop charging hourly. It punishes efficiency and creates trust issues. Price by project or retainer.
• Price based on value, not time. Your fee should be 10-20% of the value the client expects to receive.
• Be transparent about your structure. Publish your ranges. Clients respect clarity over mystery.
• Discovery calls determine price. Ask business questions, not just technical ones. The ROI conversation sets the budget.
• Say no to bad budgets. Turning down 40% of inquiries means your positioning is working.
• Do not compete on geography. Anchor your price to your output, not your location.
• Retainers build long-term relationships. Start at $5K/month after a successful first project.
• Three-option proposals close deals. Price anchoring works. Never send a single number.
• Never negotiate on price — negotiate on scope. Protect your rates. Adjust deliverables to fit budgets.

*I am Uvin Vindula↗, a full-stack and Web3 engineer based in Sri Lanka, building production-grade software for clients across the UK, US, and EU. If you have a project that needs senior-level development — or if you are a developer who wants to talk pricing strategy — check out my services or get in touch.*