
Meta social website
- Design
- Development
Services
Seven services, one team
The people who design are the people who build, so nothing gets lost between the first question and launch day. It sounds like a small thing. We think it’s the whole thing: the difference between a product that arrives the way it was drawn, and one that arrives as a slightly blurry photocopy of itself.

One service at a time, told the long way
Why seven? It’s a fair question, and people ask it a lot, usually right after they’ve read the list and done a quick headcount of the studio.
The honest answer is that most projects need more than one of them at once, and they need them to agree with each other. A new company needs a position before it needs a logo, and a website by the same Tuesday. An app needs screens, code, and the words on every button. An AI feature needs a model, an interface for it, and someone to decide what it should never say. A launch needs a film, a page for the film to send people to, and an email telling everyone the page exists.
The usual way is to hire a different company for each, and then spend months making them look like they came from one. We do all seven with the same people. Here’s how we do each one, and why, in rather more detail than you asked for.
Every rebrand starts with an awkward fact: somebody made the old one. Often they’re in the room, and they’ve just hired a team of strangers to fix it. So we don’t open with sketches. We open with questions.
Who comes to you, and what for? Who else could they go to, and why don’t they? What’s slowing the company down that nobody says out loud in meetings? For the first few weeks we don’t know your business, and it would be odd to pretend we did, so we read your market, your customers, and your competitors before anybody draws a thing.
The answers become a strategy: a page or two of plain sentences that you sign before any design starts. From then on, every name, mark, colour, and word is judged against that page rather than against anyone’s taste. That’s what lets the person who made the old brand let it go without losing face. Nobody was wrong. The company moved on.
Most categories end up looking alike. Lay the competitors side by side and you’ll find them all standing in the same spot, often in the same blue. We find that spot and put you somewhere else, on purpose, for a reason that’s true about you.
Then we test it where it’ll live: your name set in every typeface on the shortlist (most fail on sight), the type at real sizes on a real phone, the voice written down as a few traits, each with the line it mustn’t cross. The rules arrive as a website, not a PDF going stale in somebody’s inbox, written for whoever makes your next poster long after we’ve gone. There’s a page on what not to do with the logo, too. Someone will try to stretch it eventually.

Most interfaces are designed for the moment everything works. Ours start a step earlier, with a question that sounds almost rude: is this the right problem? The brief says the sign-up needs a redesign. Sometimes it does. Sometimes the sign-up is fine and nobody can find it.
So we write the brief with you, then keep rereading it, especially halfway through, when everyone’s busy and it’s easiest to forget. We work backwards from it: what people come to do, what that takes, which screens it needs, and only then how they all hang together. What goes in comes before where it goes. How it looks waits its turn.
We go wide first, with ideas that ignore every limit, and then cut hard to one direction. (Trimming a bold idea is easier than inflating a timid one.) The map becomes wireframes, the wireframes become prototypes, and each one answers a question the last one couldn’t. Then we put them in front of people who’ll actually use the thing, early and more than once.
After the main path come all the others: every kind of user, the empty screen on the first day, the spinner on a bad connection, the form filled in wrong and the message that says how to fix it without making anyone feel silly. Those are the screens people remember, usually for the wrong reasons. And because we build what we design, the prototype isn’t a picture of the product. It’s the first version of it.

