18 - Choosing the Right MVP: Landing Pages, Prototypes, Concierge, and Wizard-of-Oz

When I think about building a startup, one lesson keeps becoming clearer: we don't need to build the complete product to start learning from customers.

In fact, building everything before validating the most important assumptions can be one of the costliest mistakes a startup can make.

While building AINexLayer, I have increasingly come to see the MVP not as a "small version" of the final product, but as a learning mechanism.

The objective is simple:

That question changes how we think about product development.

An MVP could be a landing page. It could be a clickable prototype. It could be a manually delivered service. It could even be a product that appears fully automated while humans are doing the work behind the scenes.

The technology can come later.

The learning cannot.

There Is No Single Definition of an MVP

One common mistake I see among founders is treating MVP as a fixed formula.

They assume an MVP means building a smaller version of the final software with fewer features.

I don't think that is the right way to look at it.

The right MVP depends on what you are trying to learn.

For one startup, the biggest question might be:

"Will customers pay for this?"

For another:

"Do users understand this workflow?"

For an AI startup:

"Will customers trust an AI system to perform this task?"

And for an enterprise platform:

"Can we integrate this into the customer's existing systems and processes?"

Each question requires a different experiment.

This is particularly important in India, where startups often have to be extremely capital efficient. Whether you're building for an Indian MSME, a manufacturing company, a bank, a hospital, or a global enterprise from India, spending months building something before validating demand can be dangerous.

The MVP should therefore be designed around the riskiest assumption, not around the features we want to build.

Landing Page MVP: Test Whether People Care

A landing page is probably one of the simplest MVPs available.

You explain the problem, communicate the value proposition and give potential customers a way to take action.

That action could be:

• Joining a waitlist

• Requesting a demo

• Signing up

• Booking a meeting

• Starting a trial

• Pre-ordering

The important thing is that you measure behavior rather than opinions.

Someone telling me, "That's a great idea," is interesting.

Someone giving me their email, booking a demo, sharing their business problem, or actually paying is much stronger evidence.

For example, imagine I'm building an AI solution for Indian manufacturing companies.

Before building a complete AI manufacturing platform, I could create a landing page explaining how AI could help factories reduce downtime, analyze production data, and automate reporting.

Then I could measure how many plant managers, operations teams, or manufacturing companies actually request a discussion.

That tells me something far more valuable than simply asking people whether they like the idea.

Prototype MVP: Test the Experience Before Building the System

Sometimes we already know that a problem exists.

The bigger question is whether people can actually use the proposed solution.

That's where a prototype becomes powerful.

A prototype can simulate the experience without having the complete backend infrastructure underneath it.

For example, imagine designing an AI analytics interface.

Instead of immediately building the entire data pipeline, authentication system, AI orchestration layer, database architecture, dashboards and deployment infrastructure, I could first create an interactive prototype.

Then I can put it in front of real users.

Where do they click?

What do they understand immediately?

Where do they get confused?

What information do they expect to see?

What questions do they ask?

These observations can completely change the product roadmap.

This is especially relevant to enterprise AI because the technical complexity behind the product can be enormous, while the customer experience should remain simple.

Concierge MVP: Become the Backend

The concierge MVP takes the idea even further.

Instead of automating the service, you manually deliver the service yourself.

The customer receives the intended value, but the technology behind it may still be completely manual.

Suppose I wanted to build an AI-powered business intelligence service for Indian MSMEs.

Instead of immediately building a sophisticated automated analytics platform, I could ask a small group of companies to share their Excel or CSV data.

I could manually analyze the data, generate insights and deliver the results.

If customers repeatedly ask for the service, pay for it, and tell me they need it regularly, I've validated something important.

Only then does it make sense to automate the process.

This approach can feel uncomfortable for technical founders.

We naturally want to build the technology first.

But the customer doesn't care how elegant our architecture is.

They care whether the problem is solved.

Wizard-of-Oz MVP: Hide the Manual Work

The Wizard-of-Oz MVP is particularly interesting for AI startups.

Here, the customer believes the product is automated, while some of the work is still being performed manually behind the scenes.

The customer experiences the intended product.

The founder learns whether the experience actually creates value.

This can be extremely useful when the underlying technology is expensive or complicated to build.

Imagine an AI assistant that promises to analyze a company's internal documents and answer business questions.

Before building the complete RAG pipeline, document processing system, agent architecture, evaluation framework and enterprise security infrastructure, a founder could manually prepare answers for a small number of users.

