When does your business need Custom software?

Do you need custom software to improve your business?

 

For some companies, this isn’t even a question.

 

For example, in order to serve their customers, ParknSave needed a business system that made it easy for users to purchase parking.  They alleviate stressful situations every day with their custom software.

 

Other businesses, like ImedView, need custom software to save time for their staff and manage their workflows better. The new system helps save costs every day and frees up time for staff to focus on other business development tasks.

 

Every business is unique.  You may be wondering whether you need to create something from scratch in order to improve your business.

 

Let’s start by examining processes to identify if you need custom software or if existing, packaged software can accomplish your goals.

 

How to identify if you need custom software vs. packaged software

 

Sometimes, you may think your organization needs a custom solution, but existing, packaged software will do the trick.

 

A packaged software solution is a commercial solution available to the public that you can pay a monthly or annual fee to use.  

 

Software packages are often rigid in terms of what they can accomplish.  They come with a set list of features that often cannot be fully customized.  

 

Some will let you make customizations, but require advanced API knowledge or further software development.  Others allow you to add plugins or extensions (paid and free) to include your preferred features.

 

Salesforce is an example of packaged software that helps manage your sales, while Quickbooks is an example used for bookkeeping.

 

What if your organization’s needs go beyond the common uses of packaged software? What if you’re trying to extend the functionality of packaged software so it can accomplish everything you want? 

 

These are instances when you need to start thinking about a custom solution.

 

Here’s an example that our CEO, Chris Miles, likes to share when consulting with customers.

 

One company came to us and said they needed an intranet.  The system needed to connect everyone within an organization and allow them to chat with each other.  

 

Users needed to share stories, send direct messages, and create an interactive poll.

 

This organization could spend hundreds of thousands of dollars building an internal web portal for their employees, or they could create a private Facebook group.

 

While this solution may not fit every organization due to security or the effects of using a shared environment, it does offer a different way of thinking.

 

We know every organization is unique.  

 

However, just because you occupy a niche space in your industry or follow unique processes doesn’t mean custom software is right for you.  

 

Can HubSpot and Quickbooks in tandem accomplish what your needs are today?  

 

If so, then you may be able to use them as is for now.

 

Custom software may be the best choice when your tech stack becomes so intense that you’re combining 5, 10, or 15 pieces of software.  At that point, one interface custom-tailored to your organization would be a better fit to help you accomplish more.

 

Existing Software by Industry Vertical

 

What if another organization already had your idea?  Can you leverage that solution for your organization, or do you really need something custom?

 

You can also utilize frameworks created by others in your industry, but this may not always be the best solution.

 

One of our customers utilized a program designed for home care agencies and applied it to hospice.  While this solution worked to get the job done every day, it wasn’t tailored to their specific needs and led to frustration among their employees.

 

Sure, they could get the information they needed, but they had to spend additional time in the application answering the same questions over and over. 

 

It wasn’t easy to change the process.

 

As a result, this company benefited from a custom solution that streamlined operations. The system saves time for employees and allows them to focus on other business processes and improvements.

 

Look internally to see whether you really should invest in custom software development.  

 

What can technology do for you?

 

You’ve certainly taken your business to new heights if you’re considering custom software to enhance processes.  

 

You may have utilized some intuitive business technology along the way.

 

But if you’re using Google Sheets or Excel right now, you are missing out on more modern technologies.  The world has advanced since you first used this solution to run your business.

 

Custom software will take your business to the next level.

 

Whether it’s business intelligence software that reveals new insights or a system that identifies areas for improvement, a custom solution can help you leverage new opportunities for your business.

 

The right software can also improve communication between employees.  If your team uses Slack right now, but it doesn’t connect to your ERP, then there will be gaps in communication.  You should consider creating an intranet for your employees to communicate and keep everything in one place.

 

Additionally, productivity will improve with an enhanced business software solution.  Rather than waiting on long-load screens, your staff can spend more time doing what matters for your bottom line.

 