Picture a relay race. The designer runs the first leg, hands over a file and a page of notes, and walks off the track. The developer runs the rest, building what the notes seem to mean. Nobody drops the baton, exactly. It just arrives a little different from how it left: the spacing drifts, the timing gets simpler, and the small settle at the end of an animation disappears, because it was hard to describe.
Design engineering is what happens when there’s no second leg. The person who draws the interaction builds it, in the real medium, at real speed, with real content. Motion is planned at the start and costed like any other part of the job, so it makes it to launch instead of being the first thing cut. The easing gets tuned in the browser, where it’ll be felt, rather than described in a document nobody reads twice.
Before any code, we go through the whole design and find the pieces that repeat. Each does one job, and the build starts with a page that shows every one of them in every state, before a single real page exists. When a piece starts collecting options, we split it rather than teach it one more trick. We never take scrolling away from you, and when the browser learns to do something we built by hand, we delete ours.
What you’re left with is a design system that’s already code. The parts your designers draw with and the parts your engineers ship are the same parts, so they can’t quietly drift apart.
Speed is the first thing people notice and the last thing they forgive. We measure it in two places: on the server, where the first byte leaves, and in the hand, where it’s judged. Whatever doesn’t need to be live gets built ahead of time, and whatever does gets cached where every server can reach it. Pictures arrive with a tiny stand-in and keep their place, so the page doesn’t jump while you’re reading it.
Then there’s the question every backend should start with, and few do: who changes things after launch? If it’s a handful of lines a year, you don’t need a content system, and we won’t sell you one. If it’s a team that publishes every day, they get proper tools, with the words kept apart from the design, so they can change them on a Sunday without asking anyone’s permission. A website you can’t change without calling the people who built it isn’t finished. It’s a hostage situation with nice typography.
We choose platforms by their limits before our preferences: what they cost at ten times the traffic, where the data has to live, who’s allowed to see what. Privacy is built in from the start, not bolted on at the end: plain words, a no that looks exactly like the yes, nothing ticked for you in advance, and a way to take your data with you, or to have it gone.
And because the same people built the front, the back is shaped around what the screens actually need, not a spec written before anyone knew.
Here’s an unfashionable thing for an AI studio to say: not every product needs AI. Some need a better search box. If yours is one of them, we’ll tell you, and save you the bill.
When it does belong, someone who knows the models sits in the first design meeting, not the last. What a model can really do should shape the interface, rather than the interface promising things the model can’t keep. We design with real output from the first day: the pause before an answer, the answer arriving a few words at a time, the confident wrong one, and the way back from it. Those moments are the product now, and they deserve the same care as any button.
Underneath, every tool does one job. The model sits behind a clean seam, so it can be swapped as the field moves, which it will, probably by Thursday. We use the smallest model that does the job as well as the biggest, tested on your own material rather than on somebody’s leaderboard. Answers stream, repeated questions are remembered, and anything that doesn’t need thinking about live is worked out ahead of time.
Every project gets a page that runs each of the system’s behaviours on sample inputs, side by side. It’s a design tool and a test at once: when a change makes one answer worse, it shows up there long before it shows up in front of a customer. And when a newer model makes one of our clever workarounds unnecessary, we delete the workaround. Gladly.

A film gets about two seconds to earn the next ten, and most of those two seconds get spent by a thumb deciding whether to keep scrolling. So the idea comes first: the one thing worth stopping for. Every script starts with three answers. Who’s speaking? Who’s listening? And what should they do, or believe, when it ends?
Then comes the part that decides whether an AI film looks made or merely generated. We gather references and settle the look in sketches and rough frames before spending any time generating. The brief decides how real it should feel, and the look decides the tools, not habit. Every shot shares one light, one palette, and one grade, so the film reads as one world rather than forty lucky accidents. Generated footage gives itself away the way bad stock photography does, with smiles a little too wide and light that doesn’t match, and we hunt for exactly those tells.
Each round, we say precisely what’s off: the proportions, the contrast, a detail that isn’t there. If the style moves halfway through, we redo the whole set rather than leave the early shots behind. The movement gets as much care as the pictures, because easing and restraint are still what make a film feel made rather than assembled.
Then come the versions, because one film is never just one film anymore: the long cut for your site, short ones for feeds, an upright one for phones, and six seconds for when six seconds is all you’ll get. Each works with the sound off, and each is compressed by eye, only as far as nobody can tell.

Your audience isn’t waiting for you. They’re on a train, thumb on the glass, between forty other things that also want them. Marketing that works respects that: it’s useful before it’s clever, and it asks for one thing at a time.
So every brief starts with the same three lines: who’s speaking, who’s listening, and the one thing they should do or believe afterwards. We only push toward things that are genuinely good for the person listening. That rules out more tactics than you’d think, and it leaves the ones that last.
Content that looks boring usually isn’t. It’s been arranged around what a company has rather than what people came for. We rebuild it around the job they came to do, and give everything on the page a reason to be there. When we tell the story of a project, the client is the hero and we’re just how they got there. We claim only what’s true and show the thinking as well as the result, because whoever’s reading is mostly checking that hiring you won’t come back to bite them.
Then one voice carries it everywhere: the site, the ads, the posts, and the emails, which we build to survive the oldest inbox your customers still open, from templates your team can send without a developer. Sign-ups ask plainly, nothing is ticked for anyone, and leaving is as easy as joining. It’s also why we answer questions in public on #HeyInternet: one good answer, read by everyone who was wondering.
None of this means every project needs all seven. Plenty only need one. Some need two, and a strongly worded email. If yours only needs one, we’d much rather say so than sell you the other six.
When you’re ready, tell us everything. The people on that call are the people who’d do the work.
— The folks at Internet Labs
Websites, apps, and brands, up close













Details on steroids