3 Key Challenges to Building Great Software

ionicons-v5-kBy TyJune 27th, 2022

So you’re looking at building software. Let’s look at a few of the common reasons why you might be wanting to build a software product:

  1. You want to start a new business
  2. You have an internal problem that needs to be solved
  3. You think software will make your processes more efficient
  4. You’re a product company that wants to reach a new market or segment

While these are all valid reasons for wanting to build new software, you need to carefully examine whether or not building software will result in a win for your organization, or fall on its face and cost a bunch of money, and possibly cost you your job.

So, what are some key challenges to building software in general?

#1 - Software can be expensive

Building software requires a lot of up front investment, particularly in people. To build software well, you need experienced product owners, project managers, solutions architects and software developers or engineers.

Most of these people don’t come cheap.

Also consider that you will likely need 2 or more of those software developers for even a smaller sized project, and someone with Solutions Architecture experience if you’re attempting any kind of larger scale system, or complex system.

Now, you need to think about how long these people (and remember, you haven’t yet hired anyone to manage the engineering team) will need to build your product. Let’s say you’re wanting to build a medical app that helps doctors and healthcare professionals connect with their patients via some kind of video portal in real time. This app will require quite a bit of up front development. You’ll need features like:

  • Account Creation
  • Login
  • Password Resets
  • Live Streaming Video
  • Secure Storage
  • Etc

Not to mention that you’re likely talking about different experiences for Doctors vs. Patients. An app like this, for a junior team, is probably going to land in the 12 - 18 month build cycle for mid-level engineers.

Add in the cost of a fractional Solutions Architect, full time Project Manager, and consider yourself the product owner, and you’re talking about $400k to $600k, bare minimum to build a decent MVP (minimum viable product) app. This is your app… without the spinning rims.

Now, there are ways to mitigate this cost, but it’s important to understand that if you’re going to build good software, it’s going to cost some money.

#2 - Not many people (even pros) know how to build software products well

The sad reality of software development today is that:

  1. Tons of companies are building software, and…
  2. Only the top 1% of them are doing it well.

As more and more enterprises try to gain a competitive advantage in their industry via the creation and distribution of new software, they are having to dig deeper into the talent pool to find resources.

Companies are demanding more innovation and competition, the life spans of old code bases are getting shorter as technology improves more quickly, and projects are becoming increasingly more complex with the advent of better cloud computing, machine learning, AI, and blockchain technology.

Basically, technology is moving faster than people can enter the market as software engineers. And it’s not just a problem with software developers… Anyone in the software development life cycle is facing the same reality.

Companies are having to hire under qualified Solutions Architects, Project Managers, and Product Owners, simply because the hiring pool for these roles isn’t keeping up with demand. So what happens when you hire under qualified people for complex jobs that require a lot of experience?

Bad software gets produced, deployed, consumed and publicly reviewed.

Again, and sadly, this is the reality for most companies building software, even (sometimes especially) Fortune 50’s. It’s true, there are wildly successful software organizations (Uber, Doordash, etc), who can build truly transformative, stable, and scaled products, but again, they are the top 1%.

If you don’t have that kind of experience under your belt, or know someone who does, you might consider avoiding a build altogether, or consulting an expert (which will cost money, but will be well worth it in the long run).

#3 - Most companies (and founders) fail at step 1 - The Initial Spec

Good software needs to be well-defined if you want engineers to move quickly and accurately.

If you’re a new founder, this is probably daunting, and you are probably either scratching your head or crying. Speccing software well is part art, and part science, and for most people, takes years of experiencing failure to even know where to start. Fortunately, it doesn’t have to be that hard, and in another article we will break it down for you, just know that most people in your shoes have no idea what they are doing.

If you’re a tenured product manager or technical leader at a large company, you’re probably starting to think about who you can find (internally or externally) to take your napkin idea and build out your waterfall spec. You may also be reverse time-budgeting for when you may possibly get to market. You’re probably not happy with what that timeline is looking like, and you know you’re going to get some flack from your other stakeholders, and a lot of push to release the product faster.

Additionally, and in contrast, today’s pace of technology moves too fast for traditional, extremely detailed “waterfall” style software requirements gathering. Those documents can take weeks, months, or sometimes even years to develop, are incredibly difficult for software engineers to consume, and make it nearly impossible to create a cohesive product roadmap for aligning a team.

This inability to quickly, correctly and coherently define software requirements is not just a problem in new, un-indoctrinated startups. It’s a problem for big companies too. Tenured product managers are still stuck in the old ways of defining software, and are constantly struggling to get to market in a fast, streamlined fashion. We could go into a lot more detail here, but the tldr; points here are:

And this is why most software products fail before they even launch.

So, you still want to build it…

There are lots of compelling reasons not to build software. It’s difficult, expensive, and not many people on planet Earth know how to do it well. Sometimes, though, it just can’t be avoided. Here are a couple of good tests to determine if you should keep pursuing it:

  1. You have access to solid funding, or are experienced at raising money in the millions of dollars
  2. You understand where your product fills a gap in a market, and have validated this
  3. You are an experienced stakeholder at a very large company, and understand the risks & rewards
  4. In addition to all the points above, there is no software you can by to fit your need

If you fit into one or more of these buckets, building software is likely in your future. However, you’re going to need some tools in your toolbelt to make the process of developing software faster, cheaper, and result in a superior product:

  1. An experienced advisory team
  2. A solid understanding of modern software development processes
  3. A tried and tested playbook of what works, and what doesn’t
  4. A well-vetted implementation team

If you have these things, you’ll be able to deliver superior software in record time, for a reasonable budget. This is good for everyone, including investors, potential investors, stakeholders, board members, your company or organization, and ultimately… you!

Subscribe to 🎉💪 content!

Get our tech articles once a week, free of spam.