Sales can improve, too; if you have a SaaS solution, you’ll want to provide a seamless user experience and make sure all information is accessible and available.  If these customers have an excellent experience, they will likely be happy, long-term clients.

 

Misconceptions about custom software

 

People often have misconceptions about custom software.

 

Custom software development isn’t just a one-time project—it’s part of an entire ongoing business strategy.

 

When we work with a customer, we’re partners throughout the entire journey.  We care about the software, its full adoption, and its scalability as much as they do.

 

Yet, some customers come to us with a pipedream.  

 

They may want to build the next Amazon or Lyft, but they only have a $20,000 budget.

 

Both of these publicly traded, billion-dollar companies have thousands of employees to build and maintain their systems.  Keep in mind that these employees also have salaries. 

 

The idea of “the Amazon of X industry” is a good starting point.

 

But it’s not that simple to just recreate one of these giants.

 

That being said, custom software can be a game-changer for you and your customers.  It doesn’t need to change the world immediately, but if it can change the world for a select number of people, that’s a great start.

 

Systemplicity

 

Whether you decide to use custom software or a packaged solution, your goal should be creating Systemplicity.  Systemplicity is the state of having a technology infrastructure that is uncomplicated and easy to understand, maintain, manage, scale, and use.

 

Our VP of Software Consulting, John Horner, created a presentation that addresses how you can better understand your current IT systems at your organization.

 

Sometimes, businesses end up using ton of extra software and IT systems and are unsure how to simplify.

 

We recommend taking a step back and reviewing all of the different software systems you’re using.  Consider the number of people using each system and the impact of any inefficiencies related to the system.  Then, evaluate the investment in terms of licensing, hosting, and vendor support.  From there, you can diagnose which systems you need and which you can eliminate.

 

You can use this list as a starting point:

 

• How many different systems do you have within your organization?
• What do you use for sales?
• What do you use for invoicing?
• What do you use for scheduling?

 

You get the idea.  This list may not be exhaustive, but it’s important to measure what you have in place.

 

You may find you can remove systems now, or decide that you need these functionalities to exist, but perhaps not as siloed as they are now.

 

Working towards Systemplicity can help drive the realization that you do need to create custom software.

 

If you feel that you have too many different pieces of software and they conflict or cross paths with one another, you may need a custom solution to help simplify your infrastructure.

 

If you need simplification and have the time and budget to invest in your business to improve processes, then it’s time to develop custom software.  

 

Keep reading to learn how to start this journey.

At this point, you have identified that custom software is right for your organization.  In this chapter, we’ll discuss what you should know about the process.

 

Creating a plan of what you need

 

Running through the exercise of Systemplicity should have revealed what you need and what can be removed.

 

While you may be able to cut out some systems themselves, the functionalities of these solutions are what you should look to add to your custom software.

 

Begin by creating a large list of what your software truly needs to do.  Then,  pare it down and write next to each functionality whether it’s a “necessary” or “nice to have” feature.

 

In addition to functionality, you should look internally at your business processes and take note of any issues.  Consider questions like:

 

• How are processes carried out today?  What is essential?  What could make them run better?
• Is the complexity of your day-to-day business preventing you and your team from reaching your full potential?
• Do your employees spend hours copying and pasting data throughout their day?
• Does your current process work adequately today, but could be improved?

 

Creating a Roadmap

 

Creating a roadmap is defining an understanding of where you are today and when you’d like to have all of your desired functionalities implemented.  

 

Your goal should always be to create a minimum viable product or minimum valuable product as we like to call it.

 

A minimum viable product is the first version of your custom software that includes only the essential needs of your new system.  This version will be the foundation of your eventual expansion of this software.

 

From here, you should map out when you will create additional functionalities on top of what you built.

 

How do I phase out my old software?

 

Because it’s better to build software one step at a time, you may not think that your team will be ready to adopt a piece of software that isn’t completely ready to use..

 

Before you think that you need to have everything working 100%, take a look at Google.

 

