My first productized service!
Recently launched https://buggynomore.com/, a monthly bug fixing subscription service for startups. While working with clients, we realized that their core team is often heads down on feature work which takes priority while the bugs languish and the bug backlog grows.
Bugs are a funny animal. They're hard to estimate but I think our pricing makes sense and if we could squash even a handful every month, it more than pays for itself.
Would love to hear what you all think!
I don't subscribe for your service.. here is why. But correct me if I am wrong.
Bugs general happens for following reasons
My developer had lost some focus / flow while coding
My developer would have not envisioned the possibility particular implement creating bug
My team of developers would have not communicate well with each other team after change release
If you look at it all these bugs get created because the developers were not fully involved
Not that said, if I outsource bug fixing to you then for sure you would fix that bug but may produce 3 more extra bugs.
Why ?
Because even you will not be fully involved into the project. You would dealing with 3-4 other projects like mine in a give day / week.
In that sence, for me it feels better if I ask my developers to fix the bug. Because they are into this software day in and day out. They would eventually may even improve the code quality as well during this bug fixing activity.
Please correct me if I am wrong. I would love to hear your point of view as well.
I completely get your concern. A couple of thoughts:
I think bugs occur more often when developers don't consider all the possible paths and account for them or if they're under time pressure to deliver on a feature and cut corners. Bugs also occur when there isn't good test coverage and the code becomes brittle over time. I don't believe full-time involvement has a strong bearing. For instance, I've part-time freelanced for companies and I still took the time necessary to understand the context and codebase. I believe what matters is quality of the developer and how thorough they are with their work.
In a given day, if we are working on your codebase, we are not working on anything else. We do this because context switching is hard and doesn't really favor what we do. We'd rather be fully focused on a single codebase and knock out what we can vs juggling multiple projects in a day.
My experience has been that core engg teams are often focused on feature work, often due to customer request pressure or management pressure. In spite of their best efforts, the time and bandwidth available to reduce the bug backlog is limited. So while dev teams genuinely want to address the laundry list of product bugs and improve quality, in reality there are forces that prevent them from doing so (more often than not).
We help teams take the majority of (non-urgent) bugs off their plate and leave the code and the product better than how we found it.
Very cool idea. Does that pricing work out for you only if you oversubscribe people, aka the "gym membership" model? Or does that pricing work well for you even if you end up just booking 100% of your time this way. Depending on your experience and your area of the world, $400 for a "full day" of work could be very inexpensive and potentially very attractive to people.
It works even if we book 100% of the time we committed for the service. However, the great unknown with bugs is there's no way to estimate how long it might take to fix one. That does make pricing, specifically balancing the service we offer and the margin we have challenging.
Being the founder of a productized subscription service myself, I think this is a fantastic business model and the pricing structure seems more than reasonable. In fact, it seems like a no-brainer. Keep up the good work. Looking forward to your updates.
@brettwill1025 thanks! i recently learned of Hue and it's super inspiring what you've built. I'd love to ask you a couple of questions. What's the best way to reach you?
Hi @bfaas, anytime. You can reach me at brettwill1025@gmail.com.
This comment was deleted 3 years ago
@heylorenzut Patrick, thanks for that feedback! You're right about the 2 bugs/sprint. Bugs are hard to estimate but we've priced the service to aim to fix 2 bugs every sprint. Now of course bugs can end up taking longer but on the balance, once we are up to speed with the codebase, I believe we can deliver on that goal.
I've been considering a one-time activation/get up to speed fee but am first testing the waters with the concept and will figure that out soon.
This comment was deleted 3 years ago
That's a fair point and perhaps makes sense to completely drop that metric from the pricing and re-orient the value another way.
This comment was deleted 3 years ago