WWCode Career Nav #21: Technical Growth as a Startup CTO: From 0 to 100k+ Users
Written by Kathy Zhou
I'll give a little background on why I'm giving this talk and why I feel like what we've accomplished as an all-female team is super important. Queenly started as an iOS first, later web and Android that year. We achieved many milestones in the tech industry. First, we were accepted by Y Combinator in their winter 2021 batch and did their demo day. From demo day, we raised a $6.3 million seed round led by Andreessen Horowitz, many wonderful angel investors, and many wonderful firms.
Our platform is for weddings, proms, and special occasion dresses. We have over 70,000 dresses listed. My first company was my co-founder's first company as well. From the beginning, from my own experience, I always had that imposter syndrome on whether I could call myself a CTO, whether I had the skill set, experience, or qualifications. My background is that I'm a computer science grad from the University of Pennsylvania. Right after graduation, I joined Pinterest. I was a full-stack engineer, working on the web and iOS stack.
Our whole engineering team is all women so far. I feel like what we've accomplished, and the technical journey Queenly has gone through is worth showcasing. In 2019, I was still a full-time engineer at Pinterest. We were thinking about launching Queenly as a minimal viable product. Looking back, the best advice was to do it without getting hung up on thinking about having a big launch or a super polished end-to-end user design. When we first submitted this first app to the Apple App store, we ran into issues with getting approved by the App Store. They're strict about it when you're a first-time developer and getting that first approval. That timeline is always going to be a huge hurdle. My advice is not to get hung up on that because you'll always have this process of getting feedback from your customers and users iterating on your design, and it will not look like what you saw on day zero of your product.
One of my biggest pieces of advice is to start with out-of-the-box tools. When building the MVP, everything was on Firebase. Firebase is a very out-of-the-box tool for having things like basic database setup. It's a NoSQL data store. It's pretty that you don't have to set up a whole server or API to create a cloud data store, which is fantastic. I lean a little more toward the front-end than the back-end in terms of my own engineering experience. I was able to launch a bunch of the core features, list addresses for sale, do a checkout flow, and do all those foundational things without having to set up a whole bunch of servers. They also do so many other things, like crash reporting analytics. It's important to try to use as many tools as possible because when you're a small team, it's hard to set up so much infrastructure.
It's hard to have one person dedicated to monitoring. It's extremely important to take as many of these tools as possible and see what you can piece together. It's a bit of a Frankenstein project. That's what a startup tech platform is, but it will help you survive. Use startup credits. Go and apply to the MongoDB Startup program and the Heroku Google Cloud startup program. These can cost a few thousand dollars a year if you're not careful, but if you're starting a company, you can always apply for these credits and get all your cloud costs for free.
I started on Firebase, which is NoSQL. It's a base structured non-relational database. Firebase is slightly restrictive in compound queries, but it's similar to Mongo. We were able to stick to Mongo. This is a big decision that you have to make early on. You have to think about the shape of your data and the speed at which you want to do things like quick feature launches. I like a quick primer, the whole SQL versus not SQL, acid versus base. I think it's important to think about consistency versus availability. What's great about a NoSQL like Mongo is that we can be flexible with the data because we don't need to update it so much. For example, people might buy a couple of dresses a day or list a couple a day, but we're not like a social media app where people are constantly changing data. It's what's considered a low-right, high-read frequency data access. This type of data storage solution was great for Queenly.
You want to think about database migrations at a big company that sounds like a scary word. It is moving from one data store to another. For us, it was moving from Firebase to MongoDB. It's not that scary as long as you do it early. Early meant that we had a manageable enough size and scale of our data that we were able to migrate it completely. If you're in the middle of a migration, ensure you're doing this to improve user experience. Make sure to duplicate data. I know that's a little tough to manage and not ideal philosophically. You'll have to manage data in two states and make them consistent. As an early-stage startup CTO, I learned that it's better never to lose data. My next piece of advice, hindsight is 20/20; log everything. Please over-log every back-end event, front-end event, and user action. This is one of my regrets that we did not log everything from the beginning. For so many of our early users, whenever there was a crash or a weird buggy experience, we could not remotely figure out what actions they took to get to that screen. Also, if you make sure you have all these metrics records, it can help lay the foundation for better growth engineering and analytics.
I recommend using Amplitude because Amplitude was super easy to set up. It was just like installing the SDK and writing one code line. They have a lot of out-of-the-box tools. Outside of growing all these skills, all these tech stacks, and learning about different areas of engineering, I'd say what was useful was learning about marketing and analytics when it comes to growing a company. Thankfully, we've gotten to hire wonderful growth marketers from Poshmark. We've gotten to learn a lot about how to break down and how grow users as a startup. When people talk about startup growth, it's not building one viral sensation that you'll have thousands or hundreds of thousands of users one day. The way we got from zero users to hundreds of thousands of users was through a lot of iteration, a lot of incremental changes.
A lot of this is based on growth marketing. If you're an engineer, if you're looking to be a technical leader, even though marketing might have seemed a fluff word to you way back or you might have that stereotype, a lot of things are super core to engineering. Educate yourself on all these terms, cost per click, cost per install, how ad displays work, and how dynamic ads work. Suppose you're doing any consumer startup that needs to grow through paid ads and SEO. In the SEO space, it's important to learn how it works because that's a whole industry. This is how companies don't get growth for free. It's a lot of strategies; it's a lot of thinking.
I would recommend taking classes, getting advice from SEO marketers, and seeing how this whole breakdown of growth works. When you're an early-stage tech leader, it's good to learn everything. That's a bunch of things that aren't directly engineering because you're not just an engineering leader. You're a startup founder. You're responsible for much more than just one small business component. My advice as someone who's pretty front-end heavy and as someone who's trying to touch as many parts of the stack as possible is similar to my back-end stack advice. Our front-end stack has iOS, Android, and the web apps. We have relied extensively on many out-of-the-box tools similar to our back-end stack. There are many packages and libraries for different UI components, different ways of doing form validation, and different ways of doing navigation.
The biggest advantage of a company this early is not that it's necessarily overly complex or messy, but there's a huge advantage of just making this hybrid Frankenstein app. For a background, at Pinterest, I worked extensively in Objective-C. The most common easy-to-use languages are Swift and SwiftUI. Our app is in this hybrid model where I built many of our Objective-C views and view controllers through muscle memory. A huge advantage to a startup that needs to move fast and doesn't have such a massive legacy code base that you need to think so much about maintaining. Another topic on this whole thing when you're building a consumer app for multiple platforms is, should I build it in React Native? I've worked with React Native, and it's a great tool. I believe you should do whatever you have the most muscle memory off. I did build our apps from the native code bases of Objective-C Swift for iOS, Kotlin for Android, and React for the Web. I was fortunate enough to have the experience of relying on muscle memory. This is how I set up the different navigation view controllers on iOS. Then I had the muscle memory of experience on how to do it on the web. Doing it that way also gives you that level of fine tune control over building custom stuff for each of those user experiences. I wouldn't say to use React Native; I'd say to use whatever tool you feel most comfortable with. I did whatever was speediest for us to get our app off the ground.
If you are a technology startup leader, it's important to set an example as a role model by looking at trade-offs. You're allowed to write bad code, but it's good to manage those trade-offs. Know why you're making those decisions. Know why it's important for you to take certain shortcuts. Be aware and pay down your technical debt. It's good to set that example for other engineers. Set the culture of taking ownership of whatever you build. It's also good because you are the person that made those speedy decisions. You, yourself, are the one who can do the best at cleaning it up, refactoring, modularizing, and deprecating certain things. An early startup CTO should be the one that takes ownership of the tech debt they create.
As a tech leader, it's important to think about the soft skills, the non-technical things such as being a good communicator and being someone who can speak with empathy, who can understand, communicate, and build that emotional skill aspect of yourself. In terms of hiring, a lot of it was built on thinking about culture and having tech interviews that are not just like algorithms but purely CS fundamentals—seeing if someone had the drive, the passion for building the largest marketplace for dresses, to caring about building a nice user experience. That person doesn't have to be interested in dresses or fashion or necessarily have that direct experience. Still, it's something that signals that outside of having tech skills, those are things that bring a team together.
Another thing I like to do in our interviewing loop has the non-engineering aspects of our team interview engineers. Very often, aside from the technical interviews, there are interviews where our ops team and our partner's growth team talk to engineers. I think it's core in a startup to be able to talk with and show respect to the business side of things. When you're a small team and when you're trying to build something like a consumer app, when you're trying to build something that, like everyone on the founding team should show care and passion to, I think having that scale of being able to collaborate with non-engineers on ideas, move projects forwards is extremely crucial.
Outside of hiring, I am thankful for my own positive experiences. I've had great engineering mentors in the past. I want to do my best job to push it forward. This is the first time I'm a manager. I care about transparency, communication, and the eagerness to learn and grow. In terms of reflecting on myself and being able to be a good leader, I think it's more than just being able to make decisions. It's more than just a title. I feel that as an early-stage technical founder, you are responsible for being a role model and mentor to people. Especially if you have something like my team, where we're an all-female engineering team. There is a certain level of advocacy. Give people a skill set to have something they're proud of after they've worked with you.