They’re forcing everyone to move from Universal Analytics (UA) to Google Analytics 4 (GA4) by the summer of 2023.  If you take the time to play around with the GA4 interface and compare it to UA, you’ll realize there are missing features.

 

Right now, in order to see the entire picture of analytical data, you need to use the old system to find specific data points.

 

That being said, just because one of the largest companies in the world follows this process doesn’t mean it’s the best practice for your business.

 

Try to think about what a minimum viable solution looks like.  What are the essentials of your software that help your team get their job done every day?  

 

Start with those features and slowly expand by bringing “nice to haves” over.

 

How to modernize my software?

 

Now that you’ve identified what you need and when you need it, it’s time to modernize your software.

 

If you already have software, you may ask, “Should I blow it all away and start over?”

 

It makes sense to start over in situations where:

 

• the technologies are excessively outdated/unsupported
• the needs from your software are significantly different from what exists today, or you can leverage and gain significant value from what current technologies afford
• the system is not built on a stable foundation
• the system is very intertwined and making updates in one area affects many others

 

If none of these conditions are true, then you can work with the existing software solution that you have in place and expand upon it to add your laundry list of features.

 

What technology should I use for custom software development?

 

If you’ve decided to build your software from the ground up, you may need to decide what language to build it in.  

 

There isn’t oneright answer to this; your system just needs to be built in a standard, up-to-date, and supportable language.

 

When choosing a company to build your software, you want to make sure they have multiple experts and a great deal of experience in the technologies and languages that you have chosen for your system.  It also can be helpful if they have a breadth of expertise spanning other technologies and languages.

 

For example, our team doesn’t just specialize in .NET; they have mastered many different languages and are always continuing to expand and learn.

 

 

What’s involved in creating your new custom software?

 

Creating custom software takes a considerable amount of time and energy.  

 

 

The investment in the first iteration of your software is the most significant investment you will make in a custom software solution relative to the result. 

 

There are multiple options you can take.  

 

You can hire internal developers who will build and maintain your software, or you can outsource to a third party.

 

If you’re using a third-party company, you’ll still want to have internal resources assigned to working with this vendor so that the final product can match your business vision.

 

There are a lot of moving parts to keep in mind.  Below is a short list of all of the main components that should go into development:

 

• Discovery
• Architecture (Vision to Reality)
• UI/UX design
• Development
• Project Management
• Quality Assurance
• Data Migration
• UAT
• Refinement (Adoption)

 

Let’s take a look at how you can find the right vendor to assist with all of these needs.

 

Finding and choosing the right vendor

 

When it comes to actually building custom software, you’re going to need to decide where to allocate resources.

 

If you hired an internal staff member to build and maintain your software, then you need to consider the future.  What happens if that employee(s) leaves the company?  Is there a backup staff member who can fulfill their role?  Do they have the breadth of expertise to handle security, performance, and other software needs?

 

If you decided to outsource, then you’ll likely have a dedicated team behind your software.  

 

The right team will be able to support what they build and keep it modernized year after year, so you don’t have to worry about using an outdated piece of software in 10 years.

 

Outsourcing doesn’t mean only using overseas development companies—you can hire in the US as well.  The expense is almost always higher, but the project is much more likely to succeed, and the final product is often vastly superior.

 

Whichever option you choose, it’s essential to have documentation and backup plans in place so you’re never reliant on one person using and maintaining the software.

 

It’s also worth considering the intellectual property of your system.

 

Some organizations don’t let you own the code once it’s built.  Make sure you’re explicit in your roadmap and RFP that you will own the intellectual property when the software is developed.  

 

That way, you can modify, distribute, and expand upon the software in the future without needing to license it from the development company.  

 

How is your software built?

 

The best part about our custom software process is that we work within the Agile framework.  We recommend that you do too when working with your chosen developers.

 

This process means that we build with the end goal in mind, but take incremental steps toward that end goal.

 

For instance, if we were building a house and just said we wanted a door, four windows, and a roof, the outcome may not turn out how we expected.

 

