We're in the middle of January now, and last week was spent at the Australian Open tennis. The qualifying week is extremely exciting – people are fighting to the death just to get through every single match to try and qualify for the main draw. We watched some hard fort matches and got to see some of the big names, Djokovic and Alcaraz, in the expo games.
It was amazing to see some of the young Australian tennis players coming through – 16, 17 years of age – and just playing phenomenal tennis, Renee Alame is going to be a name to watch in the future for sure! Amazing player.
But as much as I enjoyed the tennis, I've been wrestling with a question that every product builder faces: when is a product actually ready? When do you stop building and start releasing?
The Evolution of the MVP
There's this old startup mantra that says if you're not embarrassed by your first release, you've launched too late. I just can't bring myself to do that anymore. The bar has been raised significantly – every product I use these days has upped their game. You can't get away with a bare-bones MVP with one feature anymore.
An MVP in today's world is a very complete product that does the job very, very well, and it needs a few bells and whistles on it. The days of shipping something half-baked and hoping users will forgive you are long gone. Users expect polish, they expect thoughtfulness, and they expect products that actually solve their problems from day one.
"I've always erred on the side of let's have something a little bit more refined than to release something early. I probably go against the grain a little too much here with startup mentality."
The Personal Litmus Test
So how do I determine if a feature is complete? It comes down to one simple question: would I pay for it myself? If I would pay for it, then I think it has reached that point where it's good enough to release. That's my test – putting myself in the customer's shoes and asking if I'd open my wallet for what we've built.
This personal perspective is what I use as the test to get a product to launch stage. It's not about perfection, but about value. If I wouldn't pay for it, why would I expect anyone else to? This approach has served us well at Dazlab.digital as we build niche SaaS products that solve specific problems for real industries.
Building for Known Problems
There's some grey area when it comes to building a product that you know you need because it's a problem that you have, but you also know from experience and from enough conversations that many other people are facing the same problem.
This is exactly what we're doing with Handl Billing, which we've finally released to our staging environment for QA and UX testing. Big milestone here, as its feeling very close to a production release!
One of the problems I've always had is understanding what my pipeline is going to be like – what projects have I got on, what possible projects are coming up, when will they hit, when will the money hit. Cash flow is essential. You need good cash flow to run a business, but you want to make sure that you know when those invoices are going to be paid so that you can pay all of your bills.
So we've added features beyond basic billing – pipelines and a forecast visual so you can see when invoices are going to be paid, and when the projected ones could come in over the next couple of months.
We also finished the client portal so clients can see which invoices were paid, how to pay, and even set up automatic payments if that's what the agency user requests.
"I always think that I've got to build more into a product, but sometimes if you're building a product for an audience that you don't know, I think it's hugely valuable that you need to ask the audience what they need before you build it."
The Context Problem in Software
With mber.ai, we're tackling another universal problem – the need for context. Whenever you're using any software, any content that you need to create needs context. It needs core information about whatever the product or services that you're using. We're building a tool that allows you to do a product walkthrough which provides the core information that helps with all future content creation. It includes screen recording of you doing a demo of the product as well as the voice narration.
This is the kind of feature that goes beyond the basic MVP thinking. It's not just about getting something out there – it's about solving the complete problem. Users don't just need to create content; they need to create content with context, with understanding, with the right information at their fingertips.
Beyond Feature Releases
Not everything we release is a shiny new feature that users can see and touch. Security updates, performance improvements – these all play a large role in everything we do at Dazlab.digital. While they might not be visible features, they're about giving users peace of mind. Updates to supporting content and help documentation are hugely important as well.
"Products need to be a very refined offering that has to tick all the boxes. An MVP now in this day is a very complete product that does the job very, very well."
The User Feedback Loop
My personal perspective – the "would I pay for it" test – is what I use to get a product to launch stage. But after that, user requests and feedback play a huge role in determining features and how good something needs to be before release. We won't build everything that is requested because it might not fit the purpose of the product. But if our paying users are asking for it and it's more than one person, then it's important to build.
This creates a healthy balance between vision and market needs. We start with a strong opinion about what the product should be, refined enough that we'd pay for it ourselves. Then we let real user feedback guide us toward what it needs to become.
The New Reality of Product Development
The landscape has changed dramatically from the early days of web applications. Users have options, they have expectations, and they have little patience for products that don't deliver value immediately. This isn't about perfectionism – it's about respecting your users' time and money.
As we push Handl to our live site hopefully by the end of this week, and continue working on Arbeo.jobs and mber.ai, we're constantly asking ourselves: is this ready? Does this solve the problem completely? Would we pay for this?
The answer to "when to build more and when to release" isn't found in startup mantras or growth hacking playbooks. It's found in honest self-assessment and a deep understanding of the problems you're solving. Build enough that you'd pay for it yourself, then let your users tell you what comes next. That's the balance we're striving for at Dazlab.digital, and it's served us well in creating software that actually makes a difference.
Thats it for this week!
Cheers
Daz
Frequently Asked Questions
What's the biggest mistake teams make when deciding between building more features and releasing?
The biggest mistake is following outdated advice like "if you're not embarrassed by your first release, you've launched too late." Today's users expect polished, complete products from day one. An MVP now needs to be a refined offering that solves problems well, not a bare-bones prototype.
How do you know when a feature is ready to release?
The key test is asking yourself: "Would I pay for this?" If you wouldn't pay for it yourself, why would you expect anyone else to? This personal litmus test ensures you're delivering real value before launching, not just shipping features for the sake of shipping.
Should you always wait for user feedback before building new features?
Not necessarily. When you're solving a problem you personally experience and know from conversations that others face the same issue, you can build with confidence. However, once launched, user feedback becomes crucial - if multiple paying users request something that fits your product's purpose, it's important to build it.
What types of releases are just as important as new features?
Security updates, performance improvements, and documentation updates are equally critical. While users can't see or touch these improvements, they provide peace of mind and better overall experience. These updates should be communicated through newsletters and prominently displayed on your site.
How has the definition of an MVP changed over time?
The bar has been raised significantly. You can't get away with a one-feature MVP anymore. Today's MVP needs to be a complete product that does the job very well, with some bells and whistles. Every product out there has upped their game, and users expect that level of quality from the start.
