Where the honest answer is “it depends”, we have said what it depends on. If your question is not here, email [email protected] — you will get a reply within one business day.
Getting started
How do I start a project?
Email [email protected] with a few lines about what you need: what you are building or what is wrong with what you have, your current site address and platform, and roughly when you want it live. If you have a budget range in mind, say so — it changes what we recommend, not what we charge.
What happens after that first email?
A developer reads it and replies, usually with questions rather than a proposal. We want the constraints — existing systems, deadlines, who else touches the site — before putting numbers against anything. Then you get a written scope and estimate. The full sequence is on our process page; the people you would correspond with are on the team page.
Does a first conversation cost anything?
No. Scoping questions, a look at your current site, and the estimate itself are free. You are committed to nothing until you approve a written scope and price.
Why is there no phone number or contact form?
Two practical reasons. Technical detail — plugin names, error messages, URLs, launch dates — survives better in writing than on a call, and email leaves both sides a record. Second, with no form this site collects no lead data at all: nothing about you is captured until you email us, as our privacy policy sets out.
How long before work actually begins?
It depends on how quickly the scope settles and how much groundwork the project needs before anyone writes code. A small marketing site with its content already written can start shortly after you approve the scope; a build involving migrations, integrations or design research needs lead time first. In practice the date is usually decided on your side — content, access to existing systems, and someone available to decide.
Can I see examples of your work?
There are three write-ups on the case studies page. They describe anonymised clients, and the figures in them are self-reported by those clients rather than independently verified. Read them for how each problem was approached, not as a benchmark for what your project will do.
Cost and scope
What drives the price?
Roughly in order of impact: how many genuinely different page templates you need (not how many pages); custom design versus an existing theme; how many third-party systems have to be integrated and how well documented they are; whether the site sells things; and who writes and migrates the content. Integrations and e-commerce move the number more than page count ever does. Indicative ranges are on the pricing page.
How do you give an estimate?
We scope in writing first: a list of templates, features, integrations and content tasks, with the assumption behind each one written next to it. When something turns out differently, you can see exactly which assumption broke. Where a piece genuinely cannot be pinned down yet — an API whose documentation we have not seen — we say so and price it separately rather than padding the whole estimate.
What happens if the scope changes?
It usually does. Anything outside the agreed scope gets a short written note: what it is, what it costs, what it does to the timeline. You decide before it is built, and nothing is billed that you have not agreed to in writing.
How does payment work?
In general terms: a deposit to begin, then the balance across milestones tied to delivered work rather than to calendar dates. Maintenance is billed monthly and separately from the build. Exact figures and terms live in your proposal.
Are there ongoing costs after launch?
Yes, and most exist whether or not you keep working with us: domain renewal, hosting, and any commercial licences the build depends on — a store platform plan, a premium plugin, a search or transactional email service. A maintenance plan is optional and priced on top. Every recurring cost we know about goes in the estimate, so the running total is visible before you commit.
Technical questions
Which platforms and stacks do you work in?
WordPress, headless setups and Contentful for content-led sites; Shopify, WooCommerce and custom builds for stores; JavaScript front ends with a custom backend for applications. The full list is on the services page. The choice follows the problem, not our preference — if a well-configured CMS does the job, we will say so rather than sell you a custom build.
Will you work with my existing site, or do you insist on a rebuild?
We work with what exists whenever that is cheaper for you. A site with sound structure and a dated front end is a redesign, not a rebuild; a site whose data model is wrong, or which sits on a platform nobody maintains, costs more to keep patching than to replace. We read the code before saying which one you have, and if the answer is “leave it alone and fix three things”, that is what you will hear.
What happens to my SEO and rankings during a redesign?
Rankings follow URLs, content and speed, so those are what a redesign has to protect: a full URL map before anything moves, redirects for every changed address, titles and headings carried over deliberately, structured data rebuilt rather than dropped. Damage happens when URLs change without redirects or pages disappear during a content cull. Expect movement in the weeks after launch while search engines recrawl; our insights section covers the mechanics.
Will the site be accessible?
Accessibility is built in rather than added at the end: semantic HTML, full keyboard operation, visible focus states, sufficient colour contrast, labelled controls and real alt text. WCAG 2.1 AA is the standard we work toward. No one can promise a site stays conformant once your own editors publish, so we show your team what to watch for. See our accessibility statement.
Who hosts the site?
It depends on the stack. A Shopify store is hosted by Shopify; a WordPress site normally sits on a managed WordPress host; a custom front end goes wherever its framework runs best. Whichever it is, hosting and domain accounts are set up in your name, so the bill, the credentials and the ability to walk away stay with you.
Can I edit the content myself?
Yes, and for most sites that is the point of using a CMS. We shape the editing interface around the content you actually publish rather than handing over a generic admin panel, and you get a walkthrough plus written notes at handover. Where a layout is fragile we lock the structure and leave the text editable, so a routine edit cannot break a page.
After launch
What support is included after launch?
Every build includes a defined post-launch window, written into the contract, during which we fix defects — anything that does not work the way the scope said it would — at no extra cost. It covers bugs, not new features; a request that adds behaviour is quoted as a change.
What does a maintenance plan cover?
Platform, plugin and dependency updates applied and tested rather than auto-applied and hoped for; backups with restores actually verified; uptime and error monitoring; security patching; and an allowance for small changes. What a plan needs varies by stack — a hosted store needs far less patching than a self-hosted install with a dozen plugins. Options are on the maintenance page.
What happens if something breaks?
Email the same address you always use. Urgent problems — site down, checkout failing, a security issue — go ahead of routine work. Clients on a maintenance plan have a response time agreed in writing; without one we help as capacity allows and bill for the time.
Can I take the site elsewhere later?
Yes. You own the code, the content, the design files and the accounts once the final invoice is settled. We hand over repositories, credentials and documentation, and we do not hold a domain or hosting account as leverage.