8 years of code.

Finding a co-founder: my 100 matches at Harvard and MIT

When starting a company, there's a few key ingredients you need, including a good idea, great co-founders, and a healthy dose of engineering ability never hurts. Great companies don't live and die based on the idea's behind the company, but by the founding team behind the ideas. With that said, finding a great co-founder is is both difficult and necessary.

Problem

Out of the nearly 10,000 students at Harvard and MIT, find the 100 students who'd be most compatible to start a company with me (including findname, linkedin, and email)

Solution

‍1. I pulled the list of every Harvard student with their major and email from the Harvard directory. I got a similar list of MIT students (this was more complex since I don't go to MIT). For students without a listed email in the directory, I wrote a custom program to deterministically find the .edu email for the student using some basic tricks.

2. I pulled all of this data into a spreadsheet. I then created a script that went through each of the students and used the People Data Labs API to find their most probable LinkedIn profile URL based on their first and last name.

3. I then scraped their LinkedIn and placed that data into a spreadsheet in JSON format.

4. I then assigned a score to each LinkedIn profile based on certain attributes I care about in a co-founder, like past startup experience, whether they studied a technical field, and internship experience.

5. I then took all of this data and plotted it in a graph using the open source intelligence (OSINT) software Maltego

Outcome

I was able to find several dozen people with large scores on my LinkedIn Scraper. I reached out to several of them and had great conversations. Some of them even applied to the accelerator I helped run, Prod. 

Fun fact: I actually co-founded the AR/VR club and the Augmentation Lab with the person who scored the highest out of all Harvard CS majors... so maybe my algorithm did work pretty well :)

Code to create a company

Eniac: Improving mental health via text

Eniac was my first company. I started it in high school. I was a high school senior that made an app to help his  his sister keep track of her migraines. In 6 months, I led a team of 7, raised $100k, and had created a product that helped people improve their mental health. It was a wild journey—and the story doesn't end there.

The Beginnings

My younger sister had chronic migraines. Her doctor instructed her to keep a migraine journal and track her migraines each day. Compliance with this regimen was difficult for her, since she was 8 years old. She's Gen-Z (like me) so I knew she liked to use her phone. I created an app for her to track her migraines. It wasn't an app in the traditional sense though. Instead of downloading something from the app store, I set it up as so:

1. Every day she would receive a reminder to track her migraines.
2. She would then just reply to the message with an emoji, representing how she felt. She could also add a text annotation in a follow-up message describing the migraine.
3. This data was then stored in a website where she could see her past annotations. Each of the emojis was associated with a number, so the data could be visualized in chars and graphs.

I noticed that a lot of people liked the app—but most weren't using it for migraine tracking. Instead, they were using it to do daily journaling to improve their mental health. What was more amazing was that some people were even willing to pay for the product I made. I set up a paywall and got a few dozen users. I was in high school and had never done a startup before, so at the time, this was really promising to me and sounded like good traction (in hindishgt, it was not). My mom found me a mentor who could help me form an LLC around this idea.

The entire story is too long for this website, but feel free to send me a message and I can go into details :) Long story short, I formed a team of advisors. The work required outgrew capacity of the advisors, so I raised around $100k from some mentors who really believed in me. I hired a team of staff and grew to about 7 people. As a small team, we developed the product, got our first hundreds of users, got partnerships with major organizations, and, hopefully, helped improve a few lives

Getting deep into the code

This was a complex code project. As I was a solo-founder on this venture, I wrote the first several thousand lines of code before I could hire people onboard to help. Here's how it worked:

Text-messaging Interface

Eniac was fundamentally a text-message based application. Users would receive reminders and respond with an emoji.

1. A user would receive a text message at 9pm prompting them to respond with a journal entry. The message would be scheduled by a Redis Cache running on Azure. The text message itself was sent with Twilio.
2. The user would respond to the text message with an emoji or journal entry. Upon Twilio detecting a message being received, it'd send a webhook to my Django webserver.
3. Firstly, the Django webserver would store the results of the text message in an AWS mySQL database (emojis were converted to numbers and journal entrys were left as plain text).
4. Secondly, the webserver would respond with a reply to their text message. The reply would vary depending on keywords used in their original journal entry, but would be often probe the user for more info, asking  questions like "What made you feel this way?" and "Was this your happiest moment of the day".
5. If the user responded to the follow-up questions, these would also be stored in the mySQL database.

Online dashboard

As users continued to reply to the daily text messages, Eniac would store more and more of their journaling data. When the user went to their online dashboard, the dashboard would show all their data in an intuitive format.

1. In the "Overview" menu, the user could view numerical data associated with their journal entries, as well as the text data. The online dashboard was built with Django.
2. In the "overview" tab, all the emoji data from previous days was pulled and converted to a number. A chart generating library was used to display the data in different formats like a bar chart and a line chart. When users clicked on a data point, in addition to showing the numerical data from that day, it'd show the text annotation.
3. Users could also add each other as friends on the website.
4. Users could change basic settings like when their reminder text message was sent out, their profile picture and name, and the types of questions Eniac would ask them.

Outcome

