A studio brief is a wish written in the language the client thinks we want to hear. It is rarely a description of the problem. Across roughly 40 engagements in the last year — enterprise, mid-market, government, and a few well-funded startups — we kept a small note pinned to the wall: what they asked for / what they needed. The two columns are almost never the same. Five patterns showed up over and over.
01 — "We need an AI feature"
By a large margin, the most common brief in 2026 starts with "we want to add AI to X." When we sit down with the team that actually owns X, the first hour is usually spent discovering that X is not a workflow — it's a folder of inherited habits, three Excel files, and one heroic person who knows the exceptions. No model in the world fixes that.
What the client needs first is the workflow written down: inputs, decisions, owners, exceptions, escalation paths. Once that exists, the AI feature is often a two-week build. Without it, the AI feature is a two-quarter project that ships something nobody trusts. We now budget the first sprint of every "AI feature" engagement for workflow archaeology, and we have stopped apologising for it.
02 — "Build us a dashboard"
Dashboards are the universal client request and the universal disappointment. A dashboard is what gets asked for when the real ask — "I don't know what's happening in my business" — is too uncomfortable to say out loud.
In nearly every dashboard engagement, the actual need turns out to be three to five decisions the leadership team is failing to make on a regular cadence. The right artefact is usually not a dashboard at all. It's a weekly one-page report, a single alert when one number crosses a threshold, or a meeting structure that forces those decisions. We've delivered "the dashboard" as a Slack bot, a Monday-morning email, and once as a printed sheet of paper. Each one outperformed the dashboard the client originally asked for.
03 — "We want to replace [vendor]"
Vendor frustration is real, and the urge to rip and replace is understandable. But "replace Salesforce" or "replace SAP" is almost never the right scope. The client is unhappy with two or three specific workflows that the incumbent platform handles badly. The other eighty workflows it handles fine — and replacing those costs ten times more than the value it returns.
The honest reframe we now offer in kickoff is: which three workflows is the incumbent failing at, and what would it take to surgically replace only those? Most clients exhale when they hear this. The boardroom pitch was "replace the vendor"; the actual job to be done was "make the renewals team stop hating Mondays." Those are very different projects, and the second one ships.
The boardroom pitch was "replace the vendor." The actual job was "make the renewals team stop hating Mondays." — Kickoff notes, Q3 2025
04 — "We need it to scale to a million users"
Scale anxiety is the most expensive form of anxiety in software. We hear it from seed-stage startups with no users and from mid-market companies with predictable, bounded customer bases. In neither case is "a million users" the real constraint.
The real constraint is almost always: surviving the next major customer launch, passing a security audit, supporting a new region's regulatory regime, or onboarding the next ten enterprise accounts without the team burning out. These have concrete, near-term shapes. They demand specific engineering — not abstract scalability. A system designed for "a million users" usually serves the actual hundred users worse, costs three times more to run, and slows every feature shipped against it. We push back on scale framing every time, and we have yet to regret it.
05 — "We need it custom"
The mirror image of pattern 3. A client who has been burned by off-the-shelf software will sometimes arrive convinced that everything must be bespoke. It's an understandable overcorrection and an expensive one.
In every "fully custom" build we've shipped, the parts the client actually cared about — the parts that made the system valuable to their business — were a clearly identifiable 20% of the surface area. The other 80% was authentication, audit logs, file uploads, search, role management, exports: solved problems with mature, boring components. Choosing well-trodden libraries for the 80% lets us spend our budget where it matters, which is the custom 20%. Clients who let us draw that line consistently get better systems for less money. Clients who insist on artisanal versions of solved problems get worse systems for more money.
What we tell new clients in kickoff
Two things, every time.
The brief is never the job. The job is always one layer underneath it. The studios that thrive are the ones willing to dig the extra layer before they start cutting code.
Graffitecs is a small, loud studio in Lahore, Pakistan. Est. 2017. We build software, occasionally ship products of our own (Vero, DocEngine), and write things down when we have something to say.
