We talk about:

• Eamonn’s love of coffee and how he bought VHS tapes to learn latte art

• How he finds time to expand his skills in between running coffee shops and ultra-marathoning

• How he used spreadsheets to automate the logistics of running coffee shops

• How he balances being a musician and writer with the practical realities of providing for a family of 6

Can you guess what song I'm playing in the intro?

Support comes from the 11,113 kind folks who support freeCodeCamp through a monthly donation. Join these kind folks and get involved in our mission by going to donate.freecodecamp.org

CORRECTION: Vincent van Gogh was supported by his younger brother – not his brother in-law. van Gogh never married so he never had a brother in law. I'm not sure why I thought that. Also, he seems to have sold more than one painting in his life (as many of us were taught in school), but nowhere near enough paintings to support himself as an artist.

Links we talk about during our conversation:

Eamonn's freeCodeCamp articles: https://www.freecodecamp.org/news/author/sieis/

Eamonn's YouTube channel: https://www.youtube.com/@eamonncottrell

Excel-based esports: https://www.youtube.com/watch?v=N2QC6VQXo8U

Ultra Marathons: https://www.youtube.com/@runtired

Got Sheet: https://www.gotsheet.xyz/

Progress and Perfection: https://www.progressandperfection.com/

Eamonn on LinkedIn: https://www.linkedin.com/in/eamonncottrell/

Eamonn on Twitter: https://x.com/EamonnCottrell

Dennis dropped out of college at 18 and taught himself how to build websites. He started his first agency, built and sold products, and eventually started teaching his skills on YouTube.

We talk about:

• Growing up in an immigrant family of 13 kids

• Dropping out of school and working construction before learning to code

• Figuring out how to get web development clients through trial and error

• Selling his codebase to his employer $61,000 and using it to fund his journey into teaching Python

Can you guess what song I'm playing during the intro?

Also, I want to thank the 10,943 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

You can watch the interview on YouTube:

Or you can listen to the podcast in Apple Podcasts, Spotify, or your favorite podcast app. Be sure to follow the freeCodeCamp Podcast there so you'll get new episodes each Friday.

Or you can listen to the podcast in Apple Podcasts, Spotify, or your favorite podcast app. Be sure to follow the freeCodeCamp Podcast there so you'll get new episodes each Friday.

Links we talk about during our conversation:

• The Bussard Ramjet theoretical spacecraft Quincy mentions as an analogy: https://en.wikipedia.org/wiki/Bussard_ramjet

• Dennis Ivy's React + Appwrite course on freeCodeCamp: https://www.freecodecamp.org/news/build-a-sticky-notes-app-with-react-and-appwrite/

• Dennis Ivy's YouTube channel: https://www.youtube.com/c/dennisivy

• Dennis Ivy on Twitter: https://twitter.com/dennisivy11

We talk about:

• Growing up in rural Ohio, marrying young, and staying out there despite his success as a developer and entrepreneur

• Early client work, and how he designed thousands of logos for clients before becoming an all-out web developer

• Using his skills to help his wife start her own lactation consultant business online

• Gary's guitar shredding chops

I recorded this podcast live and I haven't edited it at all. I want to capture the feel of a real live conversation, with all the human quirks that entails.

Can you guess what song I'm playing on my bass during the intro? It's from a 1995s Nintendo game.

Be sure to follow The freeCodeCamp podcast in your favorite podcast app. And share this podcast with a friend. Let's inspire more folks to learn to code and build careers for themselves in tech.

You can watch the interview on YouTube:

Or you can listen to the podcast in Apple Podcasts, Spotify, or your favorite podcast app. You can also listen to the podcast below, right in your browser:

Also, I want to thank the 9,331 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

Links we talk about during the interview:

• Gary's Learn UI Fundamentals course on freeCodeCamp: https://www.freecodecamp.org/news/learn-ui-design-fundamentals-with-this-free-one-hour-course/

• Gary's freeCodeCamp live stream series: https://www.freecodecamp.org/news/design-course/

• Gary's tool for memorizing the Guitar fretboard and it's 49 notes: https://fretastic.com/

• Gary's Retrowave Guitar music video: https://www.youtube.com/watch?v=yDc2OvReYh0

On this week's episode of the podcast, I interview Gary Simon, a developer and designer who started DesignCourse and has published several courses on freeCodeCamp.org over the years.

We talk about:

• Growing up in rural Ohio, marrying young, and staying out there despite his success as a developer and entrepreneur

• Early client work, and how he designed thousands of logos for clients before becoming an all-out web developer

• Using his skills to help his wife start her own lactation consultant business online

• Gary's guitar shredding chops

I recorded this podcast live and I haven't edited it at all. I want to capture the feel of a real live conversation, with all the human quirks that entails.

Can you guess what song I'm playing on my bass during the intro? It's from a 1995s Nintendo game.

Be sure to follow The freeCodeCamp podcast in your favorite podcast app. And share this podcast with a friend. Let's inspire more folks to learn to code and build careers for themselves in tech.

You can watch the interview on YouTube:

Or you can listen to the podcast in Apple Podcasts, Spotify, or your favorite podcast app. You can also listen to the podcast below, right in your browser:

Also, I want to thank the 9,331 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

Links we talk about during the interview:

• Gary's Learn UI Fundamentals course on freeCodeCamp: https://www.freecodecamp.org/news/learn-ui-design-fundamentals-with-this-free-one-hour-course/

• Gary's freeCodeCamp live stream series: https://www.freecodecamp.org/news/design-course/

• Gary's tool for memorizing the Guitar fretboard and it's 49 notes: https://fretastic.com/

• Gary's Retrowave Guitar music video: https://www.youtube.com/watch?v=yDc2OvReYh0

I’m Gaël, a 25-year-old software engineer who’s been working in a startup environment in Southeast Asia for a few years. 🌏

Working remotely has its perks, and while hopping from one exotic location to another, I’ve been nurturing a little dream: to kick-start my journey as a solopreneur.

I genuinely love my job—there’s a certain thrill in startup life that I think everyone should experience at least once. Sure, it’s a rollercoaster of highs and lows, but it's where I've learned the ropes of product development and caught the bug for making things people love (and will hopefully pay for!). I often think of coding as adult LEGO—endless possibilities and just plain fun. 🤓

After two years of nomadic life, I chose to plant my feet firmly on the ground to strike a better work-life balance and finally carve out time for my side projects.

But here’s the kicker: settling down didn’t magically make time appear. Between the 9-5 grind and weekend exhaustion, I struggled to find the energy and belief needed to start something of my own.

Choosing the Right Tools for the Journey

Embarking on this solopreneur journey, I decided to harness the tools and technologies I was already familiar with: HTML, CSS, Tailwind, JavaScript, along with React and Next.js for creating websites.

This choice was not just about comfort but was also about applying best practices in web development that I've learned over a few years of experience.

In the following sections, I'll explain why I chose these particular technologies. I'll also provide guidance on how you can select the most suitable tools for your own projects, balancing learning curves, productivity, and project requirements.

Expect to find practical tips and lessons from my hands-on experience, which you can apply to enhance your coding skills or streamline your development process.

Realizing the Need for Change

Until recently, my daily routine was disordered. I juggled work with late-night phone scrolling sessions until 1-2 AM, only waking just in time for a hurried breakfast before starting my day.

Frequent use of food delivery apps led to overeating and unhealthy habits, which, despite my overall good life, I knew wasn’t sustainable.

I was trapped in a cycle, fearing that cutting back on my late nights would reduce my life to just work, work, and work. 💻

Then, something clicked a month ago. Motivated by all the recommendations I've seen about going to the gym, I contacted a personal trainer and started my first few sessions. Initially skeptical about lifting weights, I was surprised by the surge in energy it brought me.

"Talking to my therapist today" - @levelsio on X (Twitter)

This burst of energy triggered a chain reaction: I began paying more attention to my diet, choosing healthier, lighter meals. Sleep, too, became a priority. Influenced by the insights from "Why We Sleep" I transformed my sleep routine, targeting eight hours a night. This shift turned my mornings from a rush into a peaceful, productive time. 😴

Now, a month later, these practices have almost become natural. Waking up earlier, I feel more energized, and I've discovered precious time in the morning before work.

How Improved Health Boosts Coding Productivity

For those on a coding journey or balancing work with learning new skills, I cannot stress enough the importance of good sleep and regular exercise. These aren’t just lifestyle choices – they are essential tools for enhancing your cognitive function and focus.

After integrating better sleep and exercise into my routine, I noticed a significant improvement in my coding productivity. I was able to learn faster, stay focused for more extended periods, and tackle complex problems with more clarity. It felt like unlocking a cheat code for my brain!

Coding is an exciting yet demanding journey. With the additional energy gained from these changes, you'll be more equipped to face the challenges and joys of learning how to code.

Taking the First Step: BooksByMood

The concept for BooksByMood had been developing in my mind for months, inspired by Mood2Movie, an app developed by Marc Lou.

The idea of finding books based on your mood captivated me, and I envisioned a platform with my own twist on design and suggestions. This marked the beginning of my indie project journey with BooksByMood. 📚

Getting started on this new journey was daunting. My Twitter feed was full of stories of polished apps and good earnings, which heightened my stress and anxiety about starting. At that time, I didn't fully realize that we all have to start somewhere, and even the well-known people out there started at the beginning one day.

To manage my expectations and focus, I established clear, achievable goals:

• To create a straightforward website centered around a single, compelling feature.
• To keep the website free, ensuring accessibility and user engagement (IMO, also easier to get started with–particularly as a 1st project).
• To dedicate a week to learning promotion techniques, aiming to drive traffic to the site.

These goals weren’t just milestones – they were my commitment to myself to prove that I could bring an idea to fruition and attract visitors. 🎯

How I Chose My Technical Stack

As mentioned earlier, I utilized technologies I was proficient in: HTML, CSS, JavaScript, along with Tailwind for styling and Next.js for the framework. I chose this stack for its familiarity and efficiency.

I specifically opted for Next.js due to its convenient features:

• server-side rendering and static site generation, leading to improved website performance
• the file-based routing system
• various optimizations such as website navigation using the <Link> component or the <Image> component
• it's great for SEO
• overall it helps craft a better user experience

This stack allowed me to rapidly prototype and deploy, enhancing the site's performance without additional effort.

Takeaways: Stick to technologies you know well when validating an idea quickly. This approach helps you move faster and focus on the project's core value. That's why you can find many solopreneurs online using the same technologies for years (for example, Pieter Levels is using HTML, CSS, JS (with JQuery) and PHP for years).

App Development Process and Challenges

The journey of developing BooksByMood was iterative, starting with a basic, barely functional version.

I encountered several challenges, such as sourcing reliable book data and crafting a user-friendly interface. Overcoming these obstacles required research, trial and error, and continuous iteration.

Challenge 1: Finding Reliable Books Data

Finding a dependable source for book data was unexpectedly challenging.

I initially wanted to use some APIs. Unfortunately, Goodreads closed its API on December 8th, 2020. OpenLibrary was not bad, but the data needed to be more consistent. Google Books API was alright, but I would have also curated manually in the end, and sometimes some info could have been better.

This made me realize that it's hard to find a good books API out there (probably due to Amazon owning Goodreads and making sure it's hard for competitors to have good data as they do).

There was one thing I knew: it'd be complex to satisfy everyone with the recommendations, but I could do my best. My best was to ensure that what was recommended was well rated by the community (for example, it had a good rating on Goodreads).

You may wonder what will happen in the future, if the website is growing? In that case, it'll definitely need improvement. But, for a first release, it does the trick!

Takeaways: When facing a challenge on a new project, always take your time to consider all options and find the right balance between shipping fast, quality and reliability.

As an example, I'm 95% sure that curating books manually in JSON files with the help of AI has been a great choice. It resulted in shipping in a reasonable time, only showing books liked by the community, and controlling the data (for example, cover, title, description, tags, authors, and so on).

Challenge 2: Designing a user-friendly interface

As a full stack developer who's been working on the backend for a while, designing an appealing front end was my second major hurdle. Ensuring the site was not only functional but also aesthetically pleasing was crucial for user engagement.

I'm still in the process of learning about design, and it's far from perfect. But I discovered Dribbble and it's been a great place to get inspiration. Also, I've been using Excalidraw to sketch an initial layout version showing how I'd like to organize the information.

Takeaways: For non-designers, drawing inspiration from design-focused platforms like Dribbble can be incredibly helpful. Combining this with UI component libraries, like DaisyUI, can significantly enhance the design process, making it more effective.

