The method, and the proof
Two questions come up in every first call. How does a project actually run, and do we use this ourselves. This page answers both, because the second is the only honest way to answer the first.
What a project looks like
Five stages. Each one produces something specific, and you can stop after any of them with the work so far still yours.
- 01
Map
1 to 2 weeks
A ranked list of processes with hours, error rates and owners
We sit with each function and trace where the working hours actually go. The gap between where managers think time goes and where it goes is consistently large, and the processes people complain about are rarely the biggest ones.
- 02
Choose
Days
One target, with a baseline number and a defined "after"
We pick the workflow where you can state the before and after in numbers a finance person would accept. That does two jobs: it forces scope discipline during the build, and it gives you an honest verdict at the end instead of a vibes-based one.
- 03
Ship
2 to 6 weeks
A working system your team touches daily
Built in production conditions from week 1: real data, real integrations, real permissions. The distance between a sandbox demo and a working system is where these projects die, so we cross it while it is small.
- 04
Enable
1 to 2 weeks, overlapping the build
People who operate, adjust and trust the system
The process owner learns to read the output, handle the exceptions it routes to them, and adjust the parts that drift. A system only its builder can operate stops working the day that person is busy.
- 05
Expand
Ongoing, usually as a retainer
The next process, on infrastructure that already exists
Back to the ranked list from stage 1, with integrations and trust you did not have the first time. Most clients carry on from here as a monthly retainer, taking one process at a time at whatever pace suits them. The interesting shift is when department heads start bringing you candidates with their own numbers attached.
What we run on ourselves
Automation Flow is two people. It runs like a larger company because most of the operational work is done by systems we built, using the same tools and the same patterns we sell. Here is the actual list.
Sunny
Classifies expenses as they land, generates invoices, chases payment, and surfaces the numbers that need a decision. An orchestrator with workers underneath it, on the same Supabase and Next.js stack we build client platforms on.
Jimmy
A voice message saying "move my Tuesday meeting" gets the calendar changed, the affected people emailed, and the related tasks updated. This is the WhatsApp agent pattern, pointed at ourselves.
Proposal drafting
A discovery call transcript becomes a structured first-draft proposal: scope decomposed into modules, effort estimated, red flags surfaced for a human to argue with. Nobody sends a draft unread.
Meeting prep
Before a first call, an agent researches the company, validates what it finds against real sources, and writes a client profile. Anything it cannot verify is marked as unverified rather than smoothed over.
The company wiki
Pulls from Drive, Gmail, GitHub and the calendar twice a day on a schedule, then writes and cross-links its own pages. It is where the numbers on this website are supposed to be traceable to, which is a standard we hold ourselves to and audit.
The build team
Builder agents write code and separate reviewer agents gate it on spec compliance, code quality and security before anything merges. The reviewers see the diff and the acceptance criteria, never the builder's reasoning, because a reviewer told why something was done tends to agree.
Why running it ourselves changes what we build for you
Every system on that list has broken at least once, usually in a boring way: an API changed, a credential expired, a scheduled job reported success while delivering nothing for four days. Living with that is why a client build ships with a global error handler, retries where retrying helps, alerts that reach a person, and a searchable log. Those are not upsells. They are the parts we learned to stop leaving out.
Where a person stays in the loop
Every system we build has at least one point where a human signs off, chosen deliberately rather than sprinkled in. Anything that reaches a customer, moves money, or writes a record other systems read goes through review. Reading, drafting, classifying and enriching usually do not. As your team watches it get things right, that checkpoint moves or comes out, and you make the call with real numbers in front of you.
What you own at the end
The code, the prompts, the workflow definitions and the infrastructure config, in your repository and your cloud account, running on your own infrastructure. Handover is working sessions on the systems we actually built for you plus a runbook, and it is inside the price. We would rather your team changed a prompt on a Tuesday without booking us.
Working alongside you, at the pace you set
Most engagements do not end at handover. They continue as a monthly retainer, which buys a standing amount of our time rather than a fixed scope. We sit with your team, take the next thing on the list, build it, and move on. That suits a company whose priorities move during the year, and it suits one that would rather go a process at a time and watch each one settle before starting the next. You set the pace, you can change it, and the retainer runs month to month. Everything built inside it is yours on the same terms as project work: the code and the IP transfer as it ships.
Questions we get asked
Do you actually use this, or is that a marketing line?
We use it. The list above is the real inventory, and it is why a two-person company can run delivery, finance, sales prep and an internal knowledge base at the same time. The honest caveat is that our own systems get less polish than a client's, because ours only have to satisfy us.
What happens if we stop working with you?
Everything keeps running, because it runs on your infrastructure with your credentials and the code is in your repository. That is the point of the IP transfer rather than a courtesy at the end. If you want us for changes later, that is a separate conversation and not a dependency.
Can we stop after the mapping stage?
Yes, and some clients do. The output is a document naming the processes, the sequence, what each one needs and what it should cost. Take it to your own team or to another vendor. We would rather you built the right thing without us than the wrong thing with us.
How do you decide what not to automate?
A process nobody owns cannot be automated, because nobody can say what correct looks like. Neither can one whose rules change faster than they can be described. Where an off-the-shelf product already does the job, we say so, and the engagement becomes configuration rather than a build.
Tell us what's slowing your business down.
30 minutes. No pitch, no deck. Just listening to your needs and seeing how we can help.
Schedule a discovery call