Software has become a vital part of almost every business. Whether it’s a web site, a cloud application, mobile apps, or even the Internet of Things, there’s a good chance that your business relies (or should rely) on software. If you’re just getting into building software, then you likely have many questions; if you’ve already tried and it’s not going well, then you likely have more.

FAQ: The realities of building software

Many of our clients come to us after they have had a less-than-stellar software development experience. They contracted for a $30,000 app and are now $500,000 into it and they still don’t have an application they can release. Or, they hired a programmer and have come to realize that code is not enough. In an effort to explain why these horror stories are so common—and more importantly, help you avoid them—we have compiled a series of FAQs about the realities of software application development. 

Q: What are the biggest mistakes people make when building software?

A: Based on our experience with clients and what we have seen in the marketplace, the top five mistakes people make when developing software applications are:

  1. Lack of a clear vision. You need a well-defined end goal and a business case. Most importantly, why are you building this? It may sound silly to say this, but you’d be surprised how often people go into this world because “they all tell me I need an app” or other vague goals. The answer to this question is critical because it will take time and money to build, perhaps more than you realize. You need to make sure there is a strong business case to support it, and that your team stays focused on that business case. 

  2. Under-funding. We hear the phrase “under capitalized” a lot in the business world, and it applies here: running short on money leads to failure. This happens more than it should, often because people don’t want to believe that software development is costly, so they don’t allocate enough budget. Many developers estimate what it would take them to “write the code,” but there’s a world of work outside of just writing code. It’s like building a house: laying the foundation and doing the framing is one thing; getting permits, installing and testing all the mechanical systems, dealing with constant inspections, and the hardware and the crown moldings—all that finish work—is where the costs add up. There are parallels in developing a successful application, and it takes sufficient funding to make sure those items are built in. 

  3. Rushing the project timeline. The path to a successful software application also takes time. You need to factor in time for design, defining acceptance criteria, prototyping, building, rolling it out, and making adjustments based on market feedback. And, during all of these phases, testing requires even more time. In fact, for successful apps, testing starts on day one and continues throughout the life of the product; it includes regression testing, freeform tests, user testing, beta testing, and application security testing. 

  4. Ignoring security. Even though security factors into the other mistakes we mentioned already, it deserves its own spot on this list. Application security is really more of a recent evolution. Enterprises have gotten pretty good at protecting the perimeter of their businesses, but the fact that attackers can get in through the doors (applications) is often overlooked. While industries dealing with more sensitive data need to focus on security more than others, everyone must pay more attention to application security—from day one.

  5. Assembling the wrong team. You need more than just skilled programmers on your application team. And everyone needs to be a team player capable of communication and collaboration. If people don’t appreciate the role played by their teammates and work well together, it’s going to be very challenging to get things done. Not everyone is cut out for this, and the software development community is known for attracting a certain kind of individual who is better fit for solitary work than teamwork. 

Q: How long does it take to develop a software application?

A: If you’re lucky, you will never be finished developing your application. Your users will love your product and want to add more features and functionality, so it will continue to evolve. Let’s focus on getting to that first big milestone.

If we look at what it takes to release an initial version of your product that is reliable, robust, secure, and well-tested enough to take to market, a good rule of thumb is to assume six months to build an application requiring any type of complexity. That’s six months from “I have an idea” to someone actually using it. 

Keep in mind this number is very fluid, and increases as your requirements become more complicated. We’ve worked on apps that took nearly two years to the first release. But don’t expect it to be less than six months, unless you have a really simple app.

The good news is that you can come to market with a solid subset of your overall vision, and then incrementally leverage the cloud and mobile to automatically push updates out to users. Users can gain more and more value from your product as time goes on, without any heartache. New functions and improvements can appear before their eyes as you roll them out. 

The real question then becomes, “How soon can I start realizing value from this project?” Then that value will help you pay for what comes next. 

Q: How can I find out which type of application my customers want us to build?

A: You cannot answer this question without knowing your customers. Guessing and assuming guarantees that you will miss the essentials that matter most to your customers, and they will be unimpressed when you take your product to market. 

Don’t spend a lot of money developing before you really know what they want. Talk to your customers. Ask questions and listen—really listen—to what they say. Once you think you know what they want, test, test, and test. Find a designer who can construct a low-cost, no-code mockup, so users can interact with the application and provide feedback. Expect users to change their minds about what they want once they see it and can interact with it. Refine and test again. And again. 

Test until your users are happy. Then you can begin to build an application that will succeed in the real world with real customers. 

Q: Why is it so expensive to build software?

A: The more realistic question is, “Why is it so expensive to build successful software?” A software application that will generate revenue—one that is valuable, reliable, secure, and well-reviewed—requires more than just decent code. If you want your application to do more than “just work,” you need people devoted to design, testing, prototyping, iterations, and quality assurance. 

Yes, the code is important, but it is just a small piece of a high-quality software product. Many software applications also require behind-the-scenes work, such as platform integrations and pulling data from backend systems, which requires more skill (and more investment). Your user’s experience in using the app has a huge impact on its success, and so you need to focus on experience design. Maintenance updates and new features or functionality demand additional budget dollars. An application that will survive and thrive in the real world is more than just code and a pretty interface. 

