In 2024 I left my job (at AWS) to pursue my open source passion, and turn open source project into a living. With the help of Cursor I’m more productive than ever (in 20 years of coding), I can ship features today faster than I could ever before…. but I start to ask, is this the right thing to do for my customers?
To give you some background, I created an open source project called EventCatalog, the tl;dr this helps companies get a handle on (wtf) is going on in their event-driven architecture. The project is for anyone building these types of architectures, but the project attracts companies with the problem…. these companies tend to be mid/large size businesses.
Now, as I said… it’s super easy to fall into the trap of releasing features, especially as most the features can be built by AI tools such as Cursor, and for the past 6 months that’s exactly what I have been doing, releasing new versions of the product and features 10x times a week!….. users seem to like the ride, some get excited, majority of the feedback I get it “Can’t believe you move so fast!….. I struggle to keep up”.
Releasing too often vs product heart beat
Can a product release too often and ship to fast? I think it really depends on your audience, if you are in the indie hacker space, this audience thrives on this release cycle…., my customers/users are mid/large enterprises…. these developers, architects and business owners have a lot going on.
As I said, I’m currently bootstrapping, with (1-5) meetings a week (if that), and I have the ability to move at lightning speed, but my users/customers cannot. I wonder if this starts to create skipped heart beats with the product and my users?
What do I mean by product heart beats? Releasing just enough to let your users know you are still here, innovating, but at a pace they can keep up and are comfortable keeping up.
I don’t want my users to feel like it’s a job to keep up to date with the releases, bug fixes and new features, so maybe releasing in heart beats, consistently, but not every day/week is the way to go? Maybe….
But this goes against the developer in my head, if you’re not shipping, wtf are you doing!…. it’s addicting to ship, ship, ship, but there is so much more to do that just write code, and it’s important to understand this and checkin with yourself.
If you’re not shipping, what do you do?
What I’m learning from solo bootstrapping EventCatalog is writing features for the product is only a fraction of what you need to be doing.
I try and split my time into sections:
Research the market
So easy to just focus on your product, ship features, and do stuff. But just take time out, dipstick what is going on in the market, where are you users, what they doing? What is the market doing? Where is the value?
Talking to customers (I know right!?)
My favourite thing. I book 30min meetings with anyone I can get my hands on using EventCatalog (using https://calendly.com).
Read “The Mum Test”, try not to lead your conversations with bias. Dive into the roots of there problems and document this. Cross reference problems of your users, this is your roadmap.
Working with customers (hands on)
I actually enjoy getting hands on with users. Consulting with them helping them with there problems and understand how EventCatalog can help.
If you are also open sourcing / business your own project, then this can be a great way to earn revenue.
Package up your features
Is the feature a good one? Write a blog for it, video for it, document the features. Help your users get up to speed faster, reduce the barrier to learn, get the feature into the hands of your users as fast as they can, they are busy people.
Plan
As I said it’s easy just to fall into the trap of releasing new ideas, and building things, fixing issues on GitHub, before you know it time has disappeared. Plan your work and time, what do you want to get done today, this week. What can we package up as our heart beat release?
In reality, there is a ton of things to do, especially if you are starting out, bootstrapping, don’t feel bad if you are not shipping features ( I have to keep telling this to myself…).
Focus on your users, and customers, work backwards from them, let that feedback into your product, but release at a pace your customers can keep up to with, build the trust and make them the heart of the product.
Final thoughts
I imagine my view will change over time. If the project had a team (goal this year), maybe my views would be different? I don’t know, but like most I’m learning on the fly, I’m out my comfort zone, and sharing this journey with you.
But I do believe sometimes going slow is the way to go fast. Taking time to think, plan, connect with users and release at a steady pace can be far more beneficial than releasing 10x a week… for my users anyway.
Still reading?
Hi!
I’m Dave Boyne, a dude that is trying something new. I’m a believer of open source software, and trying to create a business from it. The journey is a roller coaster of emotions, but I want to share this journey with you reading.
If my thoughts or experience can help others do the same, then it’s all worth it.
If you want to follow me on this journey you can sign up below, or just reach out to me, love to hear from you!
