Systems I've built and teams I've worked with

The problem

One of my clients, a nonprofit growing fast, had outgrown the way it ran. Contractor invoices, expense reports, advances, procurement, contracts, and activity reports were all handled by email and across separate documents. That worked when there were only a few things to track. With more than 20 contractors, four staff, and around 40 active work orders, the volume had become too much to hold together by hand.

The harder problem was oversight. It was difficult to see how much of a work order had been spent or when it was about to expire, difficult to keep a clear picture of grants and their reporting schedules, and slow to reconcile advances and expenses one at a time. The leadership team was spending real hours each week tracking down numbers, time that needed to go to the technical work only they could do. This is the exact moment I'm built for: an organization growing faster than its systems can keep up.

It was also the clearest pain point the team named when I started, so it's where we began. I build from where the pain actually is, not where I'd prefer to start.

How I built it

I'm not a developer. I built this system myself, without an engineering team, using the same tools I teach other non-technical people to use.

Before I built anything, I spent weeks understanding the process. Getting it out of people's heads and into clear flowcharts, understanding what the policies required, mapping every decision, approval, and handoff until there was no ambiguity left. That became a product requirements document that sharpened over weeks.

Then I designed the tech stack around what the system needed to do: Lovable for the interfaces, Supabase for the database, n8n for the automation, DocuSign for signatures. I had both Claude and Codex review the plan independently for where it might break, and rewrote it based on what they found. We scoped versions, starting with a minimum viable product. As it came together, I tested every integration and handoff, ran a separate test environment alongside the live one, kept everything under version control, and updated the requirements document with every change.

The whole build took four weeks, end to end. With a traditional development team it would have taken months and a budget the organization didn't have.

The approval queue. An invoice that would push a work order over budget can't be approved. The system blocks it before it happens.

What it does

The system runs the operational core end to end: procurement, contracts, contractor onboarding, invoicing, advances and expenses, and grant management. A few pieces show what that means in practice:

• An invoice can never push a work order over its budget. The system blocks the approval before it happens, so overspend is prevented, not discovered later.
• Contracts and work orders are generated and routed for signature automatically through DocuSign.
• Each contractor logs into their own portal, sees only their own files, and submits invoices and reports. Their data stays theirs.
• Admin gets one view across everything: outstanding invoices, expiring work orders, and spend against budget.

One view of the money: budget, spend, and remaining balance across every grant, updated as invoices are approved and actuals come in.

The audit trail

Every file, every receipt, every contract, every activity report is entered through the portal and then saved automatically into the right folder in the team's shared drive. Around 60 documents a month, filed without anyone touching them. The apps are the interface. The drive is the permanent, browseable record, audit-ready even if no one ever opens the system. For a nonprofit answering to funders, that matters as much as anything else the system does.

Rollout and adoption

A system only works if the people it's built for actually use it. So the rollout was as deliberate as the build. I made training videos, ran live sessions to walk the team through each part, set up a help desk so questions got answered as they came up, and supported the team directly through the transition. By the time it was fully live, it wasn't a tool sitting off to the side. It was how the team worked.

The result

The leadership team gets back around four hours a week each, time that now goes to the technical work only they can do. They went from chasing numbers to having them: automated alerts when something needs attention, a live view of spend and expiry, and the confidence to make decisions from real data. The administrative load stopped competing with the mission.

I built this as the organization's fractional COO. If you wanted something this size today, I'd scope it as a larger discrete build, priced on its own, or build it as part of an Embedded AI Partner engagement.

The problem

Tandem, an early-stage consumer startup, needed to run real marketing campaigns: landing pages, email sequences, paid ads, video, all tailored to distinct customer personas. The team was very small, with one part-time marketing manager who had nowhere near the time to build out multiple campaigns, and founders already stretched across product and everything else. A single campaign done properly means dozens of assets, each needing strategy, copy, imagery, review, and then daily management once it's live. Done by hand, that wasn't going to happen at the pace the business needed.

The standard answer is to do less marketing, or do it worse. Instead we reimagined the marketing function with AI in the loop from the start. And the goal was never one campaign. It was a marketing function that improves itself every time it runs.

The foundation came first

This engine produces work worth publishing because of what we fed it before asking for anything.

We spent significant time up front building the knowledge foundation: the brand voice, the visual style guides, the messaging pillars, the product's real capabilities, marketing strategy itself. Then the audience layer: extensive research into current market signals around the ideal client profile, distilled into a standing library of eight personas, each a named individual with a life, fears, and reasons to buy, each representing a different audience type.

