It is the question people do not always dare to ask, and it is one of the most useful. An agency of thirty and a structure of two do not expose you to the same risks, and do not bring you the same things.

How the work is shared

  • The founder designs, frames, decides and pilots. He decides what gets automated and what stays human, and he is your contact from the first meeting through to daily operation.
  • Independent professionals come in case by case, on a precise, dated need: specialised development, design, writing. They work on our repositories and our environments, not on theirs.
  • Our own automations do part of the work other agencies hand to juniors: site analysis, content preparation, page generation, compliance checks, monitoring, reporting.

That third point is not a figure of speech. It is what allows a structure of this size to follow several advertising accounts, run an audit engine and operate client sites at the same time. We apply to ourselves what we sell, which is also the best test bench we know.

The advantages, without exaggeration

You talk to the person who decides, so decisions take one conversation instead of three committees. There is no management layer to fund, which shows in the prices. And the person who built your automation is still there to repair it, which is not guaranteed in an agency with high turnover.

The limits, and how we cover them

  • The single point of failure. That is the real risk of a small structure. We cover it through documentation and through ownership: the code, the instructions and the accounts are yours, and a competent third party can take over. See our article on ownership.
  • Capacity. We cannot absorb five projects at once with the same headcount. We would rather say no or postpone than promise a schedule we will not hold.
  • Very large organisations. A rollout in a group of several thousand people, with a procurement department, an IT department and a security committee, is not our ground. We say so at the first meeting.
A small structure is not a flaw to hide. It is a model, with trade offs that must be named.

The question to put to us

"What happens if you are unavailable for three weeks?" The answer must not be a promise but a mechanism: documentation up to date, access on your side, automations that run without daily intervention, and a third party able to take over. That is exactly what we require from the providers of our own clients.