Web development is bought as a deliverable and experienced as a relationship. The terms that determine whether that relationship goes well are agreed — or not agreed — before any code is written.
Ownership, unambiguously
- Full source code on completion, in a repository you control
- Design files, not just exported images
- The domain registered in your company's name, with you holding the account
- Administrator credentials for hosting and the CMS
- Clarity on any third-party licence and whether it transfers
These are ordinary asks. Resistance to any of them is informative, and it is far easier to settle now than when you want to change developer.
A staging environment, used
Changes reviewed somewhere before production, always. This should be part of the engagement rather than something you ask for later.
It also changes the review conversation: you see the real thing in a browser rather than approving a static image, and the gap between "the design looked fine" and "the site feels wrong" closes before launch.
Performance agreed as a target
Set a number before the build starts — a load time on a mobile connection for key pages — and make it an acceptance criterion.
Without this, performance is nobody's responsibility and is discovered after launch, when fixing it means revisiting decisions already made. Images, fonts and third-party scripts all get chosen differently when there is a budget to meet.
Accessibility as a requirement
Keyboard navigation, sufficient colour contrast, alternative text on images, labelled form fields, sensible heading structure.
This is not only about users with disabilities, though that is reason enough. The same structure that makes a site usable with a screen reader makes it comprehensible to search engines and AI systems, which read structure rather than appearance.
Retrofitting accessibility is expensive. Building it in costs almost nothing.
Content, decided explicitly
Who writes the text and sources the images? This is the most common cause of a project stalling — the build finishes and waits months for content.
If content is yours, agree a delivery date as part of the schedule. If it is the developer's, agree how many rounds of revision.
Search fundamentals, included
- Unique title and meta description per page, editable by you
- Clean URLs
- A sitemap and correct robots directives
- Structured data for your organisation and content
- Self-referencing canonical tags on every page
- Redirects from old URLs if this replaces an existing site
The last two cause the most damage when missed. A new site canonicalising every page to the homepage removes itself from search results, and a rebuild without redirects discards whatever ranking the old site had.
Handover that leaves you able to operate
- Documentation of how to update content
- A training session for whoever will maintain it — with them doing it, not watching
- A list of every third-party service and who holds each account
- A defined support period with what it covers and what happens after
Before sign-off, have your own person add a page and edit an image unaided. If they cannot, the handover is not complete regardless of what the documentation says.
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
