By Cathy Edwards (Co-Founder & CTO, Chomp)
Chomp is an app search company that I co-founded with Ben Keighran. We let you search for apps based on what they do (e.g. “tip calculator”, “free puzzle games” or “to do list”) rather than needing to know the name of the app.
As Chomp’s CTO, I’ve learned a lot about about the engineering challenges in a new startup.
Here are some lessons that may be useful to technical co-founders of early stage companies, particularly in that initial period before and just after you launch.
Don’t Build Everything From Scratch
When building your startup, it is important to focus your limited resources on components where you can add a significant amount of value. Work out what technology will be core to your business, and find existing or outsourced solutions for everything else.
For example, most search startups spend lots of time (and a considerable amount of money!) building a search engine from scratch before they launch and get critical user feedback.
At Chomp, I deliberately chose not to take this route. Engineering a custom index that scaled to many billions of documents wasn’t an issue for us; there are still less than a million mobile apps at the moment. We needed to focus instead on building a really intelligent search algorithm — understanding the function and topic of apps — and performing sophisticated ranking so that we could serve more relevant results than anyone else.
As a result, we built on top of the open source search server Solr (and the underlying Lucene search engine). We got a lot of core search functionality out of the box, and were able to concentrate our time building advanced machine learning and natural language processing tools, and doing some pretty tricky hacking into the standard ranking functionality.
We were able to launch our initial app search prototype in just 4 months with only myself and one other engineer. We now have a much bigger team, because search is really difficult, but we were able to prove the model before committing resources. Getting to market this quickly also allowed us to gain crucial insights into our query traffic and learn from our users. As the app market expands and scaling becomes more of a challenge, we will be able to build out more custom components as necessary.
No Premature Optimisation
This leads into another key point: not optimising too early. Again, it’s important to make sure that you and your team’s time is focused on adding value efficiently. Although writing scalable code is a given, it’s also important not to over-engineer your solutions before your startup has found product-market fit. This can lead to a lot of wasted time when you inevitably pivot and need to kill one of the features you’ve spent so much time engineering.
Originally, Chomp experimented with social features for app discovery, including an app review feed and the ability to follow your friend’s app reviews. This lead to a worrying “Twitter-esque” product that we could see becoming a difficult engineering problem if the service really took off. Rather than trying to solve this problem from the start, we decided to start with a more straight forward (and much faster to build!) architecture that would cope with our most optimistic traffic projections for the first 6 months. If it really took off, we could always optimise the system — or completely rewrite it — to cope with the real traffic demands, rather than our imagined worse-case scenarios.
Again, this allowed us to get to market faster and learn more quickly that our users actually weren’t so interested in social reviews. It would have been terrible to learn that after investing months building a scalable news-feed service!
Do Invest In Monitoring
I can’t over state enough the importance of knowing what’s going on in your system. Before you launch, implement thorough monitoring and alerting using tools like Nagios (to regularly check your systems and send you emails if things go down) and a graphing solution like Cacti or Munin (to graph both application and system level metrics over time, so you can predict when problems may happen in the future). Setting up one of the many external services for uptime monitoring is also helpful.
Good monitoring can prevent sudden downtime (like when Foursquare had their horrible outages in October 2010). It also allows you to identify bad behaviour like long execution times long before users complain or something more catastrophic happens. I cannot express how useful monitoring has been at Chomp; it has definitely been worth the time investment.
Lastly, trust your team
Technical co-founders have a tendency to be a little
OCD controlling perfectionist about their company. There’s no way you’re going to be able to personally write all the code, or even review all the code, as your company grows; the single genius model just doesn’t scale.
From your very first hire, learn to hire engineers you trust and respect, and give them ownership over their component of the codebase.
You’ll end up with a team of leaders who can mentor new people on the code base and processes as they join, and you’ll be a lot less stressed out (and productive!) than if you’re the bottleneck for everything.
Editor’s note: Got a question for our guest blogger? Leave a message in the comments below.
About the guest blogger: Cathy Edwards is Co-Founder and CTO at Chomp, a search engine for mobile apps. She created Chomp’s proprietary algorithm that understands the function of each app, allowing you to search for apps based on what they do rather than just what they’re called. Prior to Chomp, Cathy led mobile product management at Friendster; and 3jam where she launched a converged SMS-IM mobile messaging product. Cathy holds degrees in pure mathematics, linguistics and computer science from the University of Western Australia. Follow her on Twitter at @cathye.