The 3 Mistakes Non-Technical People Make When Building Software (And How to Fix Them)

It’s hard to develop successful software. It’s harder to develop successful software if you aren’t technical yourself. Not only do you have to deal with all the typical hurdles that accompany development, but you also have to learn what those hurdles are in the first place. It can feel like you are navigating a whole new world, and it’s all too easy to get lost in the intricacies of development.

Over the years, we’ve worked with hundreds of non-technical clients who turned to us for their first software projects. Based on those experiences, we’ve put together a list of the top 3 mistakes people who are new to software development make on projects to help you avoid them.

Mistake #1: Underestimating The Language Barrier

Communication is a two-way street. Some of the biggest issues stem from a misunderstanding – either of requirements, expectations, or solutions. Translating complex technical concepts into layman’s terms is no easy task. Entire job roles exist for that purpose (hello product engineers!).

But it’s not just technical terminology that can cause gaps in understanding. The language of software development confuses many non-technical people, but the same is often true in reverse. When working with your team, you likely use industry or company-specific terminology. Technologists are specialists in their field, but not in healthcare or logistics or finance, or other sectors.

Solution: Over-Communication

Don’t be afraid to clarify terminology and ask questions. Even better, go the extra mile and define common terminology you use within your own industry.

Practice patience. You didn’t learn your job overnight – nor will you understand all the intricacies of development right away. The best way to learn is through experience. Remain diligent, ask questions, and embrace the process.

Mistake #2: Getting Stuck on the Wrong Things

This mistake most often comes up during the wireframing and design phases. It’s exciting when you first get your hands on something tangible. The problem? Often people get caught up in the details, like stock imagery or filler copy. In this early stage, it’s not about the content but rather the structure and outline of the page or the way menus work.

The main concern during the wireframing phase of a project is to make sure the functionality you would like is represented. Don’t be too concerned about the look, that comes later during the design phase. When looking at designs you should look at the color and feel of the design as well as the layout, don’t be concerned about the text content or images. Pay attention to the layout of the text and the area available, you need to make sure there is enough room to communicate what you like.

Solution: Clarify Feedback Expectations

Many development projects follow an agile model, with biweekly sprints focusing on smaller pieces of functionality. Check out our article on development methodologies for more information on agile development.

Whenever you receive a deliverable, ask your developer what you should be evaluating. For wireframes, it’ll likely be the page structure and user flows. For designs, review the colors and page elements. Make sure you understand the objective of each sprint and provide feedback accordingly.

Mistake #3: Simple to Explain =/= Simple to Build

Just because it is simple to explain (and understand) a workflow or process or feature needed in a software application, it does not mean it is also simple actually to develop.

For example, you want to add the capability for a user to add/upload a document to your existing online form submission. Sounds simple – we’ve all encountered this capability online. And, this is relatively simple to develop. However, to do it correctly, the code should do a lot more than just accept the file and store it in a database on a server. Code needs to account for user considerations, security issues, error handling, data storage, and retrieval capabilities. Here are a few examples:

• What kind of file types will be allowed to be uploaded?
• Are the files free of any viruses or malware?
• What is the maximum upload size?
• Did the entire file transfer from the user’s browser to the database?
• How do we give the user feedback on the transfer and success (or failure)?
• What happens if the user’s internet connection fails during the transfer?
• Can the user delete and upload a different document if they accidentally uploaded the wrong one?

This is the case for just about every feature or functionality that a software application can perform.

Solution: Don’t Assume Anything is Simple

You know what they say about assumptions – they make fools of everyone. No matter how simple a concept or functionality seems, there could be a number of “behind-the-scenes” complexities that make it anything but “simple” to develop. For a deeper dive, check out our article on the hidden complexities of development.

It All Comes Down to Trust

All that being said, there’s a reason you hired a professional development firm to build your software rather than doing it yourself. You rely on them for their experience, knowledge, and skills. There will be decisions around technology stacks, architectural structures, and more that you may not understand. Each choice will have ramifications for the current project and future maintenance. If you choose the right software development firm, they will have your best interests at heart for every decision, but it may be difficult to explain the technical reasoning behind it. This is where trust comes in.