About
One engineer. One learner per session. No exceptions to either.
SoloZ AI is one person, deliberately — and it delivers to one person at a time, deliberately. The pitch is not that AI is transformative; you have heard that. It is that AI adoption fails in groups, and that most AI automation is a demo nobody engineered to survive the following Monday — and that both of those are solved problems almost nobody in this market bothers to solve.
- Engineer, from the first call to the handover
- 1Engineer, from the first call to the handoverThe person on the fit call is the person who writes the code, runs the evaluation and delivers the handover. Nothing is passed down to somebody junior after signature.
- Delivery, at every scale
- 1:1Delivery, at every scaleTwo people in the session, always — the person whose work is changing, and me. Twenty-five people means twenty-five intakes and twenty-five separate sets of sessions, not one delivery for twenty-five.
- Golden pairs in every evaluation suite
- 40Golden pairs in every evaluation suiteEvery AI deliverable is checked against the same forty questions before handover, and again before any change to it afterwards. Below the written pass threshold, it is not shipped.
- From the fit call to a written proposal
- 24hFrom the fit call to a written proposalWritten by the person who would do the work rather than generated by a sequence — and once it is written the number does not move except by a change order you agree first.
The position
The demo is not the hard part.
Anyone can produce an impressive AI demo now. That is genuinely new, and it is why the market filled up with agencies in about eighteen months. What has not changed is the gap between a demo and something a business can depend on at nine in the morning when a customer is waiting.
That gap is ordinary software engineering: version control, tests, error handling, retries, observability, documented handover. The work is not glamorous and it does not demo well, which is precisely why it keeps getting skipped — and why so many automations are quietly switched off a few months after they are delivered.
My background is production systems architecture — building things that keep running when nobody is watching. SoloZ AI applies that discipline to AI delivery. The evaluation suite that ships with every AI build is the clearest example: forty golden question-and-answer pairs and a documented pass threshold, so is it working? has a number rather than an opinion behind it.
The same afternoon's work, read six months later
Read a row across: what a prototype does with it, and what it takes for the same thing to still be running.
Time to something impressive
A demo: An afternoon — and it will genuinely impress the room. This is the part that got easy.
A production system: The same afternoon, plus the fortnight nobody demos.
What it has to survive
A demo: One meeting, driven by the person who built it.
A production system: Every morning after that meeting, unattended, with a customer waiting.
When something upstream fails
A demo: It stops quietly, and somebody notices days later.
A production system: It retries on a schedule, and when it does finally give up it says so, by name, the same morning.
How you know it still works
A demo: Somebody tries it and forms an opinion.
A production system: You can answer it without asking anyone: the same question set, re-run, against a threshold agreed in writing.
Who can change it in six months
A demo: Whoever built it, if they still remember what they did.
A production system: Your own engineer, from your own repository, with the history to read and a runbook to follow.
It is a narrow, unfashionable pitch. It also disqualifies me from competing with the cheapest bot builder on a freelance marketplace, which is exactly the intention.
This is a good fit when
- An individual professional who wants to be materially better at this, with no employer involved
- A sponsor who needs a whole function competent and accepts that means one programme per person
- B2B teams of roughly 10–200 people with a real operations bottleneck
- Someone senior — founder, COO, or head of operations — who owns the decision
- A process you can describe in one sentence and count in hours per week
- Existing systems worth integrating: a CRM, a helpdesk, a document store
- An expectation that software is version-controlled, tested and documented
This is not a fit when
- Anyone who wants a group class, a cohort or a one-day workshop — no such format exists here
- Pre-revenue startups looking for a technical co-founder
- Anyone whose first question is the price rather than the problem
- “What can AI do for us?” — with no process, owner, or number attached
- Work that requires hosting your operations on my infrastructure
- Projects where nobody internally is accountable for the outcome
Being told no early is worth more than a proposal that was never going to work.
How this business is run
Five rules that decide most things.
They cost revenue in the short term and they are the reason the work is worth buying. Each one is printed here with the business it rules out, because a principle with no cost attached is a slogan.
Say no to the work that will not succeed
A project with no named owner, no access, or no measurable process behind it will fail regardless of how well it is built. Turning those down early is better for both sides than discovering it in week three, so the fit call is genuinely a qualification call.
What it rules out · Exploratory work commissioned by an enthusiastic sponsor with nobody accountable for the result.
Quote it before it starts, then hold it
A fixed price in writing, numeric scope caps, and change orders priced above the blended rate so nobody nibbles. No number is adjusted to what a buyer looks like they can afford, because that is not a relationship worth starting.
What it rules out · Discovery-priced retainers, and any engagement that has to start before its number is known.
Never teach two people at once
Every training and adoption engagement is delivered to exactly one person, including the enterprise ones. It is slower and it costs more per head, and it is the only version that changes how a named individual works the following Monday. There is no group tier to fall back on when a deadline gets tight.
What it rules out · The margin in one-to-many — the highest-leverage revenue line in this industry, and the one not on offer here.
Build it so you can leave
Client-owned infrastructure, version control, runbooks and recorded handovers are the standard, not the premium tier. If the only thing keeping a client is that leaving is painful, the work was not good enough.
What it rules out · Recurring managed-service revenue, and every arrangement where leaving would mean rebuilding.
Cap the calendar, not the quality
Delivery capacity is deliberately limited. Over-booking is how solo operators miss first deadlines, and a missed first deadline costs the referral — which at this stage is the only lead source that matters.
What it rules out · The next project, whenever the calendar for the current ones is already full.
What production-grade means here
Most AI automation is a prototype
with a confident tone.
The demo always works. The question is what happens on the bad day — when an API times out, a model is deprecated, or someone asks the assistant something it should refuse. That is the part I get paid for.
These are not upsells or a premium tier. They are the standard every engagement is delivered to, and they are the reason a quote is what it is.
You own the infrastructure
Everything runs in your cloud, your automation instance, your API keys, your vector database. I get delegated admin access that you can revoke in one click. You are never renting your own operations back from me.
Everything is in version control
Workflows exported to your Git repository. Prompts as versioned files, not pasted into a web form and forgotten. You can read the history, diff a change, and roll it back.
Every AI deliverable ships with an evaluation suite
Forty golden question/answer pairs, a documented pass threshold, and a regression run before handover and before any change. When someone claims the assistant "got worse", there is a number to check instead of an argument.
Failure paths are built, not assumed
Retries, timeouts, dead-letter handling, and alerting into a channel your team already reads. The interesting part of automation is what happens on the bad day, not the demo.
Observability from day one
Execution logging, failure alerting, and a token-cost view — shipped with the build rather than sold back to you later as an upgrade.
Handover is one to one, like everything else
Each person who has to operate or change the system gets their own recorded session, pitched at what that individual actually needs to know. Nobody is asked to keep pace with anyone else in a shared briefing.
The business
Who you would actually be contracting with
SoloZ AI is the services practice of OpenEng Labs, operating from Bangalore, Karnataka, India. Delivery is remote and scheduled inside your working hours rather than mine.
There is no bench behind that. One engineer scopes the work, builds it and runs the handover — which is why the calendar is capped, and why nobody you have not met ever turns up to a session.
Everything commercial is written down before anything is built — and most of it is published on this site before you ask for it.
Where the work is delivered
Remotely, to teams in these markets. Sessions are booked in slots that already overlap your working day, and the time zone is agreed on the fit call rather than assumed.
- United States
- United Kingdom
- European Union
- United Arab Emirates
- Saudi Arabia
- Singapore
- Australia
- India
- Operating from
- Bangalore, Karnataka
- Practice of
- OpenEng Labs
What governs the work, and which document wins
Published terms, a signed statement of work per project, the clauses specific to AI work, and what you are left holding at the end.
The terms of service
Published, standing
The default position for every engagement — confidentiality, intellectual property, liability, governing law. Published here in full rather than sent on request, and where a signed statement of work or master services agreement says something different, the signed document controls.
The statement of work
Signed, one per project
Numeric scope caps, deliverables, acceptance criteria, timeline and payment schedule. This is the document that forms the engagement: work begins once it is agreed in writing and the first payment in it has cleared. Anything outside the caps is a change order, quoted before it happens.
The AI-specific clauses
Section 7 of those terms
The three things that are genuinely different about this work: model outputs are probabilistic rather than deterministic, human review stays your responsibility in customer-facing and financial use, and a third-party model being deprecated underneath you is a change-order event rather than a defect.
Intellectual property transfer
On full payment
Workflow definitions, prompts, evaluation suites, configuration, documentation and bespoke code transfer to you. What does not is named rather than implied: general methods and reusable components that pre-existed your project, and third-party components under their own licences.
Two revision rounds are included on every build, and the complete terms — including what happens if an engagement is cancelled, and which clauses survive it — are in the terms of service.
Worth twenty minutes?
Bring one process and roughly how many hours a week it costs you. That is enough to know whether there is anything here worth doing.
Prefer email? hello@soloz.ai