We got what we wanted, but didn’t follow a roadmap and didn’t think through all of the steps.  Consequently, the result was different than what we anticipated.

 

When building software, it’s important to take it one step at a time and build the foundation first.

 

This means understanding the core functionality, accomplishing your main goals, and making sure the software works before incorporating additional features over time.

 

You may discover from using the software that there are aspects you want to change.  As a result, your initial list of functionality requirements may drastically change from your vision to reality.  

 

That’s why it’s important to start one step at a time and expand during the adoption phase.

 

In order to find the right company that uses the framework that fits your business, you will want to create an RFP.

 

Creating an RFP (request for proposal)

 

When considering who to choose to help build and maintain your software, it’s best to start with an RFP (request for proposal).

 

This RFP should include details from your roadmap such as your project vision and goals, current processes, and functional requirements.

 

You’ll also want to outline a reasonable timeline for your organization.  

 

Remember that you don’t need to have all the bells and whistles right out of the gate.  It’s more helpful to start with the essentials and build from there.

 

Choosing the right partner to build your software is extremely important.  If you choose the wrong vendor, you’ll be incurring additional costs by wasting time and money on this first vendor.  In some cases, you may even need to redevelop the software if it does not have a sound architecture.

 

Take your time with this step and carefully weigh out all vendors you’re considering.

 

Hourly vs. Fixed Costs

 

You’ll want to weigh the pricing structure of your third-party vendors and consider how they will be billing you.  Will they charge you an hourly or fixed price for creating all of the functionality defined from your roadmap?

 

We follow an agile process for our software development that is also based on a fixed-cost model, but this isn’t true for every company out there.

 

This means that our pricing is based on estimated points rather than hours.  Our customers are charged based on the work completed, not the amount of time it took our team to complete it.

 

When someone says it will take 2 hours to complete a portion of the work, it might only take one developer 2 minutes, whereas other, less experienced developers may take 2 hours to complete it.  In the latter case, you would be charged for those 2 hours.  As you can see, the company isn’t incentivized to apply the best or fastest resources to your project.

 

Great companies will understand their internal point structure and each worker’s capacity with an Agile system.  

 

Our focus when building a piece of software is completing the project.  We want 100% adoption and successful customers who champion their software.

 

Overseas companies often prefer to charge hourly rates, which means their deadlines are further out.  This strategy often costs a lot more for the customer in the long run.

 

Your RFP will help you understand the range of costs you’ll need to consider when building the software itself.  But what about ongoing expenses?

What types of ongoing expenses should I consider?

 

There are many factors associated with software that you may not consider right away.

 

Of course, you need to factor in the cost of building the software itself, but what about ongoing expenses?

 

Let’s take a look at what you should keep in mind when pricing everything out.

 

Development

 

The majority of your software costs will go into the development efforts.  It is important to understand the impact of different types of costs associated with software development to ensure you don’t under-allocate efforts and have your software fall short of your expectations.

 

The different costs related to software are sometimes bundled together and sometimes broken out separately.  This includes the following:

 

• Discovery & Architecture:  This is one of the most critical costs.  If you don’t have a sound architecture, your project will likely be riddled with unexpected costs, timeline delays, and excessive support & maintenance costs.
• Development:  It is important to ensure high-quality developers so you don’t end up with unforeseen “technical debt,” which is the future cost of reworking software that wasn’t built the way it was originally intended.
• Project Management:  Superb project management is critical to avoiding scope creep, unexpected costs, and timely delivery.
• Quality Assurance:  Quality assurance specialists and efforts, including automated testing, can ensure you have a high-quality product. Overall, this can save time for your team, ensure a seamless launch, and prevent unexpected support issues & costs.
• Quality Assurance:  Quality assurance specialists and efforts, including automated testing, can ensure you have a high-quality product. Overall, this can save time for your team, ensure a seamless launch, and prevent unexpected support issues & costs.
• User Interface & Experience:  Many systems benefit from user interface and experience specialists.  They can help improve your software’s adoption and efficiency
• Other specialists:  If you have specific requirements related to compliance, security, or other specialized areas, it is important to consider these as well.

 

