1. Plan plan plan
Start your project with a strong plan. To successfully reduce costs when building a software project, we must commit to more design and scoping from the outset. Using a divergent-convergent approach during planning, you can explore as many solutions as possible, and ensure you converge on the solution that provides the most value.
Creating a plan makes it easier to not only break down the work and estimate more effectively, but to also highlight the goals for the project. This ensures the focus is clear between the development team and all project stakeholders. It also allows stakeholders to view from the outset what the project will look like, and prioritise the work for the development team based on the project’s budget. For example, you might shift features that are only “nice to have” rather than “must-haves” to the back of the product backlog, in an effort to spend less money creating an MVP and get your product to market.
But, make sure you find the balance in the force between planning and over-planning. You don’t want to deep dive into all the nitty gritty details of the requirements for the entire project, as this will take up far too much time and money. In addition, it stops teams from being adaptable as the product develops. You want your development team to be able to be flexible in what they work on next in case you need to reduce your budget by shifting the priorities of your product backlog requirements, or make a change due to user feedback halfway through. Make sure you walk the line between the two types of planning.
Scoping and planning for smaller batches of work allows the project team to remain adaptable and flexible to user responses to the project, changes in business processes, or stakeholder goals. This prevents redundant features from being scoped, or code that requires refactoring. Instituting smaller changes as needed reduces the likelihood of needing bigger ones later on. That’s why it’s critical to give clients freedom to ask questions and suggest adjustments as the project evolves.
2. Understand your target market
Spending time during your planning to understand and define your target market is a huge priority for reducing costs. Always focus on the problem and never the solution. The job is to solve the user’s problem not make a solution. If you come from that mindset, you are far more likely to build a successful product.
You need to ask, who is your user? Find out what your user wants and how to best deliver this. You can ensure what you are delivering has value and will be welcomed through user testing. Have your target market test your application frequently and give feedback as you are building. If you do this frequently, and discover any problems earlier, you can pivot the direction of your software earlier. You’re better off finding a problem early and addressing it, than spending the money to finish building the product and discover something you could’ve known weeks earlier.
As our Creative Director Isaac Joe Kong says: “It’s better to solve the right problem the wrong way than to solve wrong problem the right way”. Understand who your target market is, how they work, what they are used to, and what they like. All of this information is important to inform what you build.
3. Automate as much as possible
What are the advantages of automation? Higher output and increased productivity are two of the more commonly cited advantages. Remember, the most expensive part of a software project is the people working on it. Automation leads to smaller timeframes for production, meaning less person hours, and consequently reduced costs.
Despite this, automation is not about replacing humans with computers, but about creating efficiencies in your processes. When your team is freed up from time-consuming tasks through automation, they can instead contribute more in other aspects of the project.
An easy place to start with automation in software projects is to automate testing to ensure quality. Research tells us that software testing utilises approximately 40%-50% of total resources, 30% of total effort and 50%-60% of the total cost of a software project. This is therefore one of the first and best places software teams should look to for cutting costs.
Is the cost of automating testing worth it? Though the initial investment is far more substantial compared to manual testing, mainly due to the time spent actually coding the tests, analysis shows that the long term answer is - yes. Studies conducted on the ‘Impacts of Test Automation on Software’s Cost, Quality and Time to Market’ shows that over time testing automation has a positive impact on all of these aspects of software development. While it’s true that automated tests initially may take longer than manual tests due to the time spent coding, once the tests are written they can be rerun as often as needed.
It is now possible to also automate development with bots that code. For example, low code and no code platforms utilise common application functionality to automate coding. Codebots is a platform that uses models as the application requirements and can write up to 90% of an application’s code base. This type of automation in a project frees up developers to work on the unique business offering, and saves developers large amounts of time spent otherwise on coding common business problems.
4. Involve the right people
Software development can get expensive, and usually the most expensive part of a software project is the people working on it. Therefore the more you can reduce the time spent on a project, while maintaining code quality, the more you can reduce the overall cost of development.
This means, hire the right people! In our software estimations series we have covered how to hire a good cross-functional team for building your software. This means finding a range of people that cover a variety of skill sets. We cover some of the particular skill sets you should look for in another article of our software estimations series: How to form a successful cross-functional team.
5. Partner with experts
Sometimes partnering with offshore software development teams can be a valuable strategy for reducing costs. These offshore teams can be highly competitive in pricing due to lower wages and a surplus of qualified professionals, particularly in countries like Vietnam and Indonesia.
However, you need to choose carefully which company you want to partner with. There are a number of risks involved in managing a partnership with an offshore team. For starters, communication is key since you will be likely working in very different timezones. Use products such as Zoom to meet early and ensure the team is the right fit with your company culture. Once the project kicks off it’s also important to schedule regular daily standups. Check how things have progressed, ask them if they are blocked on anything and if you can help remove those blockers, and ask what they will be working on next.
How do you find the right offshore development partner? There are a few things you should first check. Look on the company website and on search engines to find out about the company’s history and reviews. If they seem to match your company values and deliver a high standard of code, the next step is to meet them! Don’t hesitate to ask as many questions as you can. This is also the best way to make sure communication between you and that company is going to work.
6. Strong processes
More than likely you will choose to use some type of Agile methodology for development. However, establishing strong processes is not just about implementing Agile. It is about the processes you put in place around the technology and people. Ron Jeffries, one of the founders of the Agile manifesto, even wrote an article advocating ‘abandoning Agile’ and moving to an approach that more broadly follows the Agile Manifesto.
This means teams should instead, as the Manifesto calls for, be “self-organising”. This includes choosing their own development process. Ron goes as far as to state “If I were starting a company, I’d let the teams choose any process they wish”.
It’s important not to strictly follow every process you read online. Every team works differently. What is important about your processes is that you are constantly experimenting and improving your process with every lesson, not remaining rigid and falling into the same traps repeatedly.
This is something we have learnt as a company. For example, with our software estimations process we have returned to using hours instead of story points to estimate, despite story points being a heavily advocated for process. We found hours saved us a lot of time on estimating and offered us the same benefits as story points could, such as using fibonacci. You can read more about our decision on this in our article on why you should use hours vs story points.
7. Avoid Fixed Price and a Fixed Scope
This one might sound crazy to those hiring software teams, but there is strong scientific evidence to support avoiding fixed cost software projects. Magne Jørgensen in his book on Time Predictions: Understanding and Avoiding Unrealism in Project Planning and Everyday Life, talks about why “rewarding accurate time predictions is usually not a good idea, particularly if people behave strategically and stretch the work (lower work quality) to fit the prediction.” So, if you try to get a low fixed price (like Marina Astapchik recommends), you are possibly heading for disaster.
In essence, if you pay peanuts, you’ll get monkeys. A fixed price project may seem cheaper initially, but if a development team has to deliver a project in a shorter time to meet the cost, the first thing to go will be the quality. Don’t compromise on quality! Low quality code leads to more technical debt, and long term will increase the development effort required to bug fix, maintain and extend the project.
8. Know your domain and read widely
While you can hire an expert in the type of software project you are building, it is extremely unlikely a developer will ever be 100% confident with building every aspect of a project. Therefore, before you begin development you should ensure the development team has thoroughly scoped what is involved to deliver a requirement.
One way to manage this is through using tech spikes. These are assigned periods of time in an iteration that a developer can draw on to research and experiment with a requirement in order to de-risk it.
Following this strategy can prevent project time frames (and therefore costs) from blowing out when a developer gets caught up trying to solve just one problem of the bigger project.
Summary
It is impossible to predict from the outset the exact amount a software project will cost. However, by following these eight methods, you can significantly reduce the cost of development.
Written by Tessa Mylonas
Head of Support and Education
If Tessa isn’t busy answering support questions or educating you about the Codebots products, she is typically found putting together flat-pack furniture, playing with her chocolate Labradors or hoarding houseplants.
