Consulting
Before you pay anyone to build an AI tool, find out whether the idea holds up. For owners and executives of businesses with ten to two hundred people: a plan precise enough to build from, then the build, with you coached through it. Fixed scope, fixed price, from $2,700 to $14,000.
The problem I actually work on
Most organizations adopting artificial intelligence are not held back by the models. They are held back by everything around them: nobody can say what a correct answer looks like, the data is not shaped for it, the approval path was designed for software that behaves deterministically, and the first confidently wrong output destroys the credibility of the whole program.
In a business your size that usually looks like one person who knows how a messy job gets done, a spreadsheet nobody else can follow, and no time to find out whether AI could take it over. You do not need a strategy for that. You need one problem picked, a written definition of done, and someone to tell you honestly whether it will work before you spend real money finding out.
What transfers between organizations is not an industry. It is the sequencing: what to do first, what to refuse to do, how to tell early whether something is working, and how to build a system that fails safely rather than plausibly.
I have written the whole argument down: how to sequence AI adoption. It is long and it is opinionated, and it is the fastest way for you to decide whether I would be useful to you. I would rather you read that than take a call, and it is deliberately the most substantial thing on this site.
If you would rather start than read, the evaluation plan is the one page that argument comes down to. Six questions to answer before you build anything, free and with nothing to sign up for.
Why the engagements are shaped the way they are
Every offer below is fixed scope and fixed price, and that is not a billing preference. Hourly billing means you carry the risk of me being slow, and you cannot know the total until it is done. Fixed means I carry that risk, and you know the number before anything starts.
Prices are on this page rather than behind a call, because you should be able to decide whether this is worth a conversation without having one first. I take on two or three engagements at a time, so I would rather decline something than take it on and do it badly.
Find out whether the idea holds up before you pay to build it
Most AI projects in a business your size do not fail while they are being built. They fail because nobody wrote down what the thing was supposed to do, so the first version is a guess, and guesses are expensive. Before you spend $9,000 or more on a build, you can spend $2,900 finding out whether the idea is sound.
You describe the idea in your own words, however rough. I send back a specification: a short, precise document that says what the thing must do, how you will know it is right, what it must never do, and where the edges are. Clear enough that a developer, or an AI assistant, can build from it.
That document is a decision in your hands. Build it with me, build it with someone else, or stop, having spent a fraction of what the build would have cost. Plenty of people stop here, because the specification was the hard part.
How it runs
- You buy it, then describe the idea. A short form asks what the idea is and how you would know it worked. If the idea leaves a gap that would change what gets built, I ask by email. No call, no meeting, no slides.
- Within a week of sending the idea, you get the specification, plus a list of what you did not say and what I assumed in its place.
- One revision after you have read it is included.
If the idea is not ready to specify, for example because it depends on a decision you have not made yet, I will tell you plainly and refund you, rather than write something that looks finished and is not.
The Spec Review
I write the specification for your idea.
Fixed price: $2,900. One idea, one specification, one revision, about a week. No meetings.
The Spec Kit
The same method, to use on your own. The one-page spec, the checklist I run over every spec before it is built, seven ways a spec goes wrong, and two worked examples from rough idea to finished thing.
$29. A download you can read in twenty minutes and use the same day. No programming knowledge assumed.
I keep my consulting outside the financial sector, without exception, so neither is for a business in it. The Spec Review is paid through Stripe and the Spec Kit through Gumroad, and refunds for both are set out in the terms.
A working prototype in two weeks
When the idea holds up and you want the working thing rather than the document. Rather than a report recommending what you might do, you get the smallest real version of it, built, so the decision is made against something that exists.
In two weeks I turn one idea into two concrete things.
A build-ready specification. A short, precise document describing exactly what the thing does, what counts as correct, and where the edges are. Clear enough that any developer, or an assistant, can build it without guessing.
A working prototype. Not a mockup and not slides. A real, running version of the core idea that you can click, test, and show to other people.
You end the two weeks knowing whether the idea works, what it should cost to build fully, and holding something real either way.
How it runs
- Days 1 to 3. I interview you to pin the idea down, then write the specification. You review and approve it. Nothing gets built until we agree what done means.
- Days 4 to 10. I build the prototype test-first, against the specification. You get one short check-in midway.
- Days 11 to 14. I hand over the prototype, the specification, and a plain recommendation on what to do next.
Your time cost: one kickoff conversation, one midpoint check-in, one handoff. That is it.
The price
Fixed at $9,000 to $14,000, quoted flat before we start. No hourly billing and no scope surprises, so you know the number on day zero. Half to begin, half on handoff.
Nothing about a quote expires, so there is no reason to decide quickly.
Stop retyping paper into spreadsheets
For small businesses where someone types paper forms, photos, or notebooks into a spreadsheet or a system by hand. It works because that person is good at it. It also costs hours every week, and you pay for the same information twice: once when it is written down and again when it is entered.
Tools that promise to fix this look great in a demo and then quietly get things wrong on your actual documents. So the useful question is not whether software can read your paperwork. It is how often it reads yours correctly, and what happens the rest of the time.
In two weeks you get four things.
A short specification. Exactly what goes in, exactly what comes out, and what counts as correct. You can read it in ten minutes.
A working pipeline on your real documents. Your paper in, your spreadsheet or system format out. Not a mockup and not a demo on sample data.
An accuracy check on your own documents. It is run on documents the pipeline has not seen, with the numbers filled in: how often it is right, where it goes wrong, which fields you can trust without looking, and which a person should still check.
A one-page handover. How to run it, what it costs to run, and what to do when it gets something wrong.
You own all of it outright, including the specification and the code.
How it runs
- Days 1 to 3. You send a batch of real examples, the messier the better. I write the specification and you approve it. Nothing gets built until we agree what done means.
- Days 4 to 10. I build the pipeline test-first against the specification, then check its accuracy on documents it has not seen.
- Days 11 to 14. I hand over the pipeline, the specification, the accuracy results, and a plain recommendation on what to automate and what to keep a person on.
Your time cost: one kickoff conversation, one batch of sample documents, one handoff. That is it.
How it differs from the other two
The Spec Review gives you a specification only, for any idea. The Blueprint Sprint gives you a specification and a prototype of a new idea. The Capture Sprint does one job, getting paperwork into a system, and gives you the finished pipeline plus proof of how far you can trust it.
The price
A launch price of $2,700 for the first five clients, then $4,900. Fixed either way, for one document type going into one destination. No hourly billing and no scope surprises. Half to begin, half on handoff.
The usual arithmetic: if retyping takes one person a day a week, that is about fifty days a year. Even at the full price, the sprint costs a fraction of that, and the pipeline keeps running afterward.
Other ways to work together
Fewer, larger, fixed-scope pieces of work, on purpose. Each one ends with something you keep.
Coaching for owners and executives
You are the one who has to run the thing after it is built, and most of what makes AI work in a small business is judgment rather than software: which problem to hand over first, how to tell a good answer from a plausible one, and when to switch it off. I coach you through that alongside the build, on your actual business rather than a case study.
Packaged with build work: six one-to-one sessions across a Blueprint Sprint or a larger build, support between them, and a written plan for what to do next that you keep. Quoted with the build it goes alongside.
A part-time product lead
Some companies do not need a project. They need a senior product brain steering the effort a few hours a week: owning the roadmap, writing the specifications, and stopping the wrong things from being built.
Retainer: $4,000 to $6,000 per month, month to month, no lock-in. I take on two or three at a time, so availability is genuinely limited. For most people the fixed-scope work above is the better first step, and I will usually say so.
All prices on this page are in US dollars (USD). How payment, refunds, and cancellation work is set out in the terms and refund policy.
Who this is for, and who it is not
I would rather be specific than have you find out on a call. If the second list describes you, that is genuinely useful information for both of us, and there is a free version further down that you are welcome to regardless.
A good fit
- You have been meaning to build or automate one specific thing for months, and it has not happened.
- You can decide on the spend yourself, without assembling a committee.
- Your company is roughly ten to two hundred people.
- The problem involves information that starts unstructured, on paper, in photographs, in a spreadsheet held together by one person doing it manually.
- You are willing to work asynchronously, with occasional calls early or late in the day.
Not a fit, and I will say so early
- Anything in the financial sector. I keep my consulting and teaching work outside the financial sector, without exception. That includes banks, lenders, investment managers, brokerages, insurance, payments, financial technology, accounting and tax practices, and any project whose subject is markets, lending, trading, or investment. It is a line I hold rather than a judgment about the work, and I would rather say so here than after a call. If that is you, the written method and the evaluation plan are free and you are welcome to both.
- You want an hourly arrangement. Everything here is fixed scope on purpose. Hourly means you carry the risk of me being slow and cannot know the total until it is finished. Fixed means I carry that.
- You want an entire product built. A two-week sprint is one core idea, deliberately. If you have twelve, the useful first step is picking one, and I am happy to help with that part for free.
- You need someone available during business hours regularly. A kickoff call in the working day is arrangeable. A standing daytime commitment is not, and that is a real constraint rather than a preference.
If none of the above rules you out but you are still not sure, the thirty-minute conversation is the cheapest way to find out, and it costs nothing.
About
I am Michael Carroll. This work is contracted and invoiced through MC AI Studio LLC, my company in New York, and I do all of it myself.
I build software by writing specifications precise enough that an assistant implements them without a single clarifying question, then I ship the result. The method is the whole pitch, so it is worth being concrete about what it actually catches.
On a recent engagement, the job was reading handwritten cards into a spreadsheet. Two things went wrong, and neither of them looked wrong.
A card reading 3/11 came back as 2024-03-11 with high confidence. The real year was 2026, and the invented date filed itself into a financial record without raising anything. Asking the model to be stricter made it worse: it then refused a perfectly legible date because it could not rule out the year 1926. The fix was structural rather than a better prompt. The model now transcribes literally and separate code does the interpreting.
Then, appending a row to a test spreadsheet preserved every chart and every format, exactly as hoped, and left the total formula stopping one row short. The data ran to row ten and the sum still ended at row nine. No error, no warning, and a total that under-reported by $12.40.
Both failures are the same failure. An assistant does not fail loudly, it fails plausibly, and a confident wrong answer goes straight into your spreadsheet and sits there. Both were caught because "how will we know it is right" had been written down before anything was built. That is what you are buying.
Everything I make is tested before it is called done, and you can try what I have built before deciding anything.
This is independent consulting, taken on in a personal capacity and entirely separate from any employment. Engagements run outside business hours, which is why the scope is fixed and the calendar commitment is small.
Selected writing
How I work, written down. Each of these is a few minutes and says more than a call would.
The Total That Was Quietly Wrong
Everyone worries a script will eat their spreadsheet chart. The chart was fine. The total formula stopped one row short, and nothing said so.
Every Requirement Traces to Something
The first rule of spec-driven development is that nothing in the spec is inferred. Following one data gap from a question through a PRD, a mapping spec, a data contract, and into merged code, and what each artifact had to cite.
The Contract Comes Before the Pipeline
A data contract is the spec's last mile: the document a consumer can hold a producer to and an agent can build from. What goes in one, why each section exists, and a template.
The Judge Needs a Rubric
A model grading your specs is only as good as the rubric it holds and the calibration set that proves it applies it your way. The rubric, the prompt, the ten-document test, and the five ways it goes wrong.
Tell me the idea
However rough. If I can see a clean version of "done" in it, I will tell you what I would do and what it would cost. If I cannot, I will tell you that too, and it costs you nothing either way. I will also tell you plainly if I think the thing is not worth building, which happens reasonably often.
No obligation attached to sending this, and nothing automated follows it. You will get a reply from me within a few days.