Once the development is complete, you must consider costs related to the adoption and support of your software.

 

Adoption costs

 

Let’s say you just spent $200,000 building an amazing piece of software.  Day 1 comes and half of your employees decide internally that they prefer the old way and continue following previous processes.

 

You’ve not only wasted a lot of money building something but now have the same wasted expenses you did before you invested in this software.

 

That’s why one of our policies here at Miles is that adoption is not optional.

 

We encourage our customers’ employees to use the software and provide full training to ensure they can use the system correctly and efficiently

 

Encouraging adoption among employees is not only imperative from a cost standpoint.  

 

You also want teams to use it so you can make continual improvements.

 

Knowing they will have to use the new system will help make it more likely for your employees to have a vested interest in the quality and usability of the new system, and get more helpful suggestions for the future improvement of the system from them.

 

Most software improvements come about because someone used it and said, “wait, wouldn’t it be better if it did X instead of Y?”

 

You may think that your roadmap will cover everything your software should do, but it won’t.

 

In order to discover improvements, you have to start using your new system.

 

That’s why we don’t recommend building every single functionality right away.  After users spend time using the software, you may find you don’t need as much additional functionality as they thought.  Or, you might realize that the system should work differently than originally planned.

 

If a company’s proposal looks higher, this adoption process may be one of the associated costs.

 

Hosting

 

With any piece of software or website, you’ll need to make sure that it is always running.  This means choosing a hosting provider that can maintain 99.9% uptime.

 

If your software is a mobile application, you’ll want to choose the right framework for your code.  Firebase or Azure Mobile Apps are great places to start because they’re well-known brands.

 

Always choose a reputable provider to host your software, website, or mobile app.

 

Support and maintenance

 

We highly recommend that every business has someone responsible for supporting their software.

 

If it’s not supported, then you leave yourself vulnerable to security risks.  

 

For instance, let’s say you built your software using Magento.  Magento has extensions that can be added on, often from third parties.  Good development companies will continue to update their extensions with improvements in functionality as well as improved security.  

 

By default, these extensions do not automatically update because there may be compatibility issues.  

 

It’s important to have someone in charge of updating these extensions properly so functionality remains intact.

 

You also should have someone in charge of quality assurance—ensuring that basic functionalities continue to work.

 

Code can be finicky; one small update can have a butterfly effect on other areas of your software.  It’s important to make sure that everything remains working as it was when the software was built.

 

Finally, and it bears repeating, you must have process documentation in place.  Just in case the person managing the software leaves the company, you’ll want to give the next manager a complete understanding of how the software works.

The purpose of creating a new software solution is to solve a problem. If you envision an aspect of your business working differently, your solution will work differently as a result. 

 

If you had to work through your own aversion to change by deciding to commission a custom software solution, think about that process and how you can now help your team reach the same perspective.

 

Aligning your team around your new system is the most important way you can help.

 

As an example, let’s say your team uses spreadsheets for daily work.  At first, this is a great way to manage different aspects of your business like billing, customer information, and analytics.  However, it can quickly grow into a behemoth with a life of its own.

 

You may start with one spreadsheet, but eventually, you add on more and more.  Then, you start linking them all together.  Eventually, you end up with a web of spreadsheets or one giant spreadsheet that takes its own PowerPoint to understand and explain to others.

 

The right piece of software can vastly improve this process, but you need to help your employees and users of your software overcome this first stage toward adoption.

 

You will want to set your employees up for success by letting them know what to expect and inviting feedback from them once you have the first version of your software in place. 

 

Let them know that this is the first iteration of your software. 

 

Your company should proceed with version 1.0 in order to move forward with creating the eventual final product.

 

If you don’t launch “version 1.0” and inform your staff that there will be future updates, your staff might ask questions like: 

 

• What if we forgot something?
• Can we still add these small components?
• What if our team is still nervous about the transition?

 

