How many pages or screens
Each service page or app screen has to be designed, written and built. Ten pages is not twice the work of five, but it is not the same work either. Decide what must exist at launch and what can be added.
Cost
What Drives the Cost of a Website or App
There is no price list on this page because a list would have to be wrong for most people who read it. What is here instead is what moves the number, so that when you ask for a quote, from anyone, you know what it depends on and what a cheap one leaves out.
Why two quotes for "a website" can be so far apart
Because "a website" describes anything from one page with a phone number to a site with forty service pages, a booking system and a customer login. The quote you get reflects what the person quoting assumed you meant. Two quotes are only comparable when they are attached to the same written scope.
Most of the price of a site or app is people's time, and time is driven by a short list of factors. Here they are, roughly in order of how much they move the number.
The factors that move the price
How ready the content is
Words, photos, credentials, reviews. If they exist, the project moves. If the developer has to interview you and write every page, that is real work and should be in the scope, not discovered halfway.
Integrations
Payments, booking, a calendar, your accounting system, an existing database. Each is a separate piece of work with its own testing, and each usually carries a monthly fee from the service itself.
Logins and user accounts
The moment people sign in, the app needs a database, password handling, account recovery and rules about who sees what. This is the single biggest step up in cost and it is worth being sure you need it.
Platforms
A website reaches everyone. A web app reaches everyone with a link. Native iPhone and Android apps mean store accounts, review, and updates each year. Choose the platform by who uses it, not by what sounds impressive.
Custom design versus a system
A site built on a consistent design system looks finished and costs less than a bespoke layout for every page. Bespoke earns its price for a brand that sells on look; for most companies the system is the better spend.
The costs that continue after launch
The most common budgeting mistake is planning only for the build quote. Whatever you are quoted, ask for the monthly figure alongside it and who receives each part.
- Domain. Yearly, small, paid by you, in your account.
- Hosting. For a static site, very little. For an app with a database, more, and it scales with use.
- Third-party services. Maps, text messages, email sending, payments, booking. Each has its own bill.
- App store fees. If it is a native app, Apple and Google each charge a developer account fee.
- Keeping it working. Phones and browsers change. A static site barely notices; an app needs someone responsible for updates, at a stated cost.
What a cheap quote usually leaves out
- Writing the pages. "Content by client" in small print means the site sits empty until you write it.
- Testing on real phones, not just a laptop.
- The pages that earn search traffic: cost factors, not-a-fit, honest FAQs. The cheap site has a home page and a contact form.
- Ownership. The domain and hosting in the developer's name, with a monthly fee that is really rent.
- Anyone to call after launch.
How to get a real number
Send enough for a scope: what the company does, what the site or app has to do, roughly how many pages or screens, what it must connect to, whether anyone logs in, what content already exists, and when you need it. With that, a quote is a commitment. Without it, it is a guess, and the guess is the number that grows after the deposit.
Questions people ask
Why don't you just publish prices?
Because the honest price for a five-page site with content ready and the honest price for a site with a booking system and forty pages are not on the same page of a rate card, and a single number would mislead one of them. What this page publishes instead is what moves the price, so a quote from anyone can be read properly.
Is a fixed price or hourly better?
A fixed price attached to a written scope is easier to budget and puts the risk of underestimating on the developer. Hourly is fair for work that cannot be scoped yet, like taking over an unknown codebase. Whichever you are offered, ask what happens when something outside the scope comes up, and get the answer in writing.
Does a cheaper developer overseas make sense?
It can, for well-specified work with someone who communicates clearly. The risk is not the location; it is an unwritten scope and a time zone that turns every question into a day's delay. Judge the scope and the communication, then the rate.
What about the no-code tools that promise an app for a monthly fee?
For a simple internal tool they can be the right answer, and it is worth saying so. The trade-off is that the app lives inside someone else's product: the price can change, the features are theirs, and leaving means rebuilding. Fine for a small tool; risky for the thing your business runs on.
Tell us what the business needs it to do
A short message is enough to start: what the company does, what the website or app has to do for it, and when you need it. You will get a reply from a person.