Charging for your services as an agency or freelance web developer is challenging. How much should you charge, and what is the best pricing model?
If you charge too little, you leave money on the table and struggle to stay afloat. Charge too much, and you might price yourself out of work. So how do you find the right balance?
To help you find the right answer for you, we'll introduce the three main types of pricing: hourly, project-based, and modular. We'll detail how each structure works, its pros and cons, and how much you should charge for each. There are also a few things you need to consider when choosing your price, and we'll detail each so you can make informed decisions with your clients. We'll finish by discussing recurring revenue and other ways you can make your business succeed.
What are the pricing structures for charging for a website?
Three ways to charge
For website projects, you may bill clients in one of three ways: hourly, project-based, and modular.
Hourly billing is the most common way to bill clients. You charge for the number of hours you work on a project. This can be a good option for smaller projects, but it can be challenging to estimate how many hours a project will take, and it can be difficult to track your time accurately.
Project-based pricing is when you charge for a specific project, regardless of how many hours it takes to complete. This can be a good option for larger projects for which you can estimate the time it will take to complete. It can also be helpful for clients who want a fixed price for a project.
Modular pricing is when you charge for specific parts of a project rather than charging for the entire project or by the hour. This can be a good option for projects that are too large or complex to bill with other methods. It can also be helpful for clients who want more flexibility in how they pay for their projects. For websites, developers would typically charge by the page or by reusable website sections (Prismic calls these Slices).
Don't ship a website. Ship a headless website builder.
Prismic's headless website builder is a CMS that allows you to build a fully custom website and connect it to a customized website builder experience for content teams through our API. In your code, you'll create reusable website sections (A.K.A. Slices), which become building blocks in our editor.
Which pricing structure should I use?
There is no right answer for everyone, but there is probably a method that suits you or your clients best. Let's figure it out by learning the pros and cons of each method. We will compare hourly, project-based, and modular pricing.
Charging by the hour - pros and cons
You get paid for every hour of work 👍
With hourly billing, you'll never work unpaid overtime. If things take longer than expected, or you get pulled into meetings with the client, you bill it and get paid at your rate.
Scope changes are easy 👍
If your client needs to change the scope or an unexpected situation arises, you don't need to renegotiate the entire contract. As long as you have availability, you just continue to bill those hours.
Poor estimates create unhappy clients 👎
Charging by the hour can also be risky. If a project takes longer than expected, you might sour the relationship with the client when you try to explain why your original estimates were incorrect.
Clients can often see an estimate as a quote, and become unhappy when the real price differs.
Diligent time tracking 👎
Charging by the hour requires you to be always aware of the time you're spending on the project, and to be spending it well. This might be easy for very organized people, but others might struggle.
Efficiency is penalized 👎
Freelance web developers who bill by the hour are not rewarded for being more efficient. If they finish a project more quickly than expected and charge fewer hours, they might make their client happy, but they lose out on money.
Time-saving tools like boilerplates, which allow you to focus on the parts of coding you enjoy, also mean you’ll work and be paid for fewer hours. You might say developers who bill hourly should just raise their rates as they become better at their craft (and thus more efficient), but that comes with a problem, too.
Raising rates is difficult 👎
It can be difficult for freelance web developers to raise their rates when they're billing by the hour. When clients hear your hourly rate, they compare it to other professions and hourly rates that they are familiar with. Going from $80 to $90 an hour might make a client hesitate while saying their new project will cost $1000 more wouldn't have the same effect.
Project-based pricing - pros and cons
Easy budgeting for clients 👍
The main advantage of billing by the project is that it's easier for clients to budget for their projects. They know how much the project will cost upfront, and there are no surprises for them if it takes longer than expected.
Raising your rates is easy 👍
Unlike hourly rates, clients may not have a clear expectation of how much a website should cost as a total sum. As you develop your skills and your network, you should raise your rates to match your demand. This is much easier when you're charging for the entire project. Project-based pricing has a much higher ceiling than hourly rates for this reason.
Efficiency is rewarded 👍
Freelance web developers who use a project-based or modular pricing system are rewarded for being more efficient with their time. As they become more efficient, they can charge the same for less time spent.
If you can work twice as fast but charge the same, you've doubled your income. Plus your client will be thrilled to get their site quicker.
You can use a hybrid model 👍
It's common for developers to use project-based pricing with hourly rates. You might say a website is $10,000, and detail everything that it includes. In the contract, you can mention that additional work will be billed at a rate of $100 an hour. This reassures the client that they won't be stuck with a site they can't change before launch. It also ensures you're getting paid for the extra work.
Bad estimates can cost you 👎
Billing by the project can be risky for freelancers. If you estimate the job at 20 hours, and it takes 40, it can create all kinds of problems for your finances and your business. It means you're getting paid for half your desired rate, and it has the chance of delaying your next project, and potentially losing you more business.
Unclear contracts lead to conflict 👎
If your contract is not explicit about everything that is and is not included in the price tag, conflicts can arise. The client might assume they can have daily Zoom calls or unlimited revisions. You need to be explicit or the relationship can quickly turn sour.
Modular pricing - pros and cons
Clients like à la carte 👍
With modular pricing, clients get to choose the number of either pages or page sections they're getting. Clients typically appreciate this 'order off the menu' approach, where they can purchase the exact pieces they need and nothing they don't.
Clients get a better deal 👍
If clients are paying for page sections, they get a better deal than if they're paying per page. Because reusable page sections (like Prismic's Slices) can be used to build an unlimited number of pages, it's far better than paying per page.
If a client needed hundreds of pages created, other pricing models could be prohibitively expensive. With a system like Slices, they get a custom website builder experience, and each Slice is a building block. They can combine their custom-built Slices to make endless page combinations.
Follow-up work is simple 👍
When you start thinking about websites as being made up of smaller parts, you no longer think of updates as big sweeping changes. You don't need to replace the entire website or even an entire page. You can just edit the way existing page sections look or ship new sections to the editors.
Complexity complicates things 👎
Every client, website, page, and page section are unique. If you're charging by the page section, some will be very straightforward, while others might require complicated API calls and animations. One might take an hour, while another could take a day. If you don't account for this in your pricing of each modular piece, a complex project could take much longer than you estimated and billed for.
Having multiple tiers of complexity can help alleviate this burden. Make it clear that basic animations and styles are the base rate, while more complex visuals or logic are charged at a higher rate.
How much should I charge for a website?
The range of hourly rates for freelance web developers varies depending on a number of factors, including:
- the developer's experience
- the project's complexity
- the client's location
Generally, web developers in the United States tend to charge more than in other countries. For example, a freelance web developer in the United States may charge $100-$200 per hour, while one in India may charge only $10-$30 per hour.
However, it's important to remember that these are just general guidelines and that each developer should consider their unique situation when setting their rates.
A freelance web developer may charge $1,000 for a small website project and $10,000 or more for a larger website project. In determining project-based rates, you’ll still need to calculate and estimate the number of hours a project will take you in order to ensure that you’re charging a sufficient amount overall.
Both hourly and project-based are good but have their downsides. We recommend a different pricing model that combines the benefits of both.
There are a couple of rates you will need to come up with to define your modular rate. Here I'm providing you some general starting points.
- How much does the essential setup of the website cost?
- How long will it take to hand the website off to and train the client to use their website?
- What ongoing maintenance should you charge for and propose in your rate?
- What is your price per module (this could be per page or per Slice)? And how are you structuring these prices to account for varying degrees of complexity?
Setup covers setting up the framework, CMS, domain, hosting, and other aspects that need to happen with any site. If you're building on the Jamstack these should be relatively quick to get off the ground.
Client handoff might include sending documents that you reuse for each client, as well as creating resources that are specific to a project. This might be Loom videos or other forms of walkthroughs.
In your contract, detail what maintenance is and what it is not. Maintenance is not upgrades or new features. This covers issues with infrastructure and other routine tasks. If you're building on the Jamstack and using a hosted CMS like Prismic, these tasks are rare.
With Setup, client handoff, and maintenance you might have a base price somewhere in the $1,200 range. On top of that, you’ll need to charge for the individual modules or page sections.
For example, with Prismic’s headless website builder, when you're charging by the reusable page section, you aren't the one creating all the pages the end user will browse. Your client is able to use your page sections to build unlimited pages. The only difference between a small site and a large one is the number of pages the client generates with the components you deliver.
So you might charge $400 for a simple page section, including design and development. And then you might set additional pricing tiers for more complex sections (like a section that allows visitors to leave reviews on the site).
Rather than charging for individual page sections, I recommend packages where clients get packs of 5, 8, or 12 Slices. You can recommend the most common types of page sections (heroes, testimonials, logo grids) to make decisions easy for the client.
Things to consider when setting prices
No matter which pricing method you use, it's important to estimate how much time the project will take. This can be difficult, especially if you're not familiar with the project requirements. However, by breaking down the project into smaller tasks and estimating how long each one will take, you can get a better idea of how long the entire project will take.
Another thing to consider is how familiar you are with the technology involved. If you're not familiar with a certain technology, you may need to spend more time learning about it. Similarly, if a project involves a lot of coding or complex design work, it will likely take longer to complete than a project that involves less coding.
When estimating how long a project will take, it's important to add padding to your time estimates. This means multiplying your estimate by 1.5-2x to allow for unexpected problems, delays, or over-optimistic estimates. By adding padding to your estimates, you can ensure that you don't end up losing money on a project.
Unexpected problems or delays can happen for various reasons, such as changes in client requirements, unexpected bugs, or difficulty coordinating with other team members. By adding padding to your time estimates, you can account for these potential problems and avoid losing money on a project.
In addition to estimating how much time a project will take, you'll also need to factor in how much your materials cost and how much profit you want to make. Material costs can include things like domain names, hosting, and service subscriptions. You'll also need to consider how much your time is worth and add a profit margin that you're comfortable with.
A modular pricing system can make it easier to charge for your work. When you charge by the page section you can break down your projects into smaller units, each of which has its own price tag. This makes it easier to charge for different aspects of a project, such as the design work, coding work, or hosting and domain costs.
Complexity is one of the main factors that freelance web developers consider when pricing their services. The more complex a project or website section is, the more time it will take to complete. You'll want to assess this upfront. Some freelancers structure their packages to allow for a certain number of simple and complex Slices. If a Slice requires complicated animations or logic, you can consider that a complex Slice.
Friends and family discount
Generally speaking, you should always charge for your services. However, you'll probably offer a lower rate for friends, family, or non-profits.
Whoever the client, it's important to communicate what the discount provides. Will they get a lower rate for all services or just a few free Slices? Will you knock off some hours from the total project time, or is it free entirely?
Be specific in your contract and make sure both you and the client are clear on what you're offering.
Would landing this client open doors for you in the some way? For example, if you want to build sites for the sporting goods industry, it will be easier if you have experience in that market, so landing your first client could be an entry point.
If this is the case, you might want to lower your rates to land the client. Just don't price yourself too low, or you'll go out of business before you can get those future clients.
Recurring revenue is an important factor to consider building into your business. Essentially, it’s revenue that you generate from clients on a recurring basis through something like a maintenance subscription, retainer, etc. It creates stability for your business because it’s often based on a long-term contract.
One of the most intriguing aspects of Modular Pricing is getting clients on a recurring revenue model. Once you've delivered their headless website builder through a service like Prismic, they will quickly see how powerful Slices are for building out page after page. They will want more Slices to give them more options so that their pages all look unique and exciting.
You can sign multiple clients to a pricing model where you deliver a "Slice of the Month" to all clients at a reduced cost. You can create a general Slice type each month, like a Hero or CTA, and then customize it to match each client's brand. You deliver it and collect your monthly fee. This pricing model creates a constant revenue stream so that you're not always in feast or famine, as is the life of many freelancers.
You can also have a recurring model where clients can request specific Slices each month, but this should cost more because you're crafting them specifically to their needs.
If you need inspiration for Slice types, check out packages like Tailwind UI for inspiration.
How can you explain the benefits of modular pricing to clients?
Clients who work with a developer on a project-based or hourly rate may never be quite sure what they're getting. There's always the chance that the developer will run into unforeseen problems or the project will take longer than expected. This can lead to unhappy clients and financial problems for the developer.
With modular pricing, clients know exactly what they're getting. They know how many Slices they need and choose exactly the Slices they want. If they need more meetings or changes, they can purchase additional Slice Packages at any time. This makes it easy for them to budget for their project and prevents any surprises along the way.
A better deal for the client
Most clients are happy to pay a one-time fee for a website rather than paying by the page. However, hourly rates can quickly run up a large bill.
Reusable page sections allow clients to create an unlimited number of pages for their website without incurring any additional charges. This makes it more affordable and convenient than paying by the page.
When it comes to website updates, most clients want the convenience of having new features and content added without having to go through a big rebuild. This is where Slices come in.
With modular pricing, clients can purchase new Slices at any time. This means that they can add new features and types of content to their website without having to go through a big rebuild. This makes website updates easy and convenient for the client.
It also helps the developer because they don't have to spend time on big rebuilds. They can simply work on new Slices and add them to the existing site. This makes website updates faster and easier for everyone involved.