How non-engineers at Digits ship AI-built tools

Digits is an AI-native accounting platform, so it won't surprise you that our own people lean on AI constantly. What did surprise us is where the bottleneck moved. Sometime last year, AI got good enough that anyone here, not just engineers, could ask Claude for a working dashboard and get one. Building stopped being the hard part.

Everything after the build was a cliff. You'd have a beautiful HTML dashboard sitting in a folder on your Mac with no good way to do anything with it. Sharing meant zipping files into Slack. The moment Claude refactored something, your old version was gone. Hosting meant the word "deploy," which meant filing a ticket, which meant the dashboard quietly died in the folder. The numbers inside were baked in at generation time, a screenshot pretending to be software, because reaching our BigQuery warehouse required SQL that most of the company never learned. Every tool looked different from the last, styled however the model felt that day. And the part that kept us up at night was security. Vibe-coded projects full of revenue data or PII were one careless hosting decision away from leaking, with no authentication anywhere in sight.

The Sidekick home feed. Every AI report, analysis, tools at Digits is just a click away.

So we built Sidekick, a Mac app for everyone at Digits who builds with AI. Sidekick doesn't write code. Claude does that. Sidekick handles everything around the code. It hosts the project behind our Google Workspace authentication, attaches a data store, keeps version history, applies the Digits design system, and publishes to a shared feed where teammates discover it. Drop in a single HTML file and it's live in seconds. Drop in an entire folder and Sidekick retrofits it with everything it needs to become publishable, which is how the more complex tools and reports arrive.

If that sounds like something Claude or Codex already do, it’s worth considering the differences between our custom harness and artifact sharing within those tools. Their sharing shows colleagues the html snippets that you made. Everything above turns it into a tool the company can rely on, governed, styled like Digits, version controlled, with a datastore, cloud functions, and with user-level data access permissions. And none of it is welded to one model. Sidekick sits above the AI, not inside it: point it at Claude today, Codex or open source tomorrow, and it's still the one place every project lives, on rails we own instead of a vendor's. Producing the artifact is the part anyone can do now, which is exactly why we put our effort into everything that comes after it, the part that decides whether a one-off becomes something the company can trust and reuse.

Two weeks into our open beta, sign-ins grew 5x in the first week and a new project has gone live roughly every 16 hours since! The builders come from every department, and so far the heaviest ones are people who typically don't write code for a living.

This is how it works, starting with the architecture, which may surprise you.

The backend that isn't there

Our first design for Sidekick's cloud side looked like everyone's first design. Cloud Run services, Firestore, GCS buckets, a Cloudflare worker for URLs. We had it scaffolded before we asked the uncomfortable question: who is this for?

The people we're serving, our internal business teams, live in Google Sheets all day. They already know how to open one, inspect it, and hand-edit a cell when something looks wrong. So instead of inventing storage they'd never see, we rebuilt every project out of pieces they already understand, on infrastructure we could prototype in days and update in seconds. Every Sidekick project is exactly three things in Google Workspace:

• A Google Sheet. The project's data store. Every "table" is a tab, first row is headers.

• An Apps Script project. The code, a Code.gs server file plus an index.html UI, pushed via the Apps Script REST API. With access to our datastores, product metrics, drive, and so much more.

• A Web App deployment. The URL teammates load, served by Google and restricted to our Workspace domain.

Every Sidekick project is three pieces inside Google Workspace. Your Mac publishes, teammates open it behind a digits.com sign-in, and BigQuery data flows in read-only.

That's the entire stack. There’s little for us to operate, and authentication is fully managed by Google Workspace. When a teammate opens your project, Google verifies their digits.com sign-in before a single byte is served. Nobody at Digits can accidentally publish customer data to the open internet.

The Sidekick Mac app is the orchestrator, and even there the AI era shaped the choices. We built it in Tauri rather than native Swift because AI is exceptionally good at React, which let us ship polished, beautifully styled screens about ten times faster than we could have in SwiftUI. The core is Rust because we wanted the app lean and fast. Speed is part of the Digits experience, and we hold our internal tools to the same bar as our product. The app watches your project folder, and on every save it pushes the code to Apps Script, mints a version, and repoints the deployment. The deployment ID never changes, so the link you shared on day one still works on version forty. Rollback is the same trick in reverse.

Even discovery follows the pattern. The home feed, the grid of every project that greets you when Sidekick opens, is itself a Sheet that every install reads directly, with writes funneled through one locked writer script so two people publishing at once never collide.

And it's hard to overstate how small each project is. This is the entire server side of a typical Sidekick dashboard:

// Code.gs: the whole backend
function doGet() {
  return HtmlService.createHtmlOutputFromFile('index');
}

function getNewFirmsByWeek() {
  return SidekickQueries.run('new_firms_by_week');
}

The page renders, calls one server function, and that function runs a saved warehouse query. Everything else, auth, hosting, versioning, data access, is the platform's job.

Live data without learning SQL

A dashboard with baked-in numbers is stale the day it ships. Sidekick projects query our BigQuery warehouse live, every time someone opens them, and the person who built the project never writes a line of SQL. They describe what they want, Claude writes the query, and the library underneath enforces the rules:

// Claude saves the query first, with a required description...
SidekickQueries.save('arr_by_month', sql, 'ARR by month across all firms');

// ...and the app runs it by name. Automating saved queries.
const rows = SidekickQueries.run('arr_by_month');

That library has opinions. It rejects any statement containing DML or DDL before storing or running anything, dry-runs every query and refuses one that would scan more than a gigabyte, and parameterizes inputs rather than concatenating strings. Saved queries live in a tab of the project's own Sheet, so they travel with the project and every collaborator sees the same list.

The best part is what we didn't have to build. Apps Script Web Apps run as their author, so every query executes under the author's own BigQuery permissions. If you can't see a dataset, neither can your dashboard. When IT revokes access, every tool that person built loses it at the same instant. Governance stays exactly where it already lives.

No jargon, ever

Sidekick's primary user has used Claude a few times, knows what an HTML file is, but could not tell you what "deploy" means. They should never have to. We keep an actual list of words banned from the UI, including git, commit, deploy, repo, branch, build, and endpoint. What they see instead is plain language like "save a version," "share," and "make a copy."

Collaboration follows the same philosophy. Multiple people can edit one project, and to users it feels like Google Docs, while underneath it's libgit2 doing real three-way merges between Apps Script versions. When two people change the same line, Sidekick shows a friendly side-by-side view with buttons instead of merge markers. We deliberately keep the AI out of conflict resolution, because "what did you both mean?" is a human question.

Agents need a contract, not vibes

Claude writes every line of application code in the Sidekick world, so the most important interface we maintain is a set of instructions, not an API.

Sidekick ships a companion plugin for Claude whose skill is, in effect, a contract. It spells out what files make a project, the Apps Script runtime's hard limits, the saved-query rules, and the Digits design system, brand tokens and all, so every tool comes out looking like we shipped it and good design thinking lands with the first prompt. Alongside the skill, Sidekick exposes an MCP server for saving queries, publishing, and validating.

Two decisions did more for reliability than anything else. First, validation is the gate. Claude isn't done when it says it's done; it's done when sidekick_validate_project returns ok, and a unit test pins that a passing validation means Sidekick flips the project to ready. The agent and the app agree on one machine-checkable definition of done. Second, handoff is a file. When someone drags in a folder Sidekick can't host directly (a React app, say), Sidekick writes a conversion brief to .sidekick/inbox.md and opens Claude, whose skill says to read the inbox first and work it. The user just sees "your project is being set up."

The handoff loop. Sidekick writes the brief, Claude does the work, and validation is the gate.

The contract even self-heals. When we fixed a bug in the shared query library, we taught the validator to flag stale projects and taught Claude to quietly re-publish on sight of the finding. The fleet patched itself the next time anyone touched a project.

Two weeks in

We opened the beta in late May. By the end of week one, sign-ins had grown 5x, and a new project has gone live about every 16 hours since.

Cumulative projects since internal launch.

Three favorites so far:

Finance stopped waiting in line for the data team. One analyst shipped six live dashboards in his first nine days, covering ARR, unit economics, firm churn, and cash flow forecasting. Questions that used to sit in a request queue are now URLs he checks each morning.

Account managers walk into every call prepared. A Firm Insights dashboard pulls a firms entire picture into one screen, with real-time usage metrics, a deep-dive into ways Digits can further automate their business, and where their time is being spent. What used to mean asking a data scientist to generate is now an impressive tool designed by our AM’s.

A firm insights dashboard in Sidekick gives firms a 360 view of how to make their practice more efficient.

Enablement shipped a tool, not a chart. A converter that transforms QuickBooks exports into the Digits import format now smooths customer migrations. It's exactly the kind of utility that’s incredibly helpful and so challenging to bake into a traditional roadmap.

None of these existed three weeks ago. Each one is a question someone had, an afternoon with Claude, plus a drag onto Sidekick. Because every project lands in the shared feed with a live thumbnail, each one teaches the next person what's possible.

Constraints are the point

Apps Script is not a general-purpose platform, and we lean into that. There are no websockets, requests die at six minutes, and nothing in the stack can write to BigQuery. When an idea needs more than the platform allows, Sidekick says so plainly and offers a path to engineering. We've gotten comfortable saying no to feature requests, because the constraints keep the system understandable and safe for a team whose day job is building Digits, not Sidekick.

The fair critique is that this is a lot of constraint, and it is, on purpose, but it isn't permanent. Because every project lives behind the app instead of directly on Apps Script, the runtime underneath is just an implementation detail; what stays fixed is the contract Claude builds against, validate, publish, saved queries, the design system. The day a project genuinely needs websockets or a long-running job, we can put a different engine behind the same rails without anyone ever noticing.

Similarly Sidekick offers a path into the product roadmap. When a new tool or report becomes a hit and proves its worth, it now prompts a discussion on how to prioritize it into the Digits roadmap.

The operating story is hard to argue with too. Hosting, managed auth, storage, and the database all ride on Workspace, so the marginal infrastructure cost of the platform is zero and there’s no pager.

Who gets to build

We started this project to fix a sharing problem and accidentally changed who builds software at Digits. The distance from "I wonder" to "here's the link" collapsed to under an hour, and it turns out a lot of people were standing at that cliff with something in their hands. Engineers haven't lost anything; they've gained colleagues who answer their own data questions, against live numbers, with guardrails nobody has to think about.

The feed fills up a little more every day, mostly with serious tools, occasionally with something delightful and unnecessary, which we take as a sign of health. The stack still makes us smile. The next time someone says there's no time to build a platform that lets non-engineers ship, remember that ours runs on a spreadsheet, and it's doing fine.