Say you have a bright idea for how to take your business forward or an innovative solution for improving your management systems. You know your customers, you know the market, and you know your business. You’re absolutely, absurdly sure that now’s the time to double down or lose out to the competition. 

But then there’s the question — do you know your software? 

Perhaps this ‘bright idea’ involves launching a new internal system to streamline your business or introducing a tailored software solution to the market. In either case, a detailed software development plan is an essential tool for your success. 

Even in today’s fit-for-market world, with pre-built software templates and apps, figuring out precisely what you want to create and how long it’ll take is key to maintaining funding and pleasing your shareholders. Because without a clear strategy, you’ll bounce between development projects while your launch date recedes further into the distant past. 

For the sake of argument, let’s say you’re looking for something a little more bespoke. Maybe you need a website with greater functionality that screams ‘high-status’ or an app to tap that specific niche customers have been dying for in the financial market. Just what do you do then? Who do you talk to?

Here are the steps to creating a software solution from start to finish;

Step 1: Set realistic expectations 

We don’t mean to be pessimistic at the outset, but this one needs to be said early. No matter how cogent your business plan, your initial start dates are just best guesses. And that’s not all on your development team — you’ll want to make changes too.

Any software developer worth their weight in keyboards will give you their best guess estimate, topped with a heavy review period at the end, which includes time to tweak designs and review code. The review process should also include plenty of time to sit down and revisit designs, with added time for refining components if needed. 

Ideally, you want to be tweaking minor things, such as imagery and backlinks, in your final few weeks of development — but again, be prepared to shift those dates.

Step 2: Find someone who speaks tech

Now that your expectations are set, the next step is to find someone who speaks in technobabble. The best software developers will be willing to break things down for you into bite-sized, recognisable chunks, sparing you the more complex details. 

Depending on the project’s size, you should be looking at hiring a spare head for your business. If your knowledge is tied up in business acumen, your software developer will hold a more technical viewpoint of the project, with intimate knowledge of how ‘software things’ work. They know how possible what you’re asking is, how long it’ll take to develop and the cost of such an undertaking. Essentially, your software developer is your site manager, with the experience to lead your project and the ability to report in detail on its development. 

Your software developer should also be more than willing to involve you in the design phase. Maybe your business works with graphic designers, copywriters, legal teams or supervisors who know a little bit more about what software developers do. You’ll still need to hand over the technical tasks to the software team— but they should be just as willing to have you step in and leave your mark where needed. 

In short, your software developer is part of your team for however long the project lasts. Software development is always more complex and time-consuming than the most intricate plans allow. You should expect a litany of emails and phone calls while your project is under construction, so make sure to choose someone that can;

1. Build for you the desired application (and holds prior experience in doing so)
2. Be trusted to keep you informed
3. Work with your team
4. Accept responsibility and lead the tech-development side 

And, if you’ve got a translator in your team, use them. It always helps to have someone internally who’s even moderately computer literate and who can help in the planning stages. 

Step 3: Do they like Java?

Before you go ahead and strike a deal with a developer, you need to establish exactly what software programme they work in. Software agencies generally advertise their preferred systems on their website and will talk about their expertise in certain programmes. 

If you’re creating a software system that needs to integrate with your existing platforms (such as a time-tracking application that feeds to payroll), you need to be aware of how compatible your new system will be. Many of the latest applications will advertise their web-based, cloud server function, allowing them the freedom to work alongside virtually any operating platform. 

Other considerations should take centre stage if your software project doesn’t need to adapt to an existing platform. What devices do you need your software to work on? Will it be available on the app store for purchase? Will you likely need ongoing changes within the application that a member of your internal team best performs?

Your software developer should take you through the pros and cons of the systems they use, but it doesn’t hurt to have some idea yourself what to expect. 

Step 4: Presenting a plan

Even if your idea is just a scribble or a piece of paper, presenting it to a software developer will involve something called an SDLC — a Software Development Lifecycle. This fancy term basically describes how your project goes from an initial concept to a fully-fledged idea. 

Every time you give your software developer something, whether it's an image to use or a process you want your user to take (such as a download button), you’re asking for an output — a result the final user will see once the software is finished. This result relies on input from the software developer — the go button that will make what you want to happen work. 

The best plans will present a number of outputs and their logical steps, thinking in terms of what you want people to do and what it helps them achieve. Keep in mind that a piece of software isn’t like a novel — you don’t necessarily run through it in a linear fashion. You’ll want to be able to click forward and back, reviewing different buttons at different times. Each click takes you to another stage, maybe a page or a separate function. Think about how your user is going to get back to where they started from or even just quit out of the function when they’re done. Can they undo changes? What sort of warning, legal or otherwise, should they receive?

Step 5: Study other applications

