Anchor High

Somebody on your team is doing work a system should be doing.

You know which process it is. It eats a day a week, it only runs correctly because one person remembers the steps, and it has been on the list to fix since last year. I build the thing that does it, hand it over, and leave.

1 Advisory call is automation even the right answer? $500 2 AI workflow build one process, end to end, fixed scope $2,000–$4,000

The advisory call comes off the build price in full if you go ahead within 60 days. If the honest answer on that call is that you don't need a build, you have spent $500 to avoid spending $4,000.

Why this is usually still broken

It is never because nobody noticed. It is because fixing it is nobody's job. The person who feels the pain does not build software, and the person who could build it has a roadmap that this will never reach the top of.

So it gets attempted twice a year by whoever has a quiet week, gets eighty percent done, and stops. Now there is a half-built script nobody trusts sitting next to the manual process everybody still runs.

The other failure is the opposite: an agency arrives, scopes a platform, bills hourly, and eleven weeks later you own something large, generic and unfinished that only they understand.

What actually works for a process this size is narrow and boring. One problem. A written scope. A fixed price so nobody is incentivised to make it bigger. Something working at the end that your team can operate without me.

How a build goes

Typically two to three weeks. 50% up front, 50% on delivery.

Before anything is agreed

You describe the process

What happens now, who touches it, where it breaks, and roughly how many hours a week it costs. A rough answer is fine — the point is to find out whether this is worth doing at all.

Within a few days

I write the scope

What gets built, what does not, what it will run on, what I need from you, the price, and the delivery date. You read it before you pay anything. If I don't think I can help, this is where I say so.

Week one

The unglamorous half

Intake and data first, because that is where these projects actually fail. Getting the input clean and reliable is most of the work; the clever part on top is usually the easy part.

Week two

You use it while it's half-built

You get your hands on it early and on real cases, not on a demo. What you say at this point changes the build — which is the entire reason it happens before the end rather than after.

Delivery

Handover, not a black box

A written handover doc and a recorded walkthrough, so the person who runs this next month can understand it without me. Everything lives in your accounts, under your credentials.

14 days after

Fixes included

Two weeks of fixes for anything that does not do what the scope said it would. That is fixing, not new features — new features get quoted, because that is what keeps a fixed price honest.

What's in scope, and what isn't

Things I build

Intake — forms, inboxes and uploads turned into structured, checkable records
Routing and triage — work sorted and sent to the right person with the right context
Drafting — first-pass replies, summaries and documents a person then edits
Extraction — pulling the fields you need out of documents, emails and transcripts
Reporting — the weekly number somebody currently assembles by hand
Glue — making two systems you already pay for talk to each other

Things I don't

Anything that makes a consequential decision with no person in the loop
Customer-facing chat that speaks for your company unsupervised
A platform, a rebuild, or a multi-month programme — this is sized for one process
Ongoing operation — I hand it over, you run it
Work that needs regulated data handling I'm not set up for
Anything where the honest answer is a tool you can buy for $30 a month

Where possible it is built on tools you already pay for. A new subscription has to earn its place, and I would rather hand you something that runs in your existing stack than something that adds a vendor.

What you own at the end

A working system

Running in your accounts, on your credentials, doing the thing the scope said it would do.

A handover document

What it does, how it does it, what to check, and what to do when it misbehaves.

A recorded walkthrough

Me going through it end to end, so a new person can get up to speed without booking my time.

The scope, as written

What was agreed, so there is never an argument about whether something was included.

Two ways in

Start here if you're not certain

Advisory call

60 minutes · written summary within 48 hours

You describe the bottleneck and I tell you what I actually think — including, sometimes, that you should buy something off the shelf or change the process rather than automate it. I would rather lose a build than sell you one you don't need.

An honest read on whether automation is the right answer here
Build versus buy, with named alternatives where they exist
A rough scope and price if it is worth building
Written up and sent within 48 hours, so you can forward it internally

The build itself

AI workflow build

Fixed scope · typically 2–3 weeks · 50% up front

One process, end to end. The price depends on the scope, which is why it is a range and why the scope gets written down before you pay anything. Most builds land in the middle of it.

Written scope before anything starts — price, deliverables, date
Built on tools you already pay for where that is possible
Changes are priced rather than absorbed, which is what keeps the date real
Handover doc and walkthrough recording at delivery
14 days of fixes after delivery included

Prices exclude Washington State retail sales tax where it applies. Tax is calculated at checkout and shown on the invoice.

Before you get in touch

Why fixed price rather than hourly?

Because hourly billing makes us adversaries. Every question you ask costs you money, and every hour I take is revenue for me — so we are both quietly pulling against the thing we supposedly both want, which is for this to be finished. Fixed price means scope has to be written down, which is a discipline that protects both of us, and it means the fastest path to done is in both our interests.

What if I don't know exactly what I want?

That is what the advisory call is for, and it comes straight off the build price if you go ahead. You describe what is painful; I work out whether it is an automation problem, a tooling problem or a process problem. Those three have very different answers and only one of them is a build.

What happens if it needs changes after the 14 days?

Tell me what you want and I quote it. Small things are often small. I don't sell a retainer, because a retainer is a bet that you will keep needing me, and the whole point of the handover is that you shouldn't.

Who owns what you build?

You do. It runs in your accounts on your credentials, and the handover doc is written so that somebody who has never met me can maintain it. I keep no access after delivery unless you ask me to.

Is our data used to train anything?

No. Whatever I see during a build stays between us, and I don't use your process or your data as an example — anonymised or otherwise — without asking you first.

How many of these do you take at once?

Few. The two-to-three-week delivery only means anything if I am not running four builds in parallel, so when the calendar is full I will tell you the next date I can start rather than start late.

Describe the process

What happens now, who touches it, and roughly how many hours a week it costs. I'll tell you whether it's worth building, and what it would take.

Get in touch

Or book the advisory call at $500 and have the whole conversation properly.