This page sets out how the guides here get written, who checks them, where the information comes from, and what happens when we get something wrong. It also states the rules we apply to claims about our own client work — where it is easiest to mislead you.
Why an agency publishes editorial standards at all
Most agency writing exists to sell. That is not automatically a problem, but the incentives pull one way: sound more certain than the evidence supports, present one project's outcome as a general result, leave out the inconvenient trade-off.
You are about to spend real money on a website, and you are using what we publish to judge whether we know what we are talking about. That only works if you can tell the difference between something we verified and something we are asserting. Writing the standard down makes that difference checkable, and gives you something to hold us to: if a page here breaks a rule below, that is a defect.
Who writes
The guides are written by the developers and designers who do the client work — not a separate content team, not freelancers writing to a brief. The people involved are listed on our team page. A piece on CMS modelling comes from people who have modelled content types in WordPress, Contentful and headless setups for paying clients; a piece on checkout, from people who have shipped stores and dealt with a gateway behaving differently in production than in its sandbox.
That is the point of publishing at all: the useful material is what you only learn by shipping — which decisions are expensive to reverse, which requirements arrive late. We do not write about things nobody here has done.
How a guide is made
- Commissioned from a real question. Topics come from what clients actually ask, in scoping calls and mid-build. If a question has come up three times, it is worth a page. A keyword tells us how to title a piece, not whether we have anything to say.
- Drafted by someone who has done it. The draft comes from a developer or designer with direct experience of the problem. Where the honest answer is "it depends", the draft says what it depends on.
- Reviewed by someone who did not write it. Engineering pieces are read by another senior developer, design and UX pieces by another senior designer. The reviewer checks the claims, the sourcing, and whether anything reads as a promise we cannot keep. Drafts get sent back.
- Published with its scope stated. If a guide describes behaviour specific to a platform version or framework release, the page says so rather than presenting it as permanent.
- Re-reviewed on a schedule. Every guide is re-checked at least annually, and sooner when something underneath it moves — a framework major release, a platform changing its defaults. A re-review can end in a correction, an update, or removal. Deleting a page that is no longer true is a valid outcome.
The same rules apply to a short note in web development as to a long explainer in guides. The bar does not drop because a piece is short.
Sourcing
We work from primary sources first, in this order:
- Official documentation from the platform or framework itself — vendor docs for Shopify, WooCommerce, WordPress and Contentful, maintainer docs for what we build with.
- Published web standards, including W3C and WHATWG specifications and the WCAG guidelines we test against for accessibility.
- Browser release notes, changelogs and platform status pages, for what a browser does today.
- Our own project experience, identified as experience rather than measurement.
Tutorials, aggregator posts and other agencies' articles are used to find leads, not as evidence. If a claim exists only in secondary writing and cannot be traced to documentation, a specification or something we tested, we leave it out.
Anything describing current behaviour is dated
Frameworks and platforms change quickly, and much of what is true about them is true only for now. Defaults change between major versions, browsers ship features and occasionally withdraw them, and a platform can alter its APIs without warning you. So a statement about current behaviour is written as a dated observation and re-checked on the schedule above. "As of this writing" is not hedging; it tells you which claims have a shelf life.
Where sources disagree, we say so
Documentation and observed behaviour do not always match, credible sources give conflicting advice, and specifications allow things browsers implement inconsistently. When that happens we describe the disagreement rather than picking the tidier answer and calling it settled. Knowing a question is contested beats a confident sentence that is half true.
How we handle claims about our own work
This section matters most, so it is stated plainly. The three projects written up at case studies describe real engagements, but the clients are anonymised. That has a consequence we will not hide from: because you cannot see who the client is, you cannot independently check anything on those pages.
The figures on them are self-reported — outcomes measured in the client's own analytics and passed to us by the client. They have not been audited by us or anyone else, and we have not re-derived them from raw data. They are an account of what one client told us happened after one launch.
So we do not restate those numbers as results you should expect. You will not find case study percentages reused as headline claims on our home page, our services pages or our pricing page, and nobody here will quote them at you as a forecast. Outcomes depend on your product, your market and the traffic you already have.
The same rule covers the rest of the trust-signal category. We do not publish testimonials, client logos, awards, certifications, partner badges or review scores we cannot evidence. Where we have nothing verifiable to show, we show nothing.
Use of AI
Where AI is used, and where it is not. We use AI tools to assist with research, outlining and first drafts. Every piece published here is then edited and fact-checked by a person on our team before it goes live, and that person verifies each technical claim against a primary source. We do not publish unreviewed generated text. If a claim here is wrong, that is a person's mistake rather than a tool's — which is the point of the rule.
Independence
We name the tools, platforms and frameworks we actually use on client projects, and describe them the way we describe them internally, including the parts we find annoying. Recommendations reflect what we would do with your budget, not a commercial arrangement.
We do not sell links, we do not accept paid guest posts or sponsored placements, and no third party pays to appear in or be recommended by anything we publish. If a commercial relationship ever existed that could affect a recommendation, we would disclose it on the page carrying that recommendation.
We also state the obvious conflict: we are paid to build websites. When a guide reaches a conclusion that favours hiring someone like us, it should say so and give the counter-case — including when the answer is that your existing site is good enough and a rebuild is not worth the money.
Corrections
If you find an error — a wrong technical claim, a source that does not say what we said it says, a page describing behaviour that has since changed — email [email protected] with the page and what is wrong with it. A link and a sentence is enough. Email is the only way to reach us; see the contact page.
- You get a reply within one business day, including when the answer is that we need longer.
- Clear factual errors are fixed promptly once verified. Typos and broken links are simply corrected.
- Material corrections — anything changing the substance of the advice, a number or a recommendation — are noted on the page itself, so the record shows what changed.
- If we disagree that something is an error, we tell you why rather than going quiet.
This policy covers everything in insights, the case studies, our process and FAQ pages, and our service and pricing pages.