#edutech #college #work #NFT #education #remotework #onlinelearning #stem #talent #diversity #highered #STEM #blog

Every time a new software product or service is announced the same question always comes up:

"Why build this (x) when (y) already exists?"

Some folks ask this rhetorically, implying there's no good reason when something similar already exists. They ask this question with a smug grin and think they've got you.

But when I ignore the troublemakers for a moment, I can imagine there are folks who legitimately wonder this. Perhaps they've had an idea for a product but it already existed in some form, and this fizzled out the desire to pursue it further.

So let's try to answer this. Why should we build X when Y already exists?

It increases the odds you'll pick an idea with good product-market fit.

If no one is fixing the problem solved by your product idea, it's likely for one of two reasons:

Not enough people have the problem.
No one pays to solve the problem.
It could also be, "The problem is so hard that no one has cracked the code on how to solve it.", which isn't very likely. In reality, where there is competition in a given problem space, it's a sign that you're working in a vetted, established market. This is a good thing.

People want something specifically optimized for their use case.

When Chris and I started building Chipper CI, one of the questions we asked was whether it should exist at all. There are countless continous integration systems available...some of them are even built-in to our remote Git providers. What's the point of creating something new when one already exists?

The point is all of the other options aren't optimized for the use-cases we care about. With Chipper CI we are building the tool we want to use. And the tool we want to use is smaller than everything else. It does less on purpose.

For example, I want it to be focused on Laravel. I don't care if it has a granular permission system. I don't care if it can handle a complicated app. I don't care if I can roll my own using cheap DigitalOcean servers and some bash scripts. All I want is something that will run my unit tests, run my browser tests, and kick off a deploy.

I wanted to pay someone to make the "Easy Laravel CI" problem go away. To invent a solution so impossibly simple that I'd never have to think about it again. But no one has, so we thought we'd try.

At the end of the day, there are hundreds of thousands of developers in the world and no single product serves all of their use-cases. There's always room for a new take on an old problem.

People want something official.

When I was dreaming up the foundation for what would eventually become Laravel Nova, there were already well-established, free, open-source solutions available. But Taylor and I created a new one anyways. Why?

For years people had been asking Taylor for a first-party admin panel for Laravel. There were other admin panels people were using, or people were rolling their own. However, none of them became the de-facto choice for Laravel.

In my mind, the fact this problem wasn't solved yet inside the Laravel ecosystem was a huge opportunity waiting to be embraced. So we built it. People seem to appreciate having a first-party solution to this problem. Some of the feedback I hear on Nova goes something like this:

"I know there are 2 major competitors with lower prices than you, but the fact that you're officially supported gives me confidence that it'll be supported in the long run."

People want support.

When people part with their hard-earned money, or the money of a boss who will fire them for spending it unwisely, people prioritize different things. One of those things is support. People want someone to ask questions, whether that's the project maintainers, support staff, or a community.

There may be good, free options available on GitHub, but who do you ask when you get stuck? What if there's no documentation or the documentation isn't good enough?

Creating a product that is simply well-supported is a good enough reason to reinvent the wheel.

Because You Want To.

Of course, I'm not the first person to create invoicing software, but people choose PushSilver anyways. The reason is it fills a painful need for a very-specific market who is willing to pay for the problem to go away.

I didn't go out to create a new invoicing platform to compete with the other solutions. In fact, I didn't really intend for it to be used by hundreds of people. I created it primarily for the joy of creating things. I created it so I could develop skills that would later prove useful when launching my "serious" products. Just because I wanted to.

And that is a good enough reason.