At the most recent company I co-founded, where we’re making a product for Instagram influencers 📷, we made a conscious decision to start small in terms of features, headcount, money and time. I want to share with you a short story of our product’s development and convince you that “small” and “good enough” is often the way to go. Why? Because it simply lets you focus on things that actually matter.
Early decisions
We started with an idea of building a product for Instagram users that would let them devote more time to creating engaging content their followers (and brands) love. In the long term, the product would have to offer advanced features that would take a bit of time to develop. Being ambitious in this context is perfectly fine, but we knew we had to start somewhere and first build, then test in the wild, a proof-of-concept that would serve as a platform upon which we could build bigger things.
To borrow naming conventions from Marvel’s MCU plan, our “Phase I” focused on validating key technical assumptions we’ve started with. The prototype developed at this stage was very crude, engineering-wise, and didn’t even have a UI of any sorts. It didn’t take long to develop and helped us better understand the technicalities of the problem we were trying to solve.
Next was “Phase II”, where the product’s featureset was limited to only the most sought-after, low-hanging automation tasks that we could ship to get the ball rolling. On the engineering side, we cut costs and saved time wherever possible. For example, instead of developing native versions of our desktop app for macOS, Windows and Linux, we opted for the Electron ecosystem. This meant we could develop the app once and distribute it to multiple platforms from a single codebase. What’s more, instead of building our very own auto-update system for the app, we could lean on existing libraries and tools (Open Source ❤️). In conjunction with Amazon S3 for hosting binaries (installers and update files), this also meant we didn’t have to spend a dime to get off the ground and move to validation with customers.
The “start small” mentality also extended to other parts of running a software company. For example, when it comes to website and email hosting, Zenbox has proven to be extremely cost effective and good enough for our use case. Even WordPress, which honestly I was not a huge fan of, later on allowed us to build the whole website, including checkout flow for subscription plans and invoicing, without too much of an effort. The website works well and looks good on the outside (ready-to-use, commercial WP themes!), and even though overall it may not be an engineering state-of-the-art, it serves its purpose really well.
One thing of note here is, while we cut corners whenever and wherever possible, we made sure to lay the groundwork for the future. In particular, each technical component is reasonably maintainable and swappable. The desktop app, for example, has a modular architecture and is not directly tied to Electron or the desktop itself, giving us a lot of options for what we have laid out in our roadmap.
Overall, the time saved here and there allowed us to safely focus on other challenges that come with building a product.
Early adopters
You’re in a good spot when customers tell you what they think about your product and their experience in general. Without that precious feedback, you’re essentially flying in the dark, so make sure you’re doing literally everything you can to get it. Be prepared for a good fight, as nowadays many things fight for customer’s attention, and cherish every effort on the customer’s part to talk to you about your product.
In our case, we enrolled our friends and friends of friends to test out prototypes and tell us about their experience. The feedback we’ve received was not only humbling, since it tested our assumptions about the needs of our potential customers, but also encouraging (we learned something!). We were even lucky to hear people say they experienced “wow!” moments on their journey with the product. At the end of this stage, a few weeks into development, we had a piece of software we could say was good enough to give into the hands of a broader audience. Naturally, the product backlog had quite the number of items in it, including bugs to squash 🐞, but doing anything more than that would mean delaying the launch. To paraphrase Reid Hoffman, if you’re happy with your product at launch, it means you waited too long to ship.
The launch was also “small”. There are plenty of software and hardware stack combinations people use, so we made the product available only to a limited number of people (private beta), with potential customers having to subscribe to a waitlist. It gave us precious time to thoroughly fix issues as they pop up.
Perfect is the enemy of good
I applied the “good enough” approach to hard engineering as well. In one case, we wanted for the desktop app to be properly packaged, so OS (Windows, macOS) would identify our software as safe to run. It was important to us, since it would add to the credibility of the product and help build trust. Unfortunately, I ran into an issue with macOS app notarization that took me some time to investigate. I came up with a solution that was a bit crude and involved monkey-patching one of the libraries used by our build system. At that point I faced a choice:
- Spend more time on this issue and try to get to the root cause of the problem, potentially arriving at a better way to fix this, or
- Make it work, even if it was suboptimal, and move on to other, more pressing tasks.
I must admit, I had that urge inside me to soldier on, to fully understand the problem, to arrive at an elegant solution. But, after a moment of reflection, I knew getting it perfect wouldn’t matter to our customers. They wouldn’t care about our build system. Heck, they probably wouldn’t even know we had one! To them, the end product, the customer experience, is what matters most. That’s how they will judge ⚖️ the product and the service.
There’s also another dimension to opting for “good enough” in the software world. Business requirements, libraries, frameworks – you name it – change rapidly and the software I write today might be obsolete tomorrow. Especially feedback from the customers can (and often should) make a huge impact on a product. In our case, the first iteration of the desktop UI served its purpose, but people told us they were a bit lost when just starting out. We quickly made a lot of changes based on the feedback, creating an entirely new experience for one of the core flows. And while we used off-the-shelf UI components and reused parts of the code we have already written, some had to be thrown away.
In my opinion it’s not worth spending too much time on things that will undoubtedly change. Sure, I still will go for maintainable (read: easy to change/swap), but I would rather focus on coming up with solutions that are optimal in the business context. I know it will pay dividends 💰 later on.
A few words on hiring
Try to postpone hiring for as long as possible. It’s also part of “starting small” and is an important mindset to have early on. It’s not about money and time, but first getting a firm understanding of the business beforehand. Once you’ve obtained enough knowledge and experience, hiring someone to take over your roles will be way easier and more efficient.
To give you some examples, we did all the design work ourselves, in some instances leaning on ready-to-use products, in others engaging our creative side (like for UI or promo video). We also considered finding someone to fully own the marketing side of the business, but opted to take care ourselves of things like content creation and promotion on social media. All in a quest to better understand what is actually needed for the business, long term.
Keep in mind, tough, that it depends on the skillset of the funding team. The broader the better, with few focuses that really stand out. We are lucky to have such depth in the founding team 🦾, despite a highly engineering background. It’s not all or nothing – when in a pinch, we can always ask friends for help or hire a contractor for a specific task.
Three takeaways
In a startup world (and life in general), time is a valuable currency. Choose a technology that lets your company or project move as fast as reasonably possible at each stage of product development.
Customers don’t care how a developer solved a problem on the software side. They want the product to solve their pain, be reliable and be easy to use.
When building a product (startup, side-business), try to build great software, but don’t shy away from using shortcuts where it makes sense, unless you plan to send people to space. There’s always plenty of other things to work on.
Feedback and questions are more than welcome, either in comments or on social media 🙂
Thanks a ton to Piotr Tomiak (@PiotrTomiak) and Jakub Tomanik (@jakub_tomanik) for reading drafts of this article.
Top comments (0)