Most websites do not fail because of a bad idea. They fail because the code behind them becomes expensive to change: a redesign takes months, a small copy edit needs a developer, and every new feature makes the next one slower. This topic collects how we avoid that at tbskit — the standards, tooling, and habits that keep a site fast and editable years after launch.
Why we treat code as a business asset
A website is not a one-off deliverable, it is an operating asset. The question we ask at the start of every project is not “which framework is trending”, but “who will change this page in six months, and how long should that take?” That single question decides how we structure content, how much abstraction we allow, and how much we document.
In practice that means three commitments we make on every build:
- Small, boring, well-known building blocks. A new developer (yours or ours) should be productive in the first hour, not the first week.
- Content that lives in files, not inside code. Copy, images, and page structure should be editable without touching a component.
- Budgets, not intentions. Speed and accessibility get a number we can measure, and the build fails loudly when that number is missed.
The stack we keep deliberately small
We build static-first sites with Astro and TypeScript, because a site that ships HTML instead of a framework runtime is easier to host, cheaper to run, and faster to load. Where interactivity is genuinely needed we add it in islands, one component at a time, instead of shipping a full client application to every visitor.
The rule we follow for dependencies is simple: every package has to earn its place. A dependency is a maintenance contract that never expires — it needs upgrades, security attention, and someone who understands it. We would rather write forty honest lines of code than import a library we do not control.
Performance budgets instead of promises
“Fast” is not a feeling, it is a measurement. Each project gets a budget that covers:
- Largest Contentful Paint and Interaction to Next Paint from real devices, not from a developer laptop on office wifi.
- Total JavaScript shipped per page, with a hard ceiling that requires a conversation to raise.
- Image weights and formats, because images are usually the biggest single lever on perceived speed.
Budgets only work when they are automated, so we wire them into the build and check them again before launch, on the slowest device we can reasonably expect our client’s audience to use. When a feature pushes us past a ceiling, we change the feature — not the budget.
Accessibility and semantics from the first commit
Accessibility is not an audit that happens at the end; by then it is a rewrite. We start with semantic HTML, real headings in a sensible order, visible focus states, keyboard paths for every interactive element, and colour contrast checked against the palette rather than eyeballed. Screen-reader checks and automated tools both have a place, but the foundation is markup that already means what it says.
The same care pays off in SEO. Crawlers read the same structure assistive technology does:
one clear <h1>, descriptive links, meaningful image alternatives, and metadata that matches
what the page actually contains.
How work gets reviewed and shipped
Every change goes through a review, even when the change is small — a review is where naming,
accessibility, and edge cases get caught while they are still cheap. We keep branches short,
write commit messages that explain the reason for a change, and treat continuous deployment
as normal: push to main, watch the build, and verify in production.
Before a release we run a short checklist: does the page render without JavaScript, do the redirects from old URLs still work, are the sitemap and canonical tags correct, and can we roll back in one step if something is wrong.
Handover: code your team can keep
The end of a project is the beginning of ownership. We hand over a repository with a README that explains how to run, build, and deploy the site, where content lives, how media is stored, and which decisions might need revisiting later. If your team wants to take over development, we make that easy; if you would rather we stay involved, that is what our ongoing support is for.
What we publish under Code
Articles in this topic go deeper into individual decisions: content modelling, rendering strategies, third-party scripts, migration and redirects, and how we keep a growing site predictable. They are written for the people who have to live with the result — marketing teams, product owners, and developers inheriting a codebase.
If you are planning a build or rescue mission, tell us about the project and we will show you how we would approach it.