How to Start Small & Iterate Upwards: Smart Custom Software Development

p>One of our specialties within the agency is the development of custom software applications. Most of our projects are web or mobile based, typically involving multiple moving parts such as databases, API’s, web applications and native mobile applications as well. Every project we undertake begins by conducting an introductory call with the client. This call, typically less than an hour in total length, gives us an immediate sense as to the project scale, the particular moving parts that will be necessary and the vision of the client who wants to see the project to fruition. All too often, however, we see customers that are focused on trying to do a bit too much on the first iteration of their software. Our goal, in that case, is to start to manage expectations and provide the customer with a path to success that focuses on an iterative and phased approach.

In this post, I want to walk you through some of the steps we recommend to clients who are seeking to custom develop software, and why we recommend these steps. At a top-level, our focus throughout a project is always risk mitigation. Minimizing risk, regardless of if its financial, operational or security-driven, is always top of mind when developing software. If it isn’t, then you aren’t properly preparing or executing on the development of a project. If we can minimize your risk as a client that your money will be wasted, minimize your risk of long-term costs associated with bad development, and all but eliminate your risk from a security perspective, then we’ve done our job.

With that said, here are some ways that we work to complete projects with the lowest possible risk profile for our customers.

First, Start Small

I’m always alarmed when a customer comes to us with a grand plan for a large piece of software. It usually comes to us in one of two ways. First, you have the client who says they want to make the next eBay, or similar. That’s always amusing to us: applications like eBay take millions of dollars to build and years of effort. Clearly, there is too much to undertake in one shot. The second type of prospect we talk to comes to us with documentation, flowcharts, and all sorts of explanations about how they want their software to work. Typically, things are over complicated.

Our first step is to always focus on what the smallest effective project is. In our language, that means an MVP or minimum viable product. An MVP is exactly what it sounds like: what is the minimum amount of effort you can build, the minimum amount of functionality you can enable, to prove your model works and therefore justify additional investment. Whatever the answer looks like is most likely your MVP. We want customers focused on the MVP from an early stage and to remain focused on that like a pilot on final approach to the runway. We’ll talk in a minute about architecture and future planning, but from a very early level, which means our first interaction or meeting, we want you to focus on what the minimum viable product looks like for your organization. 

Second: Architect

The next phase is architecting how you’ll actually build your project. We’ve spoken at great length in this blog and throughout the site about the architecture and discovery process. These days, it’s a required part of our process to ensure success. A client who doesn’t want to undergo discovery isn’t a serious client. And an agency that doesn’t offer such a process isn’t interested in minimizing your risk.

A successful architecture and discovery program will result in complete clarity about your project. When completed, you should know precisely how your project will be built, what the functionality will look like, the technology that will power it, and the budget requirements plus timeframes to accomplish all of this. There should be very little room for error or misunderstanding when discovery was properly completed.

This first stage is also, despite what many may believe, a good opportunity to pontificate or theorize about the future. Understanding plans for iteration of your software down the road will enable the architect to make proper decisions about technology today. So, feel free to brainstorm future possibilities but at all times remember the reason for this exercise is to execute a plan that results in an MVP within your timeframes and budgetary constraints. 

Prototype Before Development

There is a great value to having a functional prototype built prior to undergoing development. Even despite the most thorough development, when you have a usable prototype, people tend to make decisions that can affect the overall specification, changing things a bit. Building a prototype that has function before undergoing full back-end development is another method of minimizing risk during and after development. The only negative is that it takes a bit longer and may cost you more from a budget perspective.

There are a few ways you can prototype. First, you can wireframe. Wireframing is the production of mockups that illustrate the positioning of elements within screens or pages. They are typically not full designs. I find that wireframes are helpful when the end-client is technically minded and there are minimal stakeholders. After that, they tend to be more confusing than helpful.

The second method is to utilize prototyping tools such as Adobe XD or similar. These allow UI/UX experts to quickly put together designs that can be “linked” together mimicking actual user flow within applications. These tools don’t necessarily provide the most native experience, but they do give you a sense of overall flow, which can be helpful highlighting any early issues or changes to the software that may arise.

