Spearhead practice

MVP Development for AI Startups

I run ColadAI, a multi-LLM platform serving real traffic, so I build AI MVPs from the position of someone who pays an inference bill every month. That changes what I put in v1.

The AI MVPs that fail are rarely the ones with a weak model. They are the ones where nobody knew what a session cost, nobody could tell whether last week's prompt change helped, and the tool-calling surface had never been looked at. Those three things are cheap to build in and expensive to retrofit.

Book a 30-min call See pricing Contact Me

How the build runs

What is different about scoping an AI product

The screen count is small, the plumbing behind it is not

Most AI MVPs are six to ten screens. The work that decides whether the thing survives sits behind them: the provider abstraction, the eval harness, the cost instrumentation. I price the screens and tell you plainly which of that backend work is in the number and which is a separate line, so there is no surprise when the invoice arrives.

I instrument cost per session from the first commit

Not after you notice the bill. Every LLM call is logged with tokens in, tokens out, model, and a session identifier, so on launch day you can answer what a user costs. Founders who cannot answer that question at demo time end up guessing in the fundraise.

A minimum eval harness ships with v1

Not a full regression suite, that is overbuilding at this stage. A golden set of twenty to fifty cases and a script that scores them, so when you change a prompt after launch you get a number instead of a feeling. This is maybe two days of the build and it pays for itself the first week.

Injection boundaries get drawn before the tool calls exist

If your MVP reads untrusted input and can call a tool, that is an injection target on day one, not at Series A. I scope the trust boundaries and the credentials down while the surface is still small, because it is a two-hour conversation now and a rewrite later.

One provider, one seam

I do not build a multi-provider abstraction into an MVP, that is premature. I do put a single thin seam between your product and the vendor, so swapping later is a day rather than a month. It costs almost nothing to add now.

Scope

What a v1 looks like here, specifically

Screen counts are a starting point, not a quote. The real number comes out of the scoping week, and it is almost always lower than the brief that walked in.

6 to 10 screens

Typical v1 for an AI product, scoped in the first week

Goes in v1

Auth, the core generation or chat surface, and history
Per-session cost logging with tokens and model recorded
A golden-set eval script you can run on every prompt change
One provider behind a thin swappable seam
Streaming responses and sane failure states when the model errors

Deliberately deferred

Fine-tuning: almost never the right call before you have usage data
Multi-provider routing: build the seam now, the routing when volume justifies it
A full RAG pipeline if a smaller context window answers the question
Usage-based billing before you know what a user actually costs

What you're actually buying

Scoping, the build, and launch

Week 0

Scoping: every screen counted and priced

We go through everything you think the MVP needs, screen by screen, and cut it down to what actually has to exist to test the thing you're testing. Every remaining screen gets counted and priced at $80, across whichever platform it needs — mobile, web, desktop, or Linux. You leave with a scope doc and a total, not an estimate that moves once we start.

The build

Design and development, with you seeing it every week

My Panicle Tech design and engineering team builds it, screen by screen; I own the architecture, the code review, and the calls that are expensive to get wrong. You get a working build to look at every week, not a status update. If a screen turns out to need more than was scoped once it's half-built, that gets priced honestly before it's fully built, never absorbed silently.

Launch

Handover, and two weeks of me still answering the phone

Deployed, monitored, and documented well enough that the next engineer who touches it isn't guessing. Two weeks of post-launch support are included, because the bugs that matter are the ones your first real users find, not the ones QA finds.

Why me, for this market specifically

Experience, not a capabilities deck

Plenty of teams can build screens. Fewer have shipped for AI startups specifically, been wrong about it, and had to fix it with their own name on the commit. Here's what I'm bringing.

Founder of ColadAI, a production multi-LLM platform serving real traffic
M.Tech in Cybersecurity, NIT Kurukshetra, with 30+ academic citations
Published on prompt injection and AI-driven threat detection
Six ventures built 0 to 1 across three continents

Pricing

from $80 a screen. Counted up front.

Design and build, screen by screen, across mobile, web, desktop, and Linux. My Panicle Tech team designs and builds it; I own the architecture and the technical decisions as advisor on the project. Added screens are priced at the same rate, never renegotiated after the fact.

MVP Design & Development

from $80

per screen

Scoping week: every screen counted and priced up front
UI/UX design and full-stack development, screen by screen
Built by my Panicle Tech design and engineering team
I own the architecture, code review, and technical direction
Mobile, web, desktop, and Linux apps, whichever the product needs
Deployment, monitoring, and handover documentation
Two weeks of post-launch support
Added screens priced at the same per-screen rate, never renegotiated after the fact
Option to continue on a fractional retainer

Full pricing and the scoping process →

Questions

AI startups, specifically

Do the evals and cost logging count as screens?

No. Screens are what a user sees. The eval harness and cost instrumentation are backend work and I quote them as a separate, fixed line in the scope so you can see exactly what each part costs. I would rather show you the split than bury it in a per-screen average.

We want to fine-tune a model. Can you do that in the MVP?

I can, but I will push back first. Fine-tuning before you have real usage data is usually optimising the wrong thing, and it locks you into a shape you may want to change. Prompting plus retrieval gets most MVPs where they need to be. If after the scoping call fine-tuning is genuinely the right answer, we scope it in.

Can you build on top of our existing prototype?

Often yes, and the scoping week is where we find out. Sometimes the prototype is a good foundation and I extend it. Sometimes it is a notebook that proved the idea and starting clean is faster than untangling it. I will tell you which after I have read it, not before.

How do you price a feature where the model does most of the work?

Still per screen for the interface, plus the backend line for the model work. A screen that is one input and a streamed response is one screen even though the intelligence behind it is the hard part. The scoping call is where I make sure that hard part is priced honestly rather than hidden in the screen rate.

More general questions about pricing, timeline, and what's included are answered on the main MVP development page.

Earned, Not Claimed

What the founders and teams I build with say

I had the pleasure of working with Kunal while building out my MVP and I have to say that it was pleasure to both interact and work with him and his team. As a first time founder, I had a lot of self doubt and internal ruptures, however Kunal's calm, never-say-die and never-panic attitude often helped bring me back to center. I can't vouch for him enough.

Anand Tahiliani

Founder, Debaser Technologies

I had the pleasure of working closely with Kunal during my time as a Product Manager at DhunGuru. As our CTO, Kunal and his team at Panicle Tech worked closely with me across the entire product journey, from building and launching our mobile apps to developing and maintaining our web platforms. His technical expertise, ownership, and willingness to collaborate made a real difference, and I genuinely enjoyed working with him throughout the journey.

Anirudh Joshi

Product Manager, DhunGuru

Kunal helped us architect Mosler's core platform, connecting smart lock hardware, our cloud dashboard, and PMS integrations into one reliable system. The foundation he helped design in those early days still scales with us today.

Pranav Kapoor

Co-Founder, Mosler

If you need more than a build

Already have a product, not just an MVP?