Initial sketch of BooksByMood on Excalidraw (shared for my 1st day of #buildinpublic)

1st version of BooksByMood

Releasing the App

With the extra time my new morning routine afforded me, I devoted 1-2 hours each weekday and additional weekend time to developing BooksByMood. After a week of focused effort, I opted for a soft launch: I added the project on Twitter by updating my bio link.

The following day marked the beginning of more assertive promotion across various platforms, including Twitter, Reddit, and HackerNews. ✍️

Takeaways: Feel free to release your project everywhere you can. It can sound scary, but you never know what will happen. Doing that will help you in many ways, such as starting to attract visitors, getting feedback, getting backlinks, and so on. There's nothing to lose!

BooksByMood Homepage

Learning and Growing: Early Lessons from the Journey

Personal and Business Lessons

It might sound a bit cliché, but these points have genuinely resonated with me:

• Believe in Yourself: Doubt was a constant companion, but taking the leap showed me the importance of faith in my ability to turn an idea into reality.
• Ship That Idea: After all, there could be only positives in doing so. Releasing a product, no matter how small, is a victory in itself.
• Building Publicly Is Rewarding: Engaging with the Indie Hackers community has been a blast. Their support and encouragement have been pivotal, making the process not just about building a product but also about being part of an inspiring collective.
• Believe in the Internet’s Magic: Sharing my project on HackerNews was a leap into the unknown. To my astonishment, we hit the first page, and the influx of visitors exceeded my expectations. Indeed, the internet can work wonders, turning small actions into significant impacts.

Technical lessons

On the technical front, the project has been a rich source of learning:

• Choosing the Right Stack: Leveraging familiar technologies like Next.js and React facilitated a smoother development process and quicker iterations. This really underscored the importance of choosing the right tools for the job. I've said it many times in this article: Use what you know. Don't try to overthink using the latest shiny technology. I'd advise you to focus on your product, not how it's being built.
• Data Handling and AI Utilization: The challenge of sourcing reliable book data forced me to consider solutions, including using AI for content curation. This experience highlighted the need for flexibility and creativity in problem-solving. Sometimes, in tech, you'll not find exactly what you want, and you'll have to evaluate potential tradeoffs to find alternatives.
• Design for the User: As a backend-focused developer, delving into front-end design was challenging. But prioritizing user experience and employing design resources like Dribbble for inspiration proved crucial in creating an engaging interface. Also, don't be too worried about your design. Your first version will probably be "ugly," but over time and iterations, you'll start having something visually pleasing. Everything takes time!
• Iterative Development: Start with a minimal viable product with only one focused feature. It's tempting for a developer to add many features, such as a dark mode, a user account, fancy filters, and so on, but that's unnecessary. Instead, use your technical skills to make that one feature work perfectly.

To wrap up this reflection, I can’t emphasize enough the satisfaction of crafting a project, releasing it, and seeing people using it. It’s an amazing experience that I recommend to everyone. If you’ve been sitting on an idea, stop overthinking and start building it now. 🚧

Looking Ahead: The Road to Indie Hacking

I plan to stay committed to the indie hacking path for the upcoming months, balancing it alongside my 9-5 job.

A vast landscape of knowledge awaits me, especially in areas like design and marketing, where my experience is limited. Objectively, I know it's not gonna be easy. Yet, the idea of acquiring new skills is exciting. 🎨

The Indie Hackers community has been a goldmine of insights, with members generously sharing their tips and success stories. This collective wisdom, along with a wealth of books and resources, will continue to guide and inspire my journey. 🔖

In the coming months, my focus is on continuous learning and building. I aim to diversify my projects, incorporating paid features to explore different business models and market needs.

Regarding the tech stack, I plan to stick with my current tools, which are versatile enough to meet most of my needs. While I'm open to integrating new libraries like NextAuth for streamlined authentication processes, my primary focus will be learning marketing. Understanding and getting better at marketing is crucial for any indie hacker, as it's often required to transform a side project into something bigger.

Whether it leads to success or failure, every step forward is one step toward. I'm excited to see where this path will take me and to share the journey's story with you all.

Takeaways: Your journey should be one of continuous iteration and exploration. While developing your project, never underestimate the power of marketing—it's essential for gaining traction and turning your ideas into reality. To realize your full potential, embrace both the technical and business sides.

Conclusion: An Invitation to Join the Journey

As this chapter of my journey unfolds, I invite you to come along. I'd love to navigate the ups and downs of indie hacking together.

Join me on Twitter where I share real-time updates, insights, and milestones of this journey, all in the hope of inspiring some of you to embark on your own adventures. 👀

Explore BooksByMood

Curious about what I’ve been working on? Check out BooksByMood, my first indie project that helps you find books based on your mood. 👇

Arian grew up in New York and studied at MIT. She worked in finance for a few years, then built her own ecommerce Marketplace startup with a friend.

Along the way, Arian went through the South Park Commons startup accelerator, and she now leads their New York City branch as a partner.

We talk about technology, startups, and her journey from finance to building products.

Be sure to follow The freeCodeCamp podcast in your favorite podcast app. And share this podcast with a friend. Let's inspire more folks to learn to code and build careers for themselves in tech.

You can listen to the podcast in Apple Podcasts, Spotify, or your favorite podcast app. You can also listen to the podcast below, right in your browser:

Me hanging out at the NYC South Park Commons with Arian Agrawal, the startup founder who now runs the NYC branch of the accelerator.

Some links relevant to our discussion:

Arian on Twitter

Arian on LinkedIn

South Park Commons

Many people who want to try freelancing believe that they need to have years of experience to succeed. But this is a common misconception that many freelancers have disproved.

Regardless of your industry, a helpful blueprint can be all you need to fast-track your freelancing success. This article underscores what you need to know to start a freelance web development business.

Being a Freelance Developer and Its Advantages

Getting started as a freelance web designer can be a challenging feat. But if you succeed, you can be in a high-value position in your field.

As a freelancer, you need to be capable of running your own business. This task requires self-discipline, which can be hard work. You need to implement strict and rigid rules for yourself to succeed.

To motivate you, here are several major advantages of becoming a freelance web developer.

1. High Demand for Web Design Services

The most obvious benefit is the high demand for your services. Data from Indeed shows that there are over 60,000 web developer jobs in the US as of this writing.

The high demand for web design services ensures that you always have customers. There are a lot of people willing to pay you for your skills.

2. Shortage of Developers

Another advantage is that there is a massive shortage of developers in the US and worldwide in general. The lack of web designers means that you do not have to compete with too many people in your industry to get paid as a freelancer.

3. You Get to Be Your Own Boss

Freelancing also means that you are your own boss. You have more freedom and more time on your hands than when you work for someone else.

When you run your own business, you do not have to report to anyone. It will be your choice which new clients to accept, how many hours you work, and what your rate is.

4. Attractive Earning Potential

Web designers get paid a decent amount for their services. According to the US Bureau of Labor Statistics, the average yearly pay for web developers was $77,200 in 2020.

Important Steps to Take to Become a Freelance Developer

This section highlights three crucial steps to help you get your freelance business up and running. After reading, you can start offering your web development services from home with ease.

1. Choose a Niche

It is impossible to be equally good in all areas of web design. Choosing a niche lets you focus your time and effort on narrower tasks.

Having a niche also allows you to become an expert who can address the needs of one group of clients. Doing so is much easier than learning a little bit of everything about different businesses or website styles.

When choosing a specialty, it is not enough to be interested in a particular niche. You must know if there is a demand in this niche for websites. Ask yourself if people are willing to pay for it.

This step is crucial for anyone starting a business regardless of your industry. You first need to know the marketability of your business idea.

What can help you complete this step is researching the market and looking for opportunities.

For example, if you like collecting toys, you can work for online stores selling rare action figures. Your selling point could be knowing how toy collectors think and what they want in a toy figure online shop.

If you were a grade-school teacher, you could help build websites for educators. A website can help them save time, market their teaching services better, and earn more.

If you are an activist, reach out to organizations. Check and see if anyone needs a website to promote their advocacy.

You can research online and visit communities on Facebook, Reddit, or Quora. These platforms are where people from different niche markets often hang out online.

Read their questions, look for their pain points, and determine the kind of product they need. After reading up, you can tailor your web development services to solve their problems.

2. Build a Portfolio

Getting that first project can be one of the most challenging things for many web designers. It can be tough to convince a prospect if you do not have a portfolio. Luckily, there are ways to secure your first gig without any experience.

You need to have a web design portfolio that serves as your website. The site should tell clients what you do and how you can address their needs.

You must include feedback from former clients and several of your past outstanding projects.

To get your first project, you may need to build a couple of websites for free.

In your chosen niche, look for an organization that urgently needs a site and do it for free. In exchange, you ask them to submit a testimonial on how your services helped them.

Looking for a client can be easy since you are offering free work. They will have nothing to lose if they choose to accept your offer.

You can use web development platforms like WordPress to finish your work faster. You need to keep in mind the user experience, accessibility, and conversion rate optimization as you work.

Aside from these three factors, you should also remember to keep your client's needs at the forefront. You should design the website in a way that addresses their specific needs.

Some clients may worry more about conversion than user experience. Some may have other site concerns, like search engine optimization (SEO). Regardless of what they need, you must ensure that your output delivers.

If you do not want to look for a client, you can buy domains and build websites yourself. This step can be a faster yet more expensive way to get your business up and running.

If all clients want to see is your skill, then this can be a good solution. Unfortunately, you will not receive any testimonials if you choose to buy domains.

Once you finish two to three projects, you can begin looking for your first paying client.

3. Search for Clients

Now that you have a portfolio that showcases your skills, you can begin searching for clients.

Social media can be helpful when looking for clients who will pay for your services.

For example, you can market your new business by using Facebook Groups. You can either make a new group or join an existing one.

Facebook groups are made up of people with common interests. Whatever niche your business is in, you can likely find a relevant group on Facebook.

Using social media to market your web design services does not only help you find clients. It also allows you to know your target customers better. It informs you what their problems are and what solutions they want.

Another way to meet clients is by speaking at events. Attending events about web design can be a great way to establish credibility. It can also be an effective way to build a network of contacts.

The downside of this approach is it could be challenging to get invites to events, and it involves a high level of preparation.

If you are not keen on socializing in person, you can look for clients through online job boards. Regularly visiting these sites can help you get more work. Try visiting Smashing Jobs, Mediabistro, Coroflot, or RemoteOK.

You can also try freelance marketplaces. Make sure to create a detailed profile that informs your clients of your specialties and how you can help them.

When creating a profile for freelancing sites, do not forget to include your skills, experience, and portfolio.

Wrapping Up

Becoming a freelance web designer requires a significant investment of your time and effort. But the result is a career that provides you with the freedom, flexibility, and income you want.

So push yourself to learn and increase your skill set to offer the most value to potential clients.

Learn the answers to these questions and more in an entrepreneurship course we just published on the freeCodeCamp.org YouTube channel.

Business Insider wrote an article stating that book version of this course called 101 Crucial Lessons They Don't Teach You in Business School was voted as the #1 most popular business book of the year by Business Insider readers.

Chris Haroun teaches this course. Chris has sold more than 1,000,000 of his online business and self improvement courses in 12 languages in 196 countries and his courses have been profiled in Business Insider, NBC, Inc, Forbes, CNN, Entrepreneur and on other business news websites.

This course is an amalgamation of business advice that Chris has compiled from his many meetings with successful business people over the past two decades as well as observations of why the founders of giant tech companies have become incredibly successful.

The course also includes a free workbook for you to use as you go through the course.

Here are the sections in this free business course:

• Section 1: Relationships Are More Important Than Product Knowledge
• Section 2: Be Long Term Greedy
• Section 3: Avoid Burnout
• Section 4: Create Off The Charts Confidence; Wear That Super Superman Cape!
• Section 5: Ethics. Use It or Lose It
• Section 6: Every Battle is Won Before It Has Been Fought
• Section 7: Goal Setting
• Section 8: Happiness is...
• Section 9: Legal Stuff is Important
• Section 10: Management Best Practices
• Section 11: Navigating Corporate Politics; Swimming with Sharks
• Section 12: Only Take Advice from Successful People
• Section 13: Only the Paranoid Survive
• Section 14: Risk Taking
• Section 15: Sales Best Practices
• Section 16: Think Different
• Section 17: You Be You

Watch the course below or on the freeCodeCamp.org YouTube channel.

According to freeCodeCamp’s 2018 New Coder Survey, 40.3% of participants want to build a business of their own, either as a freelancer or as an entrepreneur.

If you are in that 40.3%, then this article is for you. If you are in the remaining 59.7%, you might still benefit from it. Give it a try.

This is not a “dummies’ guide to strategy and design” or a “strategy and design 101” article. This article is written specifically for developer folks. Not just software developers but also no-code developers. (Shout out to my ODNC1 fellows who encouraged me to write this piece.)

Table of Contents and How to Use this Guide

This is a long article. Actually, this is not an article – this is a guide. So, it's better to read the prologue and give the guide a quick scan. Then start applying the methods rather than reading the whole text and trying to internalize it.

You can only internalize this guide by applying it.

Getting Started

1. What is Strategy?
2. The Main Components of a Business Strategy
3. Strategy, the Scientific Mindset, and Software Development

A Rough Guide to Strategy and Design for Developers

1. How to Define Your Purpose
2. How to Develop Strategic Hypotheses
3. How to Test Strategic Hypotheses
4. How to Design Your Product
5. Conclusion

The Structure of the Guide

This guide is structured to make the actions you should take very clear. So, in every section, you will be given a little bit of context and then action items.

It is essential that you read the context in full before taking action so that you can see the part the action plays in the bigger picture.

Getting Started

I know that strategy and design can sound, well, fluffy. I know that because I have been there.

I am an engineer. I love physics and mathematics. I love breaking challenges down into their parts and overcoming them one by one using logic. I love to work with hyper-realists who think rationally. I love viewing processes as functions that take certain inputs and spit out certain outputs. I love all of that and more.

However, I am also a strategist and a designer. I know that not everything has natural reasons to be so.

Sometimes they are purely based on choice. I know that people are irrational, though still predictable. I know that people value social and emotional benefits as much as functional benefits, if not more.

So, I know that bringing together strategy, design, and engineering mindsets dramatically increases our chances to achieve whatever goals we have. I witness that day in and day out thanks to my job at ATÖLYE as its Ventures Director.

But if you don't believe me, I hope you will believe in the data. This might be one of the saddest statistics you might ever see (!):

Top 20 Reasons Startups Fail - CB Insights

CB Insights’ findings are chilling. 42% of startups failing simply because they are not needed.

Imagine this: You quit your job, and maybe risked your reputation. You raised funding from your friends, family, and investors. You started living on a very low budget. You worked tirelessly, 12 hours a day if not more… and after a year you realize there is no need for what you have been grinding and hustling for all that time. Isn’t that chilling?

Strategy and design help you minimize the chances of failing. How? Good strategy and design focus us on building lasting businesses based on customer needs and/or wants and competitive advantages. Also, they inherently mean testing hypotheses and iterating constantly.

They are great tools to find our way out of complexity… but let’s leave praising strategy and design aside and get practical. We will start by agreeing on a definition because the meaning of strategy is highly variable.

What is Strategy?

Strategy is one of those concepts that everybody understands when they hear it but no two people understand the same thing.

Very generically put, strategy is a high level plan to achieve pre-determined goals. However, in a business context it has a more specific definition. Here is how I would describe it:

Strategy is a set of hypotheses that describe a set of integrated key choices, key actions and a progress measurement framework for achieving business objectives.

We develop strategies because we believe achieving objectives will help us realize our purpose.

The Main Components of a Business Strategy

Below are the most relevant main components for a startup founder at the beginning of their journey.

If we were to consider an established company rather than an early stage startup, we'd have to think about competitive advantages, core capabilities, management systems and – depending on the type of business – a few more specific components.

The key thing to remember is that however many components there might be, they all have to be integrated with the main components listed below.

The purpose for doing business

What drives you to do business? What impact and value do you want to create? What do you want to get in return? How is it measured (directly or indirectly)?

I list this first because it is the basis, ideally, upon which all your decisions will be made. When you are in doubt or things are too difficult to figure out or mutually exclusive options are similarly attractive – you will come back to the basis and seek guidance.

Market definition

Who are the customers, users, competitors, regulators, and other main actors who take part in the value exchange you want to create?

Market definition and Value proposition are extremely intertwined. That is why I list them one after the other. Without a sharp, even discriminating, (as in consciously choosing not to compete in certain markets and thus choosing not to serve certain customers) definition of a market, we cannot define meaningful value propositions.

Say that you are developing an analytics product. If you are focused on mobile applications then you are "discriminating" against web applications and your value propositions will be shaped with this choice.

Value proposition

Your value proposition is what you have to offer to your customers (and, if you are thinking more ecosystemically, to all the actors you have in a give-take relationship) in exchange for the value you ask from them.

For example, customers pay you money, users might provide you with data, partners might help you reach customers, government supposedly ensures a fair market, and so on.

Value propositions are not the same as products, features, or services. An easy way to distinguish value propositions is to answer the question, "How will our customers benefit from using our product?" (And, again, you can extend this question to all the key actors in your market by asking "How will this key actor benefit from being part of the value equation I'm creating?")

As this question implies, it is not the product itself that your customer is after. It is the benefits that your customers are hoping to get out of using your product.

Meaningful Differentiation

Why will anyone choose your product over all the alternative products or ways to get the benefits they seek? What makes you a better fit for them?

How do you create that fit? How are you doing that differently from your competitors? How long can you hold on to this difference?

What can you do to keep the competition away? How might you make the competition irrelevant to your customers?

As Jobs to Be Done (JTBD) theory explains, jobs (the things people are trying to get done using products) do not change. The products keep changing but jobs stay more or less the same.

Take commuting, for instance. The way we commute has been in a constant evolution that brought autonomous electric cars to our lives. However, the job of getting from one point to another has been with us from the very beginning.

With every step in this evolution, more and more nuances are addressed. However, at the heart of it the job is still the same.

So, the differentiation lies not in inventing new jobs but in finding new and meaningful ways to help with getting those jobs done.

Price is just one way to differentiate. Features, benefits, the overall experience, the nuances you choose to address – there are countless ways to differentiate.

However, meaningful and lasting differentiation is hard. It's hard because copying is easier than ever. It's hard because developing software (unless it's something super advanced) is getting easier and easier. Good design is more accessible than ever.

So, we need more than design and technology to sustain a meaningful differentiation. More on this in the design section.

Strategy, the Scientific Mindset, and Software Development

Strategy is about developing hypotheses from a mixture of deductive and inductive reasoning and then measuring progress against objectives.

It requires us to break things (markets, value propositions, differentiation, and so on) down to their parts (customers, buyers, users, partners, regulators, products, services, experience, branding), understand them individually, and then melt them together to create a coherent whole (a business).

It's extremely analytical and holistic at the same time. I find these aspects of strategy very similar to the scientific mindset.

This similarity also reminds me of the role of a software architect. They are tasked with a similar challenge. The level of uncertainty and complexity, though very different in their nature, are similar.

They both have some level of information available to them to make decisions but never the full picture. They both need to develop hypotheses and test them before fully committing to a particular approach.

Crucially, they both are aware that there is no one way to achieve the objectives, which means they are making choices. So, they want all the other things that will be built on top of their strategy/architecture to be coherent with their key choices.

And this similarity makes me question why so many engineers and developers distance themselves from strategy. Probably because of the way we talk about strategy and position it in companies, but also in education. That's very sad and needs to change.

A Rough Guide to Strategy and Design for Developers

Definitions are important. They help us develop our own language and communicate. Now that we have our language in place, let's get into execution.

The guide below is rough by design. It's rough because I don't want to put too much emphasis on the guide itself.

It's rough because you are a developer trying to get something off the ground. Not a strategist or design manager in a company setting.

It's rough because it aims to hit the sweet spot which helps you get 80% of the results with 20% of the effort.

And it's rough because this is my first attempt to customize it for developers and I want to test this hypotheses before fully committing to it. So meta, isn't it? :)

How to Define Your Purpose

Start from within

What are you hoping to achieve for yourself? A side business? A learning project? The business of your life?

Describe a day in your life assuming everything went great and you have succeeded. What does a usual day look like?

Continue with others

Again, imagine everything went great and you have succeeded. What impact did you create on your customers', users' and partners' lives with that success? How did things change for them?

Action: Summarize and posterize. Try to boil everything down into a paragraph that describe a future state for you and your customers. Rewrite and rewrite it again.

Pay attention to every word you use and make sure that the paragraph sits comfortably with you. Then print it out and keep it visible in your working environment.

How to Develop Strategic Hypotheses

Start with customers

Wanting to serve as many people as possible is great. However, it is very difficult to create a product that will serve a majority of a big market from the first day.

There are many reasons that will prevent your target customers from changing their way of getting the job done: Switching costs, human resistance to change, even inertia can be considered a reason.

So, if change is so difficult, what should we do? We start with a super niche group of people who are most open to change. So, naturally, that's a very small part of the potential market. That's how it's meant to be.

Thinking in terms of Blue Ocean Strategy is very useful for identifying people who are most open to change. Ask yourself:

• Who are most dissatisfied with current solutions? Why?
• Who needs a solution but isn't finding any of the options are good enough? Why?
• Who is disregarded by current market leaders? Why?
• What are some common attributes of these people?
• Do I know anyone who fits to this description?
• Where can I find more people like them?

Then go talk to them. This article has ALL the things you need to know about the Jobs to Be Done approach.

Action: If you want something a little simpler for customer interviews, use this article about the idea of "Push and Pull" to clarify who your customers are and what they need.

Identify your value propositions

We value practical benefits. We expect products to provide practical benefits first. For sure.

However, especially in software, practical benefits are not enough to meaningfully differentiate ourselves. They are easy to copy. “This is the way the tech industry works”. So, what can we do about it?

Luckily, people are social and emotional beings. So, we can add social and emotional benefits to the mix and provide more value as well as making it more difficult to be copied.

Social and emotional benefits are the things that make people say "yeah, it's similar but not the same...".

Think about a product you really like. Not just how it works but the feeling of using that product. Then compare it with an alternative that gets the same practical (functional as it is called in the theory) job done. See how you feel about it.

So, how do we know what social and emotional value to provide? First, it comes from your interviews. You need to pay attention to things beyond functionality.

Second, it comes from your choices. Yes, your choices. There will be lots of options for providing social and emotional benefits. You need to choose ones that will sit well with your purpose.

Action: Use Bain's Elements of Value to identify your options. They have a B2B version, too.

Define your position

Now, you will make things crystal clear by defining where you stand. You'll do that by defining polarities.

Polarities help because that's essentially how we tell things apart. Think of the role of contrast in our ability to see. Similarly, we need a clear contrast for things we do and don't do. This will help us clarify our scope and also crystallize our value propositions for the super niche group of people we are targeting.

Action: Use the More About Less About technique to define your position.

How to Test Strategic Hypotheses

Testing, contrary to what you might expect, is more of an art than science. Yes, it is at the heart of scientific method, but designing tests requires imagination rather than analysis. Analysis only comes after you conduct the test.

Let's look at a very high level overview of the test process:

1. Decide what to test and what results count as success. In other words what numbers and/or feedback would show that your hypotheses are valid.
2. Devise a test from which you can trust the results and can execute as cheaply and quickly as possible. This is where you need more imagination and divergence (expanding options without judging them) rather than analysis.
3. Run a few dry-runs to mitigate failure due to simple mistakes. Learn from dry-runs and iterate.
4. Run the test and closely monitor the results to learn from them.
5. Analyse the results and decide the next steps according to your learnings.

Testing is extremely tactical and context-dependent. That is what makes testing more of an art than science for me.

That's why, instead of following a strict process, I believe that you'd be better off getting inspired by the following articles and finding your own way of testing. Much like an artist would do.

Actions:

• Learn about the concept of Riskiest Assumption Testing (RAT).
• Identify your riskiest assumptions. (p.s. I don't agree with the notion of MVP in this article. I strongly suggest you disregard it. I wrote about how I like to think of MVPs here.) Assuming you are at the very early stages of your endeavor, it's more likely that your riskiest assumptions will be about the problems, needs, and wants of your customers and how your product can help them.
• Choose the type of MVP from this list that would be the most suitable for testing your riskiest assumptions. Build a rough version of that MVP. Do dry runs and then launch the test.

How to Design Your Product

Now that you've developed strategic hypotheses and tested them, it is time for you to build things, right? Wrong. Not so fast.

One of the biggest blind spots I see in developer-led startups (software, low-code, no-code) is Design. Design with a capital D.

What do I mean by "Design with a capital D"? Often, the design work in the software industry is reduced to how things look and feel. Sometimes, people go beyond that and add the simplicity element to the mix. Making things easy as well as beautiful.

But that's not all there is to designing products. There is more. Much more.

How much more? Well, so much more that I wrote the article below to describe my personal principles for product design and management. I don't think you need to read it or create your own principles, because I assume that your aim is to start your own business. Not to become a product designer or manager.

However, I'd highly recommend reading the Design and Brand Strategy sections of that article if you are curious about what I mean by "Design with a capital D".

Let's leave the philosophical discussions aside and get practical. Below is an overview of the process I recommend for designing your product. I have summarized the philosophy behind this process in the article above:

Unless we have to invent something new, we are much better off using patterns, heuristics and principles without forgetting to adjust them to the problem at hand. This way, we’ll give people (both users and business owners) what they want: Familiar Done Differently.

Consider your customers' context

Start with considering your customers' immediate context when they use your product.

What's happening? What happened before? What will happen after? What are they trying to get done? How do they feel in that situation? In short: Don't focus on the "why". Focus on the "when".

Think about related products

Consider the other products they use to get things done in relation to your product, as well as competitors' products.

How do those products work? How do they talk about themselves? Any common patterns in their design, branding?

If your product plays well with related products and if it is familiar to your customers, then it's more likely they will adopt your product.

List out your product's features and choose the most important ones

It's important to list the features your product will have and then choose yourself a few North Stars.

You'll "steal like an artist" from these North Stars.

Say that your product has a question and answer feature. Quora would be a good North Star as they are all about Q&A's and have been around successfully for many years.

You can also choose North Stars for your branding, look, and feel. The key is viewing them as a solid starting point rather than things to imitate.

Dig deeper into your North Stars.

If you've chosen a North Star for a specific feature, then use it several times. Try to break it. Take notes on how you'd do something differently and why. Do that for all your North Stars.

Start your design with a user flow, not with a wireframe or any visual technique. One of the biggest mistakes you can make is to start designing the user interface (like screens). As I like to say, “Remember, we are not designing things. We are designing behaviours.” So, we must start with actions rather than interfaces.

Break your product down into features

You will need to create user flows for each feature, but how do you break your product into features?

Luckily, Ryan Singer has given a demonstration of how he uses the shorthand for UI and how he breaks things down into their parts. Watch the entire video.

Use Ryan Singer's shorthand for UI to design user flows.

This will save you hours if not days. You may have ideas for the interface while doing the user flow. Just scribble them somewhere and take a note but never focus on them until you are done with the user flow.

Test your user flows

Once you have a rough first version, test your user flow(s) with a few potential users.

Simply, first give them a quick walk through. Then ask them to critique it by thinking out loud.

You may ask them questions to kick start the conversation: "What did you like about this? What would you change? Why? How would you change it? What is this flow missing?" and similar other questions.

Improve your user flow(s) accordingly.

To design the interface (how things will look) go back to your North Stars. But before that you need to establish an overall look and feel through choosing colors and fonts.

First, choose a font pair from this list. Try to make it familiar to your customers but also try to choose a pair that gives the feeling you want your users to have while using your product.

Next, choose a color palette. Try to choose a palette gives the feeling you want your users to have while using your product – but also try to make it different from your competitors.

Action: Use this article to choose your main colors. Then use this website to create a color palette based on your main colors.

Design your interface in detail

Now, you are ready to design the interface in detail. This is where stealing like an artist will come into play, again. Since, you've already made color and font choices, you can focus on the layout.

Go back to your North Stars and base your interface design on their existing designs. Don't change things unless you have clear reason for changing them. Check out tools like Mobbin for further inspiration.

Remember – design doesn't end with the interface. An extremely crucial and very much overlooked element of Design is the copywriting. So much depends on the language.

It's a great contributor to usability if it's clear enough. It gives your design a deeper character if you can strike a chord. It allows you to test things faster, easier, and cheaper. It's extremely important. I highly recommend investing serious time in it.

Action: Read the basics of microcopy, first. Then continue with writing your copy based on these rules.

Go back to strategy

In the endless iteration spiral we call building a startup, at this step of the Design process, I suggest you take a step back and go back to your strategy.

Specifically, go back to your Purpose and Positioning and see whether what you are building actually fits them. Of course, you don't have to and shouldn't wait until this step. However, make sure you take a critical view of everything and see if you are still after the thing you set out to achieve.

It is fine if there are changes. It would be useless if there were not any changes after so much testing and learning.

However, if the very essence of your purpose and positioning is changing then it's a strong sign that you need to rethink things thoroughly. Otherwise, you might find yourself constantly and mindlessly "pivoting" toward whichever direction might seem interesting at any given time.

This will derail you from the long-term vision that you need to strive for. If you don't have such a vision (which doesn't need to be groundbreaking or world changing) then it'll be very difficult to persist through the challenges in the short-term.

Conclusion

Like any other guide, this guide is incomplete, too. Trying to provide a complete guide is almost an oxymoron in itself.

The purpose of this guide, very similar to an architecture or a model, is to provide enough guidance so that it captures the essence of the reality in the simplest way possible.

It is up to you, the entrepreneurs, to figure things out where this guide falls short and creates uncertainty. That, coincidentally, is the ultimate skill entrepreneurs need to have: Figuring things out under extreme uncertainty.

So, I hope this guide will help you with removing some of the uncertainty you are dealing with and accelerate your journey for achieving your purpose.

Let me know what you think and how I might improve this guide. It's an early prototype of something bigger I'm working on. So meta, I know.

In this article I will share the story of how I became CTO of a software as a service (SaaS) company. It all started about 3 years ago when I was going to hackathons for fun.

At the end of the article you can find some tips and advice I would give to aspiring entrepreneurs as well as some reading recommendations.

It was – and still – is a wild ride!

Our company team (we now have 8 more employees!)

Although I have a good knowledge of entrepreneurship, don't just take my advice at face value. Learn from books, from other entrepreneurs, and from your environment in order to triangulate how best to act in a given situation.

My First Hackathon – Which I Lost

It might sound off, but I had no interest whatsoever in entrepreneurship or business 3 years ago. I was more of a researcher in spirit than an entrepreneur.

From studying memory at the molecular level, to helping schizophrenic patients learn better, or predicting consciousness recovery in patients with traumatic brain injuries, my mind was deeply focused on the frontiers of science.

However, I had a deep passion for programming and for finding ways of building tools that didn't exist before.

Like the time I built a brain computer interface that was compatible with a Transcranial Direct Current Stimulation electroencephalographic headset (that is, it stimulates the brain by giving shocks and lets you control a kind of ping pong game). I just love to build stuff.

Cutting edge graphic from my brain computer interface

So three years ago, my brother wanted to find a new job as a software developer. We figured out that we could attend hackathons to help him get noticed by recruiters.

It was my first hackathon so I was pretty excited to spend two days building something. Our team was composed of myself, my brother, his friend, and one more member (who didn't do a lot, but was still there).

It was two days of heavy coding, and at the end we came up with a pretty cool algorithm to pattern match people with jobs given some characteristics.

On top of that, I met nice people that, like me, love to build stuff. We ended up among the finalists and came in fourth during the final presentation.

Here I am trying to figure out why the clustering is not working

What I learned From My First Hackathon

It was a bit of a bummer not to win, but I realized something important then: except for the participants, no one really cared what I coded during these two days.

It was mostly the presentation of what we wanted to build that mattered. We should have spent a bit more time making a very compelling PowerPoint instead of focusing on the development of an algorithm!

It was a fun learning experience, but my brother didn't get a job out of it – so we were back at square 1.

My Second Hackathon – in Which We Won a Special Prize

I was ready to take a small break from hackathons for a while. However, my brother decided to sign us up anyway. So his friend and I to go to another hackathon right after the first one. I would have refused as I had other stuff to do, but he had already paid the sign up fees.

This hackathon was a bit bigger than the previous one and there were still a bunch of recruiters there. We figure that this could be our second shot at getting him a job.

The theme of this hackathon was open data and environment. So we were in a good position to make something cool with my background in machine learning.

A lot more people where present at HackQC which was nice!

Knowing that the presentation was everything, we decided to be a bit more strategic with this hackathon. We combed all the different prizes we could win and selected the one with seemingly the least competition. The project would deal with the prediction of combined sewage overflow.

We then split up our team of four (another friend of my brother's joined in) so that half of us were working on the coding and the other half on the presentation.

The name of our team was “Égout Quebec” which translates to Sewage Quebec (branding wasn’t our strength). Here is the excerpt from our competition log on DevPost in French:

ÉGOUT QUEBEC permet de prédire le débordement des égouts et d’en avertir les amateurs d’activités aquatiques. Ainsi les personnes désirant aller faire des activités aquatiques pourrons éviter les zones polluées par les déversements d’eau usée. De plus, des conseils seront dispensés aux gens des différents quartier, de façon à réduire les risques de débordement.

ÉGOUT QUEBEC utilise une technologie basée sur une intelligence artificielle. Celle-ci peut déterminer lorsque les égouts déborderont. Ses analyses et calculs sont basés sur des données disponibles sur le site de donnée Québec. Finalement, les différentes villes auront avantage à utiliser ÉGOUT QUEBEC.

Grâce aux prédictions et aux analyses de la plateforme, il sera possible de concentrer les ressources de la ville aux endroits les plus problématique.

All this basically translates to “we found a way to solve the problem using a random forest + a bunch of data”.

We actually ended up winning a $1000 prize, which was huge at that time! We even got a nice glass trophy in the shape of a water droplet. It was less challenging than the previous hackathon because we had a better plan for what we needed to do.

Here we are at the podium (still technically fourth place though).

What I learned From My Second Hackathon

This hackathon made me realize that presentation was indeed important. But I also discovered that focusing on problems that people don't find interesting is a good way of increasing your chance of coming out on top!

Winning felt good and I was ready to take my share of the $1000 prize and call it a day...

My Third (and Last) Hackathon – Which We Kinda Lost Again

However, the $1000 prize came with an automatic fast-track to the semi-final of yet another hackathon! This one had higher stakes with a $25,000 prize.

We met up at a coffee shop to figure out if we wanted to split up the money or to use it in order to take our project to the next level.

After looking at the other participants' projects and the rules of the competition, we decided that we actually had a good shot to at least get to the finals. This would unlock some more funding which we could use at will and would give us a nice trip in the summer to a lake in Ontario.

This hackathon wasn't like the others in the sense that it ran for the whole year. It was more of a take-home hackathon, which was great for me since I didn't have to do that insane two-day time crunch routine over a weekend.

We changed our name to EGC Labs and managed to get a website together to advertise our sewer overflow prediction solution (which was working surprisingly well). We then went to the semi-finals competition in Ontario, and to our amazement we moved on to the final!

Here we are as finalists! I didn't go all the way to Ontario for the semi-finals, though.

This was great! We had a very good shot at winning more than a small stipend, and maybe starting a business out of this thing. To help us bootstrap ourselves, Aquahacking generously gave us $2000 and École de technologie supérieure (ÉTS) gave us $1000 for travel expanses.

However, we still didn't have any customers for our solution, which was a bit problematic.

We tried to contact a bunch of cities in Quebec in order to see if they would be interested in our sewage overflow application. We had some pretty advanced discussions with a few cities, however their process was so slow that we got very near to the finals without any concrete validation.

The final was a 5 minute presentation in front of a big audience with some investors present.

Things got a bit more tricky when we got closer and closer to the presentation date. The rest of my team started to become less and less responsive. I ended up not being able to reach my brother's friend who had joined at the HackQC competition.

This quickly followed by my brother losing all interest in the competition and focusing on other stuff. We were left with myself and my brother's other friend (Félix) who joined in the very beginning.

He was also starting to slip out of the picture because nothing seemed to be moving forward, as I was the only one left coding. I wasn't very interested in that project either, however one thing I hate is half-backed projects (even more when they are public).

Our faces were plastered everywhere

I felt that it would have been a waste to stop so close to a conclusion. So I took it upon myself to jump start the project by coding the app's user interface, getting some branding going, and creating our business cards for the event.

As things started to pick up Félix started to become more and more involved (which was a blessing because he was the one pitching!).

We were still finalizing the PowerPoint the night before the presentation in the hotel room. After all this hard work we had something pretty solid (by my standards at the time, anyway). We've ended up winning fourth place in the competition:

Us receiving the 4th place trophy (again) with no money whatsoever associated with it haha

We went from a team of 4 to 2 people and were able to get that far. However, it was exhausting since I had to do so many different things that were not in my core zone of competency.

What I learned From My Last Hackathon

I learned two very important lessons during that adventure:

• Having motivated teammates is the most important asset in any endeavor. If we had everyone pulling their weight we would have had more chance to win!
• For a startup, having clients is the ultimate measure of success. We did everything right, except making sure that we had paying customers. In the end this is what kept us at 4th place.

We won a big $0 in that part of the competition, and once again I thought that was it. I had coded some cool Flask applications, went to the final of a big hackathon, and learned some valuable lessons. Until I realized...

How I Learned About Entrepreneurship at An Incubator

Being part of the finalists of Aquahacking automatically gets you a spot in one of the provincial incubators for startups, which happened to be Centech for us in Québec.

I didn't really know what an incubator was (except in a biological sense), so I wasn't particularly excited. We had to make a pitch for our "startup" to the incubator panels even though we had a reserved spot. I let Félix do it without me, as I had other stuff to focus on.

Centech is inside an old planetarium so it has that funky circular shape. It's a pretty cool place.

At first I didn't go too often to the entrepreneurial classes and I was starting to think that this whole hackathon-thing was becoming a huge time-sink. However, I stuck to it because Félix was very motivated by the whole experience.

So I decided to give it a serious shot. I started attending the entrepreneurial classes (which were amazing), I did the homework, and I tried really hard to make our sewage company work.

Lots of entrepreneurs in our 2018 cohort, try to find me!

Frankly speaking, it was amazing. It was genuinely fun to try and make something novel. And being mentored by people that had built incredible products that helped millions of people was incredible.

The class that I was in was also very motivating, as we had people from all backgrounds and oddly enough most of them were graduate students, like I was!

I really got the bug for entrepreneurship. It was like doing research, except I could directly see the results of my experiments in a matter of days. It was like combining the pleasure of discovery I had while doing an experiment with the freedom of programming for a side project.

However, after reading the books and learning the material, I realized that we'd done everything upside-down for our budding startup. We had built the technology before even validating that there was a sustainable business out of it (silly us!).

We were ready for our very first pivot, which in entrepreneurial jargon means tweaking your business in a significant way in order to not crash and burn.

How We Made Our First Pivot After Learning that Our Startup Idea Was Doomed

Our combined sewage overflow predictor was working great. However, no one was willing to spend money on it.

We were targeting cities in order for them to be able to proactively do something about the overflow of raw sewage into their rivers (which, by the way, is a worse and more frequent problem than you think). But these cities had such a long cycle to sell to that we would never be able to grow this business.

One thing that we realized during this project was that the majority of the data that was available for the competitions were in a very bad shape. It took us many hours of cleaning and we had to develop some very custom toolsets in order to make the cleaning efficient.

We had also talked to a few of the judges at Aquahacking and what they were most interested in was the portion of our business that related to data cleaning.

So that was it! We would become a data cleaning company. For about three weeks we were frenetically searching for customers, making plans on how to make this type of business work, and coding outlier detection algorithms.

This would have been us inside the datasets for the rest of our lives: Photo by [Unsplash](https://unsplash.com/@mkjr?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit">mkjr / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

However, after meeting with our mentors at Centech, we realized that what we were building was a service company. Almost no data is similar, especially when it comes from different sources.

The amount of domain expertise we would have to gain in order to be efficient in one industry would not necessarily transfer easily to another industry. There was a lot of manual work involved in this and all our ideas for making it more automated were failing.

Now, there is nothing wrong with making a service company. It's a great type of company if you are very interested in your industry. But we did some amount of introspection and we realized that we weren't really passionate about data cleaning.

We were passionate about automating work and improving efficiency through technology. Building a data cleaning company where most of the work would be manual and not very efficient wasn't very exciting for us.

We were ready to make our second pivot, which would be our largest so far.

How We Made Our Second Pivot

During the Centech program we had met two other entrepreneurs that had a problem that was complementary to ours. They had a lot of validation from potential clients whose problem could be solved by technology. However, they didn't have the technical skills to make the technology required to power their business.

I had helped them out a couple of times in order to get them started with building their web application since I'd already done something similar for EGC Labs.

Helping out other entrepreneurs without expecting something in return is very common in this type of environment. The more I helped them, the more we realized that we could get way more done if we were a team of 4 instead of two teams of 2.

We went for lunch to discuss what a potential "merger" of our two ideas would look like. After discussing for a week, we decided to ditch the EGC Labs project completely, as it had the smallest chance of success. Instead we would join forces with their idea, which was called GRAD4.

That was the second pivot for Félix and me. It meant completely dropping a project that was leading nowhere and joining another one that we were much more excited about.

Félix pitching our new company instead of the data cleaning one

During the next weeks, we were absolutely crushing it. We did everything right. We officially incorporated our company. We made a few plans as to what the actual application would need in terms of functionality so it would deliver value to our potential customers. However, we didn't wait for me to complete it to start selling it!

The other two co-founders were already on the road talking to people who'd showed interested. They were gathering checks for a 1 year subscription to our platform, which didn't exist yet. The $500 yearly subscription would start when we launched the product and we were very upfront that we were in the process of building it.

Getting people interested in your project is one thing, but getting paying customers before building a SaaS app is the holy grail of business validation. By doing so we were able to get about 15 checks that would help finance the development of the product.

We also won a $1500 elevator pitch competition around the same time because Félix was very focused on practicing his pitch.

All of these small wins compounded during the program and we ended winning a $15,000 prize at the end of the incubator called the Unicorn prize.

This was great, but more importantly we secured a spot in the next stage of the incubator which was the Propulsion program. This would secure us an office and some additional perks that would help our company succeed.

Cozy office in the basement of Centech. It was nice, but there was lots of noise because of pipes. You can see a wild cofounder working through the night.

What I Learned From My First Startup Incubator

During that part of our young company's adventure I learned a few important lessons:

• Clinging onto an idea because it was yours even though all analysis tells you it's a bad one is usually a bad idea.
• A larger founding team is more productive than a smaller one. It also allows for cheaper labor as no one is getting paid at the start.
• Asking customers to pay for an in-progress idea is not as difficult as you may think. If the pain is big enough for the customers, they are usually very supportive of having someone fix that mess. Even if the probability of success is low.
• The technology part of the business is not that important.

We Have Money, Now What?

We now had gathered a fair amount of money and we had multiple options in front of us:

• Either we keep the money and pay ourselves.
• We keep the money and don't use it in case we fail to make the app and we need to reimburse people.
• We use the money to hire people to speed up the development.

The first idea was wasteful, and it would decrease the probability that our company would succeed. The second option would just let our funds sit idle. So we decided to go for the third option.

How We Scaled Our Startup Past the Founding Team

During that summer of 2019, we made our first two official hires to help me with the development of the platform. They were software engineering interns from the ÉTS (École de Technologie Supérieure). One intern would be focused on the backend side while the other would be focused on the frontend side.

Our product was a simple CRUD application that would allow buyers who needed metal parts manufactured and suppliers of metal parts to find each other.

It was basically a sort of marketplace where buyers would create what is called a request for quote and the suppliers would create a quote to say how much they could build the part for. Pretty simple!

The technology we choose to use was the following:

• Django + Django REST API for the backend.
• React + Redux for the frontend.
• Bootstrap for the styling.
• Heroku to host both applications.
• GitHub for remote source control.

This was our setup at first. Credit: https://blog.usejournal.com/react-on-django-getting-started-f30de8d23504

Choosing the technology was up to me as the CTO, and I honestly decided to go with what I thought would be better in the long run. I was already familiar with Flask, however I knew a bit of Django too. Seeing that a lot of the functionalities I needed were already pre-built into apps made me lean toward it.

I chose React on the frontend side because I had played around with it 6 months prior and found that it was such an easier way to build applications than the traditional way I was used to.

However, in retrospect I think I would have greatly simplified the stack. I would have only used Flask for the following reasons:

• I was more familiar with Flask than with Django.
• We didn't need to have a separate frontend, as the application we needed to build was very simple. Simple templates would have been enough for a first proof of concept.

Just this would have been more than enough

However, we went with this tech and we learned a great deal in the process.

What I Learned During My First Months as CTO

One lesson I learned from this first foray into making an application customers would actually use is that overthinking scalability is oftentimes useless.

Working with what you are already comfortable with and delivering something as soon as possible is much more useful as you learn more rapidly. This is actually what is most important in a startup.

The more learning you can do (about the business, what customers want, how to talk to them) the more probable it is that the next thing you try will work.

After a few iterations, we were finally ready to launch our closed beta with the customers that had already paid for our service.

How We Did Our First Product Launch (Closed Beta)

We were able to make the first version of the application at the end of the summer of 2019 and launched it for our users (1 month later than we promised). It wasn't pretty and it was barely working.

We had to babysit our users throughout the whole process and the buyer section of the application wasn't usable. We had to do the work manually for all our buyers while the suppliers were able to create quotes.

What was great, though, was that we continued to be able to get checks from people who were interested which helped fuel development. We made a few mistakes on the hiring side, though. We hired a friend of one of the founders who, although experienced, was a jerk to the other more junior developers.

This was the first firing I had to do, and I'm glad I did it. Creating an enjoyable work environment is much more important than technical prowess, because at the end no one wants to work in a bad environment for long.

Having people stick around for the long run in a startup environment is crucial for the company's success. I believe it is one of the reasons our startup is still alive.

As development was chugging along we realized that we had to structure the company a bit more than what we were doing. Thanks to being next to so many startups and successful companies at Centech, we could learn from each other.

During that year, we focused on getting financing going (this is a super important part of business and should be prioritized). We also focused on getting some sort of marketing going, making actual designs that made sense instead of winging it, and making sure our team was staffed by full-time people instead of only interns.

We also moved from the basement of Centech to an office space with windows on the second floor which was actually pretty nice! We maxed out the capacity pretty quickly, though, and the founders had to start working in the dining area of the building so that the employees had more room.

This was way too crowded in retrospect, but at least the view was nice

What I Learned From My First Launch

I learned a great many lessons after our first launch:

Don't do an official launch. It's useless. We put so much pressure upon ourselves to impress the paying customer with a pompous launch, and we were afraid that they would be mad at us if we didn't deliver.

The truth is they didn't really care. When we sent an apology email saying that we had to delay the launch no one complained. I'm pretty sure they were actually amazed that we were able to get something up and running so quickly.

Even if you have paying customers for your SaaS application, prioritize doing manual work over building an application. In retrospect, I would have made a simple form where the buyer could upload a Zip file containing the request for a quote which would be sent to the founders' email address.

We would then send out this request manually to the manufacturers we knew would be interested in this type of work. That would have delivered value way faster to our users and released the pressure on development.

It would also have validated a lot of hypothesis we had that would have accelerated the development work.

Stay focused on very few things and make sure that this focus is explicitly written down somewhere. At some point I was building a blockchain-powered smart request for quote because it was hyped up by one of the co-founders who knew someone working with blockchain technology. That was a solid waste of time and I'm glad I killed that project soon after.

We were starting to pick up steam and we finally had something that we could show the world. It still wasn't pretty, however customers saw the value in what we were building and we knew better what was creating value and what was not.

We were ready to open our beta to increase the amount of users in our application!

How We Opened Up Our Product to More Users

After tweaking the platform using feedback from our early users, we now had a better understanding of what exactly we needed to build. We were now ready to increase the amount of people using our platform and start to increase the output of the sales (which the founders did).

This put more pressure on our application and we started to experience downtime. We knew that we had to improve the way we were building this product if we wanted to scale to more users.

We asked an experienced software architect, now part of the team full time (thanks Karim!), to help us out. This really gave us a solid direction to follow. Here is what we changed:

• We moved to AWS to have more control over the cloud environment.
• We moved to Gitlab to have an easier-to-use CI/CD environment.
• We added automated testing to our application.
• We started to migrate toward Material-UI instead of Bootstrap.

After improving the way we worked, we now had a fully working CI/CD setup and a more robust application that was rigorously tested. The amount of downtime we experienced was drastically reduced and developers were more confident about the changes they were making. It was a more enjoyable development experience, too.

Gitlab is a very enjoyable work environment and reduces a lot of the complexities with lots of tooling. Credit: https://about.gitlab.com/

What I Learned From My First Open Beta

During that period, I learned that the minimal viable product (MVP) phase of the product is necessary. But when transitioning out of it you shouldn't hesitate to ask for expert help.

We now had sales giving us more clients (which were still a bit difficult to get, but coming along at a constant pace) and the application provided more value than before.

We were ready to ask for our first real investment!

How We Got Our First Real Investment

We applied for a funding from Front Row Ventures which is a venture capital fund entirely managed by students and which only invests in student-led startups across Canada.

We met with the people from Front Row, and explained what we were doing and where we were going with all of this.

We ended up having to do a 25 minute pitch in front of a full panel of students who were asking solid questions about the business and the technology.

This was great because we knew that if we got the funding we would not only have the cash, but also new connections that could be there to answer questions and make strategic introductions for us.

It was great, some of these people went to the same university as I did!

Well, we ended up getting the funding and the people at Front Row were very helpful in many aspects of the company!

What I Learned From Getting Our First Funding

This was another important lesson I learned during that time: when choosing a funding partner, it's not only about the funding. It's also about how much help they can provide.

Front Row ended up opening many more doors for us and ensured that their investment had all the possible tools to succeed.

What Our Day to Day Routine Looked Like

Everything was going pretty well for us on the business side. However, the pace we were following was a bit worrisome. We were an archetypal startup where employees would come at the office from 9 to 5 and where the founders worked 80 hours a week.

Meeting on the weekends at the office to plan stuff out and clear up more tasks was routine.

I wasn't too happy with this because this type of work isn't sustainable in the long run – and I started to see signs of burn out in the others. We also weren't very structured, the documentation was poor, and we had almost no processes clearly mapped.

It was at that time that I started to read more about how to structure a company properly in order to maximize our chances of success (see readings at the end).

Then, out of nowhere, we started to hear about the possibility of a pandemic hitting our Canadian shores...

How We Reorganized When COVID-19 Hit

Some employees were very afraid of the virus and of getting sick. There were no cases in Canada yet, but some of the employees had family abroad in areas more advanced in the pandemic's course.

We started to think about what we could do and we realized that we didn't absolutely need to have people come in the office to do their work. All of the work could be done remotely just fine – it was just the culture that we'd set up that required people to show up from 9 to 5 every day of the week.

This type of schedule was directly taken from what we were all familiar with, but we realized that we didn't have to do like all the other companies we'd worked for.

We decided that we would allow everyone that wasn't comfortable going into the office to stay home. I personally decided to not show up to the office and most of our employees followed suit.

_As long as people had a the tools they needed, they didn't need to go into the office: Photo by [Unsplash](https://unsplash.com/@xps?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">XPS / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

This was great because we soon realized that a lot of the shortcomings of our company's structure were hidden by the fact that all employees were available in the office every day. Everyone was always trying to setup a Zoom meeting at random hours or calling at any time of the day to ask for operational tasks status.

We also realized that people had a hard time finding where all the information was, and many different people asked the same thing many times.

I decided to read a bit more about how to structure remote work efficiently so we read the remote playbook from Gitlab and implemented some changes:

• We removed the silos between the different teams by making all communication public and via written messages.
• We organized the documentation so that people would put their files in a shared drive instead of sending them on the instant messaging app.
• We instated a Kanban methodology for all departments, not just the people working on the technology since tasks weren't properly tracked.
• We reduced synchronous meetings by only scheduling those that were necessary and by having the results of the meetings communicated in one form or another.

This helped a lot! However, it took time before it really took hold. People were still having private messaging discussions when everyone could benefit from what was said. Synchronous meetings were still the default for a lot of people to share information.

Here are the co-founders trying to keep 2m distance in our first pandemic meetup (and photo shoot)

But it got better. By putting a lot of effort into making remote-work work, we were drastically improving our company's productivity to a level way above that pre-pandemic.

In a sense it was helpful that we were forced to experience remote work (as we were in full lockdown for a while) because it gave us the necessary buy-in from people that were skeptical that this was possible.

There was no other choice but to go all-in to remote work, otherwise the company would've just ground to a halt. We had employees to pay, so waiting the pandemic out wasn't an option.

In the business sense, we were very fortunate as our platform was useful for the manufacturing industry which couldn't do business in person anymore.

Some startups that we knew of weren't so lucky and their whole business was now impossible to operate within a very short time frame. Most of them had to close shop or do some radical pivot.

What I Learned From Pivoting to a Remote Company Structure

The first few months of the pandemic taught me some very important lessons:

Starting a startup is very, very, very risky. If you had started a ridesharing startup in 2019 and things were going fantastic for you, you would still have had to stop that business once the pandemic hit in 2020.

No matter how prepared you are, there are always risks and unforeseen events happening on a daily basis.

Working on the company is more valuable than working for the company as a founder. What I mean by that is spending time structuring the company and making adjustments to how people work in order to increase productivity is invaluable.

You can't expect employees to do that on top of doing their regular work. It's up to the founders to set up a structure that make sense and to always be improving it.

Remote work will improve your team's productivity compared to in person work (when possible) only if you take the time to make it work. Trying to reproduce an in-office way of working remotely will lead to an obvious decrease in productivity. Drastic changes needs to be made in order for this type of work to be useful and it requires a leap of faith.

We were still growing during that time as we were hiring more people to sustain our rapid pace. We also made a major pivot in how we were generating revenue by ditching our subscription-based model to a transaction fee model. This allowed our sales team to rapidly increase the amount of companies we enrolled in our application.

Our first version of the application started to show signs of not being optimally adapted given all the new information we'd collected from our customers. So we were working on revamping it with an improved design and user experience with a dedicated UI/UX team.

The Improved Version of the Application

We launched the revamped version of our app (this time without a hard deadline) and the reception was great. This is when I started to feel like we actually launched a real product and not a MVP to validate a need.

You could now see the part directly on the platform (we've used xeogl for that)!

The sales of our product increased dramatically as the user interface was great and the experience made sense to prospective users. We went on to do some more major refactoring and clearing up technical debt.

We knew that the added load on our platform meant that we needed to have something cleaner to work with. This was important as technical debt will always creep up and you can't just always build features.

We were slowly emerging from the bootstrapping phase of the company to more serious territory and it felt great. We made some more hires in the customer care and the marketing side. We improved month after month how the company operated.

Around that time, we decided to implement two systems that would improve our productivity:

Objective and Key Result system: This really switched our whole mindset from working long hours to working on objective attainment. By having concrete goals that would improve how the company was doing, it allowed everyone to focus on what really mattered.

It also allowed us to stop tracking when people were working or when they were taking vacations. As long as the objectives were worked on, it didn't really matter what the employees' workflows were (as long as they were not overworking).

EOS System from Traction: This system was a very good foundational system to ensure that everyone stayed aligned. It really improved how our meetings were structured and laid the foundations for the vision of the company.

I used to scoff at the thought of having a vision or core values. But after reading the book and implementing it, I cannot understand how we got as far as we got without one.

This aligned everyone to a level that we didn't think possible and allowed us founders to make better decisions for the company.

It now felt that we were really running at a solid pace. Every month we had major improvements or good news in the company. The whole startup thing felt easier and was more enjoyable.

What I Learned From My Second Product Launch

I learned another good set of lessons during the time of the launch:

Your job as a founder is to "elevate and delegate". At a certain point, if you are still working on the minutiae of the work you are wasting resources.

It is usually way more cost effective to hire someone else that is more competent than you to do the operational work and to move on to another position that doesn't have staffing.

By de-risking and laying the groundwork for a section of the company that is weak you are ensuring that it's worthwhile to hire someone and that this person has something to start with. This is priceless.

No one can work 80 hours a week on different job types effectively. We realized this when we were looking at what the weakest points of the company were. It was always the spot where someone that had 3 different hats was working because there wasn't enough time to do quality work.

If you are working on 3 different positions as a founder and you work 80 hours per week, it is the equivalent of working as a tired part time worker. The documentation will be poor, the process will be non-existent, and mistakes will start to show up.

As soon as we saw someone work more than 40h a week it was a big red flag that we needed to distribute the load onto someone else.

Part-time and volunteer workers are usually a waste of time. Once we were picking up more speed, we found ourselves constantly waiting for the part-time worker or the volunteer to finish their part of the work. This was holding us back so we made it a policy to not hire part time workers again.

It's different for interns though, as they have a well contained work arrangement. For instance, we currently have 3 interns working on various machine learning projects as part of their PhD. This is perfect because the work that is given to them is well balanced and we know what to expect.

Around the time of the new platform release, we started our first accelerator programs.

The NEXT AI and EcoFuel Accelerators

I didn't really know what an accelerator was at that time. However by being in two I quickly understood the difference between an accelerator and an incubator.

An accelerator's job is to give tools to an already up and running startup to accelerate their growth. On the other hand, an incubator is where startups usually begin.

One thing that is very useful in accelerators is that they provide startups they select with funding. By doing the NEXTAI and EcoFuel accelerators we were able to get $100,000 in total funding!

It was way more fast-paced than the incubator we'd been in. We had virtual classes with incredible entrepreneurs and got technical classes with researchers in machine learning such as Yoshua Bengio.

We also got to meet other amazing tech entrepreneurs living similar challenges in trying to get a startup to scale during a pandemic.

Here we are keeping the 2m distance for a photo shoot.

It's at that time that we officially founded the more "research-y" side of the company that dealt with making AI models and working on the data we collected. We staffed that section of the company with PhD students and graduate master's students (and me!).

It's also at that time that we decided to raise our seed round of venture capital (VC) funding. We made this decision because we knew that we had something great, however we were in the type of business where we needed to scale fast to deliver the most value to our customers.

The more people use the platform, the more valuable it is for the people using it. Therefore, getting funding to crank up the sales and marketing is a must. We put our CEO on that full time as it is indeed a full-time job.

Around the time when NEXT AI was ending, we had one of our first major financial drawbacks that would forever change the way we saw failure in our company.

We thought that, just like at Centech, we were in a very good position to get the financing that comes at the very end of the program. However, we were in the finalists but not in the top 3 winner startup.

This was a major blow as we thought we were very solid during the whole program.

After gathering more information about why we weren't shortlisted, we realized that there was a major communication gap between what the organizers of the program thought we were doing and what we were doing.

They didn't realize how advanced our product was and were not aware of all the cool AI modules we were building to complement our offering.

What I Learned From Our First Startup Accelerator

This is where we realized a very, very important lesson:

Other people's perception of your startup is as (if not more) important than what you are actually doing. We couldn't blame the program organizer for having the wrong perception about our company when they weren't even aware of most of what was happening with our company in the first place.

There was so much cool stuff happening everyday, but the number of things we publicly showed was thin in comparison.

This was problematic and could seriously handicap ourselves in the future. This is when I made the decision to celebrate the wins of the company publicly.

Every release of the product, I would publicly acknowledge my team's work on our social media. If we were passing major sales milestones, I would make a statement out of that. A major advance in the AI research of the company would be public within the week that it happened.

I used to hate posting on social media as it felt like I was bragging, but it was one of the most important change we've made so far. By celebrating our wins publicly, we've increased by a lot the likelihood of good opportunities coming our way. This is now a vital part of the company that we leverage every day.

With our new understanding of how to best promote the company and improve our probability of success, we applied to two other bigger accelerators (Creative Destruction Lab and MaRS) and got accepted!

The Current State of the Company

This last week of February was the best week the company has had, by far. User activity is way up and the amount of people involved in our project hasn't stopped growing. We are also in the final stretch of closing our financing round, which will allow us to accelerate our growth by a large margin.

However, it's not like it's all good and there is nothing to do now. One of the curses of starting to learn about a topic and making improvements in the way you work is realizing how much there is still to improve.

My company-improvement list on Trello never gets any shorter. Every time I finish a book, I have twenty new improvement ideas and every time I talk to a mentor, I have a dozen more. Even when I finish the implementation of one improvement, I have three more that spawn.

It's very comforting, though, to know that all of the work you put to improve yourself and your startup pays off. Also, realizing that you have created a company that can provide for other human beings is amazing.

I've made a lot of efforts to shed our old prototypical startup way of thinking. This means the following:

There Are Unlimited Vacations for All Employees

This basically means that we don't track anyone's time off. The only time I'm talking to an employee regarding vacation is when I feel they don't take enough time off.

There Are No Working Hours.

If an employee wants to work early morning or late evening, I don't really care (because I do too). As long as the objectives are reasonably met, there is nothing worthwhile to track.

There is No Bragging about the Amount of Work Someone Piles Up Allowed.

It doesn't matter. Only objectives matter. If someone is working an unusual amount of hours, we flag that to the human relations department and we initiate a proposal to find more personnel.

We Invest in Our Employees

We invest in them by buying books, courses, conference tickets, certifications or finding them mentors. Learning is a crucial part of the company's culture and it is heavily promoted. It's also very great for me because I can buy all the books I want on Amazon!

In short, I'm trying to build a company which I would have enjoyed working for. This is one of the guiding principles behind the choices I've made along the way and it really created something that I'm proud of.

My Advice to Aspiring SaaS Entrepreneurs

So that's how I ended up becoming the CTO of my company that has 20+ employees, all from doing random hackathons. It's been a wild ride and still is, but I would not trade this for any other job.

I want to conclude this section with a list of advice and tips for tech entrepreneurs (SaaS in particular) that I've learned along the way. I broke it down into subsections for convenience.

General Product Advice

Your Product is Way Less Important Than You Think

The value the customer can get from your product is what matters. If you can deliver the same amount of value to your customer in a simpler way than having a full blown application, do it.

You will learn faster and you will be able to create more value for your customers in return. At some point though, the only way to keep increasing the value you can deliver is to have a good application. At that point you should have a very good idea about what is important to put in it.

Validate the Need for the Product Before Thinking About a Solution

Spending time and effort on an application that your customers don't care about is the biggest waste of time you can have.

Validate with them every step of the way to see whether or not what you are doing is useful. Even at the expense of development time.

The Tech Stack you Choose is Less Important Than you Think

The most important concern is if you have enough knowledge to build something with the tech you choose, and if you can safely hire people to work with it.

Spending time finding the most optimal stack to work with is oftentimes pointless.

Do not Overcomplicate Your Application at First

Start with a good old monolith and gradually refactor it when needed. The monolith architecture will work like a charm for longer than you think!

Put the Minimum Amount of Features in Your App to Generate the Maximum Amount of Values for Your Customers

The fewer features you have, the less maintenance, fewer bugs, and less technical debt you will accumulate. If a feature is not used by your users, kill it and scrub it from your code base.

Talk to Your Customers

Spend as much time as possible with them and really learn from them. The knowledge you will gain will be a major competitive edge and will allow you to always deliver value to them!

At Some Point CI/CD and a Good Suite of Tests is a Lifesaver.

Not having to fiddle around with deployment and not having to worry as much that you introduced a regression in your code is liberating.

It allows you to become more productive and have a better understanding of the whole code base when you have to read test errors.

Monitoring is Super Important and Should be Implemented as Soon as Possible

Being able to know what is being used, what is the state of the application, and if there are potential problems is a must.

Not having monitoring tools is like driving in a forest road at night with your sunglasses on. It's a bit weird and generally not a safe way to get wherever you want to go.

DO NOT OUTSOURCE YOUR CORE COMPETENCY.

This advice is in all caps because I'm yelling it. If the core of your business is making a web app, make sure that you have everything you need in-house to make a web app.

Relying on outsourcing firms that don't have direct access to your customers or your reality is a sure way to mess the whole thing up. It's therefore extra important that you define clearly what is your core competency in order to not outsource it.

Artificial Intelligence Advice

AI is Great, but Delivering Value to Your Customers is Better

If you don't need AI to deliver value to your customers, don't put AI in what you give them. It will slow you down big time. However, if you validated that you indeed need some sort of AI to provide value to your customers, make that a top priority for your company.

Ensure That You are Collecting the Right Data for Your AI

This is especially important if you are working with partnering organizations as they often have no idea what is good data for a given problem. You need to figure out if the data is great for the problem you are tackling before getting more of it.

Start With a Linear Regression and Work Your Way to That Deep Neural Network with Thousands of Layers

Even if you have tasks for which you have enough data to attempt larger models, start with the simple ones. It will allow for rapid feedback on your data and will help you secure some baseline performance that can be used as benchmarks for the larger models.

Iteratively Improve your AI system and Don't Wait Until Everything is Perfect to Launch.

It's fine to label an AI system as Beta and start experimenting at a larger scale with users. This applies to any product you build, but I feel like this is worth mentioning again in the AI context as it is often forgotten.

Company Advice

Join an Incubator

The amount of coaching you will get – even from the judges before being accepted – is very important. They've seen thousands of startup ideas and they will be able to give you some very valuable advice.

Incubators are oftentimes paid by the government for every startup that they get in their program, which means it's a win-win situation for everyone.

Join an Accelerator After Joining an Incubator

This gives you additional resources and allows you to get very good coaching on very specialized parts of your business (like machine learning or financing). It is also a very good way to network!

Setup Your Core Values and Your Vision for Your Company

Having a vision is like a superpower. As soon as someone throws in that blockchain idea for the nth time you can throw it right back by saying that it doesn't fit the vision.

If someone has a rotten attitude you can easily show your core values publicly and correct course. The hiring and firing is much easier when all of this is setup and understood by the whole company.

Document Your Company's Processes as Soon as Possible

You will be surprised by how much processes you have even at an early stage. You will also be surprised by how little everyone is aware of it (including yourself!).

By documenting these processes you will be in very good shape to start improving and refining them to increase everyone productivity.

You Most Likely Don't Need an Office

If you are building a SaaS product, your stuff will most likely live on the cloud and your offerings will be purely software-based. Learn about how to setup a remote work environment efficiently and save on the office cost early on!

Meetings are Less Important Than You Think

Face to face synchronous meetings are not that useful. I've found that most of the time, just having a Google document that says what problem you want to fix in the meeting and distributing it to people you want to meet with is 99% of the job.

You will get a few comments on what to change, 3-4 asynchronous back-and-forth discussions, and voilà! Another problem fixed.

Meetings are Sometimes Necessary

No meetings whatsoever are not possible, though (I'm a hardcore asynchronous guy and even I need to admit that). If after sending that document you have 30 comments and you get to a stalemate kind of situation, it's usually time to ring the meeting bell and address the point of contention synchronously.

Most of the time, it's a matter of miscommunication. Having this synchronous back and forth allows the issue(s) to be resolved more efficiently.

Make Most Stuff in Your Company Public to All Employees

If something that is work related doesn't have to be private to a specific set of people, it should be public. By having the opportunity to jump in someone else's operational discussion, you can provide much needed feedback that will save lots of time.

Also, by having this whole bank of general knowledge available to everyone, you ensure that people are all aware about what is going on in the other departments.

Make Sure that the Private Stuff Stays Private

This goes both for security-related sensitive material and for private employee matters. If an employee tells you something personal, do not break that trust.

Continuously Improve Your Company's Structure

A company is an ever-growing organism. The structure that is best for today won't necessarily be the best in a month's time. It needs to be continuously tweaked and improved in order to maximize the work that the people working on it can output.

Beware of Working with Large Entities Like Cities, Multinationals, or Governments

These are slow and could end up suffocating your company. They will book meetings upon meetings to move the project forward by inches. Even if they pay you a lot, the cycle of learning you can do with them is so long that you will not have improved by much.

Working with smaller entities allows for more direct feedback. And if you can gather enough of them you can have a much more robust business. Resting on a thousand small pillars is more stable than resting on two huge ones.

Employee Advice:

Don't Hire Jerks Just Because of their Technical Skills

It's a big no-no. If you think about it this way, a person will stifle the productivity of everyone by souring the cultural soup.

If people are dreading going to work because of that one person, you will end up with more problems than what this person can fix with their code.

Cultural Fit is not an Option

Clearly check if the person has the technical abilities that you are looking for. However, check just as rigorously if the person as the right personality for your company.

Having someone clash with the company or not upholding one of your core values will do more harm than good.

Team Fit is not an Option

Make the teams an integral part of the hiring process. You will be surprised by how picky the team is and how rigorous they are in the hiring process.

It happened quite often that the person we were interviewing passed the technical interview and the cultural one, but didn't pass the team interview.

The rationale for rejecting a participant from the team was always valid and we couldn't believe we didn't catch it earlier in the process.

Neurodiversity Increases Productivity

You have to resist the urge to hire people that think exactly like you if you want to have a truly productive company.

By having people from different backgrounds, you will increase the chance of finding creative ways out of problems and you will reduce your blind spots by a lot.

Don't Try to Fit a Good Profile in the Company, Find a Good Profile for a Need

Always start by assessing what is your most urgent need and then find the best person to fill that position. By starting the other way, you will bloat your company with people that don't truly create value.

You Will Have to Fire People and it's for the Best

I've had to let a few people in the company go, and every time it was better for all parties. However, do it with respect. If you did all the work to bring someone on your ship, you should do all the work to bring someone out of it.

This means ensuring that this person understands why it's not a fit, that you gave enough warning signs, and making sure that this person has the support they need once they are moving away from the company.

Make Sure That Your Employees are Genuinely Happy

If someone doesn't feel good, talk to them and help them out. Wish them a happy birthday. Say thank you when they do something great. Coach them when they want to grow. Debug them when they make a mistake.

Having happy employees is one of your most valuable currencies as a startup and what makes working in one such a great experience.

Personal Advice:

Make Sure that the Founders or Executives don't Kill Each Other – and the Company

What do you get when you have a toxic startup culture of working insane work hours coupled with financial stress and customer problems? A good recipe for company failure.

Make sure to always reserve at least one hour per week where you don't talk about the company, but just check on each other and try to mend personal issues in the open.

Repeat After me: It's 👏 a 👏 Marathon 👏 not 👏 a 👏 Sprint

Insane working conditions cannot last. It's not if you will burn out, it's when.

If you cannot envision keeping the pace of work you currently have for the rest of your life, change it before it's too late.

I've seen too many startups crumble suddenly because of people thinking they can sustain having no time off forever.

Leave Room for Your Personal Growth

Learn about that one topic that is completely left field for your startup and enjoy it. Go ahead and network with people for your own benefit, it's okay. The more you grow as a person the higher the potential growth for your company.

Leave Room to Just Chill Out

Even if you enjoy working on your startup don't neglect the other aspects of your life.

It's fine to have other friends outside of work and it's fine to just unplug for a while. If you can't do that you have serious issue to fix in your company.

Have Fun

It's genuinely fun to build a company from the ground up. Enjoy the time working on that nasty bug that put the whole EC2 instance down. Enjoy your time calling this one customer that has nothing good to say about what you do.

Enjoy all of the little problems that will pave the way of your company. Because a startup can only do two thing: Die, in which case you will look back at those days with fond memory. Grow, in which case it will start to become something bigger than you and gain a personality of its own!

Useful (SaaS) Entrepreneurship Reading

The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses:

This book is a very simple read and taught me that cycling through hypothesis/learning is way more important than doing the most perfect thing right off the bat.

As a technical person that loves technology, I couldn’t understand why the tech was not at the forefront of every business discussion.

This book, with the clear example of bold tests that were done with real users, showed me exactly why a focus on building a product before understanding what the users will think of the product is a bad idea.

Traction: Get a Grip on Your Business

This book helped me make sense of how to structure our company once it has scaled past the founders. I’m at something like the sixth read cover to cover.

There is a lot of useful information and practical guidelines to use in order to really get a solid structure that make sense for the next growth phase.

It also helped create a sense of calm when thinking about the future because it increases your awareness of what will come in the future.

Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs

I read this book before reading Traction, however there are a lot of similarities between the OKR goal structure and the Rock goal structure from Traction. The basic idea is that you have limited time to work on goals/projects, so work on the most impactful ones and ditch the rest.

The idea of simply not thinking about the low priority objectives really creates a sense of space in your head. Knowing exactly what to focus on and having the liberty to think about how to get there also helped create an ultra-collaborative structure.

I use the OKR system in my personal life too. It really helps me reassure myself that I’m on the right path and allow me to say no to opportunities that pop up throughout year that are not aligned with my objectives.

Peopleware: Productive Projects and Teams

This was a very enjoyable read. It talks about a facet of software engineering that is often not taken into consideration, which is the people factor. I absolutely love the straight to the point organic writing style that the authors use.

Lots of examples are given and there is a significant supplementation of statistics along their argumentation that really help gauge what non conventional changes to implement.

DRIVE: The surprising truth about what motivates us

Drive is very closely related to Peopleware in the subject it addresses. Both of them help in figuring out how to create a work environment that is purposeful and that drive people to give their fullest.

I’ve learned a great deal about how much “carrot and stick” kind of reward/punishment comes into play in the traditional workplace and how it's not the optimal way to increase motivation.

It also allowed me to understand how I can push myself to accomplish my goals in a purposeful manner without having to bribe and trick myself.

Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale

This book is an extensive introduction to DevOps culture and is a good handbook to keep to consult when you're unsure about a certain aspect or situation.

It was the book that introduced me in more depth to that way of thinking and got me to really understand it more than on the surface level. It had some very neat examples of how all of the DevOps concepts tie up in the real world.

However, it’s quite a lengthy book. It is meant to be consulted in a non-linear fashion. I recommend keeping a copy at hand if you manage a technological team to get some ideas about what to do in a given situation.

The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win

I read the Phoenix Project a while after having read Effective DevOps. Effective DevOps gave me a deeper understanding of the movement, but it’s the Phoenix Project that really made everything “click”.

It’s a novel, but explained in such an organic way that it could have been a biography. I read the whole thing in 2 days over the summer as I was very engaged with the protagonist's struggle with inefficient process and “impossible” goals to meet.

After reading it I felt way more confident that the changes I was making to my organization were the right ones.

If I had one book to give to a non-tech manager to make them understand how to make a tech department fail and how to make it thrive, it would be this one.

Designing Data-Intensive Applications

This book was so densely packed with information gained from working with very difficult problems that you probably need to re-read it from time to time while you also work on difficult problems.

I’ve learned a lot, both in the inner design of the behemoth of the internet and how much these behemoths were built by facing a constant stream of problems.

The sheer amount of tradeoffs, learning, and ambiguity that takes place in systems at huge scale was staggering. It helped me prepare and better react when I hit various problems in my tiny (in comparison) systems I’d been building.

Likewise, this is the kind of book that should be read periodically while building something that is in the process of scaling.

Forge Your Future with Open Source: Build Your Skills. Build Your Network. Build the Future of Technology

This book is one that really helped me better structure our remote company so we could hit our business objectives and help our employees feel productive and happy.

I drew a lot of inspiration from how open source projects were structured and made quite a lot of changes in that sense. It also helped me understand and appreciate a bit more about how open source projects work.

Principles by Ray Dalio

This is an incredible book with an insane amount of tips from a successful entrepreneur in the financial sector.

The amount of useful content in there is staggering and will require multiple reads in order to extract it all. If you are looking for new ideas to make your organization more efficient, better at problem solving, or stimulate growth, it's a must!

Delivering Happiness: A Path to Profits, Passion, and Purpose

A very beautiful book by the late CEO of Zappos. It's a humble book filled with good learning and takeaways by Tony Hsieh in his entrepreneurial journey.

The most important part here is the focus on making sure that the culture was right, as he had two main company successes in his career: One with LinkExchange that had no focus on the culture and another one with Zappos which was heavily invested in it.

The latter is arguably the stronger business.

Reaching Out

If you are interested in learning more about my company, you can check our website. If you have questions feel free to add me on LinkedIn or Twitter to chat :)

I hope this was helpful!

In this article, I’ll share my journey of building an API business, the technology behind it, and how to build your own API business in the future.

First, a little bit about the business I've built: Listen Notes is a podcast search engine that allows people to search nearly two million podcasts and more than 89 million episodes by people or topics. We also provide a podcast API for developers to use, which is called Listen API. It has become a core part of our business.

An accidental API business

I left my previous failed startup in September 2017. After a few days of tinkering, I picked up one of my fledgling side projects to polish the UI a bit.

That side project was Listen Notes, a podcast search engine website, which was just a single page React JS app running on three $10/month DigitalOcean droplets.

Little did I know a few years ago that my small, neglected side project would turn into the helpful business it has blossomed into.

An early version of Listen Notes

I continued to work on Listen Notes full-time and incorporated Listen Notes as a Delaware C-Corp in October 2017. One of my goals was to experience as many facets of business as possible, rather than just writing code behind the scenes.

My initial plan was as follows: (Don’t laugh at me!)

• Build a podcast search engine website and make some money from advertising, just like Google. Simple!
• If this Listen Notes thing doesn’t work in two or three months, then I’ll run out of cash, and I’ll go into credit card debt to keep going for one more month or so. If it still doesn’t work, then I’ll have to find a full-time job. Although Jeff Bezos’ parents invested $300,000 in early Amazon and Mark Zuckerberg’s parents loaned $100,000 to early Facebook, not every family is able to casually toss six figures of cash at web projects.

Then something happened.

On November 20, 2017, I got an email from the developer of a new podcast app, who asked if Listen Notes provided an API. He wanted to be able to search episodes in his app, but he didn’t want to build the entire backend.

I asked a few questions (for example, how would the endpoints look, what data fields did he need, how much was he willing to pay…). I got his answers. Everything was in an email thread within a couple days.

On November 30, 2017, I quickly implemented three endpoints (GET /search, GET /podcasts/{id}, and GET /episodes/{id}), which were basically three Django views.

I Googled “API gateway” or something like that and found a service called Mashape, which was an API marketplace that handled payment, user management, and API documentation.

So I put my three endpoints on Mashape and created two plans there: FREE and PRO. I emailed the developer back to tell him the API was ready to use.

The email thread that prompted me to build Listen API

Then nothing happened. The podcast app developer didn’t use our API and instead phased out their project.

Eventually, I moved on to primarily focus on the development of listennotes.com. The API was basically in self-driving mode on the open web. Anyone who happened to discover our API could sign up, without talking to any human beings.

On January 14, 2018, I got my first paying user. A few more paying users arrived that same year.

The email notification I received for my first paying user

Wait, what is RapidAPI? Well, Mashape was acquired by a startup named RapidAPI. They didn’t rebrand Mashape to RapidAPI completely until mid-2018. Startups typically don’t do things in a clean and methodical way, which is totally understandable.

Then something happened.

There was an outage on the RapidAPI end on November 29, 2018.

The email I sent to people in RapidAPI when the outage happened

RapidAPI had performed a big backend upgrade around that time. As an engineer, I totally understand that outages happen, especially when making huge changes in the backend. But I felt helpless because their customer support didn’t reply to my email. Phone call didn't work, as expected.

Usually their customer support was very responsive. Perhaps it was the holiday season and people were on vacation.

So I used hunter.io to find work emails of individual RapidAPI employees, the CEO, as well as the CTO. The issue was finally resolved, many hours later. In other words, our API was completely unusable during those down hours. I felt very sorry for our paying users.

Then around mid-February 2019, RapidAPI had billing problems and failed to pay us a few thousand bucks. Our paying users paid RapidAPI first. RapidAPI took a 20% cut. Then they paid the remaining 80% (minus PayPal fees) to us.

After several back-and-forth emails and phone calls, we finally got our payment. It’s understandable. Again, startups make mistakes.

In late February 2019, I decided to build our own RapidAPI replacement, for a few reasons:

• Our API revenue became nontrivial. The 20% cut from RapidAPI was a bit too much for us.
• We wanted API requests to hit our own servers directly, thus lowering latency for our users.
• I didn’t want to feel helpless when RapidAPI had outages. Overall they did a good job running the service. But I wanted to control my own destiny.
• I wanted to contact my API users directly. Using RapidAPI, API providers like me didn’t have access to our users’ email addresses. It’s understandable. It’s like the “Uber for X” companies that don’t want workers and customers to bypass them and strike deals under the table. Marketplaces don’t want users to skip the middleman’s commission fees.

In addition, I vowed to do two things really well for our new API system:

• We must provide great customer service to our paying users.
• We will give customers a very stable & reliable backend service.

After 30 days of hard work, we launched Listen API v2 on March 27, 2019. The legacy API hosted on RapidAPI became Listen API v1, a version we won’t add new features to but don’t want to shut down because some apps are still using it as of December 2020!

We continue to improve our new Listen API v2 by adding new endpoints, new data fields, improving operational efficiency, as well as spiffing up the user dashboard and our internal tools.

Things are picking up speed gradually. I’ve been happy since then.

So, that’s the journey of Listen API so far.

Note: Although we decided to move on from RapidAPI, I still think it’s a great service. Startups all make mistakes in the early stage. They fix things and continue to improve their service, which is great!

The technology behind Listen API

Developers can use our API to search podcasts and fetch detailed podcast-episode metadata. To make this whole thing work, we need to make sure a few core components are in place.

Listen API's main components and the technologies used

Datastore and search engine

This is a shared component with our website. Therefore, I didn’t need to change anything in the datastore and search engine when building our API infrastructure.

We use Postgres as our main data store (for example, for podcast metadata, user accounts, and so on), and Elasticsearch as the search engine.

I wrote an old blog post with the details of the entire tech stack.

Internal tools and processes

If you’ve worked at any web companies, you probably know what I’m referring to here.

It’s rare for an Internet business to be 100% automatic. A company always needs to build tons of internal tools and set up manual processes to keep the service functional. That’s why companies like Retool have such a high valuation nowadays.

Companies are investing big money in internal tools that are invisible to end users:

Percentage of team's time spent on internal tools. Credits: Retool

To start our API business, we needed to build (at least) two types of internal tools:

• For data operations: We needed the ability to keep the podcast metadata up-to-date, fix corrupted metadata, plus review and approve any changes made by users.
  Additionally, we required a framework that handled new, rare edge cases of corrupted podcast data along the way. To some degree, building a software product means handling tons of edge cases for a very long period of time (like, years), rather than launching new features every day.
• For user operations: We required the ability to suspend a bad user’s account, as well as immediately look up all information related to a specific user who contacted us for a specific issue.
  Plus, we had to be able to quickly evaluate if “it’s our fault” (server-side errors) or “it’s their fault” (client-side errors) when users complained.

Internal tools are used by employees inside the company. Some of those tools are fully automated, such as cron jobs that perform scheduled tasks. But many tools should be used manually by human employees, for example when inputting a user’s ID number and clicking a button.

Most of our internal tools have ugly web UIs, with default Bootstrap styling :)

A portion of our internal tool’s UI that allows us to suspend an API user’s account.

Fortunately, our API shares many internal tools with the website. So we didn’t need to build too many new things here.

The analytics and billing system

The pricing model of an API is typically usage-based. Check out some real world examples:

• https://www.twilio.com/pricing
• https://sendgrid.com/pricing/
• https://cloud.google.com/maps-platform/pricing/
• https://www.microsoft.com/en-us/bing/apis/pricing

It’s a must to track how many requests a user uses in real-time. We use Redis to keep track of such stats and periodically dump into Postgres for persistent storage.

What happens if our Redis has an outage? We might temporarily lose some tracking stats. In this case, we have an internal tool to sync stats from raw Nginx logs.

We have to change billing plans without affecting existing users. For example, if we raise prices, existing users should still enjoy the benefit of the old plans. If it’s not done right, it’s easy to have inconsistent states across the board, and angry users getting charged the wrong billing plan!

Payment failures, a very common occurrence, must be handled gracefully. We can’t just suspend users right away. We need to be able to notify ourselves that “this user failed to pay” and notify the user that “you failed to pay.”

After a few retries, we suspend users manually — well, we could’ve automated this last step. But we don’t suspend users often nowadays, so it’s okay to do so manually. There’s no need to make everything perfect (at least for now).

We have a dashboard (God’s view) to see how many requests each individual user uses in the current billing cycle. And we are able to review raw logs for each user from a web UI, without manually pulling log files from S3.

Stripe and PayPal (via Braintree) are our payment processors. Most of our international users use PayPal.

Finally, putting all of these factors together, we can calculate the actual amount of money that a user should pay us in real-time, based on their usage. We run async tasks via Celery to charge due bills.

What happens if a user unsubscribes in the middle of a billing cycle? We charge them prorated rates, based on time and usage. Users don’t need to pay a full month’s fee in those instances.

API Servers

We run Django apps to serve API requests. Each endpoint is a simple Django view. A Django middleware verifies if a request is legit, then generates a log or rejects the request right away.

We cache response data per API key + unique URL in Redis. In general, our API performance is pretty good.

We use Nginx as a load balancer and provision multiple API servers. It’s straightforward to do rolling deployment here, with a bunch of sanity checks to ensure the API is functioning.

Generally speaking, the easy and robust deployment process increases my confidence to make incremental code changes often and to deploy frequently.

An API endpoint is RESTful and returns a JSON response, pretty standard nowadays.

User Dashboard and API Docs

Each API user can access a dashboard on our website to learn the amount of requests they’ve used in the current billing cycle and view recent raw logs. They can also update payment methods, create or reset new API keys, set up webhooks, and add coworkers to the same API account.

Listen API's user dashboard

API Docs is probably the most important UI for an API business. Therefore, many API companies employ a whole team of full-time engineers to build and maintain “merely” the API Docs page(s).

An API Docs page is not simply a full page of English words. It must show code snippets for different programming languages.

Users have to be able to run your code example directly from the page. You are required to design a repeatable process (no matter if it's automatic or manual) to keep the documentation in sync with your code. There are plenty of nuances.

We spent a lot of time and energy building and iterating multiple versions of our API Docs page. Following is the end result:

Listen API Docs Page

Initially, we tried a few open source solutions for the API documentation. It’s quite time-consuming to understand an open source project well enough to customize it. Ultimately, we decided that it would be faster to build the page from scratch rather than customizing an open source solution built by others.

Our API Docs page is basically a React JS single page app.

We codify all endpoints, response data schema, and example response in an OpenAPI spec. The React JS app of the API Docs page reads from our OpenAPI spec directly.

The side effect of using OpenAPI is that we can easily integrate with tools like Postman, because OpenAPI is a (relatively) widely adopted standard for API documentation nowadays.

Why Listen API works

Listen API has been a nice business for me so far.

But don’t expect me to share revenue numbers publicly :)

Some companies are doing this open startup thing, sharing every single business metric to the public, which is great.

But we shouldn’t blame the majority of companies (including my small company Listen Notes, Inc.) who don’t want to share business metrics publicly.

Not everyone is comfortable being naked in public, literally or figuratively.

Similarly, there’s lots of business advice (or cliches) that you don’t have to follow.

• You don’t have to find a cofounder - having a horrible cofounder is way worse than not having one.
• You don't have to reveal your revenue to public or do any "open startup" thing. No pressure. Don't feel guilty if you are not doing what other cool kids are doing. You run your own company. You make your own decisions.
• You don’t have to do XYZ that a Twitter VC philosopher urges you to do in a fortune-cookie-like tweet.
• You don't have to be 100% bootstrap nor 100% VC-backed. Many things are not completely one way or the other. Usually, there's middle ground.
• ...and the list goes on.

The bottom line is, not one is absolutely wrong or absolutely correct. Each individual's vision/knowledge is limited. Each person's preferences might be very different.

An API business may be too obscure to most people in the world, but I like my API business very much. People from big companies (like Apple, Amazon, or Microsoft) may examine my business and deem it “cute”. But I would consider it a success for me personally.

And success is relative. The key is to bring happiness to customers (by saving them time and money and helping them solve problems), myself (a professional achievement), and my family (by keeping the fridge full).

So why does the Listen API work?

Demand and MVP

I didn’t build a solution to find problems. It was the problem (a podcast app that wanted to add search functionality) that found us—and we built a very simple solution at first.

We didn’t spend months launching the API. We spent a couple of hours. It costs at least $100 per hour to hire a not-so-bad engineer in San Francisco, so the cost of launching this API MVP was approximately $200. Even if it were $2,000, I'd still think it was worthwhile.

Two reasons why we were able to launch an MVP quickly:

• The heavy lifting part of building a podcast database, search engine, and data operations tool was already done, because of our podcast search engine website.
• Mashape / RapidAPI existed to provide a plug-and-play solution for us to manage users and create paid plans without writing code on our end.

However, in hindsight, it’s actually very common for a commercial search engine to license their tech (via API or other ways). Some examples:

• Yahoo Search was powered by Google circa 2000, and is powered by Bing today.
• In the early days, Baidu's only business model was to put a web search on some Chinese portal sites
• Today, Bing provides a bunch of search APIs.

By launching an MVP fast, we were able to get feedback early, especially after getting the first paying user only a month or so after launch.

Good documentation

User feedback proves that our API Docs page plays an important role in customers' decisions to use our API. There must be a reason for API companies to employ a whole team of engineers “only” to maintain their documentation pages.

Great documentation builds trust.

Stable backend service

Stability is the essential base of an API business’ Maslow’s hierarchy of needs. If an API is not stable at all (for example, it has frequent outages or runs very very slowly), it can't be used.

However, it’s boring to perform work to improve backend stability. Most tasks to stabilize backend services are preventive, including extensive monitoring and alerting, the process to deploy code with confidence, end-to-end regression tests, and so on.

No news is good news.

No outages are great news.

We use Statuspage.io to hook up our Datadog metrics to build a status page: listennotesstatus.com.

System status page of Listen Notes

Here’s hoping that the status page will convince our prospective users to try out our API :)

Excellent customer service

We are all customers of someone else’s products and services. We have all been frustrated with poor customer service at some point in our lives. It’s obvious that great customer service goes a long way — RIP, Tony.

Many people are likely not aware that you have to pay AWS big money to access better customer service!

Our customers don’t only pay us for using our API, an online service. They also pay for being able to get high-quality customer assistance from real human beings. In our case, it’s me, the person who built this thing.

I use Superhuman to process emails promptly and efficiently. And I’ve got a ton of prewritten email templates to handle the most popular customer support tickets. Oftentimes I can reply to an email within 5 seconds, using CMD + K to select an email template.

Invest in internal tools and processes

For knowledge work, it’s possible that one single person (or a tiny team) can create 10x, 100x, or even 1,000x more value than a big team.

Let’s look at an extreme example: book publishing. It’s (almost) impossible to hire 10,000 good writers to collaborate on one book together and hope it’s “better” cohesively than Harry Potter, written by a single author.

JK Rowling, a single person, created way more value (in terms of measurable dollar amount and unmeasurable happiness, good times) than most companies with hundreds of employees in the world.

Eventually, the software business would grow in a similar way.

We already witnessed the 13-employee Instagram get acquired for $1B in 2012. When will we see a $1B+ software/internet company with 5 or fewer employees achieve the same feat?

Great internal tools and processes provide leverage to enable a tiny team to be super-efficient. This is easy to understand. We human beings already built a lot of tools to greatly extend our physical/mental limits, for example bikes and cars (versus walking), computers (versus manual calculation), and so on.

Given that it’s (almost) impossible to 100% automate an Internet business, we have to improve the efficiency of manual operations. It’s a great investment to increase human operators’ productivity.

Tidbits of running Listen API as a business

Here are some things I didn’t know before…

Anyone can sign up => Submit your application first

A few years ago, I noticed that certain APIs required me to submit an application first, describing my use case, before giving me an API key.

I didn’t understand the rationale back then.

After running my own API business, now I understand.

The Internet is huge. The world is gargantuan. There are good people and bad people. If the API you provide is useful, some folks will try to abuse your API.

That’s what happened when we initially allowed anyone to create an API account. We were seeing users creating dozens of accounts in order to get around the free quota limit.

Today, we require people to submit an application first. We get a notification via Slack. Then we use our internal tool to review and approve or reject the application. The applicant receives an automatic email. On our end, it’s two or three clicks to finish all these operations.

To assist our review process, we use a bunch of heuristics:

Did this user previously create multiple accounts?

Is this IP address a well-known spammer discoverable via stopforumspam.com? (hint: there's an API for that)

And so on…

Again, we are seeing new edge cases from time to time. Yet we are also learning how to handle those unique cases.

Ideal customers and interesting customers

Our best customers are mostly startup founders who have been in business for quite some time.

They can make decisions on their own. They understand the value we provide. They have the power to finalize purchase decisions. And they are competent enough to read our documentation autonomously and ask very few questions — or they don’t even talk to us at all.

On the other hand, people from well-funded VC-backed startups or huge companies (some of the biggest companies in the world) oftentimes ask for a discount or free trial, which we don’t have. Why? I don’t have a good answer here.

Of course, there are always exceptions.

Dev shops and coding bootcamps

Many of our users hire freelancers or dev shops overseas to build apps and websites.

Generally speaking, developers from dev shops are not as good as in-house developers. Although not 100% true, the chance is quite high.

In essence, a bunch of my customer support replies are to teach Computer Science 101 . Sometimes they sent code snippets in PHP (or a language that I don’t know) to ask us to debug it via email.

I understand that some of those developers from dev shops are fresh out of coding bootcamps (or the dev shop itself is a coding bootcamp). Most of the time I will Google for them and send them a StackOverflow link or something like that. But occasionally, if I was in a bad mood, I would not reply to the “help me debug my PHP code” emails from FREE users who don’t pay us.

Also, quite a few coding bootcamps use our API to teach students how to write code, which is great. In real-world web projects, you can’t avoid using third-party REST APIs. Teaching new programmers how to talk to a REST API is necessary.

API is a slow business

Usually it’ll take a user a few months to start paying us.

They need to add a big product feature or even build an entire app first. Then they need to do some marketing and get some traction. Finally, they pay, or they give up and shut down the app.

We definitely should think about how to help our users build product features fast.

Stripe is doing a great job in this area. They built a lot of nice UI components that developers can directly use without writing tons of code, like Checkout.

API is a stable business

Our churn rate is quite low. People spend many months building an app using our API, so it’s unlikely that they’ll switch to something else overnight.

I’m happy with that fact.

Meanwhile, I’m also very bullish on all the other API businesses out there, like Stripe, Plaid, and Twilio. (This isn’t investment advice, but look at the stock TWLO.)

Start with whales, then diversify

At the early stage, there might be a few user “whales” who account for a big portion or even most of the revenue.

Don’t panic.

Having revenue is still better than not having revenue at all.

We are not in a position to be picky at the early stage. We can diversify along the way.

I like reading S-1s.

It’s not uncommon to see some SaaS or API companies with a few whales when they went public. If they lost one or two such whales, their revenue would drop 10%, or even 20%+ immediately! Well, they are already a public company. No need to worry about them. They know what to do next.

Pricing is a work-in-progress

We are always experimenting with new pricing. Similar to building software projects in general, pricing is always a work in progress.

We allow old users to stick to the lower pricing they obtained when they signed up. Any future price changes won’t affect existing paying users.

I know that select pricing experts would warn me that I leave money on the table by this practice. But I feel thankful for customers who stand by us for so long. I want them to enjoy the low pricing as a benefit.

By the way, ProfitWell has great resources regarding pricing.

Haters / irrelevant critiques

You may have seen this theory: When you have haters, you’re doing something right.

There’s a similar quote from Zeng Guofan (one of the most important military leaders and politicians in the 19th century China):

不招人妒者皆庸才. “If no one envies you, then you are incompetent.”

Side note: You can find Zeng Guofan’s wisdom inside many airport bookstores in China. He would have been a great Twitter user and beat those Twitter VC philosophers if he were born in our time - it's hard to beat a historical Chinese figure in the game of fortune cookie :)

If your project is visible on the Internet and gets a bit of traction, some people will hate you for no particular reason.

Once you offer a paid service, you’ll never provide a price that is low enough to make everyone in the world happy. No, $1.00 USD is not cheap at all in many places in the world. People who are not your target users will complain about your pricing.

From my experience, it’s safe to ignore most critics, advice-givers, and suggestions from non-users. Sometimes people try to compare two things with similar names.

For example, if you search “podcast API” on Google, you’ll find a few other APIs with “podcast API” in their names. However, if you spend a few minutes skimming the documentation, you’ll find obvious differences. It’s like comparing two people with the same first name and family name who are two completely different individuals after all.

The only critiques or suggestions I care about are mostly from our users. I can see their API usage. I know they are expressing meaningful facts. So I listen to them.

So are you interested building an API business?

Nowadays, the “passion economy” or “creator economy” is hot.

Who are creators? Writers, podcasters, streamers…

Don’t forget that software developers are also creators!

If you already run a website or have some interesting data, you may start an API business as well.

Thanks for reading this long article :) Let me know what you think: wenbin@listennotes.com. And you can read more of my posts on my blog.

I can remember the first time I went over to Joey's house. His room was an absolute disaster as any 11 year old's room is. I made his parent's laugh after they apologized for the mess, "it's no problem," I said, "it's easier to see all of the stuff he has!"

It wasn't until after high school that we completely deviated from one another. I went off to business school, while he pursued photography, having been rejected by all post-secondary institutions he applied to.

I would have never guessed that six years later we would be on the exact same path, – both self-taught developers, but on different tracks.

I remember when Joey first told me about the games he was building in Unity. We spent countless hours playing Minecraft when we were younger, so I assumed it was something in that realm.

I was soon going on a study abroad and certainly wasn't paying much attention to his new hobby. It never occurred to me this would blossom into anything greater.

He's gone from sharing his projects on Instagram, to co-founding a company in Finland, and completely starting from scratch on his newest venture, 9 Cent Games.

I want to share his story here.

Why did you start teaching yourself game development?

I had been dabbling in Photoshop and After Effects for about a year prior. I messed up my ankle up skateboarding and had a lot of free time. My work with Photoshop led me into 3D artwork.

I started thinking, what can I do with these 3D models? I can't make animations. It's too much work. I think you need a team for that. So I was like, maybe I can code these models.

I started trying to learn with these Unity tutorials. I actually gave up a few times before it really clicked in my head. Slowly, I started accumulating knowledge, just releasing simple games, asking questions on Reddit. The community on Instagram was also very, very motivating. And then it just turned into what it is now, six years later or something. I think I started in 2014.

Unity has a whole bunch of tutorials on YouTube. There was a space shooter and then a roller ball thing. I made a little ball game called Tiles based on their rollerball tutorial. That was the first game that I made.

Why did you quit?

Oh, I honestly just didn't understand it. I had a hard time really grasping even the most basic concepts of programming. For loops, if-statements, that kind of stuff. I was using the update loop in Unity to write like a hundred if-statements as opposed to just using one for loop to do basic stuff. I had no understanding at all.

Something kept dragging me back. I made a platformer, then a little shooter and then I built a game called Aldo, which was an action RPG that had six quests and a few different worlds. I kept trying to expand my games and the thought of reaching just a little further was exciting.

And then you realize you have huge gaps in your knowledge and you don't know how to plan these projects. So you kind of have to step back. Go smaller.

Thumbnails of the early games

How did you get better at planning projects?

Honestly, studying games, looking at YouTube videos of game design breakdowns, and seeing how these games are built and the ideas behind them.

I would pick any element that I could find, replicate it and then try to make it my own in some little way. Or just straight-up, copy something and just see if I can programmatically replicate a cool mechanic.

It was all literally like hacking it together. I could show you some of the code that I wrote from way back and you would laugh.

You shared everything you did on Instagram. Why? What was that like?

Instagram was and is the number one thing for me. That's kind of how it all started as well. There is a big development community there. Specifically a game development community. Everyone shares their artwork, comments on ideas; people are generally pretty supportive.

It was very motivating. Posting kept me active and pushed me forward because it's so solo. You can feel lonely at times. You have to really be self-motivated, get up in the morning on your own for no other reason than your passion for coding.

Instagram is sort of a way to stay accountable and a way to build motivation because the reach that you get, as well as the community, are real.

I still use the same hashtags today to stay in touch with the community like #gamedev, #indiegamedev, #madewithunity, #unity3d.

Instagram actually lead to you co-founding a company, right?

Yeah, I met my future business partner on Instagram. I was posting my artwork and he started with liking some photos. My partner really liked some of the weapon designs that I was doing. He eventually DM'ed me and we started exchanging ideas.

We traded ideas for a long time before I eventually bought a plane ticket from Toronto to properly meet him in Finland. It was a bit surreal. There's a massive community in Helsinki. Studios like Rovio and Supercell are based there. Finland is home to some crazy game companies.

I was starting to run before I could even walk. Soon we had our company, Action Reaction Games, and had begun planning our first game, Battle Blobs.

We just started developing the game. I had never built a multiplayer game before, so that was a bit of a hurdle. We tried all these different back end tools, all kind of worked, but kind of didn't. Every day had a new challenge. I learned about 80 percent of everything that I know now during this time.

How did you find other like-minded people to start working on the project with you?

My partner led a lot of that because he was the networking guy. I was more on the technical side of it all in those days. He led the force on that. As I said, the community in Helsinki is huge!

I think he had two engineers that he was working with to build a prototype before I joined. The fit wasn't right, so they ended up leaving. Eventually, we found an artist to work with. And then another really, really technical guy from there. All of these people he knew from his network.

At what point did it become more serious?

Around April 2018. We were just closing the funding round and that's when things really started gearing up. It was incredibly strenuous leading up to that point.

It's a lot of meetings. It's a lot of pitches. It's a lot of meeting people for no reason that barely even respond to you, even though they seem very excited in the initial meetings. I wasn't there for many of them, but I was there for enough of them. I was there for the key ones that actually landed the investment rounds. So that was cool.

Our co-working space

It is a complete grind. It's a grind of just hardcore networking and just figuring out who's really going to give you money, who actually believes in you and why am I here?

Finland's just such a hub. Money moves kind of slow there, but in a sense, it also kind of doesn't. There are tons of angel investors and venture capitalists in Helsinki focused exclusively on game investment. I don't want to name drop or anything, but we had some really cool people involved in Battle Blobs on the financial side early on.

We ended up raising about 100k euros and then the Finnish government had a program where they essentially doubled that.

How did things change after the investment?

Scheduling everything, tight deadlines, and way more meetings. We had very specific goals and needed to move much faster. The pace was much different. It was definitely an ego boost.

There was more testing, playing, trying to get the team to coordinate better, which was a big struggle. We weren't always on the same page. It's tough. You knew in your heart that someone was really backing you. You kind of felt a huge sense of responsibility on that.

I was the only one that was remote, unfortunately. Everyone else was in the office every day working on it. I would come to Finland as much as I could and be there working hands-on, but I was the only one that was remote.

It's a little bit intimidating, especially when things start to get a little bit uncertain. You know, as things evolve and develop.

What was the biggest success of Battle Blobs?

Definitely the technology we built, the software and literally just getting the game to launch. We did a really successful launch. We had fifty thousand downloads. We had no monetization mechanics, unfortunately. That was a huge oversight by us.

Battle Blobs launch party

A lot of it was pretty organic. We did pay a company to help us with our marketing. I don't think they really helped too much. But then somehow China got a hold of it and it spiked.

It was really weird. It spiked around 15000 downloads over the course of two weeks, just randomly. We were not marketing in China at all. We were only marketing in the UK at the time. We were advised that was the best place. I question that now, but it seems that the marketing and the way our app looked right had some appeal there.

When did you start to feel like things weren't going in the right direction?

We were planning for a second investment round post-launch. Our main goal was to generate retention, generate engagement and basically just generate a high-quality product. We pushed hard to get that second funding round. We did everything we could, even pivoting the entire game into something more simple.

An early prototype of gameplay

When that timeline starts to run down and you notice the cash flow is going down and the next thing you know, we're dropping off salaries because we want to survive a little bit longer. That's when things get pretty sketchy and you get to get a bit concerned about the whole thing of it and then you start to really question yourself.

I found I was questioning my entire viability as a co-founder. Even if we landed the funding round, could I even run this thing the way it needed to be run? I had virtually no experience running a company. It was a lot of self-doubt and strong emotions.

Being remote sucked when it was starting to crumble. It was hard to even work. I was sitting at my computer doing nothing because I had nothing to do. There was nothing to do. And we're just kind of waiting, hoping we're gonna land a funding round.

In mid-August [2019], my partner basically said, look, maybe do some damage control and find a job. If you need or do whatever you need to do. That was pretty much it.

I took a couple of weeks just totally off. I played Minecraft for two straight weeks; it was like therapy.

What happened to the company and everything that was built?

It still exists. I think it's technically still under the ownership of Action-Reaction Games. I haven't really talked to these guys in a little while, but last I heard they were trying to license it out. I haven't heard anything about that. I'm assuming it hasn't happened yet.

The technology we built was really solid. It is a full-on multiplayer video game backend. You can build any type of multiplayer game within the framework we built. It's very powerful.

To be honest, it was also very cumbersome. It can get a little bit too much and maybe we overdid it on the tech. That's really one of the biggest things - maybe we overdid it on the tech. That's where a lot of our money went, where it did not need to go. To the engineers trying to over-engineer stuff.

What were some of the biggest mistakes that you made?

There were moments of panic where I made quick decisions that I should've just took a step back, took a breath and thought about it more. My panic caused others to panic, which was a formula for disaster.

I didn't personally feel confident. I didn't have the coding experience. Our CTO was really scaling up the tech and as he was scaling it up, I was falling behind because I wasn't able to keep up.

I didn't have the knowledge. I probably still don't to be honest; it was very, very advanced. So I think that was another hurdle. I was trying to fill shoes that I couldn't really fill. I probably could've put myself in a better role within the company that would have been more productive, more successful.

I was the producer, so I had a good role, I was keeping busy. I was managing all the releases. I was making sure builds were stable. I was doing quality assurance as much as I could, even though that was a challenge on its own.

The quality assurance and the testing process that we had was not good. It was hard to get the team to test for some reason. We just never wanted to play the game.

I was always saying guys, we have to test this. We need to test this. And, you know, we would test out 2v2 or 1v1 and yeah, okay, it works functionally. The program works, but does the game work? The game is built around 3v3. We need to play this 3v3. Guys, this is releasing soon. We need to play this 3v3.

2v2 testing

We never spent time making sure the game was actually fun. Like, literally sit down with a room full of people and play this thing to death until we know what we need to do. We never did that. I still don't do that with my current projects. That's another problem that I'm still facing but I'm working on that.

The biggest mistake that we made was when we landed our initial investment. We took a million dollar valuation on our pre-seed round.

If you have a million-dollar valuation on your pre-seed round and in reality, you're only worth one hundred thousand dollars. You take that money that you've got at that million-dollar valuation in order to grow into a million-dollar valuation.

When you do that, you have your original investors thinking they bought a million-dollar company and then your next investors actually get a million-dollar company and then your original investors get screwed or you're screwing the next investors because they're getting a worse deal than your previous investors got.

It creates this dynamic of an impossible to raise funding round. If we had taken a real valuation from the beginning, we probably would've landed that second round. There was real value in the end but not when we took our initial valuation.

If you could start all over again, what would you do differently?

Focus on the programming fundamentals. I would spend more time understanding software design concepts and how to scale software because you're going to build software that you can't move at a certain point because you're just not building it properly.

Eventually you'll have thousands of lines of code that's just gridlocked because it's so crap. You literally have to scrap it. I've done that. I've done that multiple times and it sucks.

If I just had better fundamentals at the beginning, we might have had a whole year head start.

I use the SOLID design principles and other similar concepts now. I think that helps a lot. You don't have to keep rewriting stuff just to get one piece of functionality working. You also encountered way less bugs and way less problems along the way.

After your two-week break, what was a turning point for starting something new?

I would think about it all the time. In the back of my head, while running Action Reaction Games, I always looked at these micro game companies, like Voodoo or POPCORE. These are super huge companies that literally make the simplest games ever. They are always top charting.

Once I took a break and I thought, ok, I could maybe try and release a game. It slowly started happening. I had this vision of a whole framework to help reduce the cost of game development. One day I woke up and thought, it's time to start.

There was also an emotional hurdle. I almost felt guilty, as if I was cheating on Action React Games by doing my own thing, which is a weird feeling. It felt like divorce. It was crazy.

It started with just seeing how fast I can get a game out. I got a game out from day one in 20 days called emoji tap. That was pretty cool. Then I re-skinned it into the Halloween version about 14 days later. So I technically launched two games within the first two months, which felt great.

Emoji tap

I think I really learned the importance of goals, deadlines and scheduling from building Battle Blobs. I also learned a lot of my programming fundamentals building a bigger project. The pace of my learning has definitely slowed, but I'm really enjoying my work right now.

What is keeping you busy these days?

My new project is officially called 9 Cent Games. I'm really focused on building out the framework, so I can quickly and easily make new games. It handles in-app purchases, ads, products and pretty much everything that you could need for a minimum-viable-product.

From there, I plan on creating games and then having the games help grow the framework. When the framework grows, the games also grow by inheritance.

I want to make sure all games built using our framework have a solid foundation for success. I want to enable developers to build quickly while also reducing the cost of development. That's the idea.

It is very mobile-focused. Everything regarding iOS and Android deployment is completely handled. It's all cross-platform. This is probably already done but it's mainly a good exercise for me to build my skills as I'm trying to do this.

I just released my new game, Germs: Virus Smash! on Android. It's never coming to iOS because Apple said no. They don't want to release any virus games during the quarantine.

I'm pivoting it into Quirks. It's a subatomic particle game. It'll be the exact same game as Germs basically, but it'll have a different skin instead.

If you want to follow Joey's journey further, you can find him on Instagram, @9centgames or @joe_torbett. You can also download all of his latest releases on Android and iOS!

Don't be a stranger! Feel free to write if you have any questions, email me your favourite book recommendations, connect with me on Linkedin or follow me on twitter!

I had no coding or engineering background. I studied biology in college, with no clue about what to do with my degree.

My first jobs were making cold calls in sales, but I made almost no money and was miserable with my work.

After failing at a few different sales gigs, I gave up and found a job preparing vegetables at a restaurant — not exactly the plant life I was expecting to work with after college.

I needed new prospects, and I was ready to find anything better. All it took was a strong work ethic, a willingness to learn, and a few key resources to get me onto a whole new career path.

This also got me involved in a coding competition that took me way outside my comfort zone.

While working at my restaurant job, I started hearing stories about people who taught themselves how to code and managed to develop that into careers. Willing to try something new, I started taking online courses with freeCodeCamp during my off-time from work.

Hours here and there turned into a full-time commitment. I left my job and followed freeCodeCamp’s curriculum, aggressively studying full-stack JavaScript as my new full-time job.

I spent a year and a half focusing on learning coding, and it paid off, too. I was accepted into a long-term contract as an entry-level coder at a New York City fashion company, which was generating over $2 billion a year in sales.

Learning was my top priority. Even in this new position, I continued to practice during my off-hours, this time focusing on best practices for my specific job responsibilities, which involved writing automated tests using the NodeJS version of Selenium.

I spent 10-15 hours per week doing Selenium tutorials, which helped me get my work done faster and gave me leeway to learn from my colleagues during work hours. I maximized in-between work times, talking to co-workers in the elevator or while walking to my desk. I learned what others did and what their responsibilities were for our company.

It didn’t matter if they were in the same role as I was. I spoke to my engineering supervisors and to people in our business units so I could better understand the structure of our company, find out how others had made progress in their own positions, and see if I could find some big problem that I’d be able to solve.

Around my third week of work, while talking to my senior director of engineering, I noticed a number of awards by his desk. He told me were from his past wins at our company’s annual Hackathon.

“Wow,” I said, “You've won a lot of awards.”

He responded, “Thanks. You should participate in the next Hackathon. It will be in a few months.”

I was still relatively new to coding and had never participated in a Hackathon, so after a day of mulling it over, I went back to his desk.

"Hey, I've seen a few other people with Hackathon awards,” I said, “but no one has nearly as many awards as you have. Plus, most of your awards say first place. How do you win so often?"

He told me, “I focus on projects that make an impact. For instance, for one of the Hackathons I built a prototype that would let our customers order off our website and pick it up in our stores. The judges realized this would be a big hit with our customers and would greatly increase revenue.”

When I asked him how to find a project that would make an impact, he explained that, during his time at our company, he’d gone ahead and learned all of the many different subsystems that powered our eCommerce business.

“Knowing the whole system makes it easier to see where the opportunities are," he said. "In fact, my broad understanding of our entire platform is what differentiates me and has allowed me to reach my current position.”

Finding a Project

I realized that the Hackathon would be the ultimate test of my abilities: could I take the strategies of hard work, learning from my co-workers, and my intense study of coding to the next level?

After years of feeling like I had been wasting my potential, I’d finally found a way to prove my worth. This wouldn’t just be about showing off, because I would need to find a project that was actually of use to the company.

I didn’t have a lot of time on my side, and my tech skills were relatively basic compared to the highly skilled senior level engineers I’d be competing against.

Even though I felt out of my league, I had the secret sauce for a solution in my back pocket: lessons I’d learned from Neil Rackham’s sales strategies book SPIN Selling, which gave me the four-step model for finding problems in large enterprises.

Step 1: Learn how something works.

Since I was advised to learn the inner workings of our eCommerce business, I started talking to employees in our planning department, conveniently located between my desk and the lunchroom (and between my desk and the bathrooms). They were responsible for deciding how much merchandise to buy and at what prices they would be sold.

I’d leave my desk and take a moment to ask questions like how they chose how much inventory to purchase in advance, how they set their prices, and if retail and eCommerce had different rules for pricing. Through my questions, I learned how planners introduced new clothing lines and calculated what to sell them at.

Step 2: Ask questions to find a problem.

Once I’d gotten a sense of how planning worked, I started looking for issues that might come up. Once they set an amount for inventory, does the company ever purchase the wrong amount? Do prices ever get set incorrectly?

I was trying to find the sort of mistakes or frustrations that I’d be able to solve.

Step 3: Ask questions to explore the problem’s implications.

After several days of asking questions, I learned about pricing issues, where prices would be set and appear incorrectly on our website. How did this problem come about and what were the implications?

I asked how often pricing errors would occur and what kind of further issues they might cause.

Step 4: Ask questions to explore the value of solving the problem.

If there were an automated computer script that found all the incorrectly priced eCommerce items, how helpful would that be?

I asked the planners questions that would help me figure out what sort of value I could offer them. If I was going to fix something at our company’s Hackathon, I wanted to make sure it had a noticeable impact.

After my conversations, I found that pricing mistakes would be a worthwhile project to work on. Each of our three or four assistant planners were spending 30 minutes per week manually checking for pricing errors. An automated system would save that time — an estimated 100 hours per year that would no longer be wasted.

Even though I had already been told about the Hackathon, there was no official date yet. I had a solvable problem in my back pocket, and, while I didn’t know for sure that I had the coding skills, I was fairly confident in my chances. Until the announcement came, I’d focus on my work. But whenever it arrived, I’d be ready to get started.

Confirming with the Planners

Two weeks later, I had an email in my inbox. The Hackathon event would be in one month, going for two days straight, which included a presentation on day 2, a Friday.

Project ideas would be judged on four criteria: originality of the idea, impact on the business, completeness of the prototype, and strength of the pitch. There were so many unknowns and it was impossible to predict whether one month would be enough time to prepare.

I went over to the planners and confirmed that the issue was still present — checking online pricing sales was still being done manually.

I was happy to learn that our company had a dedicated eCommerce merchandiser, who was responsible for reporting all incorrect website prices and resolving them. She would be able to give me far more information and could confirm whether or not it was an issue worth the effort of fixing.

I was unhappy to learn that she was on vacation, and I’d have to wait a week to speak to her. The clock was ticking, and I was stuck until then.

With three weeks until the Hackathon and our eCommerce merchandiser back in the office, I was able to start exploring the problem in more detail. She confirmed the issues I had heard about and said that building something that could automatically scan the website and find incorrect prices would be a big help.

In further conversations with the planners, I learned how pricing was uploaded to the website: planners would copy and paste a list of prices from an Excel spreadsheet to SAP, a software that does many things such as managing inventory for retailers. SAP would then push the prices to our eCommerce website.

I realized that the Excel prices could be compared to the website prices to find any issues. I would build a simple website that would let planners upload Excel pricing lists.

A script would then read the Excel pricing lists and compare them in real-time to our website prices. Any and all discrepancies would then be batched into a list and sent to our planners for review.

Excited that I had a way to solve the problem, I began explaining the project idea to other developers in our organization, asking if anyone wanted to join my team. However, I made it a strict requirement that any potential teammates would have to first speak to our planners in person and hear the problem from their perspective.

As part of the SPIN system, I needed teammates who were willing to understand the process and the problem before we could fully design the solution. Unfortunately, I failed to recruit any other software engineers to my project, but other engineers gave me valuable advice on how to code out my project and what technologies to learn.

I was on my own, but I was excited, feeling confident in my solution.

Needing to Pivot

Two weeks before from the Hackathon, I revisited one of the assistant planners and explained my idea for an automated script that would compare Excel and website prices and report discrepancies. She quickly informed me that my idea would be useless, since the Excel prices and website prices would always be identical.

The assistant planner continued to explain that the original Excel pricing lists were generated by a tool that took in product manufacturing costs, delivery costs, and other relevant factors, and then spit out Excel pricing lists, which our planners would then upload to the SAP software powering our website.

If the planners accidentally entered incorrect manufacturing costs or delivery costs into the pricing tool, then the price would similarly be wrong on the Excel lists.

“So you're saying there is no master list that is guaranteed to always contain all the correct prices?” I asked.

“Exactly,” the assistant planner said.

It was the opposite of what I needed to hear. There went weeks of planning, thinking, discussing, and waiting — gone.

I was two weeks out from a Hackathon where my lack of experience was already holding me back, and I had nothing. There weren’t enough days to do this all over again.

I had to rethink my process.

Since timing was tight, I couldn’t do all the research and work I had tried the first time around. Instead, I would let the planners come up with the project requirements for me.

I came back to the planning department, this time with a different question: “Imagine you had a robotic script that could automatically grab numbers from anywhere, such as an Excel spreadsheet, a database, or a website, and automatically subtract, add, or compare the data. What problem could be solved with the help of such a script?”

After the assistant planner I was speaking to thought about it for a few minutes, she told me it would be useful for checking sales prices. She explained that our website ran weekly mass sales every Wednesday. The sales would be listed on our homepage and would use text such as “25% Off All Men's Jackets” or “15% Off All Women's Dresses.”

Every Wednesday morning, our 3-4 assistant planners would spend 30 minutes to manually click through our website and confirm the correct discounts were applied. If the planners found any incorrect sales prices, they would send them over to our eCommerce merchandiser.

Only IT was able to change live sales prices. To keep things simpler for IT, our eCommerce merchandiser might wait and send a list to IT in batches.

That meant that even once an incorrectly priced item was found — unless it was an emergency — the pricing wouldn't get fixed immediately.

I had a problem, and the solution wasn’t far off from what I’d originally planned: an automated script that could report all incorrectly discounted items would save time by reducing the amount of work involved for our planners, for our eCommerce merchandiser, and for IT, and it would make for a better customer experience by reducing the amount of incorrect sales prices and doing so quickly.

I’d only need a master list of all ongoing sales that could be compared to website prices, but the planners told me that no such “100% accurate” master list existed, at least not on paper.

“But a fully correct pricing list exists in our heads,” they said, “because we know our products through and through. That’s why we can click through our website and spot incorrect pricing.”

After thinking about it for a few moments, I asked, “What if you didn’t have to click through our website? What if you could get all our live website prices in a neat list just by clicking a button?”

“That would dramatically speed up our price checking,” they said.

We came up with a plan: I would build a simple website that would allow planners to upload dozens of item names and immediately receive an easy-to-read list of those items’ live website prices and sales discounts.

The idea was concrete and doable. It had an impact — conserved manpower, faster QA, and improved customer experience — and I was confident in my own ability to build it (even if I didn’t yet know exactly how).

I went back to my desk and typed up a document explaining the business requirements of what I planned to build, how it would be helpful, and the Hackathon date when I would build it.

I went back to the planners and had one of the planning managers and the eCommerce merchandiser read my document. There was no time to backpedal again.

They gave me the confirmation. The idea was set, and with a week left, it was time to figure out how I was going to make this a functioning, usable reality.

I went to the engineers at my company more advanced than I was (of which there were plenty) and asked, “How would you code a script that automatically returned the website prices for items we sell?”

After speaking to several engineers, I learned that our website product pages got their prices by querying our internal eCommerce database, which in turn got its pricing info from SAP. This was a Redis database that had its own neatly written documentation showing exactly how to request any pricing info from it.

I found the engineer who had built the database and learned that I could retrieve the website prices and sale prices of a whole list of items using just a single database call.

Even though my plan was coming together, I was still very aware of how much work I had ahead of me. I tried to recruit other engineers, but didn’t find much interest, especially when I told them about my expectation for them to speak to the planners.

With no engineering teammates, I spent every moment I could after work studying the material on my own, experimenting with making database calls and studying how to write JavaScript code to read Excel spreadsheets.

Expanding to our Main Brand

The day before the Hackathon, out of curiosity, I asked our planners how they knew what inventory options to sell. They responded that our company’s merchandising department was responsible for those decisions, so I went to speak to our merchandisers.

During our conversation, they mentioned in passing something about their counterparts in our main brand.

“Our main brand?” I asked. “Aren't you guys our main brand?”

“No,” they said. “The merchandising and planning for this floor is dedicated to our smaller brand, which is 15% of our total revenue. Upstairs is our flagship apparel brand.”

This couldn’t be happening. I knew we had several brands at our company, but the day before the Hackathon, I was finding out that my project was being built for the smallest brand in our organization.

With a weaker background in coding, no other engineers on my team, and the need to do something big to impress the judges, I wasn’t looking too great.

I walked upstairs and started asking around where I could find the planning department for our main brand. I needed to speak to them if my project was going to have a big enough impact.

There seemed to be at least 20-40 planners in our main brand. Who would I speak to?

I needed to find a planner who would understand what I had in mind, but also have the knowledge base and the creative thinking to find the areas I was missing.

What if the larger brand used a different system? I needed somebody dependable, and I didn’t have the time to spread out over a few weeks.

With the Hackathon a day away, I took a shortcut.

Planning had an open office space environment, which meant people were at cubicles with no walls. I began talking about my Hackathon idea to one of the planners in our main brand.

As I spoke, I raised my voice and began walking up and down the aisle, looking around at other planners as I did so. This allowed me to get the potential attention of up to eight planners at once.

One of the planners showed a ton of interest and asked a lot of questions. He was specifically interested in our Redis database and whether other information besides pricing could be found.

I showed him our database documentation and we quickly went through it all.

He mentioned that there was other information besides pricing that could be useful, such as whether the items were listed on our website, and what categories they belonged to. He then introduced me to eCommerce merchandisers from our main brand, who agreed that what I was building had potential beyond just pricing.

There wasn’t enough time for me to make any drastic expansions to my coding requirements, but we agreed that I could build my project in a way that was flexible enough for it to be used by planners from either our smaller brand or our main brand.

Hearing about my project’s value and viability from co-workers who were really enthusiastic about it was just the push I needed.

I had the confidence, the resources, the research, and, hopefully, the ability. Even if I didn’t, there would be no avoiding it — the Hackathon was starting the next morning, and it wasn’t going to wait for anything.

Finding a Teammate

The Hackathon was a two-day affair, over the course of a Thursday and Friday.

When I looked at the calendar for the date, I realized that I had a family commitment on Friday afternoon that I wouldn’t be able to avoid. The presentation and judging would both be on Friday, which meant that I absolutely had to find a teammate who would be able to present, or the project would be dead before I’d even written a line of code.

I approached the planners from our company’s smaller brand who I’d been in conversation with for several weeks already. I asked if any of them would be able to present our project to the judges. None seemed enthusiastic. A few told me they had meetings on Friday while others said they were nervous about public speaking.

Needing a teammate, I went straight to Oliver, the planner from our main brand who had such an active interest in my project. He was a popular guy with a kind face. His hair was greying, though he was in his mid-20s, and he had surprisingly made it to the role of senior planner within just four years out of college, when most took five to eight years to get to that point. He had a lot of awards at his desk, and plenty of snacks, too.

Oliver immediately agreed to present the project and said he was excited to do so.

We went downstairs to the Hackathon’s dedicated meeting space and we signed up as a team. We needed a name for our project so we called it PriceSeeker.

There were nine other teams competing, most of which were comprised of senior engineers. Some project managers and UX designers were also part of a few teams. With the exception of my planning teammate, everyone else competing belonged to our eCommerce department.

Simplifying the Design

I had my plan in mind going into the Hackathon: I’d build a simple website that would let users upload Excel lists of items.

My website would parse the Excel spreadsheet, retrieve the list of items, and request their prices from our Redis database. It would then return to the planners a new Excel spreadsheet containing items and their prices.

With this, instead of manually clicking through our website to check item prices, they’d be able to immediately see all relevant website prices at the click of a button. It would make price-checking a whole lot easier and more convenient.

We had two days to work on our project and then present it to the judges, who were high ranking leaders within our eCommerce department. My senior director of engineering — who had introduced me to the Hackathon in the first place and taught me about making an impact — was one of the judges. He was also available throughout the Hackathon to answer any coding questions.

Excited to begin, I sat down at my computer.

I soon got up from my computer, because I had very quickly hit a wall: I didn’t have enough coding knowledge to figure out how to set up a basic HTML website that could easily read from an uploaded Excel sheet.

I approached my senior director of engineering for advice, and he suggested I simplify my design and just make a form with a text area. Users would copy items from Excel into the form and submit it.

Upon submission, the pricing would be requested from our database. The pricing would then be returned in a simple HTML table, which users could copy into Excel if they wanted.

No longer needing to write code to read Excel documents simplified things a lot.

Building PriceSeeker

Even with the help, it was still an intense day of near-constant coding.

I took some breaks to check in with our planners and get approval on the design. I grabbed plenty of snacks from Oliver’s desk. I also spoke with other engineers whenever I needed help or got stuck on the code.

I wasn’t alone, and I was grateful for the help, but it was my responsibility to keep pushing through the difficulties and put in the physical and mental effort of writing out all the code.

I was extremely aware of my disadvantage in the competition, but I was happy to find that by the end of the first day, I had managed to get a decent prototype working. It returned information for small lists of four or fewer items, but for larger lists it returned nothing at all.

The day was ending and I didn’t have the time to investigate or troubleshoot, so I uploaded PriceSeeker onto Github Pages, emailed the website address to several planners, and went home. Hopefully, a good night’s sleep and some time for responses would help me along my way.

When I got back to work on the second day, I found an email waiting for me from Oliver — he wasn’t able to get PriceSeeker working, but he helpfully sent me several screenshots showing what he’d tried.

Seeing the screenshots, I immediately realized that I hadn’t properly explained how to copy and paste items into the form. I emailed Oliver back a screenshot showing him how to do so, and he emailed me back two minutes later, showing me that it was working.

After taking some time to get into the proper headspace, I went to Oliver’s desk. There were several other planners around his desk and on his screen was PriceSeeker, which they were discussing.

Oliver had sent the website address to all the other planners on his team. The planners were discussing how amazing it would be to further explore collaboration between planning and engineering. I was excited by the enthusiasm, and especially by the possibility of opening new doors with this collaboration.

This especially excited Oliver, since he loved the idea of breaking through the barriers that siloed departments and closed them off from each other. Maybe we could create further opportunities for finding problems and impactful solutions by encouraging communication between departments.

Since I knew I wasn’t going to be around for the presentation, I spoke to Oliver, and we went over his five minute pitch. He started by displaying our working PriceSeeker website and showing it in action. He copied and pasted items into the form, submitted it, and explained why it was so useful to be able to get the prices instantly.

His demo went on to explain how “the sky's the limit,” with examples of other data that would be useful to receive. He explained the business impact of how our automation website would reduce manual effort and lead to an improved customer experience.

He concluded that though PriceSeeker currently only returned pricing, there was a lot more that was possible. It was amazing hearing him speak about the website's possibilities. He focused entirely on business terms like “reduced manual effort” and “increased annual sales,” and given that he was a planner himself, Oliver was able to talk about our project with far more accuracy than I ever could have.

When he finished his presentation, I asked questions to both learn more about our project's value and to give him additional practice at explaining its potential impact: “How much manual effort could be reduced?”

“How would automating the checking of our website data improve your abilities to order the right amount of inventory?”

“In addition to planning, what other teams or departments would benefit from automated checking of website data?”

“Why?”

I knew to ask these questions because I learned this question-asking technique from the book Spin Selling. Spin Selling acknowledges that sellers sometimes cannot present directly to buyers and need to rely on intermediaries to pass on the messages. The book advises coaching your intermediaries by asking them questions that get them to explain the product's benefits in their own words.

That’s exactly what I did, asking lots of questions that got Oliver to further explain all the many ways our project could add value.

About an hour before the judging would begin, I had to leave. I was sorry that I wouldn’t be able to be there for our presentation, but I was comforted to know that we were in good hands.

I wished my teammate good luck and asked a coworker to text me if my project placed in the top three.

The Results Are In

After leaving, I sat on a train for two hours. On the way, I mentally prepared for what would happen once the contest was over.

I'd gotten the feeling that we were the only team that had extensively started planning even before the Hackathon was officially announced. I'd also gotten the impression that we were the only team who had prepared our presentation to focus exclusively on a business impact.

I had some confidence because of this, but I was still nervous because there were so many uncontrollable things that could prevent us from reaching the top three places or even winning the Hackathon.

I kept imagining all the things that could go wrong without me being able to do anything. Maybe it would turn out we’d done something wrong and we’d get disqualified somehow. Maybe Oliver wouldn't be able to present. Maybe another team would deliver a superb presentation that rocked the house.

While sitting on the train, I realized that planning to win the Hackathon was not something useful, as it wasn’t something I could control. I decided that — regardless of the results — I would continue working on my project and implement it in a way that would lead to an increase of $20,000-80,000 in profits.

I chose those numbers rather arbitrarily, but it felt like something achievable. To reach my goal, I knew there was still a lot of work that would have to be done after the Hackathon was over.

I got off the train and made it to my family event. Part of me was still somewhere else, but I knew there was nothing I could do now. I didn’t look at my phone for a bit, which is why it took some time before I saw the text. The results were in. My team had won.

For a brief moment, I was shocked, relieved, happy. I’d reached this point after so much work, so much waiting and struggling, and it looked like it was finally paying off.

Victory didn’t last long, because now I was overthinking all the negative possibilities again. To pull off this win, I’d done a lot of things at work I’d never expressly gotten permission to do.

I'd given the link to our database's documentation to planners who quite clearly were not members of our eCommerce department. I'd hosted our Hackathon project in my own personal GitHub rather than in our company's code repository. I'd been constantly sneaking off during lunch breaks and at the end of the day to talk to the planners, which meant my coworkers could argue that I was neglecting my regular workload.

Even more than all of this, I was worried about the social repercussions. I was extremely far from any level of seniority in my engineering department, so what kind of reception would I get for besting the more senior engineers?

After the Hackathon

I made it to work after the weekend, concerned for the worst, only to find that no one seemed to care much.

When I returned, a bunch of people gave me high-fives and wished me congratulations. But my regular day-to-day workload stayed the same as it was before the Hackathon. I was told by upper engineering management that there wasn't enough engineering leeway to let me or any other engineer be given official permission to work on PriceSeeker.

Our heads of planning said they were in the midst of a major restructuring and said they wouldn't be able to devote time to my project for at least several months. I was frustrated to find that, while I was receiving positive feedback from coworkers, all my efforts amounted to a neat side project I could be proud of, but wouldn’t be able to actually do anything with.

I had a lot of work to catch up on now that the Hackathon was over, so I went back to focusing solely on my workload, with 5-15 hours per week after work spent studying Selenium best practices. It took me about a month or two working on my skills to get to the point where I was finishing my workload in enough time to have a few hours during the day to spare here and there.

PriceSeeker was almost done and there was just a bit more coding that had to be done to fix all the bugs. I felt I needed maybe a day or two more, but without official permission, it would have to be my own project to secretly complete on my own.

None of my coworkers knew I was spending time on PriceSeeker, nor did they care, since I was getting my regular work done and submitted on time.

After some considerable effort and tinkering, I managed to solve all of PriceSeeker’s bugs.

Excitedly, I headed to the planners from our minor brand to show them the working model. They told me they didn’t need it anymore. I couldn’t believe it. I was so shocked that I could barely even ask what was wrong.

As I found out, the issue of incorrect pricing had been a temporary one caused by a recent change in how pricing would be displayed. At some point after the Hackathon, the pricing displays had been updated in a way that would let planners find any incorrect pricing a lot quicker.

In hindsight, I should have realized this during the lead-up to the Hackathon, but I must have been so enthusiastic about my plan that I hadn’t properly investigated all areas where it could go wrong. Regardless of why I’d missed it, this meant that PriceSeeker had been effectively useless for quite some time.

Oliver told me that PriceSeeker as it was would likewise be useless for our main brand. However, he told me that there was an issue where items on our website would occasionally “fall off.” This meant that certain items and colors that were in our inventory would accidentally get removed from our eCommerce store.

This happened rarely, but the planners wouldn't know about it until reviewing weekly eCommerce sales reports, noticing some items had zero sales, and then checking if they were on our website. At that point, they would mark the products to be returned to our website.

Once again, this was more manual work and less productivity than was optimal, and Oliver advised that it would be very useful if PriceSeeker could be modified to let them know whether or not an item was on our website.

After going through our database documentation, I realized it would be a very simple matter to query our database to see if an item was listed on our website or not, so I quickly updated PriceSeeker to also include that check.

Oliver told me that our eCommerce merchandisers were the ones who were responsible for quality checks of website inventory and they would benefit most from this new feature within PriceSeeker. I approached the eCommerce merchandisers for each of our brands and found that they were very happy with what I showed them.

They copied and pasted hundreds of items into it at once and quickly verified that PriceSeeker was properly reporting all items that were unlisted on our eCommerce store. And just like that, they began using it several times per week.

Over the next several weeks, I continued to talk to planners and merchandisers, trying to find other areas where PriceSeeker could be useful.

I learned that our planning department had recently set up a data science team. The team was responsible for building automated scripts and dashboards to help our planners make better decisions. Reporting unlisted eCommerce inventory had actually been on their to-do list.

I enjoyed speaking with the data science team and exchanging ideas, but with no official sanction to work on PriceSeeker or anything else, our conversations were mostly theoretical. Still, I was happy to know that my project had accomplished something and was finally seeing the light of day.

It wasn’t long afterward when I got an email from my consulting company’s human resources department. They wanted to schedule a meeting.

I went in to talk to them and was told there were going to be layoffs. Several consultants would not have their contracts renewed. I was one of them. I had three weeks’ notice before my contract ended.

I knew that the fashion brand had been facing a decline in sales and firing a consultant was easier than getting rid of a full-time employee. Nonetheless I was still quite surprised that I would be among those let go.

In my last few weeks, I tidied up my regular work and gave some extra attention to PriceSeeker. I wanted to see if I could quantify the financial impact it had made, but the value of detecting accidentally unlisted inventory would not be easy to quantify.

When I went to our eCommerce merchandisers, they told me its impact would be impossible to measure. There were so many complicating factors involved, such as how many unlisted items would be detected, what brand they were from, the popularity of those items, and how much inventory remained.

Oliver summed it up, “though we can’t give a monetary value to PriceSeeker, we are certain it has a positive impact on our bottom line.”

With my contract ended, I was left looking back at around seven months in a company where I’d had some amazing adventures, most exciting of which was our Hackathon.

After our Hackathon was over, many of my colleagues told me that I won because I “focused on a business impact.” Though they meant it as a compliment, I always felt hollow when I heard that being given as the sole reason.

Personally, I credit my win to actively preparing even before the Hackathon was officially announced. By doing so, I was able to continuously get the feedback I needed to improve my proposal so that it eventually had a legitimate business impact.

I couldn’t have done it without the help of others. So much of the work felt like it was up to me, like I had to be the one to push and discover and self-teach and work.

The truth is, I wasn’t alone. The ones who offered passion and enthusiasm — my senior directing of engineering and my teammate, Oliver — were the ones who pushed me to be part of a competition I wouldn’t have ever gone near two years earlier.

I’m still learning. I’m still trying new things. I’m still hoping I’ll find more of that collaboration that enabled me to create something helpful for my company and meaningful to my own journey.

Thinking back, it’s still hard for me to believe that someone like me, who had struggled so hard to land a career, would be able to enter the corporate world and turn their life around.

For me, the Hackathon was a second chance. And I made the most of it.

Twaikura, haikus but funnier

As easy as ABC: some stranger on the Internet starts a 120 characters story, some stranger on the Internet finishes it. And that makes a Twaiku (tweet + haiku). Twaikus can be funny, serious, artistic, it’s up to you.

So, as a developer, implementing something like that shouldn't be hard, right? Yes, but no. Here is the story of how it took me multiple years to create Twaikura and how you could do the same in a matter of hours.

Back to TwentyParts and why it never came to existence

TwentyParts was my first “entrepreneurial concept” back in 2015. As you may guess, the idea is to write a story in 20 parts, with each part written by a different author.

I was a CS student at the time and it took me 2 months to release a first draft. The result was disastrous. I didn’t even know about the concept of a “framework”, picture the code. The concept was too complex, the interface unusable.

I did not give up. A few months later, in 2016, I came up with a simplified version of TwentyParts, HiKoo. I limited the length of a story to 3 tweets. And instead of rushing to development, I created mocks using a marvelous tool named MarvelApp.

Now I had a great UI and all, but no working code. One more app that never came to existence.

Looks good, doesn't work

Fast forward to now. I’ve graduated. I’ve built my consulting company, LBKE. I’ve developed complex SaaS platforms for multiple clients. And I've kept this question running in my head:

What prevents me from recreating TwentyParts, now I am fast and skilled and over-confident?

After all, it would only take a full work week nowadays. Yet there’s a problem: I am not a student anymore. With one spare hour here and there, a “full work week“ can span over a few months. Too slow.

How to code fast: don’t.

I’ve explored thoroughly the realms of fast web development. You may have read my previous articles on freeCodeCamp about Vulcan, a framework based on Meteor that makes me very productive.

Those researches all lead me to the same conclusion: the best code is the code you don’t write.

There are a lot of ways NOT to write code, even for a developer. Scaffolding, declarative programming, using snippets, or using an ORM are all methods to circumvent writing code. Using open source is another great example. Some may even think that developers are a bit lazy – but aren't they?

Yet minimal skills in web development are still necessary. That means careful thinking, lots of doc reading, debugging and so on. In the end, the time needed to create a fully functional app can only be reduced this much.

You know what? Using a massive framework to speed up developments feels like cheating sometimes. What if I did not have those skills? What if I was not a developer? I would have no other choice than embracing the “no-code way”. And that’s what I’ve done.

Relax, Code will be on vacation for the remainder of this article

Sparkling innovations for web non-developers

No-code solutions have been pretty bad in the past. Limited, difficult to extend, proprietary, expensive, the list is long. But some recent tools are starting to be worthy enough.

I will focus specifically on Bubble. Its plugin system coupled with its data management features makes it the most complete solution on the market currently. Here are a few key features and how I used them to build Twaikura.

The UI editor

Bubble proposes a WYSIWYG editor (What You See Is What You Get) to create the app user interface. You put your blocks of content wherever you want, and configure their content.

It’s grid-based so you can have pixel perfect alignment. It handles responsiveness. So you should be able to create designs as complex as you wish.

Building Twaikura's interface using the WYSIWYG editor.

But I’ll be honest, I am not the hugest fan. More precisely, I am not very good with it. It’s very different both from writing HTML/CSS and from using web-based design tools like Figma, so there is a learning curve.

I ended up sticking myself to an old school Windows 98-ish style. With a little bit of imagination you could even believe it has some “V a p o r w a v e” aesthetic.

Thinking in workflows

The most impressive feature of Bubble to me is its “Workflows”. It lets you describe complex process in a visual language. It can mix data management (validating and storing a Twaiku, sending an email) and user experience (resetting a form, refreshing the page) transparently. You don’t need to mentally split the workflow between frontend and backend as you would do in a traditional web app.

Twaiku creation workflow

This example workflow is triggered when the user wants to submit the second part of a Twaiku. It will create a "Twaiku End" in the database, link it with a "Twaiku Begin", and reset the form. I could also display a success message, send a mail to a moderator and so on. Visualizing the full workflow in a single timeline is very intuitive.

Complete data management

Bubbles comes with a relational database and complete filtering features. That means you can easily create both forms and list of data. For example, the “Read latest Twaikus” block will load all valid Twaikus.

Plugins can help secure your content. For example, there is a ReCaptcha plugin to add CAPTCHAs to your form in a matter of minutes. This is important as security is usually left behind in the prototyping steps. Malevolent bots and hackers don't care that you are a "lean startup-er", and they won't miss an opportunity to spam or hack your website.

A few hours of work for an app that works

I won’t describe all features of Bubble, because it has a lot more. The conclusion is that it's been powerful enough to write an app like Twaikura. Instead of writing tons of crappy code that will end up in a dumpster, instead of creating a visual prototype as lively as Frankenstein’s Creature, I just created something that works.

Is my website great? Honestly, not yet. Does it do the job? Hell yes. I had fun creating it, it cost me no more than a few hours, and I am able to test the concept in the most direct possible way. The longest part was writing this article.

I especially recommend no-code tools for people who want to learn web development. Taking a lot of time to produce simple features can feel frustrating at first. Using a no-code tool alongside traditional programming is a way to keep having fun. It's instructive too, because, even if you don't write code, you still have to think like a developer: designing conditional workflows, structuring a database, validating forms... That's a win-win.

I won't become a no-code evangelist, but Bubble is a great addition to my tool belt. And it could be great addition to yours too!

Thanks for the read. If you liked this article, come try a Bubble app by creating your first Twaiku on twaikura.com!

And people search this question a lot, too. It's one of the top autocomplete options when you google my name.

So for everyone who's interested in my relationship with money, I've got good news.

I work full time at freeCodeCamp.org – a 501(c)(3) public charity. And since I'm on the board of directors, it means my compensation is public.

freeCodeCamp has earned GuideStar's Platinum Seal of Transparency for 2 years in a row. You can go there and browse our nonprofit's full 990 tax returns over there.

But in case you're in a hurry, I'll save you some effort.

I made $60,000 last year.

That's less than I did in 2010 when I was working as a teacher.

And that's after several years of not accepting any compensation at all from freeCodeCamp.

What's more, I put around $150,000 of my own meager savings into freeCodeCamp over its first 3 years of life.

Quincy - How did you have $150,000 saved up in the first place if you were just working as a teacher?

This is usually the second question people ask me. $150,000 is a lot of savings for a 30-something American to have on hand.

The answer is that my wife Jade and I are compulsive savers.

We worked for more than a decade and squirreled away as much as possible.

We also lived in China for much of that time, where the cost of living was much lower than in the US.

We managed to stay debt free by renting small suburban apartments, cooking our own meals, and studying at inexpensive public universities.

Our hobbies were either free or cash-flow positive.

For example, I would spend my weekends buying old arcade machines and video game systems on Craigslist, then selling them on eBay.

We were saving up to afford a downpayment on a house in the San Francisco Bay Area – the most expensive housing market in the US.

When freeCodeCamp.org started to take off – and millions of people started to use it – we decided to abandon those dreams of owning a home in San Francisco.

Instead, I put that downpayment money toward paying for servers and getting help with freeCodeCamp's growing curriculum.

How did you stay afloat for years with negative income?

Jade and I did two critical things to make this work:

1. Jade kept working full-time in accounting at a software company. Her benefits saved us $10,000s per year in health insurance costs – which are just a fact of life for people here in the US.
2. We left San Francisco. After our daughter was born, we moved back to my home town of Oklahoma City – one of the least expensive places you can live in the US.

We did what we could so that the freeCodeCamp community could continue to grow and thrive.

But this is not one of those "anything is possible" inspirational stories. Jade and I came from backgrounds of relative privilege. Both of Jade's parents went to college – which was rare in China at the time. And my father went to college, too.

The stars lined up for us. This made our many sacrifices non-fatal.

For most people, quitting your job to start a nonprofit would be a path to financial ruin. But since we had both worked for nearly a decade, we had the savings and the health insurance to see it through.

One thing's for sure, though. If my daughter had been born one year earlier, freeCodeCamp wouldn't exist. I would have had give up my dreams of running an education NGO and instead go get a job to support our family.

Baby Jocelyn checking in

But as fate would have it, Baby Jocelyn was born after freeCodeCamp had already been online for 11 months. And in that 11 months, Jade had seen how many lives it was touching.

I was able to convince her that one day this would be a viable nonprofit, with enough donations coming in that we could keep it going.

Where we go from here

freeCodeCamp is now one of the biggest programming sites on the internet. We have 1,500,000 YouTube subscribers. Our forum is now second only to Stack Overflow itself as a place to get programming help.

And we are only 5 years into our mission.

The good news is that this year we are now "break even" – meaning I haven't had to plow any more of my personal savings into freeCodeCamp. We are finally able to cover the cost of servers and payroll.

January 2018 - with Baby Quentin in one hand and freeCodeCamp's IRS Determination Letter of our tax-exempt charity status in the other.

But freeCodeCamp's budget is still comically small. To put our 2019 budget of $373,000 into perspective: I know individual developers in Silicon Valley who earn more money than that each year.

And we're trying to use that tiny sum to run a global nonprofit organization, and one of the world's biggest websites.

We can do so much more once we have a bigger budget to work with.

And I say this as someone who has personally spent $150,000 of his hard-earned teacher savings to help get this community off the ground.

If you've read this far, you clearly care about the freeCodeCamp community. So donate to freeCodeCamp. You'll be able to deduct it from your taxes and everything.

You can make a one-time year end gift here.

Or better yet – if you want to help us increase our monthly budget – you can make a monthly gift here.

With more resources, we can help more people around the world. We can create more free programming courses for you and everyone else. And we can expand our curriculum faster.

Thanks for caring about the freeCodeCamp community – even if you just clicked through to see if I was secretly a millionaire. (I'm not. With my home mortgage, I'm not sure my net worth is even a positive number ?).

Have a fun, blessed holiday season with your friends and family.

I'll be right here, working to make freeCodeCamp an even better learning resource for you, your kids, and your grandkids.

There is so much more work to be done.

Ruben runs Career Karma, a social network for people interested in attending coding bootcamp. He also hosts the Breaking into Startups Podcast.

Ruben just finished Y Combinator, a startup accelerator, where he and his team raised their first round of venture capital funding.

Ruben grew up in Atlanta and worked in finance. He met his future co-founders - Ukrainian-born brothers Artur and Timur Meyster - years ago. The three of them agreed to spread out, get jobs in different industries, then later regroup to build a startup together.

Ruben and his co-founders Artur and Timur on stage at an event.

In this interview, Ruben shares his insights on coding bootcamps. He also shares what he learned going through Y Combinator. And he talks about his close bond with his co-founders.

Communication and the power of stories

Ruben attributes much of his success to his skill at telling stories - a skill he still works to refine every day.

"It's easy to think that the way you're going to rise is through your skills technically. But the way that you rise is actually through your non-technical skills and understanding how to communicate and be creative and manage your perception - which is also your story."

Ruben failed to get into Y Combinator the first time he applied. He attributes this failure to challenges he faced when communicating what Career Karma did and the value it could provide people.

He and his team had the coding chops. They knew a lot about higher education. They understood the role coding bootcamps played in the labor market. But they had trouble conveying all that.

Ruben pinpointed communication as the thing that was holding him back. He said the team made a decision to "recognize that we may not have everything figured out. And investing time in figuring it out will pay dividends later."

His hard work did indeed pay off. Career Karma got into Y Combinator, secured investors, and have been growing since.

Breaking into Startups

Before Career Karma, Ruben, Artur, and Timur created a tech career podcast called Breaking Into Startups.

Ruben says was inspired to start this podcast after moving to San Francisco and getting a job in tech. He realized how bad most of the advice out there was for people who were looking to do the same.

"The advice that was given to me was if you want to break into tech, just move to the west coast, this magical place. You'll figure it all out. But for most people that's toxic advice. Most people will go through a psychological breakdown trying to make that transition happen. And the industry will chew them up."

He wanted Breaking Into Startups to give people a more realistic glimpse into what career change was like.

"We wanted to start documenting those stories on the podcast because the tech media wasn't really covering a lot of those stories. We realized for us to understand the shifts, it was important to talk with other people that were like us, who figured out how to get into these companies. So that's why we started featuring stories from people who were older or younger, from different sexes and religions, veterans. And we created a podcast around that became a source of truth and tactical advice that didn't really exist anywhere else."

After having recorded more than 100 episodes over a span of 3 years, Ruben summarizes the commonalities between many of his guests:

"At the end of the day, nobody has it all figured out. And similarly, when you're in a coding bootcamp or you're trying to learn a new skillset, you get imposter syndrome. But what actually eliminates impostor syndrome is realizing that everybody's lost."

He continues:

"If you feel comfortable, that's your body telling you that you're ready to push harder. You're not growing. Challenges give you growth. And growth is life."

Vocational Training as a Path to A Better Career For Millions of Americans

Ruben - himself a university graduate - is a champion of vocational education.

Pointing out that more than 7,000 Americans drop out of high school every day, Ruben says:

"The only way to level up is through education. And I think that form of education is going to be a bootcamp that's run on its own, a bootcamp that's run by a college. I actually think that the big future is going to be employer-as-payer model. And you can see that with Adobe doing Adobe Digital Academy, you can see that with Microsoft, you can see that with Cognizant. With all kinds of things like that."

He continues:

"And the reason I think that is in the US alone, over $1 trillion is spent on post-secondary education. A lot of that training and education comes from corporate America. Companies are going to realize that they have to build talent in addition to buying talent. They spend so much money on university recruiting and events that have a very low return-on-investment. I think that apprenticeships are at the same stage that bootcamps were in 5 years ago, and they're going to become more and more en vogue."

Listen to the full interview

These are just some of the insights Ruben shared during my interview with him.

We also talked about his life growing up in Atlanta and the role of his parents and his faith.

I've learned a lot from Ruben over the three years I've known him, and I think you'll learn a lot from him to.

This interview is a 75 minute listen in your favorite podcast player app - just search for "freecodecamp" and you should find it.

If you have an Amazon Echo, you can just say "Alexa - play the freeCodeCamp podcast."

Or you can listen to it right here in your browser.

Other helpful links

You can listen to Ruben interview me back in 2017 on this episode of Breaking into Startups (50 minute listen).

During the podcast, Ruben also mentioned an interview he did with Gary Vaynerchuk (45 minute listen).

Ruben mentioned this article by his co-founder Artur Meyster, about his life after completing a coding bootcamp.

Finally, you can follow Ruben on Twitter.