The best method of prototyping, but the most expensive and time-consuming, is a full HTML-driven prototype. We’ve done this for both mobile and web-based applications. When building a web-based application (and some mobile apps, depending on your methodology of development), there is a good chance you’ll be undergoing HTML development anyway. Web apps built utilizing popular JS platforms such as Angular and similar will need HTML regardless. By prototyping out the entire application in HTML, you are allowing for a few benefits. First, you’ll have an early opportunity to see what the actual experience will be like. Clients can benefit from being able to make changes prior to expensive integration work being completed. Also, you’ll have an actual, tangible deliverable that you can utilize for any internal discussions, planning or approvals you may need. In most cases, for just a bit more budget, this is a winning scenario for customers.

Regardless of the method you utilize, prototyping is an important step to take which will allow you to stay focused on your MVP and drive the highest possibility of success for your project.

By the way, custom software always has one essential component… The user interface. There are two approaches you can employ when it comes to UI/UX. First, you can custom design the entire user interface. This is exactly as it sounds – a bit time-consuming. However, like anything else built for you, it has its advantages. The other method is to utilize libraries taken off the shelf – preexisting designs which can speed up your process. This is a subject for another post, but worthy of mentioning as it is a choice you will have to make prior to prototyping.

Development: Agile or Waterfall?

There is a lot of debate about these two popular methods of development. On one hand, waterfall is a good method to ensure that each stage of the project is completed according to specification before proceeding with the next stage. This is great for projects that are well defined, especially those that went through the discovery process. But, on the other hand, agile development makes a lot of sense for those who want the ability to iterate quickly and change course as they go.

Either method can be employed post-discovery. Waterfall works BEST after discovery because you need all elements predefined and agreed to before development begins. After prototyping, waterfall is in its most efficient state, because at that point the front-end has been defined and it’s just a matter of tying it all together. With agile, it works best during prototyping, where the most pivots may potentially happen. However, many clients are not comfortable with agile as the method is open-ended and therefore costs can be difficult to predict.

A hybrid approach often works best for custom software development, where you utilize the tenets of agile during the prototyping stages when there is the most probability of pivots. Then, proceeding with development in a waterfall fashion can result in an effective and manageable way. This hybrid model allows for flexibility throughout the process and the utilization of the benefits of each approach where they are most needed.

When Done… Then You Can Iterate.

If you’ve gone through discovery and built a specification, developed a software architecture within budget and within reason considering your future plans, and created a workable prototype, you’ve won more than half the battle. The opportunity to disagree about spec is now minimized. The potential “gotchas” in terms of use cases or user flow are caught. At this point, your MVP should be through the majority of development and ready to be deployed for all to see.

This is where the fun begins – you can now grow on top of your new platform to accomplish even more than you originally set out to do. And this is the benefit to custom software development. This application, this platform that was built to your specifications for your requirements, is now your asset on which you can build more and more functionality to assist your company in completing its mission.

Having gone through the process properly, you were planning in advance for what the future may hold. At this point, the only thing to look out for is to beware of the quick fix. Always make sure whatever changes you make to your software have the future still in mind. You want to avoid technical debt whenever possible. This is done by planning new features properly and amending the code base as you go. It’s not difficult to take the easy way out when iterating – but in the long run, it’s better to focus on how you can properly grow and not just perform patchwork projects to make quick changes. Software can grow stale and become unstable – much like any asset – if not properly cared for!

Conclusion

There aren’t many mediums that can affect a business’s core operations and profitability much like custom software. However, software is also unlike anything else you build. So much of the success of a software project comes down to planning, creativity and the folks doing the actual work. The goal throughout your project should be to plan properly for an effective MVP, go through each step of the process while considering the next, and never biting off more than you or your developer can chew. By doing this, you will mitigate the majority of risks that you’ll face, and lay down the groundwork for a successful platform that will serve your company for years to come