A little bit of human psychology helps here, as well as a thorough study of your market. Each of us has certain expectations when using software which has been hammered in with each application we use. Users expect to see navigation buttons in certain places, and most won’t stop to review their decisions before getting frustrated at your new application. 

The best thing to do is wireframe each of your ‘steps’ before asking your software team to develop them. This helps give them an idea about the look and feel, but also exactly what you want them to do and build. It’s not until you complete this process that you might see a flaw in your logic — maybe it isn’t so obvious where to go from the homepage or what’s more important on the screen.

Beware of your bias!

Considering the cost and time spent on software development, you’ll likely be pondering over your project day and night. What’s perfectly obvious to you might only be obvious because you know what to expect next. View your project from the angle of someone who’s never even seen the application or who has no idea what you do. Now, how easy is it to find your way around?

Think about calling in your software developers for a chat about the more complex parts of your project. Go around the group and discuss your aims and concerns. How easy is it to navigate to the next step, and what do you (legally and logistically) need your user to do next?

Step 6: Handing out responsibilities

Now that you’ve thought about building your software, how will you get it built? Now’s the time to start delegating responsibilities and exchanging emails. For each person involved, focus on what you want them to accomplish and how long you expect them to take. Make sure to factor in check-ups, meetings, progress reports and review sessions. Consider what you’ll do when things go wrong (which they will) and how you’ll fix the bugs. 

Managing each person’s role in the project will greatly help you and your software developer reach an agreement on how to proceed. The plan helps delegate authority and divide tasks, meaning your project gets finished faster and with less confusion. 

Trust us; you’ll want to figure step six out early — there’s nothing worse than getting a billion emails from a million different people, all asking for things NOW and all with slightly different requests that don’t make sense together!

Step 7: Formalise your plan in writing

The last few steps are part of something that any marketing manager should recognise instantly — analysis and planning. This group of impressive-sounding words sums up the documentation you will need before undergoing any software development process. In it, you should include;

• A reflection on your goals as a business. How does what you’re doing with this new project further your aims or support your values as a business?
• Resources. What do you need to undertake this project? Who needs to be involved, and for how long? Do you need to hire additional people, space or equipment to undertake your project? 
• Cost valuation. What will your project actually cost you, both in payment to the software development team and for your own internal team?
• Time management. What else have you got planned that might interfere with your project? What does this project need to be finished in time for? What might interfere with these dates both internally and externally (such as a change in the market or a competitor’s unforeseen launch)?

You should consider all these points before formalising any agreement with your software developer. 

Step 8: Will this thing actually fly?

Don’t go ahead and sign up just yet; as excited as you might be. Around 42% of new startups fall flat because they fail to anticipate real consumer needs or offer a unique enough advantage in the market. 

Before, or even once you’ve started, committing the big bucks, you need to ask yourself the following hard questions:

• Is this something people actually want?
• Will people in my business really use this?
• Will anyone on the market pay money for it?
• Does it solve a real problem people are concerned about?
• What legal compliance issues might I face?
• What security issues do I need to consider?
• What will I have to ask people to do/look at before they can agree to use my product?
• Who will handle complaints/questions?
• What other applications or tools do you need to integrate? 
• Should you invite your software developers to the Christmas party?

And so on and so forth. Keep your list handy and add to it as you go. Remember — don’t get fixated on an idea just because you’ve already committed to it mentally (and financially). The sunk cost fallacy only fails when you continue to sink costs into something you know won’t work. 

Step 9: Sign the contract

Finally! Once you’ve decided who you’ll work with, thrown around some dates and really dug into the why and how of your product, it’s time to begin by making it official. 

Step 10: Chalking it out

We’re going to go back a few steps here to number four — planning. Now’s the time to get your computer out (or pencils, if you prefer the feel of paper when planning). The actual look of it isn’t the most important thing at this point — it’s more about coming back to that continual question, ‘does my software solve a real problem people are actually concerned about?’. If not, then should it exist, or how could it exist differently?

Question everything. If it’s a website you’re building, think about why people would visit it at all. Sadly, it’s not just because they think you’re brilliant — it’s usually to complete some action or find out some piece of information. 

You’ll want to start creating wireframes or prototypes with your software developer at this stage. Marvel and InVision are good examples of easy prototyping software you can use. Xode uses Figma. This process might also spark fresh ideas or make you reconsider how advanced your planning is. Time to whip out the notepad and do some more brainstorming — or maybe ask others if they’ve any suggestions.

Step 11: Building the actual software

At some stage, though, you will have to begin building your application. Don’t be afraid if you still don’t know exactly what it’ll look like yet. The building is all part of the input/output part of SDLC and will change as soon as you begin. 

You might even want to consider breaking it into stages before you begin. Start with what you need for the product launch, the definite foundational supports that make the product what it is. Then build on the additional layers that turn it into something commercially feasible. The last step is the ‘additionals’; nice to have but non-essential components that can always be added on later.

