Websites that load fast, read well, and age slowly.
This page, just now
…
Read from your browser's own clock, on your connection, for this page. The figures need JavaScript to appear. The page does not.
- Our server answered
- …
- Your browser finished reading it
- …
- The biggest text appeared
- …
- Downloaded to your device
- …
The first line is the part we are responsible for; the distance between it and the rest belongs to the network between us. For scale: the threshold a page is judged against is 2,500 ms, and the slowest of fifty measured runs on this site was 1.9 s, on a throttled phone.
Every number on this site is measured. When one stops being true, the build fails.
What we make
- A first website for a new company
- An online shop
- A rebuild of a site you have outgrown
- Looking after it once it is live
What we measure on this site
- 0 trackers, analytics or cookies
- 0 automated accessibility violations
- 12 / 12 pages that work without JavaScript
- 1.9 s slowest page to appear, 50 runs
How we work
A process built around the real problem rather than the deliverable.
We take on a few projects at a time. The person you meet at the start is the person who builds the site, which is the good part and also the reason the number stays small.
What you never get
- A discovery questionnaire instead of a conversation.
- A design revealed as a finished surprise in week six.
- A handoff to a build team who have never spoken to you.
- An invoice for a change we should have caught.
Brief
One call about the business, the people it serves, and the specific thing the site is failing to do for either. You will come out of it knowing more about what you need, and we will have said whether we think it is us.
Architecture
Structure before surface. What lives on each page, in what order, and what a stranger has to understand before anything else. Every layout decision after this one is cheaper because of it.
Design
Drawn in Figma, decided in a browser, with your real words in it. Type and spacing behave differently at arm's length on a phone than they do on a desk, and only one of those is how most people will see it.
Build
Whoever drew it writes it. The reasoning behind a decision is still in the room on the day that decision has to survive contact with real code.
Handoff
The code, the images, the accounts, written instructions, and a walkthrough of all of it. The test is whether you can change a headline on a Friday afternoon without ringing anybody.
The work
This site is the portfolio.
There are no case studies here yet, and no invented ones either. The studio is early, which we would rather say out loud than arrange the page to avoid. So the thing to judge is the page you are standing on: how fast it arrived, how it behaves under a keyboard, what it refuses to load. A grid of client logos takes an afternoon to assemble. This is harder to fake, which is the only reason it is worth showing you.
On the work page
Four decisions taken while building this site, and the thing each one cost. A list of wins tells you nothing. What a studio gave up, and why, is the part that predicts working with them.
Our thinking
Most websites are fine. That is the problem.
What that rules out
- A template dressed up as custom work.
- A page that needs JavaScript running before it will say hello.
- Words that would survive having your competitor's name pasted over yours.
- Decoration we cannot give you a reason for.
Most websites are not bad. They are fine, and quietly empty. The page loads, the menu works, nothing is broken, and you leave knowing roughly what you knew when you arrived. That is the real failure mode, and it is far harder to spot than an ugly one.
We build for whoever showed up with a question. Not the committee, not the algorithm, and not the version of you that wants every award listed above the fold. Somebody gave you thirty seconds of their afternoon. The least a page can do is answer them.
None of the craft underneath is the point. The speed, the structure, the fact that all of it works from a keyboard: those are what make the point legible. A site that takes four seconds to say something true has already lost to one that takes half a second to say nothing, which is a stupid way to lose. We would rather do both jobs properly and be done with it.
Straight answers
Three questions worth asking first.
The one about case studies is first because it is the one that decides it. Burying it lower down would not have made the answer any different.
Got a fourth one? info@gbtn.studio. No form, no funnel, and a reply from the person who would do the work. Ask it plainly and you will get it back the same way.
You have no case studies. Why would I hire you?
That is the right question and we would rather answer it here than hope you do not ask.
The studio is early. There is no wall of client logos, and we have not invented one. What there is instead is this site, which is built to exactly the standard the work is sold on and publishes its own measurements: the slowest a page took to appear across fifty runs, the accessibility results, the number of pages that still work with JavaScript switched off. Every one of those numbers has an automated test behind it that fails when it stops being true. You can open the /work page and read what each decision cost as well as what it bought.
It is a smaller claim than a portfolio and a harder one to fake. If you need a studio that has already done your exact project twice, we are genuinely not it yet, and there is no hard feeling in that.
What does a site cost?
Every project is fixed-scope and fixed-price, and you get the number in writing before you commit to anything. There is no hourly rate and no change-order game.
What we will not do is print a price range on a web page, because the honest range is wide enough to be useless. A five-page launch site and a store with eight hundred products are not the same job in any respect. What we will do is give you a real number fast. Tell us roughly what you have in mind and what you were expecting to spend, and if those two things are not in the same postcode we will say so on the first reply rather than the fourth meeting.
Who actually does the work?
We are a small studio, and small here means the person who replies to your first email is the person who draws the layouts and writes the code. Nothing is handed to a design team and then over a wall to a build team, because there is no wall.
The practical effect is that a decision made in week one survives into the build, and a problem that surfaces in development gets solved by somebody who already knows why the design is the way it is. The practical cost is that we can only run a few projects at a time, which is why the calendar is worth asking about early.
Five more covering how long it takes, what we need from you, what happens if the first direction is wrong, what happens after launch, and when we are the wrong studio for the job.
Start here
Let's build
something good
Tell us what you're working on and we'll give you a straight answer about whether we're the right studio for it. Sometimes that answer is no, and you get the name of somebody better suited instead.
Taking on work now, in the order projects are booked. Confirmed .