Experiences as a first time CTO (Twitter acquisition edition!)

I am beyond thrilled to announce Squad is joining Twitter! We are so excited to continue our mission of combating loneliness by expanding the types of conversations on Twitter. The future is going to be awesome!

And while we look to the future, it seems appropriate to take a moment and reflect on this crazy ride. No novel insights, just some anecdotes from a first time CTO.

Importance of speed for early stage startups

As a small team with limited resources, pace of innovation is our key advantage over larger competitors. Even more important, to fulfill our vision we knew we needed to iterate quickly to learn. While our mission of ending loneliness has been constant, our approach has evolved as we learned. Some features we were incredibly excited about turned out to be duds, while others became wildly popular. It’s brutal to acknowledge failure when you’ve poured your heart and soul into a feature, but as long as we kept building and learning, it was a good use of time.

Pushing to ship can be uncomfortable. No one likes being embarrassed by a buggy release. However, the bigger risk is building your product in absence of actual users. By the time you find out that you’ve built something nobody wants, you don’t have enough time to change course. However, we never cut corners in two critical areas. First, since we must guard the private communications of our users, security is top-of-mind during the whole development process. We never skip any security measures to ship faster. Secondly, we deeply care about experience, so we reserve time at the end of each sprint for polishing and a design review.

At Squad, we learned this lesson and took it to heart from the beginning. In December 2018 we built our MVP and had been testing internally. We knew our product was functional, but neither my cofounder nor I felt comfortable launching it into the world. It had too many missing features, too many bugs, and too much polish we wanted to apply before launching. But we weighed our discomfort against the need to make fast progress, so we forced ourselves to launch the first week of January 2019 no matter what. Despite the immature quality of our first version, the response and interest showed us we were on the right path. Users of all different backgrounds from around the world were excited to discover a new way to share online experiences with friends. The media also picked it up with Josh Constine writing a favorable article in TechCrunch and Taylor Lorenz tweeting about the potential of Squad. Bolstered by the validation, we went to work with renewed energy to make Squad better.

You can make exciting products with boring technology

Developers face many considerations when choosing the tech stack for their product. In the case of Squad, we insist on simplicity. We don’t have a devops team, and we’d rather spend time building features for our users rather than over-engineering our infrastructure. Our philosophy is to use sound principles and favor simplicity, while understanding the future ramifications of our choices to always make sure we don’t box ourselves in.

For other products it could be different. It might necessitate a very sophisticated production infrastructure to provide a particular kind of service. And sometimes the tech stack choice can be decisive factor. For example, would WhatsApp have reached stratospheric levels of success if they hadn’t chosen Erlang? That’s the exception more than the rule, and most of the time building the right product is much more important. Facebook was written in PHP after all…

Squad is a real time communication app and most of the complexity lives in the clients. Our backend responsibilities are relatively small and therefore it is one of the simplest components of our system. Our simple backend infrastructure:
* Node.js: Yes, JavaScript is not the best language. Typescript helps, but still. That being said there are advantages — easy to scale, easy to develop, and it is supported by a large, established ecosystem.
* Postgres: Rock solid and SQL is too useful to give up. Furthermore, NoSQL requires upfront knowledge of the domain to optimally design the data model. When you are a young company, learning and iterating, the flexibility of ad hoc queries is invaluable. While scale may eventually necessitate the move to a horizontally distributed KV option, we are able to easily support millions of users on Postgres using read replicas and caching.
* Monolith: No need to go into the microservice versus monolith debate here, but it should be unsurprising that since we prize simplicity we went with a monolith. Why add the complexity of a distributed system if we don’t need it right now? We keep our module separation clean so we can split them off into discrete services if needed for performance.
* No containers or k8s: Don’t have time for it if we don’t need it. It would be very easy to move in that direction when we feel the need.

Yes, hiring is hard

Endless volumes have been written about the challenge of hiring at start ups. We have amazing advisers, we went through YC, our Seed round led by First Round, and yet we still initially made mistakes.

Critically, we underestimated the degree of focus and time needed to hire effectively. We learned it is very important to set up a hiring plan and implement a process, even if it’s extremely lightweight.

We also learned we needed to dedicate 50 percent of our time to the process while we were actively hiring. This means that we tried not to hire during fundraising because we knew we wouldn’t have an appropriate amount of time to do it properly if we wanted to continue building and shipping. When you’re a tiny team you can’t do everything well all at once. Hire. Fundraise. Ship. Choose two at a time.

It’s a roller coaster

The startup journey is famously full of peaks and valleys.

Notable highs:
* Getting into YC: After several rejections, receiving the acceptance call was one of the most euphoric moments of my life.
* App Store App of Day (2x): Being chosen by Apple to be App of the Day twice in one year was a tremendous honor.
* Going viral and reaching #6 overall in the US App Store: It was amazing and surreal to see squad at the top of the App Store charts. Our peak was 375K downloads in a single day.

And some lows:
* The wilderness: After deciding our first product was not the path forward, we were left questioning our approach, but not our mission.
* SMS toll fraud: Criminals using European proxies and working with corrupt telcos in Azerbaijan abused our SMS OTP to rack up 35k in Twilio fees (from which the criminal would receive a kickback for from the telco). Thankfully, Twilio worked with us and forgave charges.
* Founder conflicts: Disputes are inevitable and stressful, but I am so lucky to have an amazing cofounder who, even in the most difficult times, remained my friend.

Friends on a mission

I started Squad with my amazing cofounder Esther Crawford. Through thick and thin we worked through all varieties of challenges. Along the way we were so lucky to add new friends to our team who shared our passion. I want to give my most sincere gratitude to our world class team. Thank you Maria De Lourdes Zollo, Daniel Galdamez, Alexey Zinchenko, Milan Nosal, Ahmed Murray, Paul Robinett, and Marian Vanderka!

I also want to thank our investors, advisors, and everyone who helped along the way:

First Round, betaworks, Halogen Ventures, BBG Ventures, Y Combinator, Dream Machine (Alexia Bonatsos), Rob Hayes, Alpha Bridge Ventures (& their Project Atlas team), Tuesday Capital, Funsize, Gina Bianchini, January Ventures, Bangaly Kaba, Shrug Capital, Sebastian Gil, Dylan Field, Sahil Lavingia, Scooter Braun, Delane Parnell, Cowboy Ventures, Jon Vlassopulos, Marcy Venture Partners, Quiet Ventures, Chernin Group, Vivek Kumar, Brian Bedol, Jereme Monteau, William Tunstall-Pedoe, and Laura Jones.

Thank you for believing in two first time founders with a crazy idea!