Every campaign starts by going back to that foundation. A research agent produces a campaign-specific brief, grounded in live web research and the brand's own knowledge base, and identifies the two or three personas most likely to buy for this particular campaign. Everything downstream flows from that choice.

The standing persona library. Each one is a specific, named individual with a life, fears, and reasons to buy. Every campaign starts here.

How the engine works

AI drafts one hundred percent of the creative. Humans decide at every gate.

Every piece of copy is built by a content developer agent, then graded by a marketing manager agent asking one question: would this specific persona actually act on this? Nothing moves forward unless it scores eight out of ten or higher. Work that doesn't clear the bar gets revised before a human ever sees it.

Here's what that looks like for a single landing page. The agent reads the approved persona brief, creates the page outline, and writes every section of copy in the brand's voice. It generates three versions of each image on the page, all in the brand's visual styles. The marketing manager agent grades the draft against the persona. Once it passes, the team reads the page, picks the images, requests any changes, and approves. The page is ready for the site. The same pattern, draft, grade, human decision, runs for the paid ads and the video scripts, where the team also chooses the format: animated, AI-generated presenter, or real footage, with a human voiceover or an AI-generated one.

I'm not a developer, and there's no engineering team behind this. I'm not a marketing expert either. What I am is someone who builds systems. My job was to listen and define the process we wanted, then get the right inputs into it. That mostly meant deep conversations with the marketing lead, downloading his thinking: the themes, patterns, and strategies he carries in his head, and making sure all of it was built into the system's brain. So when the engine drafts a landing page or an ad, it's channeling the wisdom of the people who actually know the craft.

A finished ad, drafted by the engine and approved by the team, as it appears in the feed.

Live, with guardrails

Once a campaign launches, the agents post approved ads directly to Meta and manage the live spend every day, entirely on their own, inside hard guardrails the team set: daily budget caps, per-ad-set limits, automatic pause rules for underperformers. Anything beyond the guardrails, a budget increase, a creative change, comes back for human approval. Every day, the team gets a report: what the system spent, what it changed, and why.

Every campaign starts smarter than the last

Most small teams run ads and guess. This system knows.

The dashboard tracks the full user journey, every day: which ad brought each person to the landing page, exactly what they did once they got there, whether they purchased, and what they went on to do inside the product. Attribution runs ad by ad, so the team sees which specific creative, for which persona, is doing the work.

The full funnel, per persona: visitors, clicks, story starts, scroll depth, and purchases, tracked live for every page and every audience.

The loop runs like this. A daily analysis agent reviews the landing page data and ad performance and recommends specific changes: kill this ad, shift budget here, test this headline. The team approves or declines each one from the cockpit. Experiments start with a specific hypothesis, get tracked daily, and end with a verdict. Every verdict, every human correction, and the retrospective the team runs at the end of each campaign gets written into the playbooks and the shared brain. And the playbooks are what the agents read before they act.

That's the compounding. Early experiments taught the system that cold ads for this audience need the product made clear immediately, with no price in the ad. That rule now lives in the playbook, and every ad the engine drafts starts from it. Multiply that by every verdict from every campaign, and the next campaign doesn't start from zero. It starts from everything the team has learned so far.

Rollout and the team

The team co-owns the engine. They review and approve through a purpose-built cockpit, work from a shared knowledge layer, and the system's rules live in playbooks anyone on the team can read and change.

The result

A startup with one part-time marketer now runs persona-targeted, multi-channel campaigns end to end, with full-funnel measurement most companies with entire marketing departments don't have. The work of a full marketing team, produced in days rather than weeks, with a human decision at every point that matters and hard limits on every pound the system can spend on its own.

And unlike a campaign an agency ships and walks away from, this one compounds. Every campaign the team runs makes the next one better.

I built this as Tandem's fractional COO, working inside the team. The closest way to work with me like this now is the Embedded AI Partner engagement.

Where this one started

The first AI operating system I built was for me.

I run a fractional COO practice across multiple client engagements at once, alongside my own business development, content, and everything else that comes with running a practice solo. That's the same shape of problem every independent professional has: too many threads, no team to delegate to, and the constant feeling that the administrative work is eating the time the real work needs.

I didn't set out to build a system. I set out to solve one problem, my mornings, and it compounded from there.

How I actually work now

This is the part that's hard to convey until you've experienced it: I work inside my AI system all day. Not visiting a chat window when I need something drafted. Every task, every client thread, every decision runs through it. When I sit down to something, it already knows where we left off, what was decided yesterday, and what's next. My thinking is amplified all day because I'm working with a partner that holds all of the context.

