By Ben Cull, Co-founder of Pinch Payments
If you are working out how to build a Minimum Viable Product (MVP), start with one question: will someone pay for it? Not whether they like the idea. Not whether they would click around a free beta. Will they hand over money because your product solves a problem that matters?
That is the job of a minimum viable product. An MVP should help you prove the problem is real, the solution is useful and the business model has a chance of working. Everything else is supporting detail.
I learned this while building Pinch with my co-founder, Paul Allen. We were two developers solving a messy payments and accounting problem for Australian businesses. Some of the conventional startup advice helped us. Some of it needed a large pinch of salt.
Here is the practical version I wish more founders heard at the beginning.
In this video, I share practical lessons from building Pinch, validating demand and turning an early product into a sustainable business.
The word viable does a lot of heavy lifting in minimum viable product. Your MVP is not simply the smallest thing that functions. It is the smallest version that convinces a customer your product is worth paying for.
You could call it a minimum delightful product, although that phrase is a bit much. The point is sound: the product needs to deliver enough value, across a complete enough journey, for a real customer to say yes.
A useful MVP should test three things:
That second question is easy to undercook. A customer paying 50 cents proves very little if you need $50 to sustain the business. You are validating a business model, not just the existence of a checkout button.
When we started Pinch, moving money from A to B was not the whole problem. Australian businesses also had to create invoices, record payments, reconcile them in their accounting software and match settlements.
Our first product was simple, but the problem we chose was holistic: what does it actually mean for a business to receive and account for a payment? That framing mattered because customers were not looking for another isolated payments tool. They wanted the process to work.
Before you decide what belongs in your MVP, map the smallest complete customer journey. Identify the moment the problem begins, the outcome the customer needs and every essential step in between. You can simplify those steps, but do not remove the part that makes the product valuable.
Validation can start before you write production code. Show prospective customers a mock-up, a clickable prototype or a short walkthrough video. Explain the problem, how you are thinking about solving it and what the solution might cost.
In Pinch's early days, we contacted accountants and bookkeepers and asked for advice. We framed the conversation around an idea we were exploring, even though we had already built much of it. People were far more willing to share thoughtful feedback when we asked for their view than when the conversation felt like a sales pitch.
Good early evidence includes:
Deposits and pre-sales can work in some markets, but they are not the only sign of demand. The more useful goal is to reach a version that creates enough value to charge for it. Revenue has a way of making vague feedback much clearer.
An MVP does not need to automate every task. Manual work is often the fastest way to learn what customers need before you commit months of development to it.
For example, refunds were not available as a self-service feature in the early Pinch product. Customers emailed us, and we handled the process behind the scenes. It was inefficient, but it worked well enough while demand was low and taught us what the eventual feature needed to do.
Use manual processes where the volume is manageable and the customer still receives a reliable result. Automate when repetition, risk or customer friction becomes painful enough to justify the build. By then, you will have evidence instead of guesses.
There is a difference between doing manual work around your product and giving paying customers a flimsy prototype. I would not build something purely to throw it away. I would build the simplest dependable version of the product you hope to grow.
That does not mean engineering for millions of users on day one. Build for the scale you have. Keep the architecture flexible, accept that you will refactor and avoid choices that trap you in a corner.
A good MVP is the first brick in a longer build. It should be small enough to learn from and solid enough that you are proud to put it in front of a paying customer.
Non-technical founders still need to validate the problem, test pricing and learn from customers. No-code tools, workflow platforms and AI coding assistants can help turn an idea into something tangible, but technical guidance becomes important early. Software development is expensive, and production systems need someone who understands what is happening under the hood.
Before committing to a large development project:
Finding a co-founder is a major relationship, not a box to tick. Start by building relationships with people who understand the problem and are interested in what you are trying to achieve. Shared work will tell you more than an enthusiastic first meeting.
Technical founders face the opposite risk: building is enjoyable, while asking customers for money can be uncomfortable. That makes it very easy to spend weeks improving the product instead of testing the business.
Build for today's usage and leave room to adapt. You can tolerate some inefficiency early. Slow, steady growth gives you opportunities to correct old decisions before they become serious constraints.
Do not add features simply because one more feature sounds impressive. At the same time, small niche problems can matter enormously to the customer who has them. Pinch won loyalty by solving awkward accounting and payments issues that larger providers had little incentive to touch.
The test is not whether a request is niche. Ask whether it removes meaningful pain for the customers you want, supports your core product and is worth the cost of maintaining it.
Do not spend your runway solving future problems that may never arrive. Keep the system as simple as the real requirement allows. Stay willing to refactor when evidence changes, including when that means making a difficult architectural decision later.
AI coding assistants and no-code tools have made prototyping much faster. They can be excellent for early experiments, simple single-purpose apps, landing page variations, internal tools and workflows that move information around a business.
They are also a double-edged sword. If you do not understand the system, you may struggle to diagnose a failure when paying customers rely on it. A fast build is not a bargain if quality, security or reliability slips.
Use AI well by keeping a human responsible for:
Use the tools to speed up decisions you have thought through. Do not outsource the thinking that makes your product valuable.
Our earliest assumptions did not all survive contact with the market. We first imagined Pinch as more of an all-in-one toolbox. Customers taught us that businesses prefer to keep using familiar systems, so our product evolved to work with the tools they already trusted.
Early customers also taught us the details of accounting workflows and the many ways Australian small businesses operate. Their fingerprints are on the product. That is a good thing.
If I were starting again, I would spend even more time following up with customers, prospects and partners. Support matters, but ongoing communication matters too. Check in after onboarding. Ask what has changed. Find out where the product still creates work. Strong relationships produce insights a dashboard will miss.
Before you launch, answer these questions in plain language:
In Pinch's early days, we applied for a grant and received feedback across roughly 30 criteria. We performed poorly on almost all of them. The one positive was customers: we had people paying us.
That did not mean everything else was unimportant. It meant we had the thing a startup cannot fake: evidence that a real problem was worth solving.
Be obsessed with customers. Solve a problem they genuinely want removed. Charge enough to test the business, not just the product. Keep the first version simple, dependable and worthy of the people trusting you with their work.
If your software product needs to collect payments, manage recurring billing or connect payment data with accounting workflows, you do not need to build the payments infrastructure from scratch.
Explore the Pinch Payments API and start testing your payment experience in the sandbox.
MVP stands for Minimum Viable Product. It is the smallest version of a product that delivers enough value to test whether real customers will use and pay for it.
Speak with the target customers, show them something tangible, test the price and look for behaviour that demonstrates commitment. The strongest validation is revenue from a product that reliably solves the problem.
No. Manual processes are sensible when volume is low and the customer still receives a reliable result. Automate once the repetition, risk or friction justifies the investment.
Yes, particularly for prototypes, experiments, internal workflows and simple apps. Before paying customers depend on it, make sure someone can understand, maintain and support the system when something fails.
Not necessarily. A well-designed MVP can be the first dependable version of the long-term product. Keep it simple, build for current scale and preserve enough flexibility to refactor as you learn.