You know what needs to exist.
Now it needs to run in production.
Nothing to something. Something to provable. Provable to scalable.
Maybe you raised on a prototype and need the real version. Maybe a process in your company runs on a spreadsheet and a person who knows where the bodies are. Maybe there's one project that can't wait two quarters for a platform team. Same gap, same work.
What you need next isn't another demo, it's the system underneath one: auth, data model, integrations, observability, and deploys that don't scare anyone. Every engagement below is fixed price, and every price is on this page.
That gap is where teams lose a year. They buy a prototype twice, once from the shop that built it and once from the team that rewrites it.
Forward deployed, not embedded
I work the way a forward deployed engineer does. In your domain, on your actual problem, close enough to your users to see what really breaks. What I'm not is a contractor you manage or a seat in your standup. You get a system that works and the context written down, not a dependency on my calendar.
The work runs on an AI-forward lifecycle, built here and written down in full. That's why the output looks like a larger team's and the invoice doesn't, and what a week of it looks like is written down too.
Three stages
Scoped before you commit. Two more doors below.Blueprint
Where every engagement starts. Nothing gets quoted before this exists.
I take what you actually have, the spreadsheets, the prototype, the deck you raised on, and work out what production requires. Then I scope and price the build against it.
- The architecture written down, including the parts you were going to discover in month four
- A build plan broken into surfaces, each one scoped and priced
- The infrastructure bill of materials: auth, data model, observability, CI/CD, environments
- A decision you can fund. Build, fix, or stop.
You end up owning a plan you can price, whether or not I build it. If the answer is that you should not build this yet, that is a real output and I will say it.
Build
A product real users can use, and numbers that prove it works.
What most teams get for this money is a demo path with nothing underneath it. You get the platform: the boring, expensive layer that decides whether this survives contact with real usage, and the measurement that tells you it did.
- Auth, billing, permissions, and a data model built to be lived with
- Observability, CI/CD, environments, and a test suite that actually gates the deploy
- A held-out evaluation set and quality gates in CI on every AI path, so a drop in accuracy fails the build like any other test
- Code you own on day one and a handover a working engineer can pick up cold
Evaluation is not a line item you can decline. A build that cannot prove it works is a demo, and I would rather not ship you one. Fixed price, agreed before a line is written. Harder than I thought is mine to absorb; different from what we agreed is a priced change, and I tell you which one it is that week rather than at the end.
Run
Shipping is not the finish line. Running it in front of real users is.
Most of what kills an early platform happens after launch, when whoever built it has moved on and nobody knows why the queue backs up on Tuesdays.
- Monitoring, on-call, incident response, and the unglamorous operational work
- The next surface built on the same foundation instead of bolted to the side
- Model and dependency upgrades, with the eval gates catching what they break
- Your team brought up to speed, so this becomes optional rather than permanent
Included: monitoring, a defined on-call window, dependency and model upgrades, and small changes inside the system as built. A new surface is a mini-Blueprint and is priced separately, and the monthly is re-scoped when the system materially grows. The goal is that you need this less over time. If you are fully dependent on me at month twelve, I did the handover badly.
Proof
A separate door into the same work, for teams who already shipped an AI system and have no answer they would defend to "does it actually work?" Someone else built it, or you built it fast and never went back. Either way you need a measured read before the next decision rests on it.
- A held-out evaluation set built from your real data, so the score means something
- The failure modes found and ranked by what each one costs when it happens
- Quality gates wired into your CI, so accuracy cannot quietly degrade after I leave
- A written measurement policy, so nobody on your team can overstate the numbers later
Bundled into every Build at no extra cost. It is priced on its own here only because the work is different when the code is already written.
Pilot
One workflow, taken all the way to production, before anyone commits to the full build. One document type extracted and reviewed. One process moved off the spreadsheet. One integration that has been "next quarter" for a year. Fixed price, fixed scope, and your team is using it at the end.
- Running in your accounts, on your infrastructure, with the people who do the work today in the loop
- A human review step wherever a wrong answer would cost you something, designed in rather than bolted on
- Measured before and after, so the decision to go further rests on numbers
- The foundation the next workflow builds on, not a throwaway
The Blueprint scopes it. If the first workflow proves out, the rest is priced as a Build on the same foundation, or stays exactly where it is with Care behind it.
Who this is for
- Seed and pre-seed teams who just raised and need the real version of what they demoed.
- Mid-market companies with a process running on spreadsheets that has outgrown them.
- Enterprise teams with one isolated project that needs to ship without waiting on a platform roadmap.
- Anyone who already has an AI system in production and no trustworthy answer to whether it works.
Pre-raise and need something real to put in front of investors? That is a smaller Blueprint and a smaller Build, and it is welcome. The only thing I care about is that the budget exists, not what stage you are at.
Who it isn't for
- You want hourly staff augmentation. I don't sell hours, and you can get them cheaper.
- You want a fixed price off a phone call. That is how people end up paying for a scope nobody understood.
- I can't get access to the people who actually do the work. Close to the problem is the whole method.
- You want the cheapest quote. There are shops that will beat me and you'll pay twice.
What it costs
Every engagement is fixed fee, agreed before it starts. I'd rather tell you the real shape of the numbers now than have you book a call to find out.
- Blueprint
- $7,500, two weeks, one product surface. Fixed, and it doesn't move. Request an invoice.
- Pilot
- $30,000, four to six weeks, one workflow in production with the review step and the measurement included. Fixed. The way to start when the full build is more than you want to commit to on day one, or when one workflow is the whole job. Request an invoice.
- Build
- Typically $60,000 to $180,000 over 8 to 14 weeks, depending on how many surfaces and how much regulated or legacy surface area is involved. Priced exactly in the Blueprint, never estimated from a call, and the schedule is agreed at the same time as the number. Billed by milestone, so what you have at risk at any point is one milestone rather than the whole engagement. Request an invoice.
- Proof
- Included in every Build. $15,000 on its own, two to three weeks, when the system already exists and I did not write it. Request an invoice.
- Run
- From $8,000 a month, scoped to the system, and either of us can end it with 30 days' notice. Covers monitoring, an agreed on-call window, upgrades, and changes inside the system as built. New surfaces are scoped and priced on their own, and the monthly is re-priced when the system grows materially rather than quietly absorbing it. Request an invoice.
- Care
- $2,500 a month for a system that is running and needs to stay that way. Business-hours support, monitoring, dependency and model upgrades, and small fixes inside the system as built. No on-call window and no new features. Three months to start, then 30 days' notice either way. Most Pilots end up here. Request an invoice.
Every tier above can be paid by a formal invoice with terms instead of a card; each "Request an invoice" link above opens an email with the details filled in, and bank transfer is available on request once it's turned on. Full terms, including refunds and cancellation, are on the terms page.
The Blueprint pays for itself
The full Blueprint fee is credited against a Pilot or Build that starts within 60 days, so if we go on, the planning cost you nothing. If we don't, you keep everything it produced: the architecture, the priced plan, the infrastructure list, and you can hand them to any shop to build. Either way, $7,500 buys a plan you own.
A Build number you don't want to spend isn't a failed Blueprint, that's the Blueprint working. The two weeks need you in them: if I can't reach the people or the systems, I'll say so before week two rather than at the end.
What moves the number
- Surface count. One workflow done properly costs less than four done at once.
- Whether you are replacing something. Migrating live data and users off an existing system is most of the risk and most of the cost.
- Regulated or audited domains, where the work is not the feature but proving the feature behaves.
- Integrations you do not control. Every third-party system with its own rate limits and outages is a week somewhere.
If your whole budget is under the Blueprint, we're not a fit yet, and I'd rather say that in an email than on a call.
"It started with digitizing my supplier catalog so I could actually understand my costs. It ended with a platform and an AI assistant that let me spend my day on jobs instead of paperwork. I have insight into my business I've never had before. JobKit is basically the operating system of my business now."
Getting started
- 1. Send me the shape of it. What you're building, where it is now, and roughly what you've set aside. Those three things get a real reply.
- 2. Thirty minutes. Enough to know whether there's a fit and which surface the Blueprint should cover. If it isn't me, I'll say so and point you somewhere better.
- 3. Blueprint. Two weeks. You end up owning an architecture and a priced plan whether or not I build it.
- 4. Decide. Fund the Build, start with a Pilot, take the plan to someone else, or stop. All four are fine outcomes.
Your work stays yours
NDA and IP assignment signed before anything starts. Nothing I build for you gets written up, named, or shown to anyone without your say-so in writing. You own the code and you own the story. What I keep is what any engineer keeps: the techniques and judgement I walk in with and walk out with, never your data, your code, or your name.
See the SOW, NDA, and IP-assignment templates before you sign anything, and the full terms and refund policy.
How your code and data get handled
I work agent-first, which means AI tooling reads your source, your logs, and sometimes your schema. That is worth being explicit about rather than leaving you to discover it.
- Work happens against your repositories and your infrastructure, under credentials you issue and can revoke.
- Database access in the course of the work is read-only unless a migration is the task, and production access is scoped and time-limited.
- Model vendors are named in writing before work starts. If you need a specific vendor excluded, or everything kept inside your own cloud account, say so during the Blueprint and it gets designed in rather than bolted on.
- Customer data stays out of prompts and test fixtures unless you ask otherwise. Where a system needs realistic data to build against, it gets synthetic or anonymized data.
- On request I will confirm in writing which vendors were used and what data reached them. If you have a policy, send it and I will work to it or tell you I can't.