The Conjuring Standard

The line under our name says we don't just develop — we conjure every line of code & pixel. The first person outside the studio who read it asked whether conjure wasn't a bit much for a boutique software studio that will spend most of its life writing TypeScript and reviewing pull requests. It's a fair question. I kept the word, and this is the argument for it.

Conjuring names an effect, not a method. When software feels slightly impossible — the list that scrolls without a stutter on a four-year-old phone, the form that recovers your half-typed answer after a dropped connection, the release nobody had to warn anybody about — you are not watching magic. You are watching the absence of the twelve small failures you have been trained to expect. Magic works by hiding labour. Engineering works by choosing to do the invisible labour on a Tuesday when no one will ever see the version where you didn't.

Conjuring is not a mood. It is a standard: a list of things we do every time, and most especially in the weeks when skipping them would cost nothing today.

Standards are unfashionable because they sound like bureaucracy. They aren't. A standard is the thing that decides for you at 6pm on a Thursday, when the client is happy, the demo passed, and the correct next move is another two hours of work that will make no visible difference. Taste alone loses that argument every time. A written standard wins it about half the time, which is the whole margin between studios.

We hire architects, not assemblers

The distinction isn't seniority and it isn't titles. An assembler asks what the ticket says. An architect asks what the ticket implies in month eighteen, when three other features depend on the shortcut it proposes. Both people write working code. Only one of them is still cheap to employ in year two.

Typing code was never the scarce skill, and it is getting less scarce by the quarter. What stays scarce is judgment: which invariant is load-bearing, which abstraction is worth its weight, which requested feature is really two features and a misunderstanding. An assembler adds the thing that was asked for. An architect asks what has to be deleted now that the thing exists — and is willing to say no, and here's what I'd build instead, to me, in writing.

So the hiring bar is a judgment bar. I want the internal arguments in this studio to be about deletion, not addition. Anyone can lengthen a backlog.

Say what the thing is not

Every system has a boundary where it stops being true. Caches go stale. Estimates assume a scope. Models are confident about things they have never seen. The industry's default is to leave that boundary out of the sentence and hope nobody meets it in production. Our rule runs the other way: the limit belongs in the interface, in the same type size as the promise.

The sentence that admits a limit is part of the product. If it isn't in the interface, we haven't finished shipping.

It is already visible in the two places we have to be honest about. The pricing calculator puts the caveat where the number is rather than in a footer: an estimate holds until scope and discovery say otherwise. The money-back guarantee names every condition attached to it in the same breath as the promise. Publishing the conditions costs a little conversion and buys the only thing worth having on day one, which is a client who is not surprised in month three.

Related, and just as binding: numbers do the persuading. "Fast" is a report on how we feel about our own work. "180 ms at the 95th percentile, on a mid-range Android over 4G" is a claim you can go and falsify. Adjectives ask to be believed; numbers ask to be checked. We would rather be checked, and when we don't have the measurement yet, the honest move is to say the measurement doesn't exist rather than reach for a bigger adjective.

Cleanup on unmount is a moral position

Here is the smallest example I know of the standard, and the one I use to explain it to people who think this is all abstract. An interactive component acquires things while it lives: timers, event listeners, sockets, observers, animation frames, a GPU context. Nothing in the language forces you to give them back when the component goes away. Skip it and the app still works — the tests pass, the demo lands, the feature ships.

Then someone navigates around your product for twenty minutes. The abandoned timers are all still firing. The phone gets warm, the laptop fan spins up, the tab that was fine on your desk dies on a commuter train. Nobody files that bug as you forgot a cleanup function; they file it as "the app is heavy", or more often they file nothing and stop using it.

I call it a moral position because it costs an afternoon and buys nothing you can put in a demo. You do it for a machine you will never see, owned by a person who will never know they were spared. That instinct scales to everything above it: sessions that actually end, jobs that stop when you cancel them, caches with an expiry someone chose on purpose, features that get removed once they stop earning their maintenance. Software that doesn't tidy up after itself is software that doesn't respect the machine it is a guest on.

Why a small studio publishes its prices

Information asymmetry is this industry's favourite trick and its oldest one. "Contact us for pricing" does not mean the price is complicated; it means the price is negotiable in a direction that depends on what the agency can guess about your budget. The number exists before the call. The call is about who learns it first.

We published ours on day one, with the arithmetic on screen — units per line item, the multipliers, the range, the weeks. You can reach a number at two in the morning without meeting anybody, and if the number is wrong for you, you have lost ninety seconds instead of two meetings and a week of politeness.

This has a real cost and I would rather state it than pretend the choice was free. It hands our rate card to competitors, it invites comparison on price with people who will happily undercut us, and it removes the option of charging two clients differently for identical work. I don't want that option. A price you would be embarrassed to publish is a price you should be embarrassed to charge.

The 100% money-back guarantee is the same idea wearing a price tag. If the project fails to launch before the contracted deadline, you don't pay. It converts our confidence from an adjective into a liability on our side of the table, which is the only form of confidence a buyer can act on.

There is a version of all this that applies before anyone becomes a client, and it is the part most studios treat as decoration. What we owe a visitor: pages that load quickly on the phone they actually own, a price they can find without surrendering an email address, no countdown that resets on reload, no cookie dialog engineered so the wrong button is easier to hit, no widget pretending to be a person who is delighted to help. Dark patterns are just a standard pointed at the customer instead of the code.

None of this is impressive in week one. Anybody can hold a standard while the studio is small, the calendar is empty and no deadline has bared its teeth yet. The reason to write it down now is precisely that it will be inconvenient later, and a written standard is falsifiable in a way a company value never is. The site went live six days ago and the prices have been public since the first hour. Both are checkable. Please check them.