3 Big Lessons From Building a Startup In a Month As a Solo Founder
In September I pledged to build a new startup every month for the next six months. These are the first three lessons from the first startup I built and launched in a month.
Find a Mentor
- It’s going to be extremely hard to keep yourself going as a solo founder.
- Some bugs will take days to fix and drive you crazy.
- The learning curve for some things is simply too great and you will start doubting your own abilities.
- There were several days when I wanted to quit.
- A good mentor will help you both with the speed of execution and motivation.
- I was lucky to get help from a developer friend but you might also want to check out platforms like Codementor and MentorCruise.
- It’s not possible to overestimate how important this is.
An Example
I spent two days trying to learn how to do authentication half-properly. By the end of it, I was ready to give up.
JSON Web Tokens alone have several rabbit holes where you can get lost. But I also needed to get some knowledge about MongoDB & mongoose, Routing, OAuth 2, cookies, React rendering side-effects, and more.
In the end, I just needed a 30-min explainer from my mentor and I was able to implement authentication in a couple of hours.
Start With Requirements & End Design, Always
- As a solo founder, you will have to switch hats a lot — product manager, designer, developer, marketer, etc.
- For me, it was especially easy to get lost in technical problems as I have worked mainly in product management and marketing but not as a developer before.
- A design spec will help you keep focus and save time later with implementation.
- It forces you to think as a product manager/designer first and as a developer second.
An Example
The startup I built, Linkchimp, is a Mailchimp integration that checks broken links in emails. Which means it needs to parse emails to extract all the links.
I got the parser working in a couple of days but the coarse design I used for it locked me in for weeks. I started designing the rest of the site around it until I realized I needed to redo the whole design.
It would have been way easier to just design the end solution first and then systematically try to see if I can get all the data required for it.
Test Deploying From The Start
- Many things can break.
- Some problems you can’t even see before you deploy — for example, possible problems with social sharing and SEO, SSL, redirects, tracking, routing, versioning, etc.
- You don’t want a bug popping up on the day of the launch when you finally deploy.
- When you’re deploying each time you commit, you’ll see which change broke what.
An Example
I’m using React in the front end and Express/Nodejs in the back end. These are kept in separate folders (but in the same git project) and I run the servers from separate terminals.
Everything seemed okay until I finally tried to get the site up. The deployment seemed to go fine but the website was blank. In the end, there were both mistakes in the deployment script but also in the way the server was set up. It took a whole day & night to figure that out.
I’m not sure I would have gone with this exact setup if I’d known it’s so hard to get it up and running.
Bonus: Set Tight Deadlines
- Not much else to say here, except that deadlines do work.
