How to build very complex software

Complex software is called so for a reason. It’s not the kind of software you can build in a few weeks with a small team of people. Just the product discovery phase can take several weeks or even months, depending on how complex the software and how much of the business idea has been figured out.

When embarking on a major software project, you might be starting with lots of big ideas and broad views. What you might not expect is that eventually those views will have to get very specific. You’ll have to be decisive, to be able to prioritize, and to know what you truly want & how to ask for it.

In our 14+ years of building software, we’ve seen and worked on so many different types of apps. Through this journey, we’ve learned some good ways to help clients figure out what their app, and thus their business, needs. Not by planting ideas but by helping them put their thoughts and imagination into words.

So in this article, we’re going to tell you how we build complex software, so you can get a good idea of what it takes and what you need to prepare in order to start building your own software.

Know what you need and what you want

A big part of building a software product is knowing what you’re building. Sounds simple enough, right? Except you might end up realizing you haven’t figured it all out when you contact a development company. They’ll ask you a multitude of questions - who’s your audience? How should each feature work? What technologies should it run onto? Are you building it mobile-first? What’s your budget? How many team members do you need? And so on.

You might have a big idea in your head, but that is not enough for an entire development team to start coding right away. Just listing a series of features that can be the basis of user stories means letting the dev team figure out most of the app. And in the case of specialized software, dedicated to a specific type of business or industry, this is not easy to pull off without the stakeholder’s input.

So before you even contact a development team, you need to sit down with your own team and figure out exactly what you’re trying to build. Here are a few things you should settle on:

• What problem are you trying to solve through your software? Apps usually offer a service that helps people accomplish something, like ordering food if they’re hungry and in a hurry. Figure out what specific issue your app is supposed to solve as this is the main thing you’ll be doing.
• Who are you creating this software for? Your audience determines a lot of important variables in a piece of software: whether it needs to be made very accessible, needs guides and tutorials, should be personalized, should look funky or minimalistic, and so on. Your audience type also determines how complex your app can really be. Don’t make extremely convoluted software addressed to the elderly, for instance.
• What are the key features of your app? Your app is solving an issue, which most likely takes a few steps. Think about what those steps should be, what users should be able to do and not. Try to go in as much detail as possible.
• What will be your release schedule? Complex software takes a very long time to be built. Some of these apps can take years. So sit down and decide if you want to build the entire thing or release an MVP and then add more on top of it. This depends on your budget, your team, and overall on your own wishes. Are you eager to get your software out there? Then an MVP might be a good choice for you.
• Will you do any kind of A/B testing before your release? If you’re a new business or launching something completely new, you might want to test it out with potential customers before releasing a fully fledged app. This can mean that you’ll build some prototypes, or simply put, designs, that you can show to users or investors - and then head into coding. Deciding this is crucial before contacting a development company: they need to know what resources to allocate for your project. Will you just need a design team for a few weeks and then a team of developers a few months later, or will there be no gap?
• What is your budget? Only so much development work can fit into a tight budget. Decide exactly how much you’re willing to spend as this determines how much a development team can build for you. You can opt for teams that offer low quotes, but be wary of who you choose. Cheap work is not always the best. Decide what is more important - quality software or low costs.

Once you’ve made these key decisions, you’re ready to talk to potential development partners. They’re very likely to ask you these questions and it’s not efficient to decide such important aspects on the spot. Come to those discussions fully prepared for maximum efficiency.

Sit down and brainstorm user flows

When you start building a complex app, you might discover that you haven’t yet figured out its user flows. Once you’ve hired an entire development team to help you build your app, they’ll need details before they get to work. Here is where the process can vary: 

This part is especially important if your app serves a specific industry that not everyone is familiar with. For instance, we’ve worked on an app for an oil drilling company, where we dealt with a lot of concepts and numbers we hadn’t seen before. The app was crucial to their business, to their day to day activity, so we sat down with them and had them explain their workflow to us.

So the first and most important step is making sure your UI/UX team truly understands what you’re building, for whom and why. Sit down with them and explain:

• What your business does and why. The why part is very important here - why are you solving this certain problem, why is it an issue in the first place? Why are you choosing to do business the way you do? With these questions you can uncover key features you haven’t thought of, features you can do without, or ways to improve your workflow that can transpire into your software.
• Who the app is for. If you’ve followed our guide so far, you’ll have the answers to this one already. But the trick is making sure your designers truly understand who the audience is. Be specific - age range, occupation, lifestyle and habits. If you want your design team to do user research, they’ll need this information. In a more pragmatic way, your design team will also need to know what user types the app will have and what sets them apart from each other.
• How you want the app to work. Designers can, of course, figure this out on their own. But if you have certain user flows in mind that you’d like them to follow, discuss them with your design team. Some of these can be industry-specific, so it’s essential not just to tell them, but to also explain how they work. If your business has to operate a certain way, make sure the designers understand that. Push them to ask questions.
• What visual preferences you have. This relates to the UI part of things, so it’s still very important. You might prefer certain looks and concepts, and if you’re hiring someone to do design for you, you have to tell them what you like. You can fully trust them and leave it in their hands, but take responsibility for that choice. If you’ve seen apps you like or if your business has a visual branding guide, share those with the design team.

Once your UI/UX team has the basics down, hold meetings with them discussing parts of the app. Make a list of the central app features you want to build and take the time to talk about each step that makes up those features.