Today’s applications must interact successfully with other applications, work on a variety of platforms, and compete successfully with other applications. All of these realities add cost to the project. 

Q: Why can’t you tell me how much my idea will cost?

A: Because your idea will likely change as you move through the design process. New details will emerge, things will take shape, and there will be many mid-course corrections. If someone does give you a set price upfront, they’re telling you what you want to hear, rather than the truth. Or they are coming in with a too-low price on the first quote, hoping to win your long-term business.

In our experience, people usually know what they want when they see it. Once you (and your users) see mockups and prototypes, your initial vision will change. And it may change again when you see it committed to working code.

This is why we follow the Agile methodology when we work with clients. It allows us to balance budgetary constraints and changing requirements by completing work in short sprints. And we start every project with, “What do you want to achieve? What is your budget for achieving it?” Then we work on giving you as much as you want to achieve for the budget you’ve assigned to it. The process will include intelligent efficiencies, simplification, occasional compromises, and mid-course adjustments. 

Once requirements are set after initial user testing, we can usually provide a better cost estimate, keeping in mind that requirements may (and likely will) still change down the road. If you do need to hold to a set budget, then you need to be ready to compromise when it comes to scope and adding new features. Adding new features as you go is just one of the realities of software development; a realistic budget will anticipate necessary additional or modified functions. 

Q: Can’t I save a lot of money on software development if I go offshore? 

A: Yes, you can—but not as much as you think. There are offshore companies that will write software for less money, but as we said before, this is just one small part of a successful and reliable product. Market acceptance is what makes the whole effort worth it, and that requires customer outreach, user testing, and product testing. 

Plus, you need to manage the remote offshore team completing the code. Frankly, it’s difficult enough to do a good job of building a revenue-producing software application when the developers are right in your backyard. It takes extra work to successfully manage a geographically diverse and distant team.

If you find an offshore company willing to handle the non-coding portions of application development, make sure they can do it well. Remember, they are far away from your users, which makes it harder for them to define requirements and conduct appropriate user testing. Many software application development companies closer to home can provide end-to-end application development without the hassle of juggling a long-distance relationship. 

The most common scenario we experience with new clients is that they chose this path, it didn’t work out, and now they are asking us to clean up a mess, with less time and less budget (because they spent so much time and money already). It’s a challenge we’ve met many times, but we always feel for the company executives who went through it.

Q: What’s the difference between a website and a web app?

A: These terms are often used interchangeably these days, but there is a key difference. A website is a one-way conversation between your business and a visitor. A web app, on the other hand, is a two-way collaboration between your business and that visitor. The user can do something constructive and useful on your site, such as make a purchase or self-serve their business needs. Even if your site just has a shopping cart, that’s still an application. 

This distinction has a substantial impact on the cost and time to build. There are many capable website builders who can quickly and relatively inexpensively assemble a good website. But a web application requires experienced developers who understand everything it takes to build a robust, reliable, and secure application.

It’s important to keep this in mind when figuring out what an app is going to cost and how long it will take. 

Q: Should I just hire some programmers to build my software?

A: Unless you are a technology company, or aspire to become one, the short answer to this is “no.” You will need more than just programmers to handle all of the non-coding elements we already discussed, such as understanding your customer needs, defining those needs, defining how to meet those needs, defining the way to test how well those needs have been met, designing the visual interactions surrounding that solution, and managing the process of rolling the app out to your customers. Programmers don’t do any of that. They just write code.

Plus, the really good programmers (the ones you want writing your code) work for full-service software development organizations. Why? Because this is where they want to be. They get to work on the types of projects they like, just focusing on the code, while receiving all the support they need from a team. The result is a high-value end product. 

Also, programmers require very precise management and motivation. They function best in a dynamic, well-run software engineering development organization. 

Q: I have spent more than 10 years using and tweaking this application we use to run my business, and it’s been fine. Why does it have to be rewritten now?

A: The short, sad answer is that “stuff happens.” Sorry. 

The truth is, things change in the real world, and you have to adapt to stay alive. You need to reinvest in your software just as you do your factory, or any other part of your business. The technology used to write your application ten years ago may no longer serve your purpose. 

It may even just stop working, and worse, the guy who wrote the software is no longer around. You may be reading about the cloud or the Internet of Things, or looking at your mobile device, and wanting to make these things part of your business . . . but your 10-year-old technology just can’t support those new technologies. 

If you have a customer-facing product, updates become even more important. Customers will immediately click away during their shopping process if your application looks old compared to the shiny, new apps they can get from your competitors. 

Even if your application is for internal use only, you can’t just force your people to keep using old tech. They have their own expectations of how technology should work, from their everyday life, and they want that same experience at work. The best job applicants want to work for companies with up-to-date systems; they will not be happy working with (and working around) an out-of-date application all day.

In either case, you will have to keep your current application alive and running successfully while you build the new one, because it will take time. It’s unfortunate and a lot of work, but that’s the reality. 

Q: Which is the best platform for building an application?

A: We’ve written about this in great detail before. The short answer is, if you’re the kind of person who reads a FAQ list like this one, you will likely want to use Agile, because it is the most flexible process and it supports creativity.