AI Engineering
A proof of concept answers whether the model can do the job. An MVP answers whether anyone will pay for it. We build both, in that order, and we tell you when the answer to the first one is no.
Most AI products die between the demo and the second week of real usage. The demo works because the person running it knows which questions to ask; the product fails because real users ask the questions nobody rehearsed. AI MVP development, done properly, is the discipline of finding that gap deliberately and early rather than discovering it after you have raised on the demo. We run two distinct stages and we keep them separate on purpose. A proof of concept is a technical question — can a model, given your actual data and your actual constraints, produce output good enough to be useful? It runs on a fixed set of evaluation cases, it costs a fraction of a build, and roughly one in four of ours ends with us recommending you stop. An MVP is a product question — will the people you built it for use it more than once, and does the unit economics work at the volume you are projecting? That needs auth, billing, error handling, observability and a support path, because users judge a product on the day it breaks. ZenMagix builds both from Mumbai for founders in India, the UK, the Gulf, Singapore and Australia. We are engineers, not an incubator: we do not take equity, we do not attend your board meetings, and we would rather ship you something small that works than something impressive that cannot be operated.
A proof of concept tests whether the technology is capable. An MVP tests whether the product is wanted. Collapsing them into one project is the single most common reason AI startups burn a seed round without learning anything.
The proof of concept has one deliverable that matters: a number, measured against a test set built from questions your real users actually ask, with a threshold you agreed to before you saw the result. Everything else — the interface, the branding, the onboarding — is scaffolding you should be willing to throw away. Two to four weeks is typical. The cost is deliberately small because the point is to make abandonment cheap. If the answer comes back below the threshold, you have spent a small fraction of a build to learn something that would otherwise have cost you a year.
The MVP starts only after that number clears. Now the questions change: what happens when the model is confident and wrong, who sees the error, how does a user recover, what does a single active user cost you per month, and what is the smallest surface area that still delivers the value. This is where founders push to add features and where we push back hardest, because every feature added before you have retention data is a feature you are guessing about. The version that ships should embarrass you slightly. If it does not, you built too much.
One user journey, end to end, working properly — plus everything required to operate it. Anything that does not sit on that journey waits until you have retention data telling you it matters.
We start from the moment of value: the single thing a user does that makes them come back. Everything upstream of that moment is required, everything downstream of it is negotiable, and everything beside it is a distraction. In practice this means the first release usually has one input path rather than four integrations, one output format rather than a configurable export, and an admin screen that is honestly quite ugly. What it always has is the operational layer, because the difference between a demo and a product is entirely in what happens when things go wrong.
That means authentication that is not a hardcoded token, a rate limit that stops one enthusiastic user emptying your model budget, structured logs that let you reconstruct what a user saw when they complain, and a cost meter per user so you find out your unit economics are broken in week two rather than after a growth push. Founders sometimes read this list as over-engineering for an MVP. It is the opposite: it is the minimum required to learn anything trustworthy from the launch, because an MVP you cannot debug produces feedback you cannot interpret.
Inference is rarely the largest line. Retries, context growth, evaluation runs and the human review loop usually cost more, and none of them appear in a pricing calculator.
A founder models cost per request from a vendor's per-token price and gets a number that looks comfortable. Then production arrives. Context grows as conversations lengthen, so the tenth message in a thread costs several times the first. Failed calls retry, and a retry with a larger model as fallback costs more than the original. Every deployment runs the evaluation suite, which at a few hundred cases is a real recurring bill. And if your product needs a human checking a sample of outputs — most serious ones do at first — that person is your largest cost by a wide margin and does not appear anywhere in the technical estimate.
There is a second surprise on the revenue side. Usage-based AI products have a customer who is expensive precisely because they are engaged, which inverts the usual SaaS intuition that your best users are your cheapest. If your pricing is a flat monthly fee, your most enthusiastic customers can be your least profitable, and you will not see it in aggregate margins until it is a problem. We instrument for this from the first release: cost per user, per feature and per cohort, visible on a dashboard from the day you launch rather than reconstructed from invoices six months later.
You own the repository, the infrastructure definitions and the evaluation harness outright. The handover is a working system your own engineers can operate, not a dependency on our availability.
An MVP built as a throwaway leaves you rewriting from scratch the moment it works, which is the worst possible time to be rewriting. We build the first version on foundations that survive: real migrations rather than a schema someone edited by hand, infrastructure defined in code rather than clicked into a console, environment configuration that does not live in one laptop, and a test suite that covers the paths where money and data move. None of that is gold-plating.
It is the difference between scaling a product and re-founding it. When the engagement ends, you get the repository with its full history, the infrastructure code, the evaluation harness with its case set, a runbook covering deploys, rollbacks and the three things most likely to break, and a handover session with whoever will own it. If you hire an engineering team afterwards and never speak to us again, that is a successful outcome and we will say so on the call.
Where founders do continue with us, it is usually as a monthly retainer on evaluation and reliability while their own team takes over feature work — the part that benefits most from experience and least from being in the building.
What you get
A narrow technical test against your real data, scored on an evaluation set built from questions your market actually asks. You agree the threshold before you see the result, which is what makes the answer worth having. Ends with a written recommendation, including a recommendation to stop where that is the honest read.
The single user journey the first release will deliver, the features explicitly deferred, and the reasoning for each cut written down so it can be argued with. Includes the unit economics model and the cost-per-active-user assumption the pricing depends on.
Authentication, billing hooks, rate limiting, structured logging, cost metering and a defined failure path — plus the feature itself. Deployed on infrastructure you own, in an account you control, with a domain you can point elsewhere tomorrow.
The test case set, the scoring method validated against human judgement on a sample, and a CI gate that blocks deploys which drop the score. This is the asset that lets your own team change the system later without silently degrading it.
Repository with full history, infrastructure as code, environment setup documentation, a runbook covering deploys, rollbacks and known failure modes, and a live session with the engineers who will own it. Written so a new hire can be productive without us.
How we work
One to two weeks. We define the single technical question the proof of concept will answer, build the evaluation set from real market questions, and agree the pass mark in writing. If we cannot state the question crisply, the project is not ready and we say so before invoicing you for a build.
Two to four weeks of focused technical work against your real data. Output is a score, the failure analysis behind it, and a recommendation. About a quarter of proofs of concept end here with a no, and that is the cheapest useful outcome available to you.
Eight to twelve weeks. One user journey end to end, with the operational layer that makes launch data trustworthy: auth, limits, logging, cost metering, failure paths. Weekly demos on the real system rather than slides, so scope arguments happen against something you can click.
Real users, instrumented from the first day. We watch retention, cost per active user and the evaluation score together, because any one of them read alone will mislead you. Then the handover pack, the runbook and a session with whoever owns it next — us, your team, or someone else entirely.
Every phase ends at a decision point you can stop at — see how that works across fixed-scope projects, embedded pods and retainers.
Stack
Questions
A proof of concept is a fixed-fee project in the low lakhs. A production MVP is a multiple of that, driven mostly by integration surface — how many of your systems it has to touch — rather than by model complexity. We scope the PoC first specifically so you can spend a small amount to decide whether the larger amount is worth committing.
Two to four weeks for the proof of concept, then eight to twelve weeks for an MVP with real users on it. Anyone quoting three weeks for a production AI product is quoting a demo. The gap between a demo and something you would let a customer touch unattended is where nearly all the engineering sits.
No. We are an engineering firm, not an investor, and equity arrangements distort the incentive that makes us useful — the ability to tell you a project should stop. Our fee structure means recommending you not build something costs us the next phase, and we would rather that be a clean commercial decision than a shareholding conflict.
You have spent a small fixed fee to avoid a large one, and you get the failure analysis: what the model could not do, whether better data would change it, and whether a narrower version of the problem is still viable. Often it is — a scope that was too broad becomes workable when cut down. Sometimes it is not, and we will say that plainly.
Yes, and it is often the best-value engagement we run. A technical founder usually needs the evaluation harness, the retrieval architecture and the cost instrumentation more than they need someone writing product code. We will build those and get out of the way rather than pretending you need a full team.
You own the code outright, with full repository history and no retained licence. Fine-tuned model weights produced from your data are yours. We do not build on a proprietary internal framework, so nothing in the handover requires our continued involvement to run or modify.
Questions about cost, timelines, IP ownership and data residency are answered on the general FAQ, and how this practice came out of blockchain infrastructure explains why we build the way we do.
Related
A paid diagnostic that tells you what is worth building and what is not.
The pipelines and quality layer every AI project stalls on.
Retrieval that cites its sources, measured with a real evaluation harness.
See also: take a proven concept into production with AI agent development · fix the data foundation first with data engineering for AI · start with an AI readiness assessment if the problem is not yet defined
Tell us what you are trying to build. We will tell you honestly whether we are the right team for it, and what it would realistically take.
