How to ask a developer for the cost of building my website?

Question

I want to hire a developer to build my custom website application (browser based), but I don't know how and what to ask to determine budget requirements. Is there a 'blueprint' or suggested method that developers use to communicate budgets with their clients or find useful to be provided with before determining the costs?

Answer 1

David Espina expressed it very pragmatically in his comment "Can you provide me a quote for this work?" The fancy name for that is a Request For Proposal.

That's a document that outlines the requirements of your project (in this case website) to help the vendor/developer understand what needs to be built. They can't offer you a cost for building your website if they don't understand what's needed.

So you need to think well about what you need. How many pages? How do they look like? Do you have some designs? The developer needs to make the designs also? Do you need a blog? Contact forms? Social media buttons? Is SEO important for you? Do you need friendly URls? Do you need a sitemap? Analytics? Once delivered do you want to manage the site on your own? Do you need an admin section? How do you want to be involved in the project (Agile or more of a hands off approach)? What kind of timeline you are expecting? How many deliveries? etc.

You then send this to the developer. The developer will ask further questions to clarify their understanding. Then the developer will provide a quote for the work.

I'm not saying you should spend your time to write a fancy Request For Proposal. For a one person website and one developer, you don't need something heavyweight like that. But do read a bit about Request For Proposals and look for some examples to figure out what you need to cover. If the developer you find is experienced, they will probe for details, if not, then you might start this project on the wrong foot and with gaps in requirements or understanding that later will be hard and expensive to fix.

One thing you should not mention though, is how much money you are willing to pay for this. Let the developer provide their price and see if it's something you can manage. If you mention your budget, then they might get focused on how to make you spend that money first, and worry about building your website second (really depends on how professional the developer is). On the other hand, if budget is an issue for you than maybe ask the question differently like "How much can you build from the requirements for X amount of money?"

As Sarov suggested, a more Agile approach with a time-and-materials contract will protect you from a bad developer and/or will allow you to get something functional until the money runs out.

Answer 2

Is there a 'blueprint' or suggested method that developers use to communicate budgets with their clients or find useful to be provided with before determining the costs?

I think this is the wrong question. I once heard a horror story about how another Department, fed up with the IT Department taking too long, decided to outsource a project. They came to an agreement, the 3rd-party did their work, handed over the software, then disappeared. Everything worked fine... for 1 year.

Then once year-end passed, it broke. The Department went to IT, asking them to fix it. Turns out, rather than include any actual logic for the values, the 3rd-party decided to simply calculate all the values by hand and then hard-code them based on date for a year. It technically did everything that had been asked for... but was entirely useless. The program was thrown in the garbage and IT had to write a new one from scratch.

Moral of the story? Do not completely rely on the developers to communicate properly when defining a budget with a separate party! Whether through incompetence or malice, you're opening yourself to huge risks.

Instead, you have two broad approaches:

1. Rigorously detail every last aspect and requirement of your project, and write up a fixed-cost contract. If you miss something, it'll be on you, so be thorough.
2. Go for a more agile approach with a time-and-materials contract. Ask the developers for what you'd like, then pay them a certain amount to work on it for a certain amount of time. Then inspect their progress and decide whether to pay them more for more time, pivot to change the requirements, stop there with what you have, or scrap the thing entirely.

Answer 3

Ask the developer to give the estimates based on the screen wise,

For example :

1. Login Page (Screen)

Ask the developer to give the estimate in the following fashion for the login page,

1. Total hours required to complete the HTML / CSS / Javascript - XX Hours
2. Total hours required to create functional Components such as Text box, Fields, and buttons in the login page - XX Hours.
3. Total hours required to complete the functional integration in login page - XX hours
4. Total hours required for release - XX hours Total hours required for testing - XX hours

-Other Costs

5. The total cost included for 3rd party services/plugins/tools - XX hours

So basically it's better to give the developer instructions to share the estimates based on the screen based on the Frontend tasks and backend tasks. if you could share the screens/requirements. could help you put the estimates.

Happy to help further. Reach me out if required.

Answer 4

Find a few candidates whose work and references you find relevant and attractive. Mail these candidates this very simple question: "How should I prepare a request for proposal? What do you need in it?". I believe they will be happy advising you in how to provide a sufficient initial description of your idea that they can work with.

As soon as you manage to gather this initial writeup they suggested, you can enter the next phase, the "website interview", where further requirements and clarifications are gathered in a dialogue format, quite possibly in (a series of) in-person (even if virtual) discussion(s).

Eventually, it is going to be the developers who translate the accumulated information into some form of a "to-do-list", the so-called "(development) backlog". You will be invited to participate in refining it further, throughout the entire process of development.

---

A few words about the general attitude:

The thing is, if you already know exactly what you want (or rather, you think you know), chances are, it will make things more difficult. :)

It's better to approach the thing as a negotiation:

