I know you really want us to build your app. I know you really, really, really want us to build your app. It will do all the things, operationalize all the pain points away, delight your users, and solidify your seat in your community as a visionary. It will be wildly profitable and move the needle. Everyone’s doing it and so should you.
I am sorry to tell you, dear reader: you are probably wrong.
For every app on your phone there are dozens — perhaps hundreds — in the great app graveyard. It’s tough to tell where to draw the line, isn’t it? Is it at a launched-then-shuttered app? A dead-on-arrival app? A failed-during-build app? A suddenly-our-funding-evaporated app? A garden-variety-vaporware app? A but-it-was-a-white-board-masterpiece app?
The reasons software projects fail are legion and range anywhere from faulty business models to a single syntax error. This has been written about ad nauseam and I won’t repeat it here. In summary, building quality custom software is expensive, time intensive, rife with business challenges, and subject to external factors beyond your control.
So, before you assume these risks, please consider these alternatives.
Is the solution actually software?
I am very thankful the 00’s are over. When the mobile boom started, every brand, company, and business was coming out with an app. This infected the imaginations of aspiring entrepreneurs everywhere. It felt like every time I shared my experience in software development with a new acquaintance, I would get The Pitch For Their App.
Never mind the fact that I all I knew at the time was the bare necessities to get MySpace band pages and WordPress sites looking nice.
Anyway, these entrepreneurs’ ideas usually fell into two categories: either they were pretty clever and hyper-specific to a pet peeve of theirs (“If only there was a way to get on-demand compost delivery!”) or they were a transposition of another app/service (“It’s eCommerce but for writers!”) While I appreciated their creativity, I grew highly skeptical of everyone’s product ideas.
This skepticism has carried over into the work we do at Highland. I am not a “tinkerer.” I do not look for excuses to build things, learn a new language, or try a new platform. Highland is wired the same way. Instead, we look for reasons to not build.
It would be malpractice if a doctor prescribed a new drug to a client “just to try it out.” It would be malpractice for us to build your software “because we wanted an excuse to use AWS Lambdas.” If I may be so bold, dear reader, it would be malpractice for you to invest in custom software “just because other people are solving problems that way.”
Not every business problem needs software. Consider these problems: poor foot traffic, angry customers, incomplete faxed order forms. I could invent a custom software solution for each of these, no sweat: A geolocation-based marketing campaign! An AI-powered chatbot! A bespoke customer portal with order entry form! And each of these custom software recommendations would probably amount to malpractice on my part.
Why?
Maybe, to get better foot traffic, an adjustment in your brick-and-mortar signage is all it takes? Oh, the sign has been broken for 3 months? Hmm…
Maybe, to help angry customers, you might implement new team agreements about staying on top of your customer support inbox? Oh, you don’t have a centralized support system? Hmm…
Maybe, to help with incomplete fax orders? How about no longer accepting orders via fax?
Just because everyone else seems to be solving problems with software doesn’t mean you should!
There’s probably an off-the-shelf tool already
There are off-the-shelf-tools you can buy, configure, and customize that do things you wouldn’t believe.
Entire businesses have been built around providing innovators and entrepreneur’s like yourself with so-called “white-label” solutions. That is, applications and services you can brand however you wish.
Meanwhile, the continued industry trend toward open APIs makes services like Automate.io or Zapier more powerful each day.
At Highland, we use the word “Tetris” to describe the artistic process of aligning people to projects. (We forked the name from our friends over at Punchkick.) At first, we did most of our Tetris management via Slack. Team members would make requests in the #tetris channel for “a designer in a few days” or “a build team for 3 months.” The vagueness of the request would trigger an inversely proportional flurry of questions. What day will the project start? Is the budget approved? Is travel required?
Fed up with the thrash, we knew we needed to create clarity for everyone by using a consistent request process. In less than 30 minutes, I created a new “Tetromino” request form configured in Typeform (a platform we were already paying for), integrated it with Automate.io, and started pushing requests to the #tetris channel.
Now all requests are still being routed into the place where we’re already working, but they’re standardized so we can meaningfully problem solve instead of spending time and energy gathering clarifying information. I used off-the-shelf-tools and there were no additional hard costs.
You can imagine how a solution like this could extend to your customer service department or serve even as a “bolt-on” solution to an existing platform or technology you already use. At Highland, we often recommend clients buy or explore existing off the shelf solutions first.
Don’t invest your research and development capital into a custom solution that already exists. You won’t feel good buying it and we won’t feel good building it.
What you really want is validation
So you have a hypothesis you’d like to prove. Maybe it’s that your customers will convert more often if they had a streamlined mobile experience. Maybe it’s that a certain market is ripe for disruption if just the right product was surgically introduced. Mobile apps and web applications are a really expensive way to prove such a hypothesis. They’re an even more expensive way to disprove one.
To make the wrong bet on your idea will cost you money, social currency, sleep, mental health, and (perhaps most importantly) time. While a typical lean MVP build can be executed in anywhere from several weeks to several months, basic product validation can be accomplished in mere days.
Wouldn’t you rather kick the tires before buying the car?
Recently, a prospect asked me, “We have a $300,000 dollars in budget for this project. How far will that get us?” I kindly respond with, “That’s great! Let’s start with a small engagement to validate some of your assumptions. I’m also curious about your business model…”
Smaller is better and validation is relatively cheap.
Where to start small
Ready to ditch your idea for a million-dollar custom software project and start with validation instead? Here are a few resources that might be helpful to you:
- Getting Started with Design Thinking: An informative blog post that gives you three mindsets and three practices to embrace design thinking within their organizations. Design thinking tools go hand-in-hand with product validation.
- Chicago Design Sprint Meetup: Design sprints are an effective and open-source validation tool. If you’re based in the Windy City like us, the Chicago Design Sprint Meetup is a great way to connect with design sprint practitioners to gain knowledge and insights that will help you lead one on your own.
