Which changes your team makes, and which come to us
What you are actually buying is a line. Your team changes what sits on one side of it, and the rest comes back to a queue.
Ask about your own site
Send the site and the one change your team most often needs to make. We write back with where that line falls.
The line is a scoping decision, and it gets written down
How it usually goes wrong is not the part anyone expects.
The phrase held. The detail underneath it did not.
The phrase fits a team that can rewrite a headline and a team that can launch a campaign section. Both sides sign it meaning different things.
You find out on a Thursday.
The discovery is never technical. It is a date: something has to go live, somebody opens the editor, and what they need is not editable.
Getting out is harder than getting in.
Leaving is the part nobody checks until they have to. A site can export cleanly and still lose the structure your team works in.
Nobody says this part out loud. You made the promise upstairs, on somebody else's assurance, and you are holding it.
We turn some of this away
Where we fit
A marketing team publishing pages, editing what is already live and running campaigns without waiting in a queue.
A WordPress build, a Sanity build or a custom headless CMS, which is a service line we run.
Where we are the wrong call
Maybe you want a platform your team runs alone, with no software partner behind it at all.
If the real question is which content system to stand on, start with how a headless CMS actually behaves.
Sometimes the decision sits with whoever owns the platform or signs for it, and they are weighing different things.
A slow page sells less. Two different kinds of evidence say so, and they are worth keeping apart.
Show data table
| Item | Purchase rate |
|---|---|
| One second | 3.05% |
| Two seconds | 1.68% |
| Three seconds | 1.12% |
The causal half is smaller and stronger. Google published a test with Vodafone on web.dev in 2021: one landing page, split 50/50, identical apart from the performance work. The faster version had a 31 percent better Largest Contentful Paint and produced 8 percent more sales. That is one brand, one page, one market. The direction travels. The number does not, and anyone who quotes it at you as a forecast is overselling it. If speed is the whole problem you came with, the work itself is over on web performance.
We will not promise you a score on launch day, and here is the reason rather than an excuse.
Show data table
| Stage | Mobile origins passing all Core Web Vitals |
|---|---|
| 2022 | 31% |
| 2023 | 37% |
| 2024 | 43% |
Two things are happening at once in that data and both belong on the table. Sites keep getting heavier: the Web Almanac puts the median mobile page at 1912 KB in June 2021 and 2311 KB in October 2024. At the same time the share of mobile origins that pass has climbed from 31 percent to 43 percent, because browsers, hosting and frameworks all got better underneath. So the platform improves while the pages fatten, and most mobile origins still do not pass. None of that measures a single site sliding after its own launch. It measures the category, one year at a time, over a different set of origins each year. A number we hand you on the day we hand over the keys tells you about that day. The question worth asking instead is who is allowed to add the next thing to the page, and what happens when they do.
Ask about specific changes, not about who the site was built for.
These seven are the ones that actually decide it. Put them to us and to whoever else is bidding, in exactly these words.
- Swapping the words in the hero on the home page.
- Publishing a new page on a template that already exists.
- Adding a page type that does not exist yet.
- Changing what the main navigation contains.
- Adding a field to a form.
- Changing how a listing sorts or filters.
- Moving a section from one template to another.
What published research measured ICT overruns to be
The tail is the part worth insuring against, and it is one in six rather than the norm. The population is ICT projects broadly, not agency web builds. Treat it as calibration rather than a forecast for yours. Written terms are cheap while everyone is still getting along. They are the only thing that helps in the sixth case.
Flyvbjerg and Budzier, arXiv:1304.4590
Flyvbjerg and Budzier, arXiv:1304.4590
Flyvbjerg and Budzier, arXiv:1304.4590
*Disclaimer: Flyvbjerg and Budzier measured average cost overrun of 27 percent and schedule overrun of 55 percent across 1,471 ICT projects. They read those averages as ICT projects performing reasonably well.
The alternative you are weighing is hiring this in house, so here is what that costs, from two sources that measure it differently.
Show data table
| Item | Median yearly total compensation, USD |
|---|---|
| United States | 145,000 |
| United Kingdom | 84,544 |
| Germany | 79,636.5 |
| France | 61,487.5 |
Two published United States figures sit beside each other and they are not two readings of one number. The Bureau of Labor Statistics puts the median annual wage for web developers at 92,650 USD in May 2025. Stack Overflow puts median self-reported total compensation for a front-end developer at 145,000 USD in 2025. One is a wage from an establishment survey. The other is total compensation as people describe it themselves. The populations differ as well. Stack Overflow's unit is a respondent-selected role, Developer, front-end. The Bureau of Labor Statistics publishes no such occupation, and its nearest series, Web Developers, is a different population under a different occupational code. Different occupational definitions, measured different ways, so carry both and subtract neither from the other. Payroll is also only the visible part. Employer taxes, benefits, equipment and the search itself sit on top of every bar. What moves the size of a build is a short list, and none of it is page count. How many distinct templates the site needs. How many regions inside them have to be editable, since every editable region is real work rather than a checkbox. How complicated the content model is. How much existing content and how many URLs move. How many other systems it talks to, and who owns each. Whether the accounts already exist. And the traffic it carries today. A live site under load is different work from a build nobody has visited yet.
A commerce performance rebuild, written up in full
Anonymised, as every case on this site is.
What we publish
Our case studies are anonymous, always, whatever permission exists elsewhere. Class descriptors only. That costs us the logo and it is the right trade. The same discipline is what stops your name appearing on somebody else's sales page later. One of them is a commerce platform rebuilt for performance. It is published rather than summarised, so you can read the work itself instead of a claim about it.
What the client holds at the end
What we will say about every engagement, including that one, is what the client holds at the end. The repositories are theirs. The deployments run in their cloud accounts. The documentation is theirs to keep, the runbook included. If they stop working with us, none of that has to be negotiated, because none of it was ever ours. That is the part of the boundary you can check after the fact rather than before.
What this does not prove
It shows the ownership half, the client keeping the code and the accounts. It is not evidence that a change boundary was agreed in advance and held. That is not what this engagement is written up to show.
1000+Shops onboarded
Read the commerce performance rebuildGet the boundary answered for your own site
Send the site and the change your team keeps needing. We write back with where that line falls today, and what would move it.
The questions people bring to the first call
Can our team change the site without a developer?
Who owns the code?
What happens when something has to change mid build?
What hours do you work, and when do we hear back?
Will you guarantee a speed score?
Somebody else built our site. Can you take it over?
Do we have to move off our CMS?
Send the site and the change you keep needing
Two things get you a useful first reply: the address of the site, and the one change your team most often needs to make on it.
That is enough for us to say where the boundary sits today and what would move it.
Tirth Bodawala, our CTO, reads these.
- You get a written answer rather than a discovery call.
- We usually reply within 24 hours.
- If the answer is that we are the wrong fit, we will say that too.