You do give a frac how it's built. It's your product.
Not just what AI belongs in your product, but how it gets built and how you ship it. Serious engineering, so it keeps delivering once it's in front of customers.
A diagnostic across your product, your users and how you build and ship. Then an honest go or no-go.
A capped budget. Built to run in your environment, on your infrastructure.
Your team, holding the line on quality after we've gone.
Which problem is yours?
AI in the product your customers pay for.
You're on that pageThe work your team does every day.
Go there insteadNeither? If you're a fractional CxO or AI engineer, join the waitlist .
Almost nobody decided how AI would work in their product. It just came out as a chat box.
Sometimes conversation genuinely is the right interface, and it is the one most consultancies will take you to. More often the value is quieter, like the exception surfaced before anyone went looking. Same capability, a completely different product, and a different bill every month to run it.
Vector search over your documents is where everyone starts, and it holds until the answer depends on a relationship rather than a passage, at which point you need a graph and a naive similarity search will confidently tell you otherwise. Agents have the same problem one layer up: you are hoping each one lands the right answer first time, with nothing checking that it did. So your product ships the wrong answer with total confidence, and your test suite passes, because nothing in it can fail a response that is merely wrong.
Then there is how you build it. Your strongest engineers are already shipping more than they were a year ago. The rest of your team is not, and neither is the business around them. The gains are real but they are personal, so they do not compound and they leave when people do. The bar has moved and only part of your organisation has moved with it.
Illustrative. No live model, and the document in it is invented.
Three stages, and a real exit halfway through the first one.
Every price is on this page, including the one we make nothing on.
The audit
Fail fast, deliberately.
The diagnostic
A structured look across your product, your users, and how you build and ship it. Days rather than weeks.
Stopping here is a normal Tuesday.
We stop and sit down with you, and you get an honest go or no-go. Sometimes the feature is worth building but not yet: the data underneath it needs months of cleanup first, and a consultancy is an expensive way to run one. Sometimes there is no way yet to tell a good response from a bad one, and a feature you can't evaluate has no business in front of customers. You keep everything we found, we shake hands, and you have spent a small amount to avoid spending a large one.
Plenty of firms will tell you they would walk away from bad work. We price the diagnostic at cost and lock this meeting in before anything starts, so we can.
Who builds it
Only the work that cleared the bar. Then the real decision: who builds it. You pay for each piece on its own terms.
An embedded engineer
Your team, shipping faster. A senior AI engineer we place inside it: your repo, your standups, your release process. Delivery first, so the tooling, testing and release discipline to ship AI work reliably, then features built side by side where you want the approach proven.
The gains stop being personal and start compounding, and your sceptics watch it done rather than hear about it. Outcome-defined, with an end date agreed up front.
Solution design
We design it, you decide. The shape of the feature, how it behaves when the model is wrong, what it costs to run at your scale, and how you'll know it's good.
Starts with a $2,000 feasibility stage; if the direction isn't viable, that's all you pay. The design is yours either way.
The build
A first build won't take your whole product there, and it isn't meant to. It ships one piece of AI in your product properly: shaped for the moments the model is wrong, instrumented, and with evals that can fail an answer that is merely wrong before a customer sees it. Every build after that is priced from what the last one proved.
A ceiling you can plan against and scope that can flex inside it, so we change direction when we learn something instead of raising a change request. Ships with the evals, the decision log and the runbooks for whoever runs it.
Hypercare
Our experience building AI platforms has taught us that you don't truly know a system until it hits production. So every build reserves a capped hypercare budget on top of the build price, already approved and there if tuning or rethinking is needed.
Got it right on day one? You don't spend it.
Typically up to 20% of the build, your figure comes with the proposal
30 days from go-live, longer by agreement on a harder build
And it's yours: built to run in your environment, on your infrastructure, encoded from your product, not rented from ours.
Keeping it sharp
If you want us to stay close after that, retainer and fractional arrangements exist from $1,000 a month. This stage is designed so you won't need them.
Every build ships with evals for what we built. This stage takes that discipline across the rest of your product and leaves it with your team: an eval suite you own and extend, runbooks for when something looks wrong, the decision log behind every threshold, and a migration playbook for the day a model you depend on is deprecated.
We build it alongside your engineers, not as a handover at the end, because the measure of this stage is that they run it without us. No consultancy will ever own your product the way you do, so the discipline has to live where the ownership does. What we bring is the method: the eval harness, and the habit of writing the cases that try to break the feature rather than the ones that show it working.
All prices AUD, ex GST.
What we look at
A lot of AI reviews start with the technology. We start with what your product is actually for, then work out where AI belongs in it, which decisions you can walk back later, and which ones you'll be living with in two years.
The diagnostic runs with read access to your repo and your telemetry.
Your product and your users
We can't analyse a product we don't understand, so this starts as conversation: the people who carry your customers' voice, product, CS and sales, plus the telemetry and support tickets that don't editorialise. We won't be asking to interview your customers. Where AI removes friction, where it introduces distrust, what a customer sees when the model is wrong, and how long they wait before anything appears. This is where the shape of the feature gets decided.
The same conversations feed the market questions, with the analysis running in the gaps between interviews: which AI features are table stakes your market will soon expect, which only you can build because of data a competitor can't get, and whether you're ready for customers who arrive with agents: MCP, your API surface, what you're willing to expose. And running cost, treated honestly: inference can't be priced from a whiteboard, so we look for the shapes that leave room to be wrong.
How you build software
Your engineering practice under an AI lens: tooling, review, test coverage, and where AI is already changing how the work gets made. The gains are often real, and often personal. We look at where they're compounding, where they're not, and where the outputs aren't transitioning into outcomes.
How you ship and prove it
Release, evals, observability, and the failure modes AI introduces: the injection surface, the tenant boundary, the answer that is confidently wrong. Whether you can tell an AI feature is good before customers see it, and whether you'd know the day it stopped being good. If the answer is no, that finding shapes everything else in the report.
01Your product and your users
We can't analyse a product we don't understand, so this starts as conversation: the people who carry your customers' voice, product, CS and sales, plus the telemetry and support tickets that don't editorialise. We won't be asking to interview your customers. Where AI removes friction, where it introduces distrust, what a customer sees when the model is wrong, and how long they wait before anything appears. This is where the shape of the feature gets decided.
The same conversations feed the market questions, with the analysis running in the gaps between interviews: which AI features are table stakes your market will soon expect, which only you can build because of data a competitor can't get, and whether you're ready for customers who arrive with agents: MCP, your API surface, what you're willing to expose. And running cost, treated honestly: inference can't be priced from a whiteboard, so we look for the shapes that leave room to be wrong.
02How you build software
Your engineering practice under an AI lens: tooling, review, test coverage, and where AI is already changing how the work gets made. The gains are often real, and often personal. We look at where they're compounding, where they're not, and where the outputs aren't transitioning into outcomes.
03How you ship and prove it
Release, evals, observability, and the failure modes AI introduces: the injection surface, the tenant boundary, the answer that is confidently wrong. Whether you can tell an AI feature is good before customers see it, and whether you'd know the day it stopped being good. If the answer is no, that finding shapes everything else in the report.
What you get
A report of findings, clear and to the point, covering:
An overview of where your product is today, and where it could be tomorrow.
Every opportunity we found, scored by impact, effort and risk.
Our recommendation, and the reasoning behind it. Including when that recommendation is don't, and what would need to change for it to become a yes.
Where your delivery practice helps or hurts you, and the changes worth making first.
What your product's AI roadmap should be, and how to sequence it. For some products that's one feature done properly; for others it's a re-think of the interface.
Results on launch day. And every day after it.
A production system has to work every day, on the inputs that never made it into the spec, while the model and context underneath it keep changing.
What does good look like? Constantly evaluated.
AI features are not deterministic, so we agree test cases and acceptable boundaries with your team and evaluate them continually. Whatever we build ships with its evals.
Good has to hold as models drift and your data changes.
A probabilistic system, in front of paying customers.
An internal tool can shrug off a bad answer. Your product can't, so the surface gets designed around the model's failure: what the customer sees when confidence is low, when an answer needs checking before it moves downstream, and when the feature should decline to answer at all.
That is why the quiet shapes usually win: the suggestion, the draft, the exception surfaced before anyone went looking. Sometimes conversation genuinely is the right interface, and when it is, we'll build it.
Domain depth, aimed at your customers.
Some features need judgment about an industry your team doesn't contain: billing and invoicing inside a cleaning-operations platform is a CFO problem before it is an engineering one. Where that's true, a fractional executive who has run the function works alongside the engineer.
Aimed at your customers' problem, not at your org chart. Your team keeps owning the product; they make sure it's right for the people who pay for it.
A record of why, not just what.
Every decision that matters gets logged with its reasoning. Why this model, why this threshold, why we rejected the obvious approach.
When someone new picks it up, whether that is your team or ours, they inherit the thinking and not just the code.
01What does good look like? Constantly evaluated.
AI features are not deterministic, so we agree test cases and acceptable boundaries with your team and evaluate them continually. Whatever we build ships with its evals.
Good has to hold as models drift and your data changes.
02A probabilistic system, in front of paying customers.
An internal tool can shrug off a bad answer. Your product can't, so the surface gets designed around the model's failure: what the customer sees when confidence is low, when an answer needs checking before it moves downstream, and when the feature should decline to answer at all.
That is why the quiet shapes usually win: the suggestion, the draft, the exception surfaced before anyone went looking. Sometimes conversation genuinely is the right interface, and when it is, we'll build it.
03Domain depth, aimed at your customers.
Some features need judgment about an industry your team doesn't contain: billing and invoicing inside a cleaning-operations platform is a CFO problem before it is an engineering one. Where that's true, a fractional executive who has run the function works alongside the engineer.
Aimed at your customers' problem, not at your org chart. Your team keeps owning the product; they make sure it's right for the people who pay for it.
04A record of why, not just what.
Every decision that matters gets logged with its reasoning. Why this model, why this threshold, why we rejected the obvious approach.
When someone new picks it up, whether that is your team or ours, they inherit the thinking and not just the code.
The chat and editor experience
Chat that can see the open record, answers that arrive as working parts of the product, changes staged into the document, editing at the cursor, and every line traceable afterwards. Five working screens, from a product we run.
What we will not do
We are not vibe coders, and we do not sell vibe-coded solutions.
No multi-year transformation programmes. No RFPs. No open-ended bums on seats.
Workshops that make everyone feel good, but don't actually deliver meaningful change.
frac this:
frac legacy.
The legacy problem in this market is not your old system. It is the firms selling to you. Same delivery model they have run for fifteen years, same process, same shape of team, now with AI in the deck. They will charge you handsomely to transform while transforming nothing about themselves. If a firm has not changed how it works, be careful about what it can teach you about changing how you work.
And no, we will not tell you to replace something because it is old. If a system has been quietly doing its job for twelve years, it has earned some respect.
frac one size fits all.
The market makes you pick one. Firms with real engineering depth turn up with a single playbook and learn your industry at your expense. Firms that have deep industry knowledge will generally provide digital solutions that are flaky and clunky. You are paying for one and you need both.
At Frac Consulting, we not only have a network of seriously impressive software and data engineers - where a build needs domain depth we do not have, we bring in an AI-pilled fractional executive who has actually run that function, working alongside the engineer. CXOs who understand your industry, your problem, and your domain, able to get up to speed and start adding value immediately.
frac big projects that turn into black holes.
You know how this one goes, because you have watched it. The pitch was $500,000. Three years later it was $4.5 million, the partners who pitched never came back, the contractors who did the work left nothing written down, and you were arguing with an account manager about a change request for a system that no longer fit your business.
We scope to the shortest piece of work worth having on its own, we agree a ceiling before it starts, and then we look at the next one. Nobody should be waiting a year to find out whether this was a good idea.
frac headcount as the business case.
AI is the biggest shift in knowledge work since the internet. Some roles will change beyond recognition and some will not survive it. But a firm that treats that as the point, that arrives with a headcount number as the business case, is bringing legacy thinking to it.
AI is not just an efficiency play. It makes what was once unreasonable not only possible, but in many cases outright silly not to do. The savings are the part you can put in a spreadsheet, so they get the attention. Human judgement, taste and instinct do not, and without them you will just do the wrong things faster. If a redundancy headline is the outcome you are after, we are the wrong firm.
Who we are
We built and run our own AI platform, Talent Hustler, and carry its uptime and its bill.
Frac Consulting was built to be the opposite of the firm that sells you AI it does not use itself. Twenty years of senior technology leadership, two of them building AI systems in production, and a network of senior engineers brought in by name when a build needs them.
“frac exists to be the firm I could never hire.”
Senior technology leadership. Readify, MatchBox Exchange, Brandcrush.
Questions people actually ask
Why wouldn't our own engineers just do this?
They can, and the model APIs are not the hard part. The paradigm is: the same input no longer gives the same output, so your tests can't assert their way to confidence. Latency moves from milliseconds to seconds, and the interface has to absorb it. Retrieval is a discipline of its own, closer to search ranking than to a database query. And something has to verify an answer before it ships, because nothing in a typical stack does. A strong team can learn all of it. Learning it in production, in front of customers, is the expensive way.
Who owns what you build?
You do. Everything transfers on payment, and anything of ours that ends up inside your product is licensed to you permanently at no cost.
What if our requirements change halfway through?
They will. That is why builds run to a capped budget rather than a fixed price. You get a ceiling to plan against, and inside it direction can change as we learn. Nobody has to negotiate to do the obvious thing.
How long does this take?
The audit's first stage is days rather than weeks. Builds are scoped to the shortest piece that stands on its own. We prefer weeks over quarters.
Hard problems do require hard engineering, though, so we can't always deliver in a few weeks. Our goal is to get the time to value as close to zero as possible.
Start with the audit.
Or just ask a question about it.
Bring what you are working on and we will tell you plainly whether the audit is your right next step, or whether it isn't.
Thirty minutes with Stephen. Free, and no obligation.