I coach my youngest son's little league team. I've coached these same boys since they had just graduated from t-ball to coach pitch, so there have been plenty of opportunities for lessons. However, there's one lesson I use every practice with them: take the easy path.

Baseball is about mechanics, repetition, and mindset. But if you've never been taught or something is new to you or if you've been doing something the same way for so long you've never thought to do it a different way, you might find yourself making life significantly harder than it needs to be. For example, many of the kids I coach struggled with catching a baseball when they first joined the team. They would start with their glove by their sides, and they would have the pocket pinched closed. By the time the ball got to them, they couldn't get the glove up in time or didn't open the glove wide enough to make the catch.

In these cases, I would ask if they wanted to make life easier on themselves. Of course, they said yes. Even at 6 or 7 years old, no one wants to make things harder. I would then show them the easy path. Keep the glove up and ready. Bend the tip of the glove to make as much space in the pocket as possible for the ball.

I've given this same advice in various other aspects of the game so many times. Do you want to take the hard path or the easy path? It's something I now have unintentionally seared into my brain, but it's become applicable beyond little league baseball.

Startups struggle with choosing the easy path often. Whether it's engineering or customer development or marketing, early-stage startups, especially run by first-time founders, tend to take the hard path more often than they need to. I've seen this in the startups I mentor, my own startups, and even at Pinata where I currently work. This doesn't happen because people want to take the hard path. As we learned from the little league example above, from the age of 6, I know people want an easier option if available.

The trouble is the availability of the easier option.

The advice I give going forward is generally applicable to pre-seed, seed, and Series A companies. Beyond that, you're probably necessarily optimizing for scale and complexity as you either go upmarket or attract a significantly larger customer base. However, if you fall into these early stages of the startup lifecycle, taking the easy path should be your default.

Let's run through a few examples to help illustrate the point. Assume you're using content to drive your SEO positioning and grow your top-of-funnel. I've seen too many founders and early marketers bring the playbooks of large companies. They will turn to Hubspot and bow at the altar of IPO-scale optimization. They will spend more time analyzing and tweaking the system than they will writing. The antidote to this is to–you guessed it–take the easy path.

Find something with built-in distribution and SEO dominance. For Pinata, in the early days, it was obvious that Medium was the place for our writing. We targeted developers, Medium had a built-in audience, and Medium articles were constantly ranking high in search results. So, we took the easy path and we launched our blog on Medium. It wasn't until 4 years after Pinata's founding that the blog was moved to Pinata's own domain and effectively off Medium (we still syndicate some content there). The easy path was both easy and effective. This is often true and the earlier you are in your journey, the more easy options you have.

Let's consider engineering. I don't mean to pick on developers (I am one after all), but engineers are notorious for taking the hard path. I think about this comment on Quora a lot.

It's better than under engineering isn't it?

It's not, actually. Not in the early stages of a company. I understand the fear of tech debt, but tech debt is opportunity. Show me a company with tech debt and I will show you a company that prioritized the easy path and put themselves in a better position to grow.

The symptoms of over-engineering are plentiful, but here are a few before we dive into an actual example.

One of the clearest symptoms of overengineering is trying to address all corner cases of the application. A corner case is a situation that occurs outside normal operating parameters.

An example of a corner case can be a user trying to order 20 Uber cars for all his friends at the same time from one application. While such a corner case is technically possible, it is not very common. The question for development teams is thus – should we spend time and money to make sure that such a scenario is viable within the app? Probably not.

Another symptom of overengineering is trying to achieve a perfect solution, rather than a good enough one. Think of a team that deliberates for ages over whether the background color in the app should be #FBFCFC or #F7F9F9; or a developer that spends days making sure their code is cleaner and more modern than anybody else’s.

Chasing innovation for the sake of it is another example of overengineering. It’s quite easy to go down this road. Most developers are innovators and they love experimenting and staying on top of the game. While this has to happen to a certain degree, what products often need is not trendy technology, but a fast time-to-market.

It's easy to justify over-engineering but hard to find a simpler path. One of the last companies I started, we were a three-person team. To create our web app, we used React (good, easy path). However, things went off the rails from there. One of the co-founders decided to host the web app, a static site that pointed to a more complex server (a story for another time) on S3. That's the first red flag. This was in 2019, and while the options weren't as plentiful as they are today, there were plenty of simpler options.

Why is Amazon's S3 not the easy path? Because we spent almost as much time configuring the bucket to be accessible in just the right way to make it useful for serving our web app. We spent a large chunk of time working on mapping our custom domain to the bucket. The build system and deployment pipeline we built was largely custom. It cost us time, but hey it was cheap!

Hear this though. Time is the most expensive thing an early-stage startup can spend. Money is cheap. Time is not. In 2019, Netlify was the leader in hosting static sites and applications. The easy path would have been to deploy to Netlify and pay them $20 a month.

The easy path is not always obvious. Whether it's engineering or marketing or any other function in a company, you may not be able to find the easy path on your own. Go back to the beginning of this article. People choose the hard path not because they want things to be harder, but because sometimes it's all they know. When you work in isolation, you are more likely to choose the hard path. By collaborating with your team, you open yourself up to the possibility that someone else on the team might know a simpler way. Or that someone else on the team might know a way to shrink the scope of the problem to make it easier to take the easy path.

Finding product market fit and generating revenue are the two most important things you can focus on in the early stages. This applies to every person on the team, not just the founders. Notice that I didn't say reducing costs? Early on, the easy path might mean spending more. Doing so strategically and in service of the easy path is fine. Spending weeks optimizing home-grown infrastructure to save a thousand bucks when you could have been getting customers is not.

The next time you're faced with a problem, try to take a step back and see if there is an easy path you should be taking. There will be plenty of time* for optimization and clean-up later when you're actually making money.

*Not really, but it will happen anyway