We replaced a 12-tool client stack with one workspace we built. Here's the row we couldn't.

SharpHaw — Mon, 31 Aug 2026 13:00:25 +0000

Ask a small agency how the monthly client update gets made and you'll hear a version of the same answer: someone stitches four or five tools into a document. A Trello board, a Drive folder, a GA4 view, a Semrush export, a Figma file. Ask the client what they make of that document and you get the other answer, verbatim from a small-business forum: "I don't even know what they do for $225 a month."

I run SharpHaw, a small agency in Lisbon, and I'm the engineer who built SharpOS, the workspace we run every client engagement in. This is our first post on DEV, so it does the introductions: what SharpHaw is, what SharpOS replaced, how it's put together, and the one row on our replacement ledger we couldn't replace. Later posts take one surface at a time.

TL;DR: we stopped stitching tools into reports and built the workspace the work itself happens in. The client reads the same screen we work on.

What SharpHaw is, in one paragraph

SharpHaw is a growth subscription for owner-operated European businesses: a conversion-first website, Meta and Google ads, a content engine and AI automations, run by one senior engineer on a weekly shipping cadence for a fixed monthly fee, with no annual contract. Before starting it I was a Senior Software Engineer inside large companies, working on products used by thousands of businesses across Europe, and I still run the engineering myself. We work with founders across 19 European countries, in English and, when it helps, in Portuguese.

The promise under all of that is short. The work is visible without asking. SharpOS is how we keep it.

The stack a client engagement normally runs on

An engagement like ours would normally run across a dozen tools, and the client holds a login to maybe two of them. This is the replacement ledger from our features page. Each row names two familiar products so you can place it; the row is the point, the brands are anchors.

	Old stack	SharpOS
01	Notion, Confluence	Pages
02	Trello, Asana	Boards
03	Salesforce, HubSpot	Customers
04	Google Forms, Typeform	Forms
05	Semrush, Lighthouse	Audits
06	Google Drive, Dropbox	Media Center
07	Figma, Canva	Studio
08	A brand guidelines PDF	Brand Kit
09	Zapier, n8n	Automations
10	Intercom, Zendesk	Support
11	Linktree, Bio.link	Spotlight
12	Google Calendar, Google Sheets, Cal.com, Resend, WhatsApp, Facebook, ElevenLabs, OpenAI, OpenRouter	Integrations
13	Looker, Google Analytics	Analytics
14	Asking for an update, then waiting on the reply	Live work, all the time

Twelve of those rows replace something. Row 12 replaces nothing — I'll come back to it. Row 14 is the reason the other thirteen exist.

Cost was never the argument. Each tool is "only" thirty or fifty euros a seat until you multiply it out, sure, and a founder who benchmarks a subscription against hiring a marketer doesn't blink at it either way. What makes them blink is paying for months and being unable to point at what changed.

Why we didn't buy a client portal

The obvious move is to keep the tools and buy a portal: a branded login where the client sees dashboards, files and a status list. We looked at that and walked away, for a reason that has nothing to do with feature lists.

A portal is where the work gets copied to. A workspace is where it gets done.

Every portal I've watched decays the same way. The real board lives in whatever the team likes, the portal gets updated when someone remembers, and within a quarter the client is emailing for an update again because the portal is three weeks stale. The r/DigitalMarketing thread asking "Is everyone stitching 3–5 tools every week/month?" is the same failure seen from the agency's chair. Visibility that somebody has to remember to produce is a chore, and chores get skipped. You can hold that off with discipline for a while; we wanted it held off by structure.

So the design constraint for SharpOS was blunt: the agency does its work inside it or the whole thing is theatre. Our editorial playbook is a page tree in Pages. The weekly queue for every engagement is a board. When I move a card from Review to Approved, the client sees the card move. There is no second copy to keep in sync, because there is no second place.

How it's built

The parts a developer would ask about.

