Mo’ Code, Mo’ Problems — Engineering Advice for Non-Technical Founders | By Michael Lynn | February, 2023

Do things that don’t scale.

I often hear similar startup stories play out among founders. It looks like the following.

1. They stopped their work
2. They spend 6 months building a product
3. They start
4. You will get 0 customers

And then they run out of savings and wonder what went wrong.

That’s the issue. They spent a lot of time on engineering, trying to recreate the beautiful apps on their phones for their startups.

But the software we use every day is the result of years of iteration and thousands of engineers working together. In the early days, many popular apps weren’t as fancy as they are now.

Startup founders can’t copy what Big Tech companies are doing because they have more resources. Instead, startup founders should prioritize speed by cutting features, abandoning their perfectionist tendencies, and making their MVP less than a month old.

In this article, I’ll share 3 engineering “techniques” to quickly launch an MVP. These tips include:

• First of all looking for no code solutions
• Instead, replace engineering with operations
• Collect emails before building the entire product

These 3 techniques will save you months of engineering work so you can focus on what matters: building sales and distribution channels.

One mistake founders make when building a startup is rushing to hire engineers first. However, developers can build most MVPs on their own using code solutions that use drag-and-drop features. They require no engineering knowledge to use at all.

For example, if you want to build a website, there are plenty of no-code website builders that you can use instead of trying to build one from scratch.

Similarly for marketplace startups, there are many marketplace templates out there that you can use instead.

As I often tell clients, “More code, more problems. Coding is difficult, time-consuming and expensive. The more you can get away with using codeless solutions, the better. Here are some of my favorite no-code tools I’ve collected over the years:

• Website-builders: Umso.com (my favorite), Ghost, Notion + Super.so, Kajabi (used by Justin Welsh), Webflow (has a big learning curve, but others like it)
• Credentials: testimony.b
• Design Templates: Canva
• Forms to be taken:- Kind of shape
• Scheduling: Calendar, Acuty schedule
• Email Collection: Umso, Carrd, ConvertKit, Notion + Super.so + Chilipepper
• Codeless Mobile App Developers: Flutterflow, Wappler.io, Adalo, Appgyver

But what if there is no perfect solution?

Often times a founder will tell me that an off-the-shelf solution doesn’t exist because it lacks certain features. But you can still use no-code tools for your product components and only write code for features that aren’t included.

For example, entrepreneur Rahul Pandey and his CTO Alex Chiu are the founders of a career mentoring app called Taro. Even though they are engineers by training, they still use off-the-shelf solutions where possible.

While their app allows users to ask Rahul questions, it needs a way to send community-wide ads. Instead of building this, they put all their members in a separate Slack community and use the @all command in Slack to ping everyone for updates.

These two former meta engineers are able to build these features, but they are still looking for opportunities to reduce the work by combining existing solutions. By not having to rebuild notification features, they save months of engineering time and can instead focus on their core product.

So if a group of former FANG engineers took shortcuts using no-code solutions, it’s a lesson for all founders to avoid reinventing the vehicle as much as possible.

💡 Tip: Before building anything, always google libraries, templates, and tools that can do the job.

Former Uber CEO Travis Kalanick once said, “Product is slow, but ops is fast.” In the time it takes engineering to solve a problem, the founders could quickly solve it. Therefore, founders should only use engineering when they are overwhelmed by operations.

The most famous example of this is with Streep’s Patrick Collison. When he founded Stripe, he never built “onboarding” flows for customers. Instead, they installed Stripe on their handhelds, saving their engineers from a lot of UI work.

Doing things manually is a way of proving the importance of a feature. If you wait until you get enough customer support emails to build a feature, you’ll know it’s worth doing the engineering work because it cuts down on work.

Furthermore, many of these features are edge issues that founders ask engineers to solve. By definition, they don’t happen very often, so instead of waiting for everything, it’s a lot less work to keep it on hand.

And by relying more on operations to cover customer issues, you may find that you never build the feature you want.

I discovered this myself when I built the login page for RecordJoy.com.

Example: RecordJoy’s missing “Forgot Password” feature

RecordJoy.com is a screen recording website that I bought in 2021 with MicroAcquire as a business partner.

When we bought Recordjoy, our first task was to monetize it by adding in different payment plans. But to do this we had to build a way for users to create an account or else we wouldn’t be able to charge them.

So in the process of building these registration pages, we realized that we need to build many small features to make them work properly. One of them was the “Password Reset” flow.

Normally we take such features for granted. But since we were on a deadline as a two-person company, we cut the “password reset” flow as you can see in the image below. Instead, customers had to send an email if they wanted to reset their password.

Customers noticed that this feature was missing. In our 1-year history of RecordJoy, we’ve only received 2 emails from customers asking us how to reset their passwords. And for those two customers, we manually trigger a “password reset” email through Google Firebase, which is a backend database.

Handling these two emails costs us 10 minutes, but building the screens takes a day or two. This may not seem like much, but small tasks add up. And when you consider the possibility of building a password reset flow and spending that time improving core features, these small tasks become more valuable over time.

So the lesson here as a founder to reduce the scope of engineering:

1. Consider whether you can handle the engineering work yourself. This includes obvious things like password resets or onboarding flows.
2. Consider whether any features you’re asking for are edge cases or a critical part of the user journey. If they are edge cases, it may be better to cut those features.

My last tip to reduce engineering time is to make your MVP an email collection page and launch that first.

The reason to start with an email-collection list is threefold:

First, building an email landing page is faster than building a complete product. You can launch an email collection page in a day or two. And it lets you focus on generating traffic for your website sooner rather than later, which is what you need to do even if you outsource your product.

Second, the further you get into your product, the less you will need to engineer. Most of the products are like smallpox. The more the user clicks, the more people will crash. So building a one-page email collection page will focus your work on the home page with the most traffic anyway.

Finally, this email list can be the foundation of your future product, as many successful businesses started out as just a newsletter before growing into a full product over time.

Example: AppSumo and Noah Kagan

App Sumo is a marketplace to buy cheap software products with lifetime discounts. It’s a 9-figure business at this point, and one of the amazing things about this marketplace is that Noah Kagan didn’t make the current version of the website until 2019. It first started as a newspaper.

In fact, you can see the first iteration of AppSumo back in 2010 when it was just an email collection page. The sad thing is that he built this list of over 150,000 people by collecting email addresses for 3 years, and 50% of his revenue comes from his email list, and 6.7% of all organic leads to his website. Traffic!

The brilliance of this is that the newsletter creates value for its customers faster than a website. It may take time to generate traffic to a website, but with a newsletter, you can email them next week with software deals.

Second, Noah combines this strategy with the previous method of leaning toward an “ops-heavy” approach to replacing email list engineering. Initially, if software companies wanted to list, he had to submit it manually. If his product is popular, he did this process automatically through the website.

Compare this to how most people build their products. Many founders start by building a marketplace and then running into a “cold start” problem where there aren’t enough buyers or sellers on either side to make the marketplace worthwhile. By building the newspaper, he confirmed that there was enough interest to justify the engineering work to build the website.

His company is easily worth over $100M, and it all started with an email list. Your email list can be the humble beginning of your big business idea.

Many founders have misconceptions about engineering, thinking that engineering is about writing code.

Engineering is not writing code. Engineering is about solving business problems in a simple way. And the best way to solve engineering problems is without writing any code. as if

• Using the available solutions
• Replacing engineering with operations
• Using email newsletters as an MVP

You can eliminate all the engineering headaches and launch your billion dollar idea quickly. I’m rooting for you!