How to Run a Startup with no Money
Lessons from the rise and fall of one of the greatest student-run dating apps in college history
Three years ago, a few college students from UCLA, lead by founder Dmitri Brereton, teamed up to develop a site that addressed a critical and relevant student need: dating. BruinMeet was a web app with the simple goal of providing students with quality matches once a week based on an elaborate matching algorithm. By the time I had taken over as Product Lead a year later, the site was at the height of its success with over 500 weekly active users. But BruinMeet had its limitations, the largest being that because it was a club project, it had no source of income and no intention of creating a revenue stream.
As a result, the most challenging part of my job was not leading the product, but leading the team. Managing a group of 15 developers, designers, and marketers meant that I needed 15 bulletproof reasons why contributing to this project for free on top of homework, midterms, and other clubs was, in fact, a good deal. From my time with the team, I learned a great deal about how the nuances of culture, atmosphere, and team dynamic can lead to the difference between success and failure; hopefully my insights can prove useful to the next generation of college students and entrepreneurs.
1. Hire people you trust more than yourself
If you ask the CEO of any company what they can credit their early successes to, chances are they will say something along the lines of “the best decision I ever made was hiring my COO.” I cannot emphasize this point enough. As a leader, you must be able to delegate without micromanaging; your job is to drive the vision of the project forward, not be a parent. I was beyond fortunate to have an Engineering Manager, Bibek Ghimire, who I felt knew more about the product than me and cared more about the product than I did. As a result, not only did I have one less person to worry about managing, I had someone who could help manage myself and push me to aim higher.
2. Take the time to find out what motivates each individual
This one is pretty straightforward. If someone isn’t getting paid, it just means they feel rewarded in other ways, most likely from the skills they’re learning. Ask yourself and ask them: What do you want to be learning? Are you learning what you want to be learning? And repeat this process every few weeks. It serves as a reminder to you both about your purpose as a contributor and learner.
3. Create a family
The OG BruinMeet team consisted of 8 closely knit individuals. They gave each other nicknames and hung out together outside of team meetings. As the team welcomed new members, we maintained the tradition of giving everyone a BM nickname and used the Donut app on Slack to assign chumming buddies (every week, randomly assigned pairs were required to have a meal together and post a selfie on the channel). Over months, even as strangers joined our family, I could see our team bond evolve and strengthen. People would stay past hack night hours and actually enjoy discussing the technical challenges they were currently facing. What a concept!
4. Give everyone a sense of ownership
Before long, our codebase started to outgrow our team. With new developers joining every quarter, it soon became challenging for anyone to become familiar with the entire repo. Bibek and I soon learned that if we assigned everyone a certain part of the codebase, not only did it become easier for developers to know exactly who to ask when they had a question, but everyone felt a certain sense of responsibility and skin in the game.
5. Establish the legitimacy of the product
At peak traffic levels, we would occasionally receive bug complaints from users. Once in a while, these bugs would be critical ie. someone’s personal info was displayed before the match was accepted by both parties. If you can demonstrate that not only your own credibility is at stake but also the well-being of hundreds of users who are loyal to your work, it’s easy to get any developer to drop whatever they’re doing at the moment and fix that P0 bug.
6. Don’t fall into the “free labor” trap
This is one of the biggest mistakes I made, and even though I try my best to warn new Product Leads of the trap’s perils, I see it happen over and over again. Just because you can hire more students doesn’t mean you should. I like to think of the relationship between people and effort to manage people to be exponential. The larger the team, the harder it is to keep everyone accountable and the easier it is for your delicate team dynamic to come crumbling down. If you want to hire someone, be sure that your team would absolutely not be able to function without the extra help of an entire human being. More teammates is less productive.
7. Know when to let people go
Because college students working on a college product are not getting paid, there is nothing stopping them from slacking off. Despite all that you do to introduce incentives and boost morale, a student’s capacity to contribute productively relies entirely on themselves. The best you can do is recognize when someone has outgrown the team and is ready to move on, whether they are ready to admit it or not. Under-motivated teammates drag expectations down and set unwanted precedents.
8. Know when to call it quits
A year into my takeover of BruinMeet, the site was in full swing; all the core functionalities were built and rebuilt, meaning that the only work left to do was fix bugs and add features. It goes without saying that new members were less than enthusiastic to join just to spend their prime college years fixing bugs. Bibek and I truly struggled to find a way to motivate the team, but at a certain point, we had to accept that like with all college projects, students sign up to learn and grow; if those requirements aren’t met, they have every right to expect more and walk away.
Unfortunately, after its glorious reign, BruinMeet had a rather un-glorious demise. Because of its wild success, our school administration inevitably caught wind of the project and cited numerous potential violations with the platform ranging from age discrimination to a lack of sexual assault liability protection. In other words, we were a pressure cooker of sueable offenses, and the school would have nothing less from us than shutting down the entire operation.
After days of frustration, denial, and late night scheming, the team and I finally said goodbye to our massive, industry-grade codebase, but deep down, a part of us felt relieved that we could walk away guilt-free and start again fresh with a new project. We were still in college, after all, and all we wanted to do was keep learning, exploring, and building.