The organisation is the tenant boundary. Each client is an Organization. Every query and mutation scopes to the requesting user's org, membership is verified server-side, and data never crosses orgs in either direction. Inside an org there are four roles (owner, manager, editor, viewer), and every piece of content is either client, which every member can see, or internal, which only platform admins can see or toggle. Even an owner can't flip it. A child is never more permissive than its parent.

Feature flags are enforced on both sides. Platform admins switch the 23 surfaces on or off per organisation. Hiding a nav item is not enforcement, so every backend access path checks the flag itself, and a disabled feature stays rejected server-side even when a UI entry point leaks.

One operation registry feeds humans and machines. Core operations are defined once as IntegrationOperation contracts; the REST API under /integrations/v1 and the MCP server are sibling adapters over the same definitions. As of this week that's 201 canonical operations and 125 MCP semantic tools, with 100% of the operations reachable from both sides. Scopes are fail-closed. The registry is an exhaustive Record, so adding an operation without a scope entry is a compile error, and an operation missing from the registry at runtime is a 403 rather than a pass.

The stack. Next.js 16 and React 19 in front; Convex for the database, functions, storage, realtime and HTTP; Better Auth with its organisation plugin for identity; BlockNote for the editor, with Convex's ProseMirror sync and presence components underneath so two people can type in the same brief; Tailwind v4 and shadcn/ui; Bun workspaces, Turborepo, Biome, Vitest and Playwright. It runs in the browser.

The size of it. 23 flagged surfaces, 49 feature docs, about five months since the first commit, a bit over two thousand commits, one engineer. Read that as a consequence of the architecture above, and as a warning: it's also the bill I get to at the end.

Where each service lands

The agency sells four things. Each one has a home in the workspace, which is how the client can tell the service is happening.

Conversion-First Websites. Audits hold the site checks and track each finding to done, instead of a PDF that vanishes after a week. Forms collect the enquiries the site produces. Analytics shows what moved. The brief for every change is a page; the change itself is a card.
Ads Management. Ads reads the organisation's own Meta account through a read-only grant (campaign-level spend, delivery, conversions, ROAS), so nobody has to log into Ads Manager to see where the money went. Customers keeps the leads next to the spend that produced them.
AI Automations. Automations is a canvas of triggers and actions over everything in the hub (boards, forms, customers, inbound webhooks, schedules), with every run recorded and replayable. Integrations connects the accounts the automations act through. Support is a chat widget on the client's site, answered from the organisation's own knowledge base. And because REST and MCP sit on the same registry as the UI, an agent operates the org the way a person does.
Content Engine. The playbook lives in Pages, each channel has its own board, Studio renders visuals from templates, Brand Kit holds the colours and type, Media Center holds the files, Spotlight is the link-in-bio. This article is a card on the Dev.to board; once it's approved it goes out through the organisation's connected DEV account. ## The row we couldn't replace, and what we gave up

Row 12. SharpOS doesn't replace Google Calendar, Sheets, Cal.com, Resend, WhatsApp, Facebook, ElevenLabs, OpenAI or OpenRouter. It connects to them. The client keeps paying for those accounts, and any all-in-one that tells you otherwise is being vague about where the world's data actually lives.

There's a second cost, and it's the one I'd want to hear about from anyone who built instead of bought. Every surface in the ledger is shallower than the tool it stands in for. Studio is not Figma. Automations connects around fifteen providers, not thousands. Audits will not out-crawl a dedicated SEO suite. The bet is that, for a client engagement, one place the client will read and an agent can operate beats depth in twelve places they'd never open. I think the bet is right. I also know it's mine to maintain for as long as SharpHaw exists — that is the real price of building.

What's next

This is part one of a series that takes the ledger a row at a time: how Boards became a database with a kanban on top, how a Studio frame becomes a PNG an agent can publish, why Support has no human handover, and what an MCP surface over 201 operations looks like in an agent's hands. The ledger with the logos lives at sharphaw.digital/features.

One question for the people who've been here: if you consolidated your stack, or looked hard at it and refused, which was the row you couldn't replace?