I had to take a deep dive into the archives for this one. The first document containing the details of myCountly dates back to February 2020. It's astonishing to think that more than three years have already passed since that initial spark of inspiration.
Fast forward two years, and we finally kicked the project off officially. I even had to rummage through my calendar to verify the exact date, as time had seemingly flown by.
In today's post, I'll take you on a journey through the evolution of myCountly's original concept, recounting the twists and turns we encountered as we refined the idea before ultimately launching into the development phase.
The Document
Over the years, I've developed a habit of documenting new ideas, whether they're big, game-changing features or small, incremental improvements. I often invite team members to review these documents, share their thoughts, and brainstorm together. Many of our feature and product ideas end up in the proverbial graveyard, not seeing the light of day. But something was different with myCountly. The document resonated with everyone who read it, generating a palpable sense of excitement. However, the sheer magnitude of work involved was daunting, and we weren't sure if we had the bandwidth to tackle it just yet.
We kept the idea on the back burner for a while, periodically revisiting the document to refine and add new elements. A few months in, we even began working on preliminary UI/UX designs. This process continued for nearly a year, with the concept slowly taking shape. But as 2020 rolled into 2021, the world faced unprecedented challenges. The pandemic disrupted lives and businesses, casting a shadow of uncertainty over everything. In such a tumultuous time, embarking on a risky venture wasn't an appealing prospect, particularly for a bootstrapped startup like ours.
Nevertheless, around mid-2021, we mustered the courage to take a leap of faith. It was now or never. This project was happening, and it was our time to shine. But for the first time in our company's history, we faced a critical decision: should we bring in a third party to assist us in building this ambitious project?
Go Solo or Duo?
myCountly stood out from traditional SaaS platforms, presenting us with unique challenges that made us question whether we should build it ourselves. Two critical aspects set myCountly apart:
First, we envisioned myCountly to be compatible with multiple cloud providers, such as AWS, Azure, and Google Cloud. This would allow our users the freedom to choose their preferred cloud provider and region for their deployments.
Second, in myCountly, every user would have dedicated deployments. This differed significantly from the multi-tenant, shared service infrastructure commonly found in other SaaS platforms. Essentially, we'd need to build our own cloud provider, with the key distinction being that the "servers" would come pre-installed with Countly and its components.
These factors led us to believe that partnering with a third party, possessing expertise in one or more cloud providers would be the most viable option. Such a partner would have comprehensive knowledge of networking, automation, and the complimentary services offered by the cloud provider, making our lives significantly easier both in the present and future.
At that time, we were just beginning our relationship with a Google Cloud partner for our Countly Enterprise business, as approximately 50% of our customers utilised our cloud hosting. This partner was highly skilled and could potentially help us get myCountly up and running faster than we could achieve on our own. After some negotiation, we estimated the partnership would cost roughly $100,000 USD, not including the development costs we'd incur ourselves.
Faced with this significant expense, we decided to pause and reassess our approach. Was it possible that we had the necessary know-how to get started ourselves? Could we simplify the original idea, making it more manageable for our team to build in-house? It was time to revisit the drawing board and refine the product into something we could confidently create ourselves.
Refining the Product
To give you a clearer understanding of our journey in refining myCountly, I'd like to share some excerpts from the original myCountly document. By diving into the initial concepts and ideas, we can shed light on the changes we made, why we made them, and how they ultimately shaped the “final” product.
This was the opening paragraph:
myCountly is a hosted environment that provides a self-service Countly experience to customers. A customer can create an account to launch new Countly Enterprise deployments in a cloud provider and region of their choice.
This was the first idea of our pricing and add-ons:
On a brighter note, this was one of the screens listing deployments in your myCountly account which is overall quite a good design; still, we ended up redesigning pretty much everything (more on that in another post):
At this moment, we made the decision to develop myCountly entirely in-house, embracing the challenge of going solo. This constraint turned out to be a blessing in disguise, grounding us in reality and inspiring us to think more strategically.
To ensure that we wouldn't get bogged down in years of development, we identified several key areas to address as our first step towards building myCountly independently:
- Embracing a phased approach to cloud support: Although we initially envisioned myCountly working with multiple cloud providers from the start, we realised that this was an unrealistic goal for the time being. We acknowledged that companies often have a preference for a specific cloud provider, so we decided to focus on supporting Google Cloud first, designing the architecture to accommodate other providers in the future.
- Simplifying pricing and add-ons: We recognised that the original pricing table and add-ons were a reflection of our desire to include everything we didn’t offer as add-ons in Countly Enterprise (it is an all-inclusive package). In the spirit of simplicity and efficiency, we opted for a more streamlined approach. This not only reduced the development time for myCountly but also minimised the impact on Countly Server, allowing us to focus our efforts on the most critical features and add-ons. These included a selection of features/plugins, custom domain/SSL, data retention, and data backups.
- Removing unnecessary complexities for users: With the realisation that myCountly deployments would be fully managed by us, we decided against complicating the process by offering replication and high availability as add-ons. Instead, we chose to prioritise the user experience and handle these behind-the-scenes aspects ourselves.
Key Takeaways
- Cultivate a culture of collaboration: Make it a habit to document your ideas, share them with your team, and encourage open discussions. Even if you can't work on a concept immediately, maintaining an ongoing dialogue can keep the idea alive and ready for future exploration.
- Start simple and stay focused: When developing a new product or feature, begin with a streamlined and straightforward approach. Concentrate on executing the core elements to perfection, and remember that additional features can be introduced as the project evolves. This will save time and resources and ensure a strong foundation.
- Turn constraints into catalysts: Embracing limitations can ignite creativity and inspire teams to reexamine and refine their concepts. By working within your constraints, you can foster innovation and discover cost-effective solutions that may have otherwise been overlooked.
Countly’s Product-led Story
Are you eager to learn how we applied these principles and kick-started the development of myCountly? Stay tuned for our next post, where we'll delve into the fascinating process of transforming our refined ideas into reality.
Join us as we continue to explore Countly's product-led story, revealing the challenges, triumphs, and lessons we've encountered along the way. Be inspired by our journey and gain valuable insights that can help shape your own path to success.