How I actually build it.
The portfolio page is the argument. This one is the evidence, and it is deliberately long. If you are deciding whether to hand someone the keys to your operation, you should get to see the inside of the machine first.
Client names, emails and account identifiers are removed from everything below. What is left is the architecture, which is the part that transfers.
GoHighLevel, end to end.
A pipeline is not a list of stages. It is a set of rules about what happens to a lead when nobody is looking. Most of the ones I inherit have the stages and none of the rules, which is why leads sit.
What I build inside it
- Capture and scoring, so a lead is graded before anyone reads it.
- Routing by source, property type or program fit, with a named owner attached at the moment of assignment.
- A twelve-month nurture sequence for the ones who are not ready, because most of them are not.
- Pipeline stages with entry and exit criteria written down, not agreed verbally.
- A Zapier bridge into the project tool, so a won deal becomes real work without anyone retyping it.
What it changes
Before: manual lead entry into a spreadsheet, no automated follow-up, and nobody certain whose lead was whose. The founder was spending roughly fifteen hours a week holding it together.
After: zero missed follow-ups, a thirty percent drop in manual data entry, and clear accountability on every lead in the system. The fifteen hours went back to the founder.
Watch the pipeline walkthroughThe Zapier ecosystem behind a live business.
Not a handful of Zaps. An ecosystem, where each one knows what the others do, and where breaking one does not silently break three others. This is the layer clients never see and feel every day.
How I structure it
- Named by function, never by whatever the wizard suggested, so a stranger can read the list and understand the business.
- One source of truth per data type. Nothing writes a client record in two places.
- Multi-step with filters and paths, rather than five near-identical Zaps that drift apart within a month.
- Error paths that notify a human instead of failing quietly, which is how most automation actually dies.
- A documented map, so the person after me can maintain it without calling me.
What sits in the stack
Forms and CRM feeding the project tool, payment events triggering access, course platform events writing back to the client record, calendar events creating prep tasks, and a scheduled sweep that catches anything the event-driven paths missed.
The sweep is the part people skip. It is also the part that turns automation from a demo into infrastructure.
⊕ Click to explore
⊕ Click to exploreAsana, built as a pipeline rather than a task list.
A task list tells you what is outstanding. A pipeline tells you where every person is, what happens next to them, and which stage is quietly slowing everything down. The second one is a system. The first one is a to-do list with a logo.
The student pipeline
- Stages that mirror the real journey, not the marketing version of it.
- Custom fields carrying cohort, start date, current module, risk flag and owner, so the board can be filtered into an answer instead of read.
- Rules that move a record when a condition is met, so nobody drags cards for a living.
- Automated check-in tasks that appear on the owner's list at the right moment and nowhere else.
- A dashboard on top that answers the founder's actual question, which is always some version of who is stuck.
Where Zapier meets it
Enrollment writes the record. Payment sets access. Course completion advances the stage. A missed check-in raises the risk flag and notifies the owner. None of this involves a human noticing something.
The design constraint I hold myself to: if the system needs someone to remember, it is not finished.
⊕ Click to explore
⊕ Click to explore
ClickUp, organized so follow-through is visible.
Most teams do not have a follow-through problem. They have a visibility problem that looks exactly like a follow-through problem. When a space is structured properly, the person who has gone quiet is obvious on Monday morning instead of at the end of the quarter.
How I lay out a space
- Spaces by function, folders by client or program, lists by workstream. Predictable enough that a new hire guesses correctly.
- Custom statuses that describe reality, including the honest ones like waiting on client.
- Every task has one accountable owner. Shared ownership is how things get dropped politely.
- Recurring tasks for anything that has ever been forgotten twice.
- A dashboard per role, so nobody has to build their own view to know what they owe.
What I watch
Tasks with no owner. Tasks with no due date. Anything sitting in the same status for two weeks. Those three filters find almost every problem in a delivery operation before it reaches a client.
They are also the three things a founder can check themselves in ninety seconds, which is the point.
⊕ Click to explore
⊕ Click to exploreHow a vision becomes something a team can do on Tuesday.
Four working demos of the method behind the board: the ladder from a twelve-month sentence down to a task with one owner, the three filters that find every defect on a Monday, a real meeting taken apart into actions, decisions, risks and information in front of you, and the capacity check that decides who gets the next piece of work.
Designing a program people actually finish.
An eight-week certification for a creator-economy platform, built end to end: the course architecture, the enrolment logic, and the platform split underneath it. Client, program and commercial terms are all withheld. What is shown is the design, which is the part that transfers.
The decision I am proudest of
Access is granted when the agreement is signed, not when the payment clears. Those are different moments and treating them as one is where most programs get into disputes they cannot win.
It also gave the program a clean definition of day one, which every other rule could then count from.
The rule I would not bend
No automated message ever reaches a learner. Automation detects the problem and routes it to a person, and the person sends every human touch.
It costs more staff time. It is also the difference between a program that feels supported and one that feels processed.
Twenty-six automations, one custom script, and a registry that cannot contradict itself.
The instructional design above is the visible half. This is the machinery that runs it: what triggers what, the script I had to write because no tool covered the gap, the registry every decision reads from, and the screen a program lead actually opens. Client, program and commercial terms withheld throughout.
Why I wrote a script at all
A signed agreement lands in cloud storage and nothing natively tells the work system it arrived. Every off-the-shelf bridge either polled the wrong timestamp or fired again every time somebody opened the file.
So the script polls on creation time, holds a thirty minute overlap for indexing lag, keeps a rolling list of what it has already seen, and writes exactly one field. That last one matters more than it sounds: re-writing an unchanged value fires every downstream rule again.
What it refuses to do
It never touches the community platform directly, even though it easily could. It sets a field, and a rule and an automation take it from there.
That restraint is the reason the chain can be changed later without going near the script, and the reason a person who has never seen the code can still follow what happens after a signature.
The screen a program lead opens on a Monday.
A working prototype of the learner progress view, reading the registry above. Twelve learners, eight weeks, filters for who needs a human this week. Invented data throughout, and it writes nothing back.
A reward economy, built out of two spreadsheets and nine script files.
Everything above belongs to one engagement. This belongs to another, in a different industry, with a different team, and it is the most complex thing I have built. A writing community wanted to reward the members who kept showing up: attend one session a week for eight consecutive weeks and you earn a token, worth four thousand words of professional feedback. Miss a week and the streak resets. No product did that, and the ones that came close wanted a per-member fee for a community that was not monetized that way, and made every member create yet another login. So I built it. Client, community and every member are withheld throughout.
⊕ Click to exploreThe form is the easy half. Open the other one.
A working replica of the claim form, with the eight things the script does after submit running beside it in order: validate, deduct, write a document backup, file it, notify the team, confirm to the member, append the row, answer the browser. There is a switch to force a rejection so you can watch the failure get logged rather than swallowed.
A public board that cannot be wrong, because it is not allowed to think.
Members needed to see their own streak without emailing anyone, and the team needed to stop being asked. The board is a second sheet and a second web app, and the only interesting thing about it is everything it is forbidden to do: it holds no logic, runs on no schedule, receives no webhooks and writes nothing anywhere. A daily job copies the numbers across; the board renders whatever it finds. When a member says the number is wrong, there is exactly one place to look, and it is never here.
Why the separation matters
A display layer that also calculates is a display layer that can disagree with its own source. The first version of anything like this always stores its own totals, and then one day the two drift and nobody can say which is right. Keeping the read half stupid is what makes a dispute a five minute answer instead of an afternoon.
What it costs
A claim does not appear on the board instantly; it waits for the next sync. So the confirmation email says so, in plain words. A known delay that a member has been told about is a feature. An unknown one is a support ticket.
The board a member checks themselves on.
A working replica: search a name, open a member, see the eight-week streak, the tokens earned and spent, and when the next one expires. Every member on it is invented. The live board carries real people's names and their attendance history, and those are not mine to publish.
EOS, and the cadence that keeps it honest.
Systems decay without a rhythm. The cadence is what turns a scorecard from a document into a habit, and it is the first thing I put in place, because everything else needs somewhere to be reviewed.
The dashboard a founder actually opens on a Monday.
A working demo, fed by a spreadsheet and rendered as a web app. Click through six weeks and watch a problem build in one column while everything else improves. Sample data throughout, no real client anywhere on it.
I use fewer AI tools than you would expect. I set up the one I use properly.
Most operators solve this by collecting tools. I went the other way and narrowed it to one, then spent the time on the setup instead of the shopping. What that buys is not novelty. It is that a client never gets re-explained, the constraints hold whether or not I remember them, the systems are already connected so an answer comes from the board rather than from memory, and each engagement is walled off from the others. The build cost collapsed as a side effect. This page, the diagrams on it and every demo linked from it were made this way, which is the only claim here you can check without taking my word for it.
Cowork
Where the operating work happens. Research, documents, analysis and the long multi-step jobs that used to eat whole days of an operations week.
Claude Code
Where things get built. Apps Script, dashboards, data migrations, redaction pipelines and every web app demo linked from this page.
The setup underneath both
Locked context per client, enforced constraints, connected systems, scoped access, scheduled work. The part that turns a capable tool into an operating layer.
Around those, four tools that carry one job each and nothing more: Wispr Flow for dictating at the speed I actually think, Fireflies for meetings I do not want to take notes in, ElevenLabs for voice, and Napkin for turning a paragraph into a picture fast enough that it is worth doing.
What the setup buys
A fractional operator carries several clients at once and cannot afford to re-explain any of them, or to let one client's context leak into another's work. So the setup does four things: it holds each engagement's canon so nothing is re-litigated, it enforces the rules that protect a client rather than relying on my memory of them, it connects to the systems the work lives in, and it walls each client off from the rest. The architecture is below. The construction is not, and that is deliberate.
What this means for you
Custom stopped being expensive. If your operation needs something the off-the-shelf tools do not do, that is now a conversation about whether it is worth having, not about whether you can afford to build it.
What it does not mean
It does not mean an AI runs your operation, and I will talk you out of that before a competitor sells it to you. Every judgment on this page is mine, every number is checked by hand, and anything I could not defend in a meeting does not go in.
A procedure somebody actually follows.
How a library of SOPs is arranged so the right one is findable, one complete procedure built to my own conventions with both checklists working, and how I decide whether a step needs a sentence, a screenshot or a recording. The friction in an SOP is never that people will not read it.
Where AI belongs in an operation, and where it does not.
Every tool in your stack shipped an AI feature this year and most of it is the automation that was already there, repriced. Three demos: a real intake process with the one step worth metering marked out, a triage classifier you can run twice and try to break, and the pricing models that decide whether an AI feature is a budget line or a fuse.