Who this is for
This service suits organisations that need something on the web to do a real job: explain what they offer, take enquiries or orders, give customers or staff a place to log in, or connect systems that currently need manual work. That might be a new company website, a rebuild of one that has become hard to update, a customer portal, an internal tool, or an API that a mobile app or partner system will use.
We work with organisations of any size, in any industry and region. You do not need a detailed specification to start. You do need to know the problem you want solved and who it is for, and we help with the rest.
How we approach a project
- Discovery. We talk to the people who own the problem and, where possible, the people who will use the result. We review any existing site, analytics, content and systems. The output is a written scope with goals, user journeys, integrations, constraints and open questions.
- Structure and design. We agree the information architecture and wireframes first, then visual design. Decisions are written down so they do not get reopened without reason.
- Build in increments. We build in short cycles and share working versions on a staging environment, so you can review real pages rather than descriptions of them.
- Test. Functional testing on the browsers and devices your users have, accessibility checks, performance checks and a security review of the code and configuration.
- Launch. A planned go-live with a checklist, DNS and redirect plan, monitoring switched on, and a tested way to roll back if something goes wrong.
- Handover. Source code, credentials transferred to your accounts, a runbook and an editing guide. If you want ongoing help, we agree the scope of support separately.
Decisions we help you make
Most of the cost and long-term effort of a web project is set by a few early choices. We explain the trade-offs in plain terms and recommend one, but the decision is yours.
Static, server-rendered or single-page application
- Static sites are generated in advance and served as files. They are fast, cheap to host and have a small attack surface. They suit marketing sites, documentation and content that changes a few times a day at most.
- Server-rendered applications build each page on request. They suit sites with logged-in users, personalised content or data that changes constantly.
- Single-page applications run mostly in the browser after the first load. They suit tool-like interfaces such as dashboards and editors, where users stay a long time and interact heavily.
Many projects mix these approaches. A static public site with a separate application behind a login is a common and sensible pattern.
CMS or no CMS
If several non-technical people update content every week, a content management system is usually worth it. Options range from traditional all-in-one platforms to headless CMS products that only manage content and leave presentation to the site. If content changes rarely and a developer is involved anyway, keeping content in the code repository can be simpler and safer. We choose based on who edits, how often and what approval steps you need.
Frameworks and languages
Teams commonly choose between several mature front-end frameworks and back-end languages. Our selection criteria are practical: what your existing team can maintain, what your hosting supports, how long the ecosystem is likely to stay healthy and whether hiring for it is realistic where you are. We avoid choosing a tool simply because it is new.
Hosting
Choices include static hosting with a content delivery network, managed application platforms, containers on a cloud provider or your own servers. We weigh running cost, the operational skills you have, data residency needs and how traffic is expected to vary. Our cloud services page covers this in more depth.
Security and quality built in
- Security. We use the OWASP Top 10, an awareness document listing the most critical web application security risks, as a checklist during design and review. In practice that means validated input, parameterised database queries, secure session handling, least-privilege access, secrets kept out of code, dependencies kept up to date and HTTPS everywhere.
- Accessibility. We design and test against the W3C’s Web Content Accessibility Guidelines (WCAG) 2.2, which define three conformance levels, A, AA and AAA. We agree the target level with you at the start, because it affects design and content as well as code.
- Performance. Google’s Core Web Vitals measure loading (Largest Contentful Paint), responsiveness (Interaction to Next Paint) and visual stability (Cumulative Layout Shift). We measure these during build rather than after launch, since fixing a slow site late is costly.
- Personal data. If the site collects personal data from people in India, the Digital Personal Data Protection Act, 2023 is relevant. It requires a notice to accompany or precede any request for consent, and it requires reasonable security safeguards to prevent personal data breaches. Its provisions are being brought into force in phases under a 13 November 2025 notification. We build consent, notice and data-deletion flows when your legal advisers confirm they are needed, and we keep the personal data collected to what the purpose requires.
- Code quality. Version control from day one, code review, automated tests for the business logic that matters most, and repeatable deployments, so nothing depends on one person’s laptop.
What we need from you to start
- A short description of the problem, the audience and what success looks like for you.
- A named person who can make decisions and give feedback within an agreed turnaround.
- Access to anything that exists already, such as the current site, hosting, domain registrar, analytics and the systems we need to integrate with.
- Brand assets, if you have them: logo files, colours, fonts and any style guide.
- Content, or an owner for it. Even a rough draft helps us design around real words instead of placeholder text.
- Any constraints we should know about early: legal or regulatory requirements, data residency, a fixed launch date or a budget range.
If you are not sure about some of these, that is fine. Finding out is part of discovery. Get in touch and tell us what you are trying to do.