Recently, I've run into a few big ideas that make me feel like it's 2010 all over again. In the worst way. They remind me that back in the heady days of 2010, we were fools for apps.

Need to know what song is playing on the radio right now? App! Are new-hires lost in your office and you want to give them a map? Enterprise app! Need to order a sandwich from the independent deli on the corner? Whitelabel app!

Ultimately these all fail the core test of making a product: they have identified a real need but fail to fulfill it better than the competition.

What do I mean by that? Well, let's look at our examples: if I want to know what's on the radio right now, does it make more sense for me to open an app and see it or should I just turn on the radio? If I need to help new-hires orient themselves in my office, should I hire someone to make a map app, get an enterprise distribution certificate for the app store, and debug issues people have installing that app, or should I draw a map and give them a photocopy? If I want to order a sandwich from the deli, do I install their one-off app, make an account, and place an order or do I just walk down the street?

In all of these cases, the competition isn't another app, it's a better way of solving the problem. Even though the wild crappy-app days of the 20-teens are behind us, this lesson still holds true when we think about designing products today.

What's wonderful about this is that you can usually find a way to achieve your goals far quicker and cheaper than by building a full app. Here are some alternatives you need to consider before you dive into the world of designing and developing a full-fledged app:

1. Info-products

If the goal of your app is to communicate something to your users, the first question to ask yourself is whether that could be better accomplished by written words or videos. Simplifying your product to an info-product like this has two big advantages. First, larger media platforms like Substack, Skillshare, Teachable, Gumroad, or even Youtube are almost guaranteed to reach a larger market than a purpose-built app or site. Second, you can often communicate your ideas and make a sellable product in drastically less time than if you were trying to capture those same ideas in the framework of an app.

2. Communities

If your app is trying to bring people together but not necessarily to form a market, you might be better off hosting a private Discord or building a community site on top of a platform like Circle, Tribe, or Dev.to's own Forem. Communities especially are an interesting opportunity when added on top of info-products, as they give you the chance to keep your customers engaged with you between releases of new content.

3. Webapps

While still kind of an app, web apps are much easier to build, maintain, and distribute to users than a native app (especially given the wealth of Nocode tools for building them). Let me stress this point, the simplicity and speed of launching a website makes the stress of launching a true native app feel like hiking Everest. Web based apps can also make much more sense depending on the context you expect your users to be in when they need whatever solution you provide. If you think a user is going to be at work on their computer, for example, it makes more sense for your product to be a website rather than an app that will require they switch contexts to use it.

4. Non-tech Products

Finally, does your product need to be a tech product at all? Let's take a hypothetical product of "COVID-friendly activities for office bonding" for example. For version one, you could jump straight to building this as a productized digital app experience that can lead customers on group tours or scavenger hunts. But, you will be able to execute more quickly, get more feedback, and generate revenue immediately if you instead take the old-school route and lead your first few experiences personally. Once you have run a couple sessions, you'll have money in the bank and a much better sense for the pacing and content that leads to a good experience, and from there you'll be in a much stronger position to think about app-ifying your product.

And therein lies the last, most important lesson here. Choosing not to app-ify your product from day one doesn't mean you'll never turn it into an app or other digital product. Rather, this is about developing your product intelligently. If you jump straight to an app without validating your guesses about what will solve your users' problems most effectively, it's likely you'll build the wrong thing and wind up wasting all that effort. The App Store is already littered with the abandoned corpses of apps that failed to learn this lesson, don't be another one of them.