Dynamic website quotes vary wildly for the same brief, almost always because the brief left the expensive decisions unmade. Settling six things before you ask for a quote makes the numbers comparable and the project predictable.
1. Who edits the content, and how often
The single most consequential decision. Content changing weekly by non-technical staff needs a genuine content management interface. Content changing twice a year can be a developer task.
This determines the architecture, so decide it first — not after the build, when it becomes a change request.
2. Off-the-shelf CMS or custom build
An established CMS gives you a mature editing interface, a plugin ecosystem, and a large pool of people who can maintain it. In exchange you accept its conventions and its update cycle.
A custom application fits exactly what you need with no unused surface, and ties you to whoever built it unless the code is clean and documented.
For most business sites the CMS is the right answer, and the reason is maintainability by people other than the original developer. Custom makes sense when the site is genuinely an application rather than pages.
3. What is dynamic, specifically
"Dynamic" covers a range. Be precise about which of these you need, because each changes cost:
- Content edited through an interface
- A searchable, filterable catalogue
- User accounts and logins
- Transactions and payments
- Content differing per visitor
- Integration with another system — CRM, ERP, inventory
A site with the first and a contact form is a modest project. Add accounts and payments and it is a different undertaking.
4. Integrations, named
List every system the site must talk to and in which direction. "Integrate with our ERP" is not a specification — does the site read stock levels, write orders, both? In real time or on a schedule? Does the ERP have an API, and have you confirmed it?
Unspecified integrations are the most common source of overrun, because the difficulty is entirely in the details nobody asked about.
5. Hosting, decided before the build
Dynamic sites need more than static ones: a runtime, a database, and somewhere to run scheduled tasks. The architecture assumes a hosting environment, so decide it early rather than discovering at launch that the chosen platform does not support what was built.
Agree also who is responsible for the server after launch. This is frequently left ambiguous and surfaces during the first security incident.
6. Ownership, in writing
- Who owns the code on completion
- Who owns the design files
- Who holds the domain — it should be you, in your company's name
- Who has the hosting and CMS administrator credentials
- What happens to any third-party licences if you change developer
Settle these before work starts. Afterwards they become a negotiation, usually at an inconvenient moment.
What a comparable quote contains
- Number of distinct templates, and number of pages
- Who supplies content, stated explicitly
- Named integrations with the direction of data flow
- Included revision rounds
- Browser and device support
- Post-launch support period and what it covers
- Hosting arrangement and who administers it
- Ownership terms
Ask every bidder for this structure. Quotes become comparable, and vendors who have thought the project through become obvious.
Before sign-off
Have whoever will maintain the content add a page, edit a page and upload an image — unaided, in front of you. If they cannot, you have bought a site you will be paying someone else to update for its entire life.
About the author. Kislay Chandan has worked with schools since 2014. Rather than gathering requirements from the outside, he worked inside a school to see what actually goes wrong day to day, and built what he found into the software. He still works with Shemrock Glitters in Patna — most changes to the product start with something that came up there.
Gallery
