Get in touch
Gabs

Case study by Gabriel Espinheira, senior full-stack engineer

SharpOS, the platform my studio runs on

One workspace per client for pages, boards, forms, customers, audits and support, on web, macOS and iOS. I build it as its only engineer, directing coding agents.

The brief

One studio, many clients, one workspace each

The problem

My studio, SharpHaw, runs websites, ads, content and automations for small businesses across Europe. Every client comes with pages, boards, forms, customers, site audits, media, a brand kit and support conversations.

Who it's for

The SharpHaw team and its clients, who share one hub. Each client gets an organization where every item is marked for the client or internal, and access is set per area and per resource.

What it does

SharpOS keeps a client's pages, boards, forms, customers, audits, Studio posts and support inbox in one place. AI agents work in that same workspace through REST and MCP.

My role

I'm its only engineer, directing coding agents, from the data model to the interface. It has shipped 104 releases since 08/04/2026, and SharpHaw runs on it every day.

2,734

commits since 24/03/2026

104

releases, about four a week

39,770

unit tests, plus 140 end-to-end

220

operations people and agents share

Counted from the repository on 07/10/2026. Test figures come from the coverage report of 12/09/2026.

Tech stack

Three apps on one TypeScript codebase and one Convex backend

Open a tool to see what it does in this product.

Interface

Apps and backend

AI and agents

Delivery

Features

What a client's workspace holds

SharpOS ships 26 feature modules. Open one to see how it works.

Cards with typed properties, shown as columns, a table, a grid or a calendar, live in every window.

A page in the block editor on a demo organization: a launch plan with a budget table and a checklist.

Briefs and plans several people edit at once, in a page, a card or a customer note.

Forms on SharpOS or the client's own site, where a submission starts the work.

Social posts designed from templates on a canvas, then exported together.

A website assistant that answers from each client's own knowledge base, then hands over to the team.

An agent audits the client's site and pushes in nine scores and a fix-first queue.

Shipping

104 releases, about four a week

Commits per week from 24/03 to 06/10/2026, merges excluded, with v1.0 (08/04), v2.0 (08/07) and v3.0 (04/09) marked. The tallest week, 358 commits from 31/08, is the move to 53 modules.
Commits per week from 24/03 to 06/10/2026, merges excluded, with v1.0 (08/04), v2.0 (08/07) and v3.0 (04/09) marked. The tallest week, 358 commits from 31/08, is the move to 53 modules.
Week ofCommits
23/03/202687
30/03/2026116
06/04/2026171
13/04/2026105
20/04/2026132
27/04/202689
04/05/202675
11/05/2026133
18/05/202684
25/05/202621
01/06/202654
08/06/202658
15/06/202633
22/06/2026194
29/06/202662
06/07/202687
13/07/202614
20/07/202647
27/07/202694
03/08/202665
10/08/202667
17/08/202699
24/08/2026132
31/08/2026358
07/09/202668
14/09/202641
21/09/202685
28/09/20261
05/10/20263

Engineering

Built with agents, held together by tests

Open a topic for the decisions and the numbers behind it.

  • 220

    operations in REST and MCP

    REST and MCP share one registry of 220 operations, such as creating a card, each one scoped.

  • 53

    versioned modules in four tiers

    53 versioned modules in four tiers, shipped together on one deployment.

  • 94.6%

    line coverage across 103k measured lines

    Every change starts from a failing test and passes one required gate.

  • v3.4.1

    latest release, 06/10/2026

    Each release is a pull request that tags the version and publishes the notes.

  • 329

    commits from v2.5.5 to v3.0.0

    How a codebase knotted into one cycle became 53 modules, one revertable step at a time.