Systems first, because sixteen people cannot carry it in their heads.

Anything we do more than twice gets written up. Onboarding a new WordPress client, setting up a WhatsApp Business API number, shipping a Next.js site to Netlify, wiring an n8n workflow into a CRM. Each has a document with the steps, the decisions somebody already made, and the traps that cost us a day the first time.

When you join, you are not handed the documents and left alone. You are given work that uses them and a senior who checks the output. The expectation, though, is that you read the SOP before asking, and that when you find it wrong you fix it. Documents here are edited by the people using them, not by a process owner.

The same applies to what we build. Client work carries handover notes, credentials in the right place, and a short readme for whoever picks it up next. A build nobody else can maintain is not finished.

Work is assigned by project, not by ticket queue. You own a piece of a client build end to end, with a clear definition of what done means and a date. That is deliberate. Splitting a build into anonymous tasks makes it faster to hand out and much harder to be proud of.

A typical assignment lands with the brief, the client context, the relevant SOP, and the name of whoever reviews it. If any of those four is missing, ask before you start rather than guessing. The cost of a wrong assumption on client work is paid at the end, in a rebuild.

Review is written and specific

Every piece of client work gets reviewed before it leaves. Design is reviewed against the brief, code is reviewed against the standards, automations are tested with real data before they touch a live account. Feedback is written down and points at the thing, not at you. Expect it to be direct. Nobody here softens a review until it stops being useful.

Mistakes are handled in the open

Things break. A migration drops a redirect, an integration fails quietly over a weekend, an estimate turns out to be half of what the work needed. The rule is that it gets said early, to the person who can act on it. What follows is a fix and usually an edit to the SOP so the same gap does not catch the next person.

This is agency work, and agency work has peaks. A launch week is busier than the week after it. Client feedback arrives late sometimes, and the date does not always move with it. If you want a job where the load is identical every week, this is not it.

What we can say is that the peaks are visible in advance, because the schedule is shared, and that a stretch of long days is followed by a lighter one rather than becoming the new normal. If a project is heading for a crunch, saying so early is treated as doing your job, not as complaining.

We also work in English all day, with clients in the UAE, Europe and North America. Writing clearly matters here as much as the build itself. A well built site with a confusing handover note still creates work for somebody.

What we expect

• Read the brief and the SOP before starting.
• Say when something is going to be late, before it is late.
• Write down anything the next person will need.
• Test with real data, not with the happy path.
• Ask early. A question costs minutes, a rebuild costs days.