A harsh truth in the world of application development is that most businesses are using their development budget the wrong way.
A common pattern is when companies get off to a good start, but because they didn’t lay the correct foundations, their project eventually hits bumps in the road and runs into serious problems – sometimes fatal ones.
A big question for businesses is how they can ensure they use their development budget wisely. How can they set their teams up for success instead of failure, and ensure they use the early stages of development to build a long-lasting, robust foundation for their project?
In this article, we’ll take a look at some of the most common mistakes businesses make and how you can avoid these by taking the right steps early on.
How most businesses use their development budget (and why it’s wrong)
Companies often start their project with a planning phase where they determine what the app should look like and get clear on a few goals and rules. Then, they simply dive straight into it.
This is often the result of enthusiasm and passion — which are good things — but it overlooks something very important: architecture.
Architecture is basically a set of coding standards for developers – rules they must stick to if the project is to run smoothly throughout its development. Good architecture keeps productivity stable.
Poor architecture, on the other hand, can be disastrous. That’s because nothing is tested, so as the app grows and attempts to scale, parts of the app are likely to break before teams can spot the issues. These can quickly snowball into much bigger problems that derail entire projects.
The result of poor architecture from the getgo is long term failure — progress can skyrocket initially and give you false expectations about how development will progress throughout, but after a while, things slow down and you just can’t maintain that initial frenzied pace anymore.
That means you might schedule a launch party too soon and quickly realize you can’t meet the deadline. You might launch your app only to find it can’t handle more than a few users, or can’t implement new features, or pivot.
A common scenario is when development teams have a fantastic first month, implementing 10 new features, and then next month manage only one. Why does this happen?
There are a few reasons. For example, you might start off with two developers building your app. As your app grows and you add more features to it, you realize you need to hire more developers to maintain and scale the app. While this is all too common a scenario in the startup world, it is actually quite possible to scale an app to a pretty large extent without hiring more developers if the team built the code on good architecture from the start.
Failing to prioritize good architecture at the beginning is a quick way to lose millions of dollars and maybe your entire project.
If you can feel this happening, take a pause and reassess. Do you have any tests in place? If not, get some in now. This will quickly show you which parts of your code are good and should stay. It could take 2-3 development cycles to get right, but this refactoring process is worth it — you’d spend far more in time and money managing a messy and tangled codebase over time.
How to build solid code architecture before you start
The most important rule throughout all steps is to document everything. Instill this practice in your teams and make sure they understand its importance.
Step 1: Choose an architectural style, learn the rules, and stick to it
MVC (Model View Controller) is one of the most popular options for this, but many people fail to use it correctly. Make sure you and your teams get to know the style so they can get the most out of it and avoid mistakes.
Step 2: Choose a testing style that works for you
There are two main options:
- Test-driven development (TDD) uses a short development cycle where requirements are turned into specific test cases and then the code is tweaked and improved until it passes the tests.
- Behavioral-driven development (BDD) places more emphasis on conversation and collaboration between developers, encouraging them to work toward a shared understanding of how the application should work.
Vermillion Sky uses both of these approaches, as both work well in different contexts. An important thing to note is that you should always document the reasons for your chosen style, along with any front-end testing styles.
Step 3: Set up all the tools around ensuring that your codebase is solid
Ideally, new developers should be able to jump in and get started after simply reading the wiki, and the best way to do this is by standardizing your codebase.
You should choose a continuous integration provider, which works by running tests in the cloud to check which code works and which doesn’t. If someone enters bad code, the continuous integration provider will make sure it doesn’t get merged until the developer fixes the errors.
Step 4: Move into the actual process of developing code
Before starting anything here, it’s important to check all previous code. Make sure all of the existing code passes before your developer moves onto developing more code.
Then, have another developer check the code and ensure it aligns with the standards defined in the project wiki.
Step 5: Integrate this into your weekly or bi-weekly process (i.e. scrum)
Even with the most rigorous practices and habits, things can sometimes start to drift. If you see this happening, it’s time to conduct an analysis to find out why.
Are you spending a lot of time fixing bugs, for example? If so, drill in on why this is happening and how you can spend less time on this issue in future.
How should businesses use their development budget to maximize output and efficiency from their development team?
Here are a few ways to get the absolute most out of your development team:
- Start with a minimum of two developers (ideally full stack) — this way, they can look at each other’s work and catch problems.
- Always budget enough for an MVP. You’ll generally plan to work with them for 3-4 months, but this is something that often runs longer than planned, so try to budget for 6-9 months to be on the safe side.
- It might make sense to hire a tester initially (if you’re bootstrapping, you can be the tester).
- If you don’t already have a designer, you should budget for a UX designer or graphic designer. Remember that design needs to be at least three weeks ahead of development.
The development stage of building an app can be stressful, complicated, and expensive. It can also be incredibly exciting, stimulating, and rewarding.
It’s crucial to make sure you budget for this stage the right way. Ensure your team has everything they need to hit their goals consistently for as long as it takes, and make sure all the pieces are in place before you begin.
If you’re having issues with your development team, like a flatline in productivity or things not moving fast enough, Vermillion Sky can help.
We can conduct a code review, analyze problems, create a clear plan for how to tweak your architecture, and train your team to get in the right architectural habits and ramp up their productivity.
To find out more, schedule a free strategy call.
