How we build a website: the details we check so nothing is left to chance

Most people see a website the way they see a restaurant from the street: the front. The things that decide whether it is good, such as how fast it loads on a cheap phone, whether Google can understand it, whether a stranger can break into it, are invisible until something goes wrong. I want to open the kitchen door and show you what we check, and why, on every project.

None of this is magic and none of it is secret. It is a long list of small, unglamorous habits. A site built with care usually looks simple, because the work went into the parts you do not see.

1. We listen before we build anything

Every project starts with a free video call in your time zone, and I spend most of it asking questions. What does your business sell, and to whom? What does a good month look like? Who are your best customers, and how do they find you today? What do you dislike about your current website, if you have one?

These answers decide almost everything that follows: how many pages you really need, which actions matter most (a call, a booking, a purchase), what must be fast, what must be impossible to get wrong. A site designed without them is a nice picture. A site designed with them is a tool for your business.

After the call you get one written proposal with a fixed quote that stays valid for 7 days. We explain why we work this way, and how to compare quotes, in How much does a website cost?

2. We build to a speed budget

Speed is not a vanity number. In a large study carried out by Deloitte for Google, a mobile speed improvement of just 0.1 seconds was linked to an 8.4% rise in conversion rate for retail sites and 10.1% for travel sites. That study was commissioned by Google and measured specific speed metrics across 37 brands, so treat the exact figures as indicative, but the direction is consistent with what we see: people leave slow pages.

So we set targets before we write the first line of code. Google publishes the three Core Web Vitals and what counts as "good", measured at the 75th percentile of real visits:

To hit them we do a handful of things every time:

• Images are sized properly. Every picture is converted to a modern format, produced in several widths so a phone never downloads a desktop image, given explicit dimensions so nothing jumps, and loaded lazily unless it is at the top of the page.
• Fonts are limited. One or two families, only the weights in use, and loaded so text never disappears while the font arrives.
• JavaScript is earned. Every script has to justify its weight. If a feature can be done with HTML and CSS, it is. Third-party scripts such as chat widgets, trackers and review badges are the most common reason a site feels slow, so each one is a deliberate decision.
• Hosting is close to your visitors. We serve sites from a global edge network, so a visitor in London, Sydney or Toronto gets the page from a nearby server instead of one on the other side of the planet.

We then test on a real, mid-range phone, not only on a fast laptop, because that is how most of your visitors arrive. For the longer story of why edge hosting matters, see Edge hosting and WebAssembly.

3. SEO is built into the code, not sprinkled on top

Search engine optimisation is often sold as a monthly mystery. Most of its foundations, though, are decisions made while the site is being built, and they are far cheaper to get right at the start than to fix later. Our checklist:

• One clear job per page. Each page targets one need, with a unique title and description written for humans, so a searcher knows why to click.
• A proper heading outline. One main heading, then logical sub-headings. This helps readers, screen readers and search engines in the same way.
• Structured data. We add machine-readable descriptions (schema.org markup) for your business, services, products, articles, breadcrumbs and frequently asked questions, so search engines understand exactly what each page is. It is also what lets some pages qualify for richer results.
• Technical hygiene. Canonical URLs, a sitemap, a sensible robots file, clean readable addresses, no broken links, and correct language and region tags when you serve several countries.
• Internal links that mean something. Related pages link to each other with descriptive text, which spreads authority and helps visitors find what they need.
• Social preview images. Every page has a proper image and text for when it is shared, because a link that looks good gets clicked.
• Redirects when we replace a site. If you already have a website, we map every old address to its new home so you keep the rankings you have earned. We wrote a full guide to this in Redesigning without losing your Google rankings.
• Search Console from day one. We help you verify the site and submit the sitemap, so you can see what Google sees.

An honest note: nobody can promise a number one ranking, and anyone who does is selling you something. What we can do is make sure that nothing technical holds a good page back, and that Google can read, understand and trust what you publish. The rest is content that genuinely helps people, which is why we also help clients with that.

4. The code is clean, small and understandable

Code quality is invisible to visitors but very visible to you in two years, when you want to change something or hand the site to someone else. We hold ourselves to a few rules:

• Few dependencies. Every library you add is code somebody else controls, which can slow the site, break on an update or carry a vulnerability. We use well-known tools and keep the list short.
• Typed, structured and commented where it matters. Data that comes from outside, such as form submissions, is checked against a strict shape before the site trusts it.
• Automated tests. The software behind our own client portal and admin is covered by more than 330 automated checks that run before every release, including sign-in, payments, file uploads and permissions. If a change breaks something, we find out before you do.
• Version control and a clean history. Every change is recorded and can be reversed.
• Semantic HTML first. Real headings, lists, buttons and landmarks, not a pile of generic boxes. It is faster, more accessible and easier for search engines.
• No plugin salad. On WordPress and Shopify we are careful with add-ons, because each one is a hidden cost in speed, money and risk.

5. Security is layered, because no single layer is enough

Attackers do not choose their victims by size. They run automated tools against everything on the internet and see what answers. So the aim is to make a site a poor target and to limit the damage if one layer fails. The things we do on every build:

1. Everything is served over HTTPS, with strict transport settings so browsers never fall back to an insecure connection.
2. Strict browser security headers, including a Content Security Policy that tells the browser which scripts it may run. This is one of the strongest defences against cross-site scripting. On our own site we go further and allow only scripts we have explicitly fingerprinted.
3. All input is treated as hostile. Forms, query strings, uploads and API calls are validated on the server, never only in the browser. Uploaded files are checked for what they really are, not what their name claims.
4. Rate limits and abuse protection on sign-in, forms and anything that sends email, so bots cannot guess passwords or flood your inbox.
5. Least privilege. Every account and every piece of code can reach only what it needs. A customer can see only their own information, and every request is checked on the server.
6. Strong sign-in. Where there is a login, we support passkeys, which cannot be phished, alongside strong passwords and one-time codes for new devices.
7. Secrets stay secret. Keys and passwords live in protected configuration, never in the code or in a chat message.
8. Backups and updates. Data is backed up before risky changes, and software is kept patched.
9. Privacy by design. We collect only what a feature needs, ask for consent where the law requires it, and write plain-language privacy policies.

These map directly onto the risks that the security community tracks, such as broken access control and injection, listed in the OWASP Top 10. If you want the longer story about trusting nothing by default, read Zero trust for small businesses.

6. The site works for everyone

Accessibility is part of quality, not an extra. We build to WCAG 2.2 AA: text with enough contrast, everything usable by keyboard, visible focus, meaningful link text, descriptions for images, forms with proper labels and errors, and motion that respects people who prefer less of it. It widens your audience, it improves your SEO because the same structure helps search engines, and in many countries it is increasingly a legal expectation. We cover the laws in Website accessibility law in 2026.

7. The launch checklist

Before any site goes live, it passes a checklist. A short version:

8. You own everything, and you get a handover

When the project ends, the domain, the code and the content belong to you. You receive a written handover that lists what was built, where it lives, how to edit it and who to call. You are never locked in. If you ever decide to move to another developer, they can pick it up. We would rather earn your return business than trap it.

9. After launch, we are still here

Every client gets a private portal where they can see progress, approve designs, share files, view invoices and message me directly. After launch the same portal is where you ask for changes. Because websites age, we offer ongoing care for updates, monitoring and improvements, but it is optional and never a condition of owning your site.

Written by Vish Jay

I design and build websites, online stores and business systems for clients in the US, UK, Europe, Australia and Canada, from Colombo, Sri Lanka. When you work with iVishwa, you talk to me directly, from the first call to launch and after.