One of the funniest and most painful questions in web development is:
“How much for a website?”
It sounds simple.
It is not.
Because “a website” can mean almost anything.
It could mean:
- a one-page landing page
- a five-page business website
- a custom CMS
- a quote request system
- a booking platform
- an ecommerce store
- a customer portal
- a dashboard
- a web app pretending to be “just a website”
And somehow, all of those conversations often start with the same question.
“How much?”
So I built a simple free website estimator.
Not because a calculator can perfectly quote a custom website.
It cannot.
I built it because most people asking for a website quote do not yet know what affects the price.
And honestly, that makes the first conversation harder than it needs to be.
The problem with quoting websites
When someone asks for a website price, the natural developer answer is:
“It depends.”
Which is true.
But also deeply annoying.
Nobody wants to hear “it depends” when they are trying to budget something.
The problem is that pricing depends on scope.
A basic website might need:
- a homepage
- an about page
- a services page
- a contact page
- a simple form
- mobile responsive styling
But then the “small website” slowly becomes:
- can I edit it myself?
- can it send automated emails?
- can users log in?
- can it calculate prices?
- can it connect to my CRM?
- can it take payments?
- can it have a dashboard?
- can it have booking logic?
- can it generate PDFs?
- can it also do my laundry?
Okay, maybe not the last one.
But you get the point.
The word “website” hides a lot of complexity.
Why I made the estimator
I run Rykon Digital, and I wanted a better way to help small businesses think about website scope before they contact me.
The estimator is not meant to be some magical instant quote machine.
It is more like a conversation starter.
The idea is simple:
- Show common website features.
- Let people choose what they think they need.
- Give them a rough estimate.
- Help them understand what affects the cost.
- Let them enquire with a clearer scope.
That is it.
You can try it here:
What the estimator teaches people
The useful part is not just the number.
The useful part is seeing the difference between features.
For example, these are not the same level of work:
- a static content page
- a CMS-editable page
- a contact form
- a quote request workflow
- a blog
- a custom calculator
- user accounts
- ecommerce
- a client dashboard
To someone outside web development, these can all feel like “just another feature”.
But from a development point of view, they are wildly different.
A contact form might be simple.
A multi-step quote flow with validation, spam protection, file uploads, admin storage, conditional emails, and follow-up automation is not the same thing.
That distinction matters.
I kept the pricing logic on the backend
One thing I wanted to avoid was dumping every price publicly into the frontend.
So the visible page is more about feature selection and education.
The actual estimate logic runs through the backend.
That gives me more control over how pricing rules are adjusted later, instead of hardcoding everything into JavaScript and letting the frontend become a tiny pricing graveyard.
The flow is roughly:
User selects features
↓
Frontend sends selected items
↓
Backend calculates rough estimate
↓
Result comes back in a modal
↓
User can submit an enquiry
Nothing crazy.
Just a cleaner way to separate the user experience from the actual pricing logic.
Why this is useful for clients
Most clients are not trying to be vague.
They just do not know what information matters yet.
A developer might care about:
- page count
- CMS requirements
- authentication
- hosting
- integrations
- forms
- content
- SEO
- permissions
- automation
- deployment
- maintenance
But a business owner might only be thinking:
“I need a website that looks good and gets enquiries.”
That is fair.
The estimator helps bridge that gap.
It gives people a way to think through their project before needing to explain everything perfectly.
Why this is useful for developers
It also helps from the developer side.
Instead of receiving an enquiry that says:
“Need website. Price?”
You get something closer to:
“I need a business website with service pages, a contact form, basic SEO, CMS editing, and maybe a blog.”
That is already a much better starting point.
It does not replace discovery.
But it makes discovery less painful.
And I am very pro less-painful-discovery.
The bigger lesson
The more I build for small businesses, the more I realise that good tooling does not always need to be complex.
Sometimes the best tool is just something that helps someone make a better decision.
This estimator is not trying to be revolutionary.
It is not AI-powered.
It is not a SaaS platform.
It is not “changing the future of web pricing forever”, thank goodness.
It is just a practical tool that answers a practical problem:
“I do not know what I need, but I want a rough idea before I ask for a quote.”
That is enough.
What I would improve next
There are a few things I might add later:
- better feature grouping
- optional maintenance estimates
- clearer package suggestions
- more detailed explanations for each feature
- saving estimates
- emailing the estimate to the user
- admin-side pricing controls
- better analytics on which features people select most
The last one is especially interesting.
Seeing what people select could help reveal what small businesses actually think they need when planning a website.
That could shape future service pages, pricing content, and FAQs.
Final thoughts
“How much for a website?” is not a bad question.
It is just a bad first question.
A better first question is:
“What does the website need to do?”
That one leads to a much better conversation.
That is why I built the estimator.
It gives people a simple way to think about scope before asking for a quote, and it gives me a better starting point when they do reach out.
You can test it here:
https://rykondigital.com.au/free-website-estimator/
Would love feedback, especially from other devs who have had to explain website pricing without saying “it depends” 400 times.
Top comments (0)