You might decide to stage your product based on the likely user journey. Think about the action you want users to complete first. Maybe they need to sign up for something or send a request. This action becomes the first part of your build, while the more profitable section can come later, once you’ve got users completing step one.

All your planning will come to fruition here as you move in stages through the application design process. 

Step 15: Beginning to test the product

Actually seeing your product live is always the most fun (and satisfying part) of the design process, as the functions you first wireframed start performing and doing as they’re told. But sometimes these functions also go completely array for unknown reasons. Maybe someone in the team hadn’t fully anticipated the final stage of the product, something you’ve only come to appreciate at this late stage in development. 

In any case, designing and testing in stages is a great idea for continual motion and improvement. It gives all members of your team the chance to be involved and have their say, as well as preventing you from going down the wrong track too far before you have to make an expensive change. 

As you test your product, make sure that you’re noting down any bugs and mistakes as you go, following the plan you’ve outlined. It’s hard for software developers to keep track of hundreds of tiny errors, so start noting down your changes into a report, or invest in a system like Trello, Notion or Monday for making notes. The more you can formalise your testing, the easier it is to pass each stage of the development process. 

You might want to take screenshots of the actual problems to make it easier on everyone else. This helps avoid any ‘techno language barriers’ that might arise between you and your software developers and allows anyone to participate in the testing phase. Simply screenshot what you don’t like or what you think is wrong and write the problem next to it!

Step 16: Beta testing

The next step is even more testing — but with new volunteers. 

A lot of applications are hard to simulate in test environments, and between you, your team and the software developers, you’re unlikely to be able to consider every scenario and every possible user. 

A beta test allows you to pick a small select population and see how your application performs in the field. The advantage of this process is that it allows you to tackle any problems that crop up quickly, as you can respond more easily to your small beta test group than with a full-blown product launch.

If you’re worried about getting responses from your test group, think about making it worth their while. Maybe you do a paid test group to remove the risk of getting a bad review for your beta-stage product. Paid groups tend to be more biased than unpaid, so it depends on what you value more — reviews or honesty. But however you go about testing, you want to monitor this stage closely with no more people than is necessary. 

You may want to design some sort of feedback or survey form here, use UX tools to monitor interaction with your software, hold a focus group or do a combination of all these things. However you do it, make sure to grab as much information as possible and leave time to fix those bugs before retesting. This spare time should be factored into your initial plan, so don’t stress if it’s not ready to roll on the first go. 

If the problem(s) are too critical, don’t start rolling out the final product until your beta test starts coming back with more positive results. That which is broke requires fixing!

Step 17: Hitting the market

This step is somewhat outside the realm of software development — now it’s time to begin marketing your product! You may consult an SEO or marketing team to boost the keyword success of your application or website or begin the transfer process from the existing software to the new one. 

Someone in the software development team will push the actual launch now button, so you don’t have to worry about handling that.

Step 18: Keeping an eye on things

Launching a new application is like firing a rocket into space — when the thing actually takes off into the sky, the process has only just begun. A good software developer will stick with you and help you monitor your application as more and more people come on board. This larger pool of users will undoubtedly find more bugs and complain louder than the beta testers — but hopefully you’ll be gaining more traction on the market by this time and can start thinking about how this groundbreaking new piece of software can pay itself off.

Down the line, you’ll need to continue with regular maintenance and updates. Technology is constantly evolving, as is the market for applications. Keeping up with those changes and adding to them is all part of the SDLC of your application — so don’t panic. The ongoing costs will likely be much smaller than the build costs, allowing you time to regain your revenue and focus on other projects before it’s time to make some more major changes or feature implementations to your software.

Work with someone you can trust

These eighteen steps are just a brief overview of the whole process, which is really much too cylindrical to capture in full. Developing a new piece of software takes a lot of going back and forth to get right, which often means going back to the drawing board to begin again. 

Ideally, you want to be revisiting changes based on design or fresh thinking, not on continual technology failures. That’s why it’s so important to choose your software partners carefully, to find someone who is open and willing to engage with your ideas early on in the development process. 

At Xode, we consider all our development projects as partnerships, working with you to help actualise your concepts. While we provide digital solutions to problems, rethinking what is possible with technology, it’s only through working in collaboration together that your ideas can perform as they should.

So if you’ve got a project burning at the back of your mind, come and see us. We’ll discuss ways we can join forces and talk you through how we can work together (we do like the challenge of something completely new). 

If you’d like to get in contact to book an initial meeting or just to ask some of those software questions you’ve always wanted to know about, feel free to send us a message or contact us on 027 825 3080. 

Sources cited:

Dautovic, G. “The 20 Most Important Startup Statistics” on Fortunly. Last updated: 8th February, 2022. Site link: https://fortunly.com/statistics/startup-statistics/.