There is a peculiar contradiction at the heart of the modern software industry. Building software has become dramatically easier, yet discovering whether anyone wants that software remains stubbornly difficult. A capable developer can assemble a working application in days, particularly with the assistance of AI coding tools. Authentication, payments, databases, dashboards, and deployment infrastructure can all be assembled from existing components. The technical barriers that once required an entire engineering team have become manageable for a single determined founder.
But something important has not changed. A business owner who spends three hours every Friday reconciling spreadsheets does not necessarily want another dashboard. A sales manager frustrated by inaccurate forecasts does not necessarily want an AI forecasting platform. A medical practice struggling with appointment cancellations does not necessarily want scheduling software. These customers want the underlying problem to disappear, and they are often indifferent to whether the solution involves artificial intelligence, a sophisticated application, or a person working carefully behind the scenes.
This creates an uncomfortable possibility for software founders. What if the fastest way to discover whether a SaaS product is worth building is to stop building software? What if the first version of the product is simply the founder performing the work manually, delivering the promised result, and asking the customer to pay?
The idea sounds backward because it appears to abandon the defining advantage of software: automation. Yet a technique known as the concierge minimum viable product, or concierge MVP, has helped founders investigate demand before committing to complicated systems. Its logic is simple. Instead of automating a process that customers may not value, the founder performs the process personally for a small number of customers and studies what happens.
The approach is particularly relevant to B2B SaaS, where customers often care more about measurable business outcomes than the technology used to produce them. A company that saves ten hours of administrative work may be worth paying for even if the first version relies on spreadsheets and manual effort. The founder's challenge is to establish that value before spending months creating a machine to deliver it.
The Company That Began With One Customer
One of the clearest early examples of the concierge MVP came from a company called Food on the Table. The business aimed to help families plan meals while reducing grocery expenses, a problem involving personal preferences, local store prices, recipes, and shopping lists. A conventional software development plan might have required a database of recipes, integrations with grocery pricing information, preference management, and a recommendation engine capable of producing personalized weekly plans.
Instead, the company began with a single customer. In the account popularized through Eric Ries's The Lean Startup, the founder met with a parent to understand her family's preferences and shopping needs. The service then assembled meal plans and shopping lists manually, performing work that a future software system might eventually automate. The process was repeated with additional customers as the team learned more about what families actually needed.
The interesting part is not that the initial service was technologically primitive. It is that the founder could observe the customer's experience directly. A recommendation algorithm might eventually suggest recipes based on stored preferences, but a person speaking with the customer could discover that certain ingredients were disliked, that a child refused particular meals, or that shopping at a specific store was more convenient than saving a few additional dollars elsewhere.
These details matter because they reveal the difference between the problem a founder imagines and the problem a customer experiences. A founder might assume that the primary value of meal planning is reducing grocery expenses, while the customer may care more about eliminating the daily decision of what to cook. Another customer might value predictable shopping lists because they reduce time spent in the store. By performing the work manually, the founder can discover which benefits actually drive satisfaction.
Food on the Table was a consumer-oriented service rather than a B2B SaaS company, so its experience should not be mistaken for direct evidence of enterprise software sales performance. Its importance lies in demonstrating the mechanism. A founder can learn about customer behavior by delivering the result personally before building the system intended to deliver it at scale.
Why Selling Before Building Feels So Uncomfortable
Software engineers are trained to solve problems through systems. When they encounter a repetitive process, their instinct is to identify the inputs, define the outputs, and design an algorithm that connects them. This is an enormously useful way to think about engineering, but it can become a liability when the underlying business problem has not yet been validated.
Imagine a developer who discovers that small accounting firms spend hours preparing monthly reports for clients. The developer sees an opportunity to automate the process by connecting accounting platforms, importing transactions, generating charts, and producing branded PDF reports. The idea is technically plausible, and the product could eventually become valuable.
The developer begins building. After six weeks, the application can connect to two accounting systems and produce a report. After another month, it supports custom templates and scheduled delivery. By the time the founder begins contacting accounting firms, the product has become a substantial technical accomplishment.
Then the founder discovers that most firms already use acceptable reporting tools, while the few dissatisfied firms have highly customized workflows that the new application cannot support. The problem was real, but the proposed solution did not address the circumstances that made customers willing to pay.
A concierge MVP reverses the sequence. Before building integrations, the founder approaches accounting firms and offers to prepare their next monthly client reports as a managed service. The founder requests access to the necessary information through appropriate secure channels, produces the reports manually, and charges for the outcome. During delivery, the founder discovers which reports matter, where existing workflows fail, and whether customers find the result valuable enough to purchase again.
The difference is not merely that the second approach requires less development. It exposes the business assumptions to reality much earlier.
The First Customer Is Not Buying Software
A founder who has spent years working in technology may assume that the product is the software itself. The customer, however, often sees the situation differently. A restaurant owner does not want inventory software because inventory databases are fascinating. The owner wants to reduce waste, avoid running out of ingredients, and understand where money is disappearing. A recruiting manager does not want an applicant tracking system because it contains sophisticated workflow automation. The manager wants to fill open positions without losing qualified candidates.
This distinction changes how an early offer should be presented. Instead of promising a platform with automated integrations, customizable dashboards, and intelligent reporting, a founder might promise to deliver a weekly inventory report that identifies expensive waste. Instead of selling an AI recruiting assistant, the founder might offer to organize incoming applications and deliver a qualified shortlist according to agreed criteria.
The first offer describes an outcome rather than a technical implementation. That makes it easier for a customer to evaluate because the customer already understands the business problem. The founder does not need to persuade the buyer that a particular architecture is innovative. The founder needs to demonstrate that the promised result is worth paying for.
This approach also changes the nature of objections. A prospect who says they do not want another software platform may still be interested in a service that eliminates a recurring administrative burden. A company that refuses to integrate an unfamiliar application into its systems may be willing to test a narrowly scoped service using an approved export process. The founder can learn which barriers relate to the outcome and which relate to the proposed technology.
For B2B SaaS companies, this can be especially valuable because early customers may resist adopting unproven software even when they urgently need the underlying problem solved.
What a Concierge MVP Actually Looks Like
Consider a founder developing software to help property management companies track maintenance requests. The eventual product might receive tenant messages, categorize repairs, assign vendors, monitor progress, and generate monthly reports. Building all these capabilities could take months, especially if the application needs integrations with existing property management systems.
A concierge version could begin with one property manager and a carefully defined pilot. The manager forwards maintenance requests through an approved channel, and the founder manually organizes them in a spreadsheet or lightweight database. Each day, the founder produces a prioritized list of unresolved requests and follows an agreed process for communicating with vendors. At the end of the week, the manager receives a report showing open issues, response times, and completed work.
The customer knows that the service is being delivered manually. The founder is not pretending that an automated platform already exists. The purpose is to determine whether the workflow creates enough value to justify continued payment and whether the repeated steps can eventually be automated.
During the pilot, the founder may discover that categorizing maintenance requests is relatively easy, while coordinating vendor availability is the real source of frustration. Alternatively, the manager may value the weekly report more than the daily task list. These observations can fundamentally change the software roadmap.
Without the concierge experiment, the founder might have spent months automating the wrong part of the process.
The Hidden Advantage of Manual Work
Automation removes human effort from a process, which is exactly why software can become economically attractive. But automation also removes opportunities to observe the details of that process. Once a founder has designed a system around particular assumptions, the software begins shaping what the founder can see.
A manual service creates the opposite experience. Every unusual customer request, confusing spreadsheet, missing field, and unexpected exception becomes visible. The founder learns which steps are straightforward, which require judgment, and which vary substantially from customer to customer.
This information is difficult to obtain through conventional interviews. Customers often struggle to explain the details of familiar workflows because many decisions have become automatic. They may describe a process as simple even though it contains dozens of small judgments that a software system would eventually need to reproduce.
By performing the work, the founder discovers those judgments directly. The experience can reveal that a proposed feature is unnecessary, that a supposedly minor exception occurs frequently, or that a particular manual decision is too expensive to automate economically.
This makes the concierge MVP more than a customer-acquisition tactic. It is a method of discovering the actual product requirements through repeated exposure to customer behavior.
How to Find Your First Concierge MVP Customer
The first step is to identify a narrowly defined customer who experiences a recurring and measurable problem. Broad descriptions such as small businesses or marketing teams are usually insufficient because they conceal enormous variation. A more useful target might be independent accounting firms with five to twenty employees that prepare monthly financial reports for multiple clients.
The founder should then investigate how those customers currently solve the problem. This can involve conversations with former colleagues, direct outreach to relevant businesses, participation in professional communities, or introductions from people who already serve the market. The purpose is not initially to present a feature list. It is to understand the workflow, the consequences of failure, and the cost of the existing solution.
Once a credible problem emerges, the founder can offer a narrowly scoped pilot. The offer should describe the result, delivery schedule, responsibilities, and price. For example, a founder might propose preparing four weekly performance reports for a fixed fee, with the understanding that the service will be delivered manually during the pilot.
The prospect should know exactly what they are purchasing. A vague promise to optimize operations is difficult to evaluate, while a concrete commitment to deliver a report by a specific deadline creates an understandable exchange of value.
The first customer does not need to represent a massive market. The purpose is to establish whether one real buyer values the outcome enough to commit time, information, and ideally money.
Why Charging Money Changes the Experiment
Many founders begin by offering their service for free because they want to reduce friction. This can be useful when the primary objective is to observe a workflow, but it creates ambiguity about demand. A customer may accept free assistance simply because the offer is convenient, even if the result would never justify a purchase.
Charging money introduces a stronger test. The customer must decide whether the promised outcome is worth sacrificing part of a budget. The amount does not necessarily need to be large, particularly during a limited pilot, but the transaction changes the meaning of the customer's participation.
Imagine a founder offering to prepare weekly sales forecasts. Five managers agree to receive the reports for free, and all five say the results are interesting. This suggests that the reports may have informational value, but it does not establish that the managers would purchase them.
Now imagine two managers agreeing to pay for the reports. The number of participants is smaller, but the evidence of commercial demand is stronger. The founder can investigate why those managers were willing to pay, how the reports affected their decisions, and whether they want the service to continue.
Payment does not prove that the business will scale. A founder might be providing an unusually high level of personal attention that would be impossible to reproduce economically. Nevertheless, a paid pilot helps distinguish appreciation from willingness to purchase.
The Problem With Automating Too Early
The most common temptation after acquiring a concierge customer is to begin automating everything immediately. The founder sees the manual work accumulating and imagines how much time could be saved by replacing it with software. This instinct is understandable, but it can undermine the purpose of the experiment.
Early customers often have different requirements. One wants reports delivered by email, another prefers a shared spreadsheet, and a third needs information formatted for an existing internal system. If the founder automates the first customer's workflow too quickly, the resulting software may be poorly suited to the next customer.
A better approach is to repeat the manual process until meaningful patterns emerge. Which steps occur for every customer? Which exceptions are common? Which outputs consistently create value? Which parts of the process consume the most time without requiring sophisticated judgment?
These observations can guide the order of automation. The founder may discover that data collection is the most repetitive task, while interpretation requires human expertise. Automating data collection first may produce a more useful initial product than attempting to replace the entire workflow.
The goal is not to avoid building software indefinitely. It is to ensure that software development follows evidence about customer needs rather than assumptions about what a complete platform should contain.
When a Concierge MVP Becomes a SaaS Product
A concierge MVP should eventually create enough understanding for the founder to make a decision about product development. The transition becomes more attractive when several customers repeatedly pay for similar outcomes, the workflow contains substantial repetition, and the cost of manual delivery can be reduced through automation.
Suppose a founder is preparing weekly inventory reports for five restaurants. Each report requires importing sales data, comparing purchases with inventory counts, identifying discrepancies, and producing recommendations. After several weeks, the founder notices that most of the work follows the same sequence, with only a small number of customer-specific differences.
At that point, software development becomes less speculative. The founder knows which data is required, what the output should look like, and which parts of the process customers actually value. The first automated feature can replace a well-understood manual step rather than introducing a capability whose usefulness remains uncertain.
The founder may begin with an internal tool rather than a customer-facing platform. A script that reduces report preparation from two hours to fifteen minutes could improve the economics of the service before customers ever interact with software directly. Later, the company might introduce a dashboard, self-service onboarding, and automated delivery.
This progression creates a business that gradually becomes software-driven. The company begins by selling a valuable outcome and automates delivery as the underlying process becomes predictable.
The Economics of Selling a Manual Service First
A concierge MVP can generate revenue early, but it also creates a risk that founders must understand. Manual service businesses often have limited gross margins because delivering each additional customer outcome requires more human effort. A software company, by contrast, aims to spread development costs across many customers while keeping the incremental cost of serving each customer relatively low.
The concierge model is therefore most useful when the founder treats manual delivery as a learning investment rather than assuming that the initial economics represent the final business model. A service that costs three hours to deliver and earns fifty dollars may be unattractive as a permanent business, but it can still reveal whether customers value the outcome. The founder must then determine whether automation can reduce the delivery cost sufficiently to support sustainable margins.
This requires measuring time as carefully as revenue. Every pilot should record how long each task takes, which steps repeat, and how often unusual exceptions occur. The founder should also consider onboarding, customer support, quality assurance, and the cost of acquiring additional customers.
If the process remains highly customized for every buyer, the opportunity may be better suited to consulting or a managed service than conventional SaaS. That is not necessarily a bad outcome, but it is important to recognize the distinction before investing in a software platform that cannot deliver the promised value economically.
Why Concierge MVPs Can Improve Distribution
The connection between manual validation and customer acquisition is easy to overlook. When founders think about distribution, they usually imagine channels such as SEO, cold email, paid advertising, partnerships, and social media. A concierge MVP appears to belong to product development rather than marketing.
But the process of selling and delivering a manual service can create the foundations of distribution. The founder learns which customers respond to outreach, which problems motivate purchases, which objections appear repeatedly, and what language buyers use to describe the desired outcome.
These discoveries improve positioning. A founder who initially describes a product as an AI-powered operational intelligence platform may learn that customers respond much more strongly to a promise of reducing weekly reporting time. The second message is more concrete because it emerged from actual customer behavior.
Manual delivery can also produce testimonials, case studies, and referrals, provided that customers are satisfied and agree to share their experiences. A founder who has delivered a measurable result can speak with greater credibility than one who has only built a prototype.
The first customers therefore contribute to more than product validation. They help the company discover how to explain its value and how to reach similar buyers.
The Thirty-Day Concierge MVP Experiment
A founder could test this approach over thirty days without committing to a full software build. During the first week, identify a narrow customer segment and investigate one recurring problem that appears expensive or time-consuming. Speak with prospective buyers about how they currently handle the problem and what consequences it creates.
During the second week, design a manual service that produces one valuable outcome. The offer should be specific enough that a customer can understand what will be delivered, how long it will take, and what the pilot will cost. Avoid promising an entire platform or a broad transformation of the customer's business.
During the third week, approach qualified prospects and attempt to secure a paid pilot. The founder should be transparent about the manual nature of the service and should avoid collecting sensitive information without appropriate safeguards. Once a customer agrees, deliver the result carefully and document every step.
During the fourth week, evaluate the outcome with the customer. Did the service solve the intended problem? Would the customer purchase it again? Which parts were most valuable? What would make the experience easier? The founder should also examine the time required to deliver the service and whether the process appears sufficiently repeatable to automate.
At the end of the month, the founder may have a paying customer, a clearer product specification, and a better understanding of the market. Even if no one purchases, the experiment can reveal weaknesses in the offer before substantial development costs accumulate.
The Difference Between a Concierge MVP and Consulting
A common objection is that a founder who performs work manually is simply operating a consulting business. In some cases, that objection is correct. A founder can spend months delivering highly customized services without discovering a repeatable product opportunity.
The distinction lies in the purpose and structure of the work. Consulting typically focuses on solving a client's particular problem, often through customized expertise and ongoing human involvement. A concierge MVP uses manual delivery to investigate whether a standardized outcome can eventually be produced through a repeatable system.
The founder should therefore look for similarities across customers rather than continually expanding the scope of custom work. If every customer requires a completely different process, the business may not support the economics of a conventional SaaS product. If several customers pay for substantially the same outcome, the opportunity becomes more promising.
This is why the concierge phase should have explicit learning objectives. The founder is not merely trying to earn service revenue. They are trying to discover the smallest repeatable process that customers value enough to purchase.
What the First Customer Really Teaches You
A founder who acquires the first customer through a concierge MVP has accomplished something that a technically impressive prototype cannot establish on its own. Someone outside the company has agreed that a particular outcome is valuable enough to justify a real commitment. The founder has also observed the work required to deliver that outcome and begun learning how the customer evaluates success.
The information is incomplete, of course. One customer does not prove that a large market exists, and a manually delivered service does not establish that software can reproduce the experience profitably. But the experiment replaces several assumptions with observations.
This is the central advantage of the approach. Instead of building software and hoping customers will arrive, the founder begins with customers and uses their behavior to decide what software should eventually do.
The sequence may appear inefficient because manual work does not scale. Yet that inefficiency is precisely what makes the early learning possible. The founder sees the exceptions, hears the objections, and understands the workflow in a way that might be impossible after prematurely replacing human interaction with automation.
For an early-stage B2B SaaS company, the greatest risk is often not that the founder will fail to build the software. It is that the founder will successfully build software that nobody values enough to purchase.
A concierge MVP offers a way to investigate that risk before the cost of being wrong becomes substantial. It begins with a customer, a specific problem, and a promised outcome. Software enters the picture only after the founder has accumulated enough evidence to understand what should be automated.
The surprising lesson is that the first version of a software company may not need much software at all. It may need a founder who is willing to do the work, learn from the customer, and resist the temptation to automate a business that has not yet been proven.
Frequently Asked Questions About Concierge MVPs for SaaS
What is a concierge MVP for B2B SaaS?
A concierge MVP is an early experiment in which a founder manually delivers the result that a future software product is intended to automate. Customers know that the service is being performed manually, and the founder uses the experience to validate demand, understand workflows, and identify which capabilities are worth developing.
Can I get SaaS customers before building software?
Yes. A founder can sell a narrowly defined service or paid pilot that delivers the desired outcome manually. This can establish willingness to pay and reveal product requirements before a complete application exists. However, a successful manual pilot does not guarantee that the eventual software business will be scalable or profitable.
How much should I charge for a concierge MVP?
Pricing should reflect the value of the outcome, the customer's budget, the scope of the pilot, and the cost of delivery. A limited paid experiment may be priced differently from the eventual software subscription. The important objective is to test meaningful willingness to pay while avoiding an unsustainable commitment to unlimited manual work.
How many customers do I need before automating?
There is no universal threshold. The founder should look for recurring demand, similar workflows across customers, repeated willingness to pay, and a clear opportunity to reduce delivery costs through automation. A small number of deeply observed customers can provide useful product insights, but broader validation may be necessary before committing to substantial development.
Is a concierge MVP the same as a Wizard of Oz MVP?
No. In a concierge MVP, customers generally know that the service is being delivered manually. In a Wizard of Oz MVP, customers interact with an experience that appears automated while some work is performed manually behind the scenes. Both approaches can test assumptions before full automation, but they differ in transparency and the customer experience.
What are the biggest risks of a concierge MVP?
Common risks include underpricing manual work, accepting excessive customization, failing to document the workflow, collecting sensitive data without appropriate safeguards, and mistaking satisfaction with a high-touch service for demand for a self-service product. Founders should define the scope of the experiment and evaluate whether the service can eventually become repeatable.
Sources
This article draws on the concierge MVP concept popularized by Eric Ries in The Lean Startup, including the Food on the Table example in which the service began by manually preparing meal plans and shopping lists for an individual customer. The example illustrates how manual delivery can reveal customer preferences and workflow requirements before software automation.
Additional explanation of the concierge MVP method comes from published startup education and product-development resources discussing the distinction between manual delivery, customer validation, and software automation. The B2B examples involving accounting firms, property management companies, restaurants, and recruiting teams are illustrative scenarios rather than claims about specific companies or measured commercial results.
The Lean Startup — Eric Ries: https://theleanstartup.com/
Concierge MVP discussion: https://www.informit.com/articles/article.aspx?p=3113589&seqNum=8
Concierge MVP and customer learning: https://www.shortform.com/blog/concierge-mvp/