What we stand for

Standards you can hold us to,not values on a wall.

These are the operating rules we work by. Each one is specific enough to be broken, which is the only kind worth publishing. Several of them cost us revenue on purpose.

Book Strategy Call About Negivu

Ownership

You own everything we build, and you can leave whenever you want

A system that stops working when a vendor stops being paid is not infrastructure. We build so that leaving is easy, which is the only real proof that staying is a choice.

  • Accounts are registered to you

    The domain, the hosting account, the CRM subscription, the ad accounts and the automation platform are in your name with you as owner. We hold access as a user, not as the account holder. You can remove that access in a few clicks.

  • Nothing is hidden inside our tooling

    Automations run in your workspace. Site code sits in your installation. There is no proprietary layer that has to be licensed from us for the system to keep functioning after we are gone.

  • The documentation is written for a stranger

    Plain language, naming conventions, what each automation does and what breaks if it is switched off. Written so your next hire or your next provider can pick it up without calling us.

  • Exit does not require our cooperation

    If you decide to move, everything needed is already in your possession. There is no handover fee and no period where the site is held while an invoice is discussed.

Commercial terms

No open-ended retainers

Work is scoped, priced and finished. Ongoing support exists where it genuinely earns its cost — monitoring, optimisation, a build queue — and it is a decision you make again each period, not a default that quietly renews for years.

  • Scope, sequence, cost and intended effect written down before anything starts
  • A fixed plan you approve, so scope creep is our problem to manage rather than your invoice to absorb
  • Nothing we build requires a monthly fee to keep running
  • No minimum term dressed up as a partnership
  • If a month of retained work has nothing worth doing in it, we say so rather than filling it

See how engagements are scoped

How we build

Standards that are decided at design time, not patched afterwards

Most of what gets called optimisation later is really a design decision that was skipped earlier. These are handled at the start because retrofitting them costs more and works less well.

  1. Performance is part of design

    Page weight, image handling, font loading and script discipline are decided while the design is being made, not audited after launch when the layout can no longer change. A slow site is a design outcome, not a hosting accident.

  2. Accessibility is a build requirement

    Contrast, focus states, keyboard paths, labelled form fields and sensible heading structure are part of the definition of done. It is also the same work that makes a site legible to search engines.

  3. Tracking is installed before launch, not after

    If measurement is added later, the first weeks of live data are lost and the launch cannot be evaluated. Events, conversions and source attribution are configured and tested before traffic arrives.

  4. Security and access are scoped tightly

    Credentials are yours, permissions are limited to what each process needs, and integrations use scoped access rather than shared logins. Access can be revoked by you at any time.

  5. Failures are made visible

    Automations break when the tools around them change. Every build includes error alerting so a broken step surfaces the same day instead of being found in a quiet quarter.

Integration

We integrate with what works instead of replacing it to bill you

Replacing a functioning platform is one of the easiest ways for an agency to increase a project’s value. It is also one of the least honest. Where your current tools are doing their job, we build around them.

  • If your CRM is working, we configure it properly rather than migrating you off it
  • If a platform is genuinely holding the system back, we explain the specific limitation and the trade-off of changing
  • We do not add AI to a process that works better as plain automation
  • We do not rebuild a site that converts fine when the real problem is follow-up timing
  • Migration is recommended when the numbers support it, and the numbers are shown to you

Explore our solutions

Reporting

Honest reporting, including the parts that are not working

A report that only contains good news is a sales document. The useful version tells you what to stop funding, and it will sometimes say the thing we built has not earned its place yet.

  • We report against the intended effect

    Each stage of a build is agreed with a purpose. Reporting says whether that purpose was achieved, in the terms it was agreed in, not in whichever metric happened to rise.

  • We name what underperformed

    If a channel, a page or an automation is not producing, it gets stated plainly along with what we propose to do about it or whether it should be switched off.

  • We separate what we can prove from what we believe

    Attribution has limits and we describe them rather than presenting an estimate as a fact. Where the data cannot answer a question, we say that instead of filling the gap.

  • We tell you when you do not need something

    Including when that means a smaller engagement, a delayed phase, or advice that ends with you spending nothing at all. It is the reason clients call back.

Next step

Hold us to it.

Book a strategy call. You will get a straight assessment of where your system is leaking and an honest view of what is worth building — including the parts that are not.

Book Strategy Call