These questions can and will be answered by future evolutions of your software.

 

Ripping off the bandaid

 

You may be tempted to keep a version of the old processes and mix them in with the new software.

 

We’ve found from experience that it’s best to rip off the bandaid and have your team transition fully to the new system.

 

The only times we recommend running in parallel (using both systems) is during beta testing or during a limited release period.

 

Let’s say you roll out your new software to a few testers to make sure it accomplishes the minimum viable product expectations.

 

At this point, you don’t need to force everyone to abandon ship and move to the new system just yet.

 

Make no mistake; people will be split over this new change.  Some will want the old system, and some will see the new software as an improvement.  They may breathe a sigh of relief knowing there’s an easier way to do their job now.

 

Here are some suggestions for discussing the launch of your new product with your team:

 

1. Have regular discussions about the vision. Be on the same page! Schedule town hall-style meetings or Q&A sessions. 
2. Assure them the software will be updated and incorporate their ideas. You’ll all be using this together.
3. The new system will be 90% better from day one than what they are using now, and 100% better after optimization.  It is 0% better until we launch!

 

Documentation and Processes

 

Any software that is developed should be intuitive.  If you need documentation, then it means the software doesn’t easily explain what it should do.

 

That being said, most companies are still working towards this never-ending goal of achieving a UX that needs no documentation.

 

Your software should be easy to understand, but you can still have help docs to fill in the gaps as you’re continuing to improve the user experience.

 

These help docs can include helpful tips—maybe some features of your software aren’t as obvious, and you want to make sure everyone knows about them.

 

Your documentation can also include information like who to contact in case of an error or bug.

 

It’s worth including backups and fail-safes in your documentation.  You’ll want to avoid the situation where a disgruntled employee leaves and takes the code with them so you can’t use or update it.

 

It’s also helpful in case an employee leaves the company for any reason.  

 

Make sure multiple people have access to documentation and all environments the platform was built on.

 

Try to cover everything you can in this step to avoid frustration for your adoptees.  Be sure that there is a place in the software where they can submit feedback as the software continues to grow and evolve.

 

What if features were missed?

 

After creating your minimum valuable product, you may find that you don’t have everything working as you originally intended.  

 

This can occur because:

 

• Not everyone who should be involved is included when an RFP is created for software requirements.
• System functionalities were created by management, and day-to-day users are left out
• The desired functionality did not make its way into the final product when it was assumed that it would be there.   
• Features were left undocumented and did not get built the way that was needed.

 

When any of these happen, you may get pushback from those who use the software.

 

For that reason, it’s important to involve not just managers, but people who use the software.  They should be included early in the process so key functionality is considered in the initial release.

 

It’s worth noting that sometimes a new piece of software is rolled out for your customers.  They may not have specifically asked for something new, but you knew it was the best way to help them accomplish more.

 

You may get pushback from users via analytics; they may not engage with the software as much as they used to.  These users should also receive announcements about updates and information letting them know that their feedback is important to improve the system over time.

Version 1.0 concentrates on achieving the first milestone on the path to your complete vision. 

 

You’ve set the foundation so your staff and customers can start using the software.

 

Next, you’ll want to work towards adding more functionality piece by piece.  Even though you don’t have everything on your wishlist in this first product, you can add functionality to your software little by little; you don’t need to add everything all at once.

 

Encourage your staff and/or customers to continue providing feedback and create an ever-evolving list of additional features.  You can decide to add these features in the future when time and resources allow.  

 

Think of Version 1.0 as the beta version. Versions 1.1, 1.2, and so on will allow your custom software to function better and help your company even more than the first model.

 

Why should Version 2.0 and beyond be your goal? 

 

Version 2.0 is where you start maximizing your software’s value. 

 

While additional releases of Version 1.0 focus on optimizing your software for your first and most important goal, Version 2.0 will repeat the process with a different problem and solution, moving your company closer to achieving your overall vision. 

 

You should continue investing in your software because it can and should improve your bottom line and streamline day-to-day processes.