The objective isn't to fake a product indefinitely.

The objective is to answer a critical question:

If this capability existed reliably, would customers actually use it?

Once that answer becomes clear, engineering investment becomes much less speculative.

How I Think About MVPs at AINexLayer

This distinction is particularly relevant to what we're building at AINexLayer.

Enterprise AI isn't simply about putting an LLM behind a chat interface.

There are questions around data, security, governance, integrations, knowledge retrieval, analytics, automation and user adoption.

If we tried to build every possible capability before validating what enterprises actually value, we could easily spend years building.

Instead, the MVP mindset encourages a different approach.

Start with a specific customer problem.

Validate the workflow.

Understand the data.

Measure usage.

Learn what customers actually need.

Then automate and scale.

For example, an enterprise might initially want a simple way to ask questions about its internal documents. That initial workflow can reveal much more about the customer's real needs.

Maybe the customer then asks for analytics.

Maybe they need integration with ERP systems.

Maybe they want automated reports.

Maybe they need AI agents to execute workflows.

Those insights should influence what we build next.

That's how a platform evolves from customer evidence rather than founder assumptions.

Choosing the MVP Based on the Risk

I find a simple framework useful here.

If the biggest question is demand → use a Landing Page MVP.

You want to know:

"Does anyone care?"

If the biggest question is usability → use a Prototype MVP.

You want to know:

"Can people actually use this?"

If the biggest question is service adoption → use a Concierge MVP.

You want to know:

"Will customers pay for this outcome?"

If the biggest question is automation → use a Wizard-of-Oz MVP.

You want to know:

"If this capability were automated, would customers use it?"

The important point is that the MVP should answer a question.

It shouldn't exist simply because every startup is expected to have one.

Indian Startups Can Benefit From This Mindset

India is an especially interesting environment for MVP-driven entrepreneurship.

We have a massive and diverse customer base, from digitally native startups in Bengaluru and Hyderabad to traditional MSMEs, manufacturers, retailers and service businesses across Tier-2 and Tier-3 cities.

But these markets can also be highly price-sensitive.

That makes capital efficiency incredibly important.

Instead of spending ₹50 lakh building a product and then discovering that customers don't want it, a founder might be able to spend a fraction of that amount testing the most important assumption first.

This is not about building cheaply forever.

It's about earning the right to invest more.

Once the evidence becomes strong, we can increase engineering investment, improve reliability, automate operations and scale distribution.

MVP Is About Learning, Not Looking Impressive

One of the biggest psychological challenges for founders is accepting that the first version may look incomplete.

We often want to show customers a polished product.

We want impressive dashboards.

We want sophisticated AI.

We want automation everywhere.

But customers don't reward us for the amount of code we have written.

They reward us for solving meaningful problems.

An MVP gives us permission to be wrong cheaply.

That's incredibly valuable.

If the hypothesis is wrong, we learn quickly.

If the hypothesis is right, we have evidence to justify the next investment.

Either way, we move forward.

The Real Question Every Founder Should Ask

Whenever I'm thinking about a new product or feature, I believe the most useful question isn't:

"What should we build?"

It is:

"What do we need to learn?"

Once we know that, the MVP becomes much easier to design.

If we need to test demand, build a landing page.

If we need to test the experience, build a prototype.

If we need to test whether customers will pay for a service, deliver it manually.

If we need to test an automated experience before the technology is ready, use a Wizard-of-Oz approach.

The smartest founders aren't necessarily the ones who build fastest.

They are the ones who learn fastest.

From MVP to a Real Product

An MVP is not the destination.

It is the beginning of a feedback loop:

Hypothesis → MVP → Customer Feedback → Evidence → Iteration → Product → Scale

That's the mindset I believe is particularly important when building AINexLayer.

We don't want to build AI simply because AI is exciting.

We want to build AI that solves real enterprise problems, creates measurable value and earns the right to become part of how organizations operate.

That means starting with the smallest meaningful experiment, learning from customers, and then progressively increasing the sophistication of the product.

The goal isn't to build the smallest product possible.

The goal is to build only what we need to learn what matters next.

And that, to me, is the real power of the MVP.

Build less. Learn faster. Invest with evidence. Then scale with confidence.

Try AINexLayer

If you want to explore how AI can help businesses work with their data, analytics, documents and workflows, you can try AINexLayer → app.ainexlayer.com.

The same principle applies here: start with a focused problem, understand the customer deeply, validate the value, and then expand from a strong foundation.

Start with evidence. Build with focus. Scale with vision.