Personal Applications

wrannaman
NoCode
Published in
4 min readJan 9, 2020

This was originally posted to https://blog.noco.io/personal-applications/

No-code is a shift in mindset from “Is there an app for this?” to “I can build an app for this!”

By definition, startups find problems that many people have that can be solved in a similar way by one single product. It’s a tall order. Some people like to solve it one way, and others are used to another workflow. Broadly, this has worked fine, as the problem the startup is solving should be painful enough that they overcome many of the shortcomings of the producing, including changing the way they accomplish a task for the sake of speed, efficiency or perhaps some kind of intangible.

This isn’t a very interesting observations. Companies solve problems many people have. The more the merrier. In this post, I want to explore the opposite kinds of problems. Problems only a few people, perhaps only one person . I’ll call the application built to solve this problem a personal application. A personal application is one where it solves a problem for the few, not the many, in just the way the few or even the individual want to do it. These are opportunities too small to build a company off of because too few people have them. The problem being solved is highly unlikely to be a trend. In short, it’s a terrible startup idea. Or rather, a highly successful startup solving a problem like this would quickly become insolvent.

The line of reasoning I’d like to explore is something like:

  1. There are a ton of problems in the long tail of work “people get paid to do”
  2. Because those problems have a small number of people who encounter them, it’s unlikely a startup will emerge to solve this problem, and / or existing tools that “work okay” to solve this problem only solve some suboptimal percent of the problem
  3. These kinds of problems are perfect for no-code solutions to step in and solve.

In short, I want to explore changing your mindset from “Is there an app for this?” to “I can build an app for this.”

What We’re Not Talking About

If you search the app store for something random, there will likely be an app close enough to do what you need it to. This works great for the consumer trying to solve relatively simple problems. “I want to track my fitness, sleep, cycle, etc”. You can toss through dozens of apps or websites until you find something “good enough” and you can move on with your life, most often for free.

This is not what we’re talking about. This would still be considered a problem “a large number of people have that can be solved in a similar way”. Let’s take sleep for example. Humans sleep. A sleep tracking app should track sleep. Perhaps there are some extra widgets you prefer from one company over another but basically they’re the same. If you were starting a business in this space, and you had an app that tracks sleep, you’d be fighting tooth and nail to differentiate.

Consumer products are broadly simple enough to find a good enough solution. We’re going to be focusing on more complex use cases. Think “things we pay people to do” type of complexity.

What We Are Talking About

I’m going to try and avoid contrived scenarios so opaque they make any existing tool seem useless to solve it. At the same time, an example is helpful. Let’s pick an abstract workflow with 3 steps in it.

  1. user submits a form
  2. form is reviewed by Employee A and assigned to Employee B
  3. Employee B does the tasks and returns it to the user.

Concretely, what workflows look like this:

  • Insurance reimbursement
  • Many services like a copywriting service or a legal service
  • Internal business apps, like submitting a budget, a performance review, etc.

The unique parts in here that make it challenging are the mix of internal and external needs. If you want to think of the “users” as other business units within a single enterprise, that works too.

A typical enterprise will solve this with a mix of google products, like google forms -> google sheets-> perhaps to some ticketing system like Jira or Monday -> then deliver the final “thing” over email. The no-code folks would likely spaghetti a solution together with zapier, typeform, and email.

But what if, upon closer inspection, it turned out that the employee submits a PDF. And you found that Employee A spends 4 hours a day pulling data off the PDF to give to Employee B. Now this becomes a ripe problem for a no-code solution to solve. This isn’t about replacing anyone, it’s about augmenting.

The “correct” no-code solution would likely look like this:

  1. User submits form / PDF
  2. OCR is done on the PDF to pull out the relevant information and automatically assigns it to Employee B
  3. The end user gets the result faster because Employee A no longer has to sift through PDF’s searching for information.

It’s a classic business optimization problem that uses technology to cut out menial tasks. Yet we’re only at the beginning of the adoption of this kind of thinking.

In speaking with people so far, the most common response is something like “I didn’t know this was possible”. That will change in time. IT departments are slammed with backlogs of to-dos and there is a never-ending list of updates, maintenance items, and technical debt to clean up. No-code offloads the burden of writing code from IT and developers and empowers employees to make their own work more efficient, and in lofter terms, perhaps more fulfilling as the software can do the menial tasks while the people can focus on the more human side of operating a business.

If there’s one thing I’m certain of its that the future will have more applications, they just won’t be written by people.

#startup #saas #nocode

--

--