Why we tell you what we cannot do yet

TL;DR

• Every RavGB service page names what the engagement is not, our DevOps page carries a whole “Not what this is” section, and our About page states plainly that RavGB is not yet a registered company.
• Naming the limits is not modesty. It is the thing that makes the claims we do make believable, because a studio willing to lose a sale is unlikely to be bluffing about the rest.
• Honest edges filter the work. Wrong-fit enquiries route themselves elsewhere before they turn into a frustrating call, which leaves the people who want exactly what we are good at.
• A client who knows the edges up front scopes well, so there is no mid-build surprise and the build stays calm.
• Overpromising is expensive later. Saying the true thing once, on the page, costs far less than managing the fallout of not having said it.

What “it is not” looks like on our pages

Most sites only tell you what they do. Ours tell you where the work stops. It is not a disclaimer buried in a footer, and it is not false humility. It is written in the same place you would look to decide whether to hire us.

Open our DevOps page and scroll to the section headed “Not what this is.” It says, in plain words, that we do not build your product under a DevOps engagement, that we do not run 24/7 pager duty with an uptime guarantee, and that we do not run a managed service for you, so when an engagement ends there is nothing of ours left to remove. Each of the four services now carries a short “Not for” line in the same spirit. The websites offer is a home page plus four to six pages shipped in weeks, not a forty-page rebuild dressed up as a quick win. The promotional video offer is one revision pass, stated up front, so the first cut is understood to be a draft and not a take-it-or-leave-it. None of that reads like marketing, because it is not. It is scope, written down before anyone pays for it.

We go further than the services. The About page says that RavGB is an independent studio and not yet a registered company, and that the page will keep saying so until the paperwork is finished. That is the most awkward thing a studio can admit on its own site, and it is exactly why it belongs there. If we are honest about that, the smaller claims cost you nothing to believe.

Naming limits is what makes everything else believable

Here is the uncomfortable truth about claims: anyone can make them, so on their own they are worth very little. “We do everything, we do it fast, and we do it brilliantly” is a sentence every studio on the internet can type. The reader has learned to discount it to roughly zero, because they have been burned by it before.

The moment you also say what you do not do, the arithmetic changes. A studio that volunteers “this is not what we are for” has shown it is willing to walk away from money rather than oversell. That single signal makes the positive claims legible again. When we say a site will meet WCAG 2.1 AA and we have checked it before handoff, the claim lands differently once you have already seen us turn work away on the next page. We can back that particular claim: this very site meets the Web Content Accessibility Guidelines at AA and scores 100 for accessibility in Lighthouse, verified rather than asserted. But the reason you are inclined to believe it is not the number. It is that we have spent credibility elsewhere by admitting limits, so the number reads as a fact instead of a boast.

This is well-trodden ground in user research. The people at the Nielsen Norman Group have spent decades documenting how trust and credibility are built in interfaces and copy, and a recurring theme is that specific, verifiable, occasionally unflattering detail reads as honest, while blanket superlatives read as sales. Admitting a weakness is one of the cheapest ways to make the strengths next to it believable. We did not invent the idea. We just decided to let it run the website instead of fighting it.

Honest edges route the wrong work away

A line that says “this is not what we do” is quietly doing the reader a favour, and doing us one too. It is a filter.

Someone who needs a round-the-clock managed service with a contractual uptime guarantee will read our DevOps page, reach the “Not what this is” section, and leave before they ever send an email. That is the correct outcome for everyone. They are spared a discovery call that was never going to end in a fit, and we are spared the slow, polite conversation where we explain that the thing they assumed was core to the offer is not something we do. The enquiries that do arrive are closer to the work we actually want, because the people sending them have already self-selected against the edges we published.

We would rather field a handful of enquiries that fit than a flood that does not. A smaller studio cannot absorb the wrong-fit ones the way a large agency can, by funnelling them to a junior team or a different department. We do not have a different department. So the filter is not a luxury, it is how the studio stays the size it means to be while still answering the right people the same week. The honesty on the page is the first round of qualification, and it happens before we have spent a minute of anyone’s time.

It produces projects that scope themselves

The expensive failures in client work are rarely technical. They are the moment, halfway through a build, when the client realises the thing they quietly assumed was included was never on the table. Nobody lied. The scope was simply vague enough that two reasonable people read it two different ways, and now there is a gap to argue about with a deadline bearing down.

Published limits close that gap before it opens. When the edges of the work are written down and the client has read them, the project arrives pre-scoped. The websites client knows it is four to six pages and not a sprawling content system. The video client knows there is one revision pass and plans their feedback accordingly, pulling it into a single round instead of a trickle of afterthoughts. The DevOps client knows we are setting up the alerting and the playbooks and that their team holds the pager, so nobody is waiting on us at 2am expecting a response that was never promised. For the shape of a real review, our post on the first things we check when we open an AWS account walks through exactly where a DevOps engagement starts and stops. A build with no hidden assumptions is a calm build, and a calm build is almost always a good one.

Honesty is cheaper to maintain than a good pitch

Overpromising is not free. It just defers the cost to a worse moment. The bill arrives later as the awkward call, the unpaid extra work you take on to save face, the review that mentions the distance between what was pitched and what was delivered, and the referral that never comes because the client left feeling slightly misled even when the work was fine. Managing that fallout takes real time and real goodwill, and it compounds.

Saying the true thing once, on the page, costs a sentence. That is the whole trade. One honest line now against a recurring tax later. The maintenance burden of honesty is close to zero, because reality never contradicts it. The maintenance burden of a generous pitch is open-ended, because every project has to keep paying down the gap between the promise and the thing.

The same logic shows up in how we build, not just how we sell. We argue in why accessible from the start costs less than accessible later that doing the correct thing early is cheaper than retrofitting it under pressure, and honest scope is the same idea pointed at the sales page. The cheap moment to be accurate is before the work starts. The security-hardening line on our DevOps page is deliberately modest for the same reason: we offer a sensible baseline informed by widely reported patterns, such as the widely reported pattern that misconfiguration and over-broad credentials sit near the top of the usual list of breach causes, and we point people at authoritative guidance like the AWS IAM best practices rather than implying we run a compliance program we do not. Underclaiming the security work is itself a form of honesty that is cheaper to live with than the alternative.

We even say it about ourselves

The clearest test of whether a studio means this is whether it will apply the rule to its own status, where it stings. We do. RavGB is run as a small, independent studio, and the About page says it is not yet a registered company and will keep saying so until that changes. We could have left it unsaid. Most would. We wrote it down because the entire argument of this post falls apart the moment we exempt ourselves from it. A studio that names your project’s limits but hides its own is not honest. It is just selectively honest, which readers can smell.

So the not-yet-registered line is not an apology. It is the proof. It is the thing that makes the rest of the site credible, for the same reason the “Not what this is” section makes the DevOps offer credible. We are telling you where we stop so that you can trust us about where we start.

This is a method, not a mood

None of this is a clever trick, and it is not a personality. It is a decision about what scales. Honesty scales, because the truth stays true for free and you only have to say it once. Overpromising does not scale, because every oversold claim has to be propped up for the life of the relationship. We chose the one that gets cheaper over time instead of the one that gets more expensive.

If that is the kind of studio you want to build with, the fastest way to find out whether we fit is to tell us what you need and let us tell you, honestly, whether it is work we should take. Read what we do and what each engagement is not, then tell us what you want to build. We read every message, we reply within a day or two, and if we are not the right people for it, we will say so.