And here's the thing I didn't appreciate until months in: while I work, the system is quietly recording everything. Every project builds its own memory. Every decision, every draft, every lesson gets written down in the background, without me doing anything. So when a new task comes in, the system doesn't start from zero. It references everything I've done before that's relevant.

That's when the compounding became real. A few months in, I needed a landing page for a new offer. I asked once. Twenty minutes later I had a finished page, on brand, with my fonts, my voice, my content, linked to payments and sign-up, because the system already knew who I am, what I was building, and why. Two years ago that would have been a week of work and a designer. It took twenty minutes because of everything the system had learned in the months before.

The dashboard: everything in flight, every client, filterable by type of work. Synced with the system automatically.

What the system does

Every morning it reads my calendar, my tasks, and my meeting notes, and hands me a realistic plan before I've started working. After meetings, it processes the notes, extracts the action items, files them by client, and drafts the follow-ups. Tasks I capture by voice on my phone flow into one list, deduplicated and prioritized.

A live dashboard shows me everything in flight across every client and my own practice, filterable by client and type of work, and it stays in sync with the system automatically. When I need analysis, the system works as my business analyst: financial models, market research, competitive landscape work, grounded in a knowledge base of more than a hundred cross-referenced pages built from my engagements, my content, and dozens of transcripts. Every week, an intelligence sweep reads the sources that matter to my work and writes me a brief, so staying current stopped being a job.

The knowledge base, visualized. Every note links to the ones around it, so the system surfaces connections I'd never think to search for. The more I feed it, the denser it gets.

It writes in my voice, because I taught it my voice: what I sound like, what I never say, and how to tell the difference. It runs scheduled routines while I sleep. And when something breaks or a better method appears, that lesson gets logged and folded back in, so the system improves the way a good team member does.

The result is that I operate with leverage I'd otherwise need a small staff for. My practice runs on it. The systems I build for clients all started here. I couldn't do the client work I take on now without this system underneath it.

How I built it, and why that matters

I'm not a developer. I built all of this with the same AI tools available to anyone, one piece at a time, while running a full client load.

That's the point. Most of what I'd read about AI systems was written by engineers, for engineers. What I wanted to know was what a non-technical operator could actually build. The answer turned out to be: essentially all of it.

From my system to yours

When I started sharing what I'd built, the response was immediate: people didn't want to admire it, they wanted one. So I turned the system into TEMPO, a six-week cohort where non-technical professionals build their own AI operating system. Not a course about AI. A guided build, starting from the system I use every day, shaped around how you actually work.

The first two cohorts sold out. Participants build a working system: daily planning, a compounding knowledge base, a weekly intelligence brief, a voice profile, and the skills to keep building on their own.

Learn about TEMPO →  ·  Executive partnership, for leaders →

Where the team was

A ten-person global health organization asked me to help its whole team start using AI together. Leadership could see what it might mean for their work and wanted everyone moving at the same pace, with nobody left guessing what was allowed.

Before the sessions

I started with conversations with the leadership and an anonymous survey of the whole team, so I knew where people were before anyone was in a room. People were already experimenting with AI on their own, with a real mix of excitement and worry.

How I designed the sessions

The first session was about getting everything on the table: what people hoped AI could do for their work and what worried them about it, in their own words, with almost the whole team there. Leadership answered the hardest questions in the room.

In the second session, small groups sorted real tasks from their own work into levels, from what AI can do freely to what stays with a person, with someone in each group asking "what's the harm if we allow this one level higher?" Then the whole team wrote its agreement together.

What the team made

Two documents, in the team's own words. The first is an agreement on how they'll use AI, covering what each person commits to and what leadership commits to the team in return. The second is an authority ladder that shows, for each kind of work, how much AI may do and at what level of review.

The outcome

The concerns, the fears, and the excitement were all out in the open before anyone connected a single tool, so nobody had to guess what their colleagues thought. Leadership's commitment to the team was talked through in the room and then written down next to the team's own. And people left seeing this as an opportunity: their agreement includes what the team commits to about engaging with AI (keeping an open mind, learning, and trying things) alongside the lines it won't cross.

Afterwards the team chose one AI platform for the whole organization, made adoption opt-in under its agreement, and set up a small working group to carry it forward.

What comes next

Foundations was the first part of a longer program with me, where each person builds their own AI system and the team builds what it shares. I'll add what changed once that program has run.

This is the Foundations workshop. The program that follows it is team capacity.