Methodology
What working with us actually involves, stage by stage — including the parts most process pages leave out.
Who this is for
Anyone about to commission work and wanting to know what they are agreeing to before they agree to it.
Understand before scoping
What the site or system has to achieve, for whom, and how you will judge whether it worked. This stage is short, and skipping it is how projects end up delivering something impressive that nobody needed.
We would rather ask uncomfortable questions here than discover the answers halfway through.
Scope in writing
What is included, what is not, what it costs and roughly how long. Written down, before work starts.
Explicitly listing what is not included is the part most suppliers skip, and it is the part that prevents the argument later. Our service pages carry the same exclusions publicly, for the same reason.
Build with review points
Not one reveal at the end. Review points exist so that a misunderstanding is caught while it is cheap, because the cost of a wrong assumption grows with every week it survives.
Accessibility and performance are considered while building rather than audited afterwards. Retrofitting either costs more than doing it once.
Test against the requirement
Against what was agreed at scoping — not against whether it looks finished. If the site replaces an existing one, that includes checking every old address still resolves, because search rankings and inbound links attach to addresses.
Hand over properly
Training, and a written record of what was installed, why, and what needs periodic attention.
The test of a handover is whether you could take the site to another supplier and they would understand what they had. If the answer is no, we have made you dependent rather than served you.
Afterwards
Sites are software: they need updates, patches and occasional fixes. That is maintenance, and it is a separate arrangement rather than something assumed.
When something goes wrong
It sometimes does. Our commitment is that you hear about it from us, when we know, rather than at the next scheduled update or in the invoice.
A problem raised early is usually a scheduling conversation. The same problem raised late is a dispute.
Frequently asked questions
How long does a project take?
It depends on scope, and anyone who gives you a duration before understanding the requirement is guessing. You get a timeline with the estimate, after discovery, and we would rather that conversation be short and specific than fast and wrong.
What if the requirement changes mid-project?
It usually does. What matters is that a change is priced and agreed before it is built, not discovered on the invoice. Small changes absorb; anything that moves the scope gets written down first.
What happens if something goes wrong?
You are told, at the point we know, not at the next scheduled update. A problem raised late costs more than the problem itself, and it is the fastest way to lose a client's trust permanently.
Do we get the code and the content?
Yes. Handover includes what was installed, why, and what needs periodic attention. A project that leaves you dependent on the supplier who built it has not finished.
Last reviewed 2026-08-30 by Rajesh.
Talk to us about your project
Tell us the goal and we will scope it properly.