attune.co · /build
subscribe →

What Eight People Ship

We’re eight people with the workload of twenty. We don’t have a BD team, a design agency, or analysts. We have a shared Google Drive, a terminal, and the willingness to spend our Fridays building something we can’t fully see yet.

I automated our financial forecast updates

Every month I reconcile our credit card transactions against the financial model. That means matching every single charge to its projected line item, flagging anything that’s off, and updating projections going forward. If our projections drift from what we’re actually spending, we lose visibility into runway, and for a company of our size and stage, that’s not something you want to lose track of.

In practice this meant pulling up the credit card statements and the model side by side, going transaction by transaction, vendor by vendor, checking amounts against what we’d projected. Variable stuff like team meals and travel made it worse since those don’t map to a single vendor; I’d have to aggregate and categorize manually. The whole thing takes me about 90 minutes, and it is tedious enough that I just didn’t do it for October, November, or December last year.

what didn’t work

I tried getting Claude to help before — through projects, extensive prompts — but none of it felt like less work. I would download CSVs, paste them into a chat, try to get it to match transactions to projections. It never worked because there’s too much nuance in the matching: Is this a recurring charge or a one-off? Is the amount different because the vendor changed their pricing, or because of an FX conversion? Is “AMZN MKTP US” the same as “Amazon Web Services”? I tried projects, I tried building the logic into prompts — but when you’re asking Claude in a chat to do this work, it never really captured what it actually means to reconcile expenses against real-world data.

Last Friday I decided: instead of spending 90 minutes doing this manually, I’ll spend 90 minutes building the thing that does it. I connected two MCP servers to Claude Code (one to our corporate card, one to Google Sheets where the model lives), then worked with Claude to build a slash command with the full reconciliation logic baked in. It pulls all cleared transactions for a given month, reads the entire Expenses tab from the financial model, and matches each transaction to its model line using a merchant mapping table I built into the command. “TWILIO SENDGRID” becomes SendGrid. Restaurants roll up to the Team Meals budget. FX charges use the USD settlement amount. It classifies every match into tiers (fixed recurring, variable recurring, annual/periodic, one-off), flags discrepancies, catches cancelled subscriptions and zeroes them across all future months. Then it presents me with a full reconciliation report, and once I approve, it executes the changes: updating the actuals and rolling projections forward through the end of next year. Every edit in the model made by Claude gets highlighted in an obnoxious colour in the sheet so I can scan it visually.

~90 min
How long the manual reconciliation took. Tedious enough to skip three months.
~5 min
How long it takes now. Review the report, approve the changes, done.

For January 2026, the full reconciliation and projection updates were done in about five minutes. The accuracy is really high because the instructions are flexible and the model under the hood is intelligent enough to make its own judgements on the edge cases. What took me 90 minutes to do every month has become some kind of fun game. I can finally see myself sticking to this process.

The reason I can build something like this in under 90 minutes, and make it usable by others, is because of everything that came before it.


It started with a question

About a year ago, I started experimenting with Zapier to help our GTM team do more with less. I automated our post-meeting workflow: as soon as a new meeting transcript with a client appears in the cloud, Claude processes it, an email recap comes out (with a summary for the client and action items for our team), and new tasks land in Asana assigned to the right person. The architecture was, frankly, pretty terrible. It spent all of our Zapier tokens (‘tasks’) for just about three workflows. But it worked and it showed everyone what was possible when you stop accepting that tedious things have to stay tedious.

Once we saw the value that created across the team, I decided to make my Fridays non-negotiable: a dedicated space to experiment with AI, try things, fail, learn, and hopefully build something highly valuable. The tedious stuff was eating into the work we actually cared about, and I was genuinely excited to find out what was possible.

I started by asking my teammates a simple question: what are the things that are detracting you from work you’re actually excited about?

I built a lead nurturing system that reminded our team to follow up with prospects on a cadence tailored to each relationship. With 9 to 12 month sales cycles and leads telling us “reach out later” with no precise timing, it was easy for people to fall through the cracks. The system scanned our communication channels and made sure they didn’t.

Eventually Zapier hit its limits. The automations got stale as our positioning evolved. Rebuilding them was slow because everything in Zapier was prescriptive (I know they keep adding new features but I don’t keep up with what they offer anymore) — you build automations element by element, and when the business changes, you rebuild element by element. So I moved on.

The real shift happened when our team started using Claude Code. Suddenly the download-upload-paste-lose-context cycle was gone. But it created a new problem: everyone was doing amazing work in their own Claude sessions, and none of that knowledge was making it back into shared systems. We went from “all work happens in shared environments” to “the best work happens in private chats that nobody else can see.”


The Second Brain, version five (and counting)

Raj, our technical consultant, had been toying with the idea of a second brain: an extension outside of your own brain that holds your context, your knowledge, your artefacts. He gave us the first series of documents and set up the filesystem connection that let Claude Code access our Google Drive directly. I took that and started building it into a system that could work for the whole company.

I rebuilt this thing four or five times. The first versions were just folders within folders: artefacts and transcripts organized so Claude could find them. But it didn’t scale, and it wasn’t fast, and two people with different workflows would get completely different results. Around the same time, we started running into context length issues. Raj and I both came to the same conclusion: we needed to restructure how information was organized internally. He suggested indexing, and from there I baked the Second Brain into all of our existing systems.

What finally worked was treating AI as infrastructure, not a side project. That distinction matters more than anything else I’ve learned.

When AI is a step in the process, you use it sometimes, it helps sometimes, and the system around it stays the same. Things change when AI is the infrastructure — the thing you work in, the default environment where knowledge lives. The context it has, the speed of navigation, the ability for one person’s work to compound into another person’s capability. None of that is possible when Claude is sitting in a separate tab.