Eniac ended up being what got me into entrepreneurship and startups. Without it, I never would have even joined Prod. I decided to change my position in Eniac from Founder & CEO to just Founder, and passed the torch off to Andrew (the COO at the time) to be CEO. My reasoning behind this can't be explained in a simple blog post, but I'm incredibly pleased with the work Eniac has done, the lives it has changed.

Quidio: The Knowledge Marketplace

Quidio, like Eniac, was another long-term project that I worked on. The goal of Quidio was to provide a place where users could ask programming questions, add a bounty, and get a great answer.

Problem

If you have a programming problem, you have two options. Firstly, you can try free Q&A sites like StackOverflow and Quora, but these suffer from low answer rates. Even if you have a really pressing question, you have to rely on the good will of volunteers to get an answer. The second option is to use freelancing sites like Fiverr and Upwork. The disadvantage of these sites is that if you're a programmer, you may just need a small part of your site completed and hiring an entire freelancer would be excessive.

Solution

The solution to this problem is a knowledge marketplace. Users post their programming questions online and pay a cost based on the price of the question. The questions are publicly available—so anybody, anywhere can answer it. A user selects the top answer to be the recipient of the bounty. The best way to understand Quidio is just to go and check it out here!

The frontend was made in React and the styling was done with Tailwind. Quidio was hosted on firebase hosting and all of the data was stored in Firestore. The backend was written in Node.js and used Vercel.

I had to implement Stripe for payments. This was complex because Quidio acted almost as a bank, in that answerers on the platform stored their earnings on the site before taking them out and transferring to their bank.

Outcome

Quidio ended up being one of the most fascinating technical and business challenges I've taken on. Building out the platform was not easy. However, the hardest part was certainly getting users onto the platform. I didn't want Quidio to go unused. I would post on sites like Reddit and message people with coding questions, offering to give them Quidio Credit in exchange for them using Quidio as opposed to other knowledge marketplaces.

Using code to explore the frontiers of science.

Solving the traveling salesman problem—with a twist (2019)

In 2019, my robotics team had created a robot that could play a game with other robots. The game involved taking a ball, loading and unloading it into the robot, and being able to shoot the ball into an elevated hoop. There were a lot of engineering challenges in building this robot from start to finish, but challenge that called my name was the question of whether we could make our robot completely autonomous. More specifically, I wanted to make it so that the robot would autonomously find a path to traverse a set of points on the field and end where it started—the traveling salesman problem (TSP). But, there's a twist. In the robotics competition, most of the points are moving. This rules out most TSP based algorithms because I wanted my algorithm to be able to create this path even as the points on the field moved.

Problem

Given a set of n points positioned in the x-y plane, create a path that visits each point and ends at the start. The points in the path are moving.

Solution

I decided to use a genetic algorithm to solve this problem. I had played with genetic algorithms before (I had used them for my ISEF project earlier in the year) and I knew them to be reliable. In particular, a genetic algorithm fit the moving TSP problem in a few key ways, including that it could create a "best guess" of the optimal path instantly, and quickly improve upon that, you didn't have to completely restart the calculations once one of the nodes had moved, and the time complexity towards coming up with a best guess was much more reasonable with the genetic algorithm than with more common, deterministic implementations of TSP.

Outcome

I ended up presenting the research I had done on this with some friends at the International Artificial Intelligence Fair in China. It was a really great experience to present to a global audience of industry veterans and researchers with a solution approach I had created, especially as a sophomore in high school. Here's the paper my friends and I wrote on the topic.

You can find the code for this here.

Making solar panels 40% better with code

In high school, I went really deep into scientific computing after working in a quantum computing research lab for a year. I'd developed my MATLAB skills and got pretty familiar with reading academic literature. I was interested in doing the International Science and Engineering Fair because a friend of mine had done it and it seemed interesting. I saw a paper describing the fabricaiton processor for solar cells, and they literally just put two plates of chemicals together to get it to work. Something told me

Problem

Solar panels are inefficient. There is a lot of energy lost between a photon striking the surface of the solar panel and the solar panel outputting energy. The chemical microstructure doesn't have the most efficient shape. Solar panels could be improved by changing the microstructure.

Solution

In 2019, I wrote a genetic algorithm to optimize the microstructure. I created a simulation a solar cell where I could calculate it's efficiency based on the microstructure. I represented the microstructure of a solar cell by a graph, where each node in the graph represented a "pixel" on the solar panel. For the sake of computation, each node was connected via an edge to the 8 nodes adjacent to it. The genetic algorithm I created would then generate several possible microstructures, evaluate each of the proposed microstructures, and propagate the features of the microstructure that had the highest solar cell efficiency.

The Process

I ended up writing several thousand lines of code for this. I estimate that this ended up taking several hundred hours. This was, up to this point, my biggest coding project. My high school physics teacher and mentor, Dr. Brandon Hogan, was incredibly helpful as I was developing this project. However, writing all the code alone and directing most of it proved to be a challenge.

Outcome

I ended up presenting the research I had done at the International Science and Engineering Fair in Arizona. You can find the pre-print I wrote up about this here. In the end, after running my genetic algorithm, I was able to develop a chemical microstructure that generated 40% more current than conventional solar cell designs.

You can find the code for this project here.