I would like (something like) this, what do you think, perhaps comment on it. Does it make sense? Do you agree this is a reasonable choice to reach my goal with? Does building it like this cause you significant difficulty?

These people (given you are talking to a seasoned expert) might know much more about the field that you do currently. You shouldn't want to miss out on their expertise by one-sidedly dictating requirements from your potentially underinformed grounds. (It does not mean you have to submit to everything, or even anything, that they suggest. It's just a possibility, for when you get convinced that their suggestion makes sense.)

A healthy collaboration would go along the lines of you introducing your idea on a global scale, sprinkled with a few of those details that are important for you.

From that position, you could grant the team some leeway: let them fill in some of the (technical) gaps for you: they could suggest which underlying technology to choose (which might solve a bunch of requirements out of the box), and generally help you with suggestions on how to round up the project in a successful manner.

Pricing:

In agile projects/environments, I believe the closest you can get to a "pricing" is calculating with an hourly rate and the estimated time that's necessary to develop specific features.

Work will usually be organized into two-week bursts, the so-called "sprints". Before each sprint, developers will provide detailed complexity-estimates on a sufficient number of features (the complexity sometimes being expressed / quantified in so-called "story-points"); based on that, you can plan how many of those features will fit into the upcoming two-week-long sprint. Based on the hourly rate and the number of people participating, you can calculate how much a sprint costs you.

If the project is large enough to be streched out into several sprints, then after the second or third sprint you can start looking at how much complexity got resolved in each sprint. That is showing you the team's "velocity". From that you may try to make forecasts on how long it may take to implement a certain set of, or all the items in the backlog.

I can imagine a preliminary project-wide estimate happening too, which attempts to envelope all the features that are defined upon the project start. But be prepared that this initial estimate (especially in the case of larger projects) is not very refined and not very precise; it really is just a rough preview, which may even loose from its relevance as new decisions are made during development.

In this environment, to get the most out of your budget, you may, to a decent extent, re-prioritize the implementation of different features on the go, during development. (This can happen regularly before starting an upcoming "sprint".)

In a simplified representation of the matter (see more on this later), you can keep adding features as long as your budget lasts. Or, from the opposite point of view, when your budget runs out, you better be in a place where you had prioritized the right features, and your website is already usable and useful enough.

If your business idea was right and the website manages to supply a revenue in its present form, you will have new budgets for embellishing and enriching it further.

If this sounds strangely surprising initially, and you want something that promises to be more tangible, then you could look into the waterfall methodology. That's about upfront planning and may involve agreed-upon all-encompassing prices. But be informed: while it may have its place in some scenarios (very small projects, probably), it's often way more difficult to reach success with that methodology.

A word on overshooting estimates:

Let's say the development of specific features overshoots the estimates, and let's say you decide to be inflexible: you demand the described feature-set priced according to the anterior provided estimate.

In some cicumstances, it may indeed be the best course. But be informed: if you make a stable habit out of this, it backfires: to protect themselves from suffering significant losses (in the form of working hours not backed up by any payment), developers will be forced to take shortcuts and deliver subpar code quality.

Ending up as the owner of a weak quality codebase can cost you: it can impact the everyday stability of the product, it can manifest in higher vulnerability against hacks, and can hinder every further work on the codebase, rendering further development more costly.

(This is the effect that non-small waterfall projects — being unable to adhere to the too-early-established, insufficient, relevance-loosing estimates — can fall victim to so bad that the entire project implodes into a doomed agonizing mess.)

Encouraging the developers to be transparent about their challenges, and showing flexibility in decisions about overcoming difficulties may bring the best results, and enable you to be the owner of a product that you can rely on.

The issue of trust:

From the above, you can see that in a successful project, a lot of trust, mutual respect, and collaboration is involved.

In a way, in this situation you are exposed with some degree of vulnerablity. You are bringing your hard-earned savings into this project, and can only hope that the other side will deliver something for it that is not disappointing.

Even if you are ready on your part, you will need to find and pick a partner who is worthy of the trust and is respecting you.

You are looking for

• personal integrity
• professional competence (knowing what to do and how to do it right)
  • complemented with honest transparency in the areas where the competence wears thin
• professional integrity (choosing to do it right, even in aspects in which you couldn't provide a requirement)

You need to use the entire initial communication / specification phase to try to evaluate these properties of the candidates. Be on the lookout for clues that could allow insight to your candidates' character and working principles.

It may come as a surprise, but in this regard, there can be significant differences even between teams in the same company.

A word on informed budgeting:

Don't use up all your budget leading up to the day of the website going live.

Remember to set aside for the regular operating costs of the website, like yearly server subscription, and the cost of regularly applying security updates to the used frameworks and libraries.

Furthermore, as the site goes live, you will (hopefully) get a surge of user feedback: "this part is hard to understand, that part is glitchy". It's easily possible that a half, or even an entire additional sprint can be scheduled to address the issues that will be revealed by the website's first real users.