Most people will be involved in approximately zero custom software development projects in their careers. And unless you’re a developer or work in an IT department, if you are involved in a custom software project, it’ll still probably be just one or two.
When you only do something once or twice in your career, chances are you’re not going to be an expert. This doesn’t mean that you can’t ace your first (and maybe only) custom software development project.
We’ve been involved in hundreds of projects and, while no two projects are identical, there are best practices no matter what type of software you’re developing. Here, we’ll share our top insights to help clients set up a custom software development project for success. These are most applicable when you’re
outsourcing to a development partner, but many apply to in-house projects as well.
Plan Your Web App
Start planning your custom software project with this free worksheet download.
A Strong Foundation for Your Custom Software Development Project
A custom software development project begins before any development work starts. The groundwork you lay before you even contact your software development partner—as well as between choosing a partner and starting development—is crucial. This preparation sets a strong foundation for your project and for the success of the system you build.
Here are steps you can take to prepare for your work with a custom software development partner.
1. Define Your Goals
If you don’t know where you’re headed, you won’t know when you get there. Make sure you know why you’re building the custom software system.
Another way to phrase this is: “What will success look like?”
I know this tip seems self-explanatory and obvious, but we talk to a lot of people who have an idea for an app or system but haven’t identified the bigger goals and purpose. Instead of, “I have an idea for software that would be cool,” think more like, “this software will help us do this process faster and with fewer mistakes, making our customer experience better.”
In other words, think outcomes, not features. Feature planning will come soon enough, but that process should be informed by the big-picture goal for what you plan to build.
2. Set Guiding Principles and a Vision
Guiding principles are more specific than the overarching project goals and are meant to serve as a litmus test as you make decisions throughout a project. They’re there to guide you and help keep you on track. Read how and why we use guiding principles.
It also helps to document the long-term vision for your custom software:
- How does it fit into your business model?
- How should it evolve in the next three to five years?
- To which areas of your business is it most valuable?
As your business grows and evolves, your application should grow and evolve along with it. Guiding principles help create a framework for evaluating your investment in and priorities for your custom system as the project moves along.
3. Identify Users and Talk to Them
It’s fine when a CEO or CTO has an idea for custom software that will help the company. But that platform can only be successful if it meets the needs of its users—whether those users are internal team members, customers, or both.
Before you start building a custom system, you need to know the type of users who will be using it, and you need to get input—even buy-in—from them. You can, of course, do more in-depth user research and testing throughout the project, but it’s important to know the basics about who your system will help even before you start.
We recommend building out user profiles for each type of user. If you have multiple user types, each will likely have different needs and priorities for the system. This step is especially important if you’re building an application that will have both internal and external users—how will each group use the system and for what?
Early on in the planning process, you can talk to internal and external audiences to learn:
- What they like and don’t like about the way work is currently done
- Anything they’d like to see in the system that would make their work better
- Must-haves for making the system more valuable for them to use than the current way
- Ideas for improving current workflows as you change to the new system
- How and where they might use the system—on desktops only, on the go on tablets, on mobile phones, in areas without internet access, only at the office, on many different devices, etc.
4. Plan Time to Be Involved the Project
Even when you work with a development partner, there’s still a lot of work for your team to do. We’re the custom software experts, but you’re the expert of your organization, your customers, and your workflows. It’s important to set aside time for the right people to be involved in the process.
Each client generally has one client product owner (PO) who serves as our main contact. This person makes day-to-day decisions, works closely with the Far Reach team, and pulls in additional members of their team when appropriate. This person should be given sufficient decision-making power to keep the project moving. This person will become familiar with custom software development and Agile/Scrum processes.
Client POs can spend several hours per week on a custom software project during the development process. Each sprint—every two weeks for us—we have a check-in meeting to show completed work, get questions answered, and prioritize upcoming work. Between these meetings, there is plenty to do with reviewing work, answering quick questions, tracking down additional information, and communicating with stakeholders as needed. When we’re in the thick of a project, we may even meet weekly to ensure a consistent flow of information among all project team members.
Each client has to decide who they want to be involved in a custom software project and to what level. An example setup could be:
- CEO - Gives overall budget and vision approval and leaves the rest to the team
- CTO - Helps during architecture setup and deployments
- Customer Service Director- Plays the role of client PO and is the main team member working with Far Reach
- Other Customer Service Reps - Provide feedback and ideas at various stages throughout the project
Every client has a different team make-up, but it’s important to have the right people in the room (well, Teams room these days) to make decisions and keep the project moving.
5. Have Realistic Budget Guidelines
When you don’t work on development projects every day, you’re not expected to know how much custom software should cost. It’s important to ask trusted consultants, do your research, and set your expectations accordingly.
Because of the nature of custom software, costs for a minimum viable product (MVP) can range anywhere from the low 5-figures up to 6-figure budgets. That’s why it’s important to get an estimate for what you’re looking to build. And knowing that custom software isn’t a one-and-done, launch-it-and-forget-it thing, you have to look at budgets beyond year one.
Custom software applications are “living” products. They (should) change when your business changes. If they don’t, you’re missing out on one of the primary advantages of custom development–flexibility. That’s why we talk with clients about investing for the long term, planning annual maintenance budgets, and looking ahead to future enhancements.
Over the years, we’ve refined our estimate process to help educate clients and reduce the potential of surprises down the line. Software development has constraints—the iron triangle—that balance the need for flexibility while also maintaining expectations, and that can be a hard concept to grasp on your first project.
We’ve done enough projects to know that things will (and, again, should) change as a project moves forward. Within reason, we don’t want budget to hold clients back from building what they need and will bring value to the business. Understanding the system’s vision and identifying priorities helps keep us all focused on the goal, and budget contingencies allow us to react to unforeseen circumstances.
The cost of custom software development is an important factor in a project. Having trust in your development partner, their experience, and their process goes a long way in making sure your large investment meets the goals you set out for it.
6. Set Timeline Goals (and Add Padding)
Similar to budget expectations, a custom system’s development timeline needs to be realistic. We can’t build a complex custom system—while maintaining our quality standards—in a few weeks.
In many cases, timelines for developing custom software are “nice to haves.” In other words, clients want the system by a certain time—the sooner the better—but there’s not a hard-and-fast deadline. We work together to estimate a manageable timeline based on the scope of the project, understand the timeline can shift as we run into situations, and work hard to meet timeline expectations and communicate changes.
Legacy software rewrites are an example of a more critical timeline coming into play. When a legacy system—or an underlying technology of the system—is being retired, there is typically a true deadline for the rebuild. This is why we recommend keeping a close eye on your systems, setting aside time to plan your software strategy, and planning as far in advance as possible for retiring technologies.
Timeline expectations are yet another important conversation to have with your development partner to understand the initial timeline estimate as well as if (and why) things shift throughout the project.
7. Document Existing Processes and Their Challenges
Custom software is most often used to replace an existing workflow, whether it’s a SaaS platform that’s solving a problem for users or an internal system that is moving work from paper or spreadsheets to a centralized digital system.
Because existing processes, well, exist, you can get a leg up on a custom software project by documenting processes you expect to build out in the system. Understand the workflows, what the people doing the work like and don’t like about the current way, and opportunities for improving processes beyond just moving them into a digital system.
Documenting existing processes can involve everything from drawing a workflow map and pinpointing dependencies to listing the form fields needed and collecting existing report examples.
By collecting information and documenting the existing way in advance, you can make sure you account for what needs to be built out in the software system and ways to make it even better.
8. Determine Your Priorities
We’d love to tell you that you can get every single piece of functionality you set out to build within whatever budget you have to work with, but we’d be doing you a disservice—and lying–if we did. Throughout the project, you’ll have to make decisions about what will be built soon, what will get put off, and what might not be built at all.
We try to work in priority order on everything we do. “Priority” isn’t always clear because, let’s be honest, we’re all usually balancing multiple priorities at once. The key is just that: balance. What can give and what can’t? What will bring the most value now and in the long term—and does the now or the long term matter more?
Clients have to prioritize custom software development at every stage of the process. At the beginning, we have to prioritize user groups and feature sets to lay out an initial MVP backlog. Throughout the entire project, we have to revisit those priorities as we narrow in on upcoming work. The previously determined vision and guiding principles are important for making sure priorities are in line with your goals.
If you set your priorities out ahead of time, at a high level, you’ll be more confident in your decisions and know you’re always working on the most important thing.
9. Start Thinking About the Rollout
The time to start thinking about how you’ll implement your new software platform throughout the company is before you begin development. If you start planning for the rollout too late in the process, you could experience delays, unnecessary rework, and other less-than-ideal consequences. Your rollout strategy can impact development decisions and vice-versa.
Building a custom software platform is one thing. Doing the requisite change management with users—whether they’re internal or external—is a whole other thing. Preparing future users for the change, helping them feel comfortable, making sure questions are answered, and continuing to support the rollout process as it morphs into the ongoing maintenance and enhancements of the system can go a long way toward ensuring the success of the project.
Where do you start with a rollout? The plan! Download our template.
Final Thoughts
Being one of the lucky few who gets to take on a custom software project may seem daunting in the beginning: there are a lot of big and small decisions to make, and each of them can impact the final product. The good news is that you don’t have to tackle everything alone.
Bring in other team members to get input and buy-in throughout the process. Moreover, don’t be afraid to rely on your development partners. If you work with the right custom software development company, they will be able to help you navigate challenges as they arise.
Have more questions about preparing for a custom software development project?
Reach out.