We do it with you.
Guide
Shorter, closer work: the plan before a line of code, your team learning the tools, a specific problem worked through together. One-off projects and coaching, not a build.
Guide
Consulting
A working session and a ranked plan that names the two or three places automation would actually help, in plain language, before anything is built.
What you are weighing
Our callA chatbot on the website
Quote approvals, still done by hand
The AI add-on in your current software
The weekly review, written by a person
Getting your team using the tools properly
1 of 5 is work for us. That is usually the shape of it. An example, of course: yours would be your own.
A working session on how the business actually runs: who touches what, where the copies live, what gets re-typed.
A ranked plan, two to three places, each with the manual cost as a range and what connecting it would look like.
One of them marked: you could do this yourselves, here is how.
Guide
Team training
Your people running the tools themselves. Built around your real work, not a generic curriculum.
Week one
They ask
“Can AI do this?”
We answer
It can. The better question is whether it should, and here is how you tell the difference.
A month later
On their ownThey ask
“Should this be automated at all?”
They answer
No. The judgment is the point. We will automate the gathering and keep the call ourselves.
What gets taught is not the tool. It is the question. And a month later it is theirs to ask, and theirs to answer.
Built on your work, not a slide deck. Your inbox, your CRM, your documents.
Half a day to two days, on site or on a call, with the exercises left behind so the next hire gets the same thing.
The measure is whether your team is still using it a month later, so we check.
Guide
Tool coaching
Expert use of specific tools: Claude Code, Cursor, n8n, the ones your team already opened and got stuck in. Hands on, inside your own projects.
Whatever you already run
And whatever replaces itCoding agents
- Claude
- Codex
- Cursor
- Windsurf
- Replit
- Gemini
- Claude Code
Automation
- Make.com
- n8n
- Zapier
Data and backend
- Supabase
- Airtable
- Postgres
- Neon
- Retool
Hosting and edge
- Vercel
- Cloudflare
- Netlify
- Railway
Where the work already lives
- Notion
- Slack
- Linear
- Figma
- GitHub
- Stripe
- Webflow
What your team leaves knowing
In plain words01A Markdown file is just text
# How we quote- Check the customer's tier first- Anything unusual goes to Maya before it is sent
A hash makes a heading and a dash makes a list item. That is nearly the whole format, and every tool on the left reads it. Your operating knowledge can live in a file your team can read without any of them being technical.
02A skill is a folder with one file in it
skills/quoting/SKILL.md
Describe the job in plain sentences, save it, and the agent can do that job on demand. So can everyone else on the team, the same way, without asking the one person who knew how.
03Claude, or n8n? One question tells you
Claude
Reading an email and working out what it actually is
n8n
Form filled, record created, text sent. Every time
Does each item need somebody to decide something? If yes, it belongs with an agent. If the steps are identical every single time, it belongs in an automation, where it is cheaper and it never improvises.
The job is not to make your team technical. It is to make the work shorter, in whichever tool you are already sitting in.
Claude Code, Cursor, n8n, Make: the tool your team already opened and got stuck in.
Hands on, inside your own project, one to three sessions.
You leave with the thing working and the habit of how to keep it working.
Guide
The audit
Where the hours go, what to automate first, and what to leave alone. The hinge between looking and buying.
One real week, as it actually went
What we foundHeavier means more of the week went there. An example week, not a measurement of yours.
The findings are the scope. Three of them, ranked, written up in two or three pages. If you go ahead, that write-up is the project plan. Nothing is sold twice.
A short intake: your stack, the most annoying weekly task, the size of the team.
Founder time against the pattern library, then a two to three page write-up: three findings, each with the cost of the manual version and what connecting it looks like, as ranges.
The findings are the scope. If you proceed, the audit becomes the project plan; nothing is sold twice.
How an engagement is shaped
A project, ninety days, or a year.
Three shapes, depending on how much of the work is yours to keep running. We scope around your workflow, your team and your goals, then quote it. Fixed, before anything is built.
A project
Fixed scope, one number
One system, scoped in the first conversation, built and handed over with an operating guide.
You know the problem. One of the eight recipes, or something like it, wired into your stack.
Ninety days
A monthly rate, three months
Three months of us in the room: the plan, the first builds, and your team learning to run them.
You have several problems and want them sequenced, built, and adopted, not just delivered.
A year
A monthly rate, standing
A standing engagement: the systems kept running, extended as the business changes, and the next one always in progress.
You want the capability on retainer without hiring for it.
- Fixed scope, never an hourly meter.
- You know the number before a line of code is written.
- The first conversation is free and ends with a real estimate.
- We scope around your workflow, your team and your goals, so the number means something.
- The systems library comes with the work: anything of ours a project needs is installed as part of it.