Keeping up with our oil drilling company example, let’s say the main feature you’re working on is allowing your team members to view drilling progress on multiple wells at once. This means that you need a list of wells, each well needs to contain a series of technical data so you can see that progress, and they need to fit into one page. The page will probably need filters and sorting options, as the team members might want to quickly see wells that are in a specific stage.

What you need to do here, as a stakeholder, is explain your process to your UI/UX team well enough. The more complex your activity, the more detailed explaining you’ll have to do. Keep in mind your designers don’t know your business as well as you do, so be patient and explain in simple terms to make sure they understand. If they don’t do so well, you risk getting an app that doesn’t work for your target audience.

Write good user stories & turn them into detailed dev plans

We go by a process called design-first development. In this type of workflow, we fully design an app and use that as a basis to code it. So what happens after weeks of designing and refining the look and feel of an app, in our process, is writing user stories. 

When you’ve got a completed design for an app, it’s much easier to derive user stories from your existing screens. Features have been figured out and you have to sit down and explain how things work. On the other hand, with no design done, user stories will be a lot more vague and the developers will have to come up with a lot of ideas on their own.

In the case of complex software serving a very specific industry and/or group of people, it’s a lot more efficient to take a design-first approach. By doing so, you’re putting more effort into product discovery, into clearly defining each feature. Figuring out a big app’s user flows while in the midst of writing its code takes much more time and costs way more money.

So if you choose to take this approach, user stories can be of great help in making sure your app’s features are clear, as long as you write them well. Here are a few points to consider:

• Explain what happens when a flow goes one way or another. Just how you can type some random text in a field for email addresses and you’ll get an error, clear up in your user stories what should happen if users don’t do what they’re supposed to.
• Include validation messages where needed. For features like account deletion, for instance, you’d want to ask users if they’re sure. So in each user story related to a big choice, or an action that can have negative consequences, talk about what validation message the users should get.
• Provide all essential information. In a convoluted feature where one action leads to another, or a dropdown choice influences what shows up in the rest of the page, provide all of that information. What choice leads to what, what variables lead to what, and so on.
• Ask developers if the user stories are detailed enough. Make sure you’re on the same page and that they understand what they have to do. Developers will have a different perspective than you and the UI/UX design team, and they’ll notice if certain details are missing.

Once you’ve finished writing user stories, import them into a task tracking system such as Jira or ClickUp. This is the job of a project manager, and if you’re working with a software development company, they’re most likely to take care of this part.

Developers can go through each user story and estimate how many hours it would take to code. Through this, you can get a direct price for the code part of your software project. And using this info, you can decide how much work can be done at once, if you can afford to build the entire app or just an MVP, you can estimate when you could release the app and whether you need multiple developers or not.

Based on your available budget, tasks can be organized into well-thought-through sprints. The most basic (such as setup tasks) will go first, and the others will be sorted so as to fit into the number of hours you can afford. For instance, if you want to pay for 80 hours in one week, a one-week sprint can contain tasks that add up to 80 hours.

Keep in mind, estimates aren’t foolproof. There’s a reason why they’re called “estimates”: developers can’t predict the future, they can’t account for errors or external factors. There is always a chance that an estimate of 80 hours can turn into 120. Be ready for such situations and have a contingency plan. If you want to release your software but it still has issues that make the user experience not so great, take some time to fix it.

Do some hardcore testing

Before you release your software, making sure it actually runs as intended is crucial. Your software shouldn’t make people’s lives harder, especially if it’s meant to fix problems. And the best way to handle this is by doing rigorous testing.

You can either:

• Hire a quality assurance team
• Test it yourself
• Have the UI/UX team test it, as they came up with how it should work
• Let a few potential users test it
• A combination of all of these options

When testing your app before release, you can go back through the user stories written before and recreate all the user flows described. If they work as described in the user stories, you’re good to go. You can use the user stories as a reference since it’s what the developers used when writing the app’s code.

If they don’t work as described, it’s either (1) a bug or (2) the developers might have done things differently on purpose. The latter happens when developers had issues building the feature as you wanted them to and they had to find another solution, or they ran out of hours - either way, it’s best to talk to them about it.

When testing, look for edge cases, do things a regular user wouldn't do, just generally try to break the app. This is a great way to find issues and to make sure the app works well. Users aren’t robots, and you shouldn't let them make major mistakes when using your app. They should get errors when they do something wrong - so you gotta do something wrong to make sure they get said errors.

Testing is always essential when creating software, but even more so in a complex app. A lot of things can go wrong and you don’t want that to happen after the release. Make detailed testing plans, think of every way a certain action can go, and pay attention to everything that happens in the app.

Depending on your budget, you’ll have to decide whether or not you can fix all the bugs you end up finding. If you can’t afford to fix everything, fix the bigger problems. Think of what would bother users the most and focus on those.

And there you have it, these are some major steps you need to take when building a complex app. Information, communication and transparency are key in such a process. Explain what you want clearly, and make sure you know what that is before you even start. If you're feeling a bit lost, we provide a free product roadmap. Fill in the form and we'll have a productive chat about your software.

Looking to build your own complex software? We do that for a living. Contact us and let’s see what we can build together.

If you liked this article subscribe and get an email when we publish new, juicy stuff. We hate spammers, so we don’t spam.