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 doesn't.
- Our server answered How long we took to reply.
- …
- Your browser finished reading it All the words and the layout were ready.
- …
- The biggest text appeared The headline was on your screen.
- …
- Downloaded to your device The page, its styling, its code and one typeface.
- …
The first line is the part we're 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 60 measured runs on this site was 1.7 s, with the processor slowed four times and the connection throttled.
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's live
What we measure on this site
- 0 trackers, analytics or cookies
- 0 automated accessibility violations
- 12 / 12 pages that work without JavaScript
- 1.7 s slowest page to appear, 60 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'll come out of it knowing more about what you need, and we'll have said whether we think it's 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're 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's 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's the problem.
The studio is taking on work. One desk, one project at a time, and whoever answers your first email is the one who builds it. Calendar checked .
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 can't give you a reason for.
Most websites aren't bad. They're 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's the real failure mode, and it's 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's the one that decides it. Burying it lower down wouldn't 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'll get it back the same way.
You have no case studies. Why would I hire you?
That's the right question and we would rather answer it here than hope you don't ask.
The studio is early. There's no wall of client logos, and we haven't 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 sixty 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're genuinely not it yet, and there's 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's no hourly rate and no change-order game.
What we won't 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 aren't the same job in any respect. What we'll 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 aren't in the same postcode we'll say so on the first reply rather than the fourth meeting.
Who actually does the work?
We're 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's 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're 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. Each project starts when the one before it ends, which is why the dates we give you hold. Calendar checked .