So I reorganized our entire Google Drive. Six years of organically grown content, restructured around two principles: information has to be findable by humans, and it has to be findable by AI. I created thematic drives with permission boundaries, a clear folder and subfolder structure, and mechanisms for archiving stale content. I built index files for every major folder; a layer of navigation that tells any future Claude instance exactly where to look based on the topic and the person asking. And I wrote a set of instructions that loads every time anyone on the team opens Claude Code from our shared directory that has the ground rules for how it should interact with the content in our systems.

Now when someone types a question, Claude doesn’t search. It navigates. It knows the map. It knows who’s asking. It knows where client files live, where our financials live, where product decisions live. And it gets there in seconds without wasting the context window, letting us do more in every session. Most importantly, it captures new knowledge and ideas we develop in every session into artefacts, commands, and skills accessible to everyone on the team.


People started building without being asked

I presented the Second Brain to our full team in the first week of February. I showed them how it works: the onboarding, the transcript sorting, the daily logs, the skills and commands everyone can now access with their own Claude. Then I did a live demo, asking Claude to pull feature requests from a client’s meeting transcripts and emails. We all watched it navigate the drive, find the right folders, read through the sources, then realize it needed more context and go look for it on its own.

That same meeting, Claire, our Head of GTM, shared that she and Andy, our CEO, had already started building a GTM automation system on top of the same infrastructure. She’d read an article about Natalia Quintero, Every’s Head of AI Consulting, who had automated her project management workflow. Claire told Claude: “This is what I want to do for all of go-to-market.” Her first instruction was: “Do your best to build on what’s already in the Second Brain. Don’t rebuild what already exists.”

That’s when it clicked for me. The system was working not because I told everyone to use it, but because they started building on top of it without being asked.


What eight people ship

That was three weeks ago. Here’s what happened last week.

Raj built complete relationship timelines for five major clients: full six-year narratives synthesized from hundreds of email threads, meeting transcripts, contracts, and internal docs. Each one includes a stakeholder registry, competitive landscape, strategic analysis, and open questions. For one client alone, he processed 346 sources. This is the kind of deep synthesis that helps us build a product we have no doubt our clients will love; the kind of work that would have been impossible to do manually before these tools.

346
Sources processed for a single client relationship timeline. Emails, transcripts, contracts, and internal docs synthesized into a six-year narrative.

Claire, our Head of GTM, built four slash commands that run her entire weekly operating rhythm. Customer success sync, sales pipeline sync, partnership sync, marketing sync. Each one pulls live data from Asana, Gmail, and Google Drive, analyzes account health and deal momentum, presents a decision interface, then executes on the decisions she makes: updating tasks, drafting emails, flagging risks. She also built a skill to run her post-meeting workflows; meeting transcript goes in, recap email comes out, action items land in Asana assigned to the right person at the right time (a lot like what we used to have in Zapier but way smarter). What used to take up all of every Monday is now a few commands. The time she gets back goes into the work she’s excited about: building our pilot proposals, refining our positioning, designing our marketing strategy.

Andy, our CEO, has been deep in positioning and product strategy. Over the last week and a half, he’s been pulling from the relationship timelines and customer insights that Raj synthesized, reviewing them against our positioning, and pressure-testing every angle. He’s been building product mockups, putting different versions side by side so the team can see the contrasts, writing PRDs, creating sprint plans, spinning up code repositories and scoring engines, building out our website, and updating the frameworks we use internally to make decisions. All of it feeds back into the same shared system so that when one thing changes, everything downstream updates with it. The volume of what he’s been able to produce and the speed at which our product direction has crystallized is something that would have taken months and dozens of people in a traditional work environment.

I (Head of AI and Ops or Haio!!) locked our visual design system, drafted our quarterly planning agenda and started building the machine to make this a repeatable process, and built two new cash flow automation skills. I also built a fully automatic transcript sorting system: our meeting recordings get synced, deduplicated, matched to the right client or project, and filed into the correct folders without me touching anything. It runs on a schedule every afternoon, and when it’s done it pops up a report on my screen to quickly review.

We’re eight people. We don’t have a BD team. We don’t have a design agency. We don’t have analysts. We have Attune, a financial health infrastructure company, and an incredibly ambitious set of goals for this year.


We’re having so much more fun

The thing that surprises me most about all of this isn’t the speed or the output. It’s that we’re having more fun, and many of us are not technical. We’re eight people and we spend more time together showing each other things we learned and cool things we did. Someone builds a new skill, someone else runs it and comes back with feedback. Claire builds a weekly sync system and Andy runs it the next morning and responds to a prospect within minutes. I build a reconciliation command and share it in Slack and people start asking what else they can automate.

We’re not chasing anything. We’re not trying to be on the cutting edge. We don’t appreciate the “if you’re not doing this then you’re failing” tone, and we are inherently sceptical about the hottest new AI release. We’re a small team that figured out, mostly through trial and error and a lot of rebuilding, that when you make AI the place where work happens instead of a tool you sometimes use, the work gets better and the people doing it get closer.


This is the first of many

This is the first in a series of pieces from our team. We’ll go deeper on the specific builds (how the post-meeting workflow actually works, what the Second Brain architecture looks like, what broke along the way). Different people will tell different parts of the story.

But I wanted to start here, with the big picture, because when I look at what our team achieved last week I still can’t quite believe it. I think there are other small teams out there, running lean with big goals, who would benefit from knowing that this kind of thing is possible: with just eight people, a shared Google Drive, and the willingness to spend your Fridays building something you can’t fully see yet.