Every company has its own unique software needs, and it is becoming increasingly common for companies to forego commercial solutions and build their own. While it has become simpler from a technological standpoint to build custom platforms, the process of planning and executing remain human endeavors that can go wildly off the rails. If you’re thinking about building your own solution, here are some things that you should keep in mind.
Know Your Ecosystem
Every solution exists in a larger context, and it can be easy to lose track of all the components and stakeholders that will be affected by your development effort. The most dangerous assumption you can make is to assume that your project affects only you and your team. Not only can this lead to costly re-work, you could be missing out on a great opportunity to add value for other people within your organization. Or worse, making other people’s lives harder.
When you begin planning, make a map of all the people and things that your project could potentially touch. Include IT, management, vendors, and other teams. Think of upstream and downstream players who could be included in your planning, then work with them to make sure everybody is aligned on what the project is and what it is not. Not only will this help you avoid re-work down the line, but it will allow you to leverage a larger pool of expertise throughout your project.
Think About Value
Most of the time, a custom development process is undertaken to replace some existing manual process. Maybe you’re close to this process. Maybe you even designed it. But, that does not mean that your software should simply be an automated version of what you already have. It should add value above and beyond what the existing process offers.
For example, say you have a spreadsheet that you have to populate manually, and you want to create a web form to capture the same data. Does it actually take less time for the user to enter the information into the form than it does to enter it into the spreadsheet? If the answer is no, then the solution does not provide value, and needs to be expanded.
User Experience Matters
The internet has moved far beyond text-entry boxes and radio buttons. Modern frontend frameworks allow for user interactions that would have been prohibitively expensive only a few years ago. Don’t fall into the trap of creating a digital file cabinet. Pay close attention to how your problems are handled in existing solutions and don’t be afraid to copy. We’re all using the same tools, so most controls you see in other products can be easily added to your own. You will find that good user experience can add tons of value and efficiency above and beyond automation, and a thoughtful design will make your stakeholders much happier than clunky webforms that were state of the art in 1998.
If you are building automation, don’t assume that there will be no humans involved. We all know you want to automate from end to end, but reality is rarely so cut and dry. Think about how humans in your organization will troubleshoot issues and deal with exceptions. If you’re not careful, you will create five problems for every one you solve.
You must keep the user in mind for every choice you make. It is tempting to believe that if something isn’t right, you’ll just force them to use it as it is. But I can tell you from experience that angry users will cripple your development effort. It’s far better to keep them happy.
Use Dedicated Resources
There are few things that do more harm to an internal development project than unbound resources. If you find yourself in a situation where you have a couple developers who can work on your project for a few hours a week, then your project is doomed to fail. Those developers have higher priorities that will interfere with your work. Furthermore, it is not good practice to have developers jumping from project to project. Coding requires a high level of focus, and it is mentally disruptive to constantly switch from one piece of work to another. If your developer is only spending a few hours a week on your project, then it is very possible that one hour of that time every week is spent just trying to remember what your project is even for.
Have a Support Plan
So you’ve finished your product and released it to production. You’ve cut your developers loose and now you can just let the program run. All is right with the world.
That’s not how it works. Regardless of how much testing you do, you will have issues when a program goes into use. There will be technical and ergonomic failures that will require rework. Even once those wrinkles are ironed out, you will still have to deal with the ever changing technology landscape. Features will be depreciated and integrated technologies will be updated, invalidating your work. If you’re not prepared to support the product long term, you risk that your product will slip into obsolescence. If you cannot support issue reports from your users, you risk that they will simply abandon it.
Beware the “Grand Vision”
Designing software is fun, and it’s so easy to fall down a rabbit hole to a world where you’ve automated every problem, and there is peace throughout. The problem is, the more features you plan, the more complex and interdependent your code becomes. You can easily get bogged down in all the details. The days where teams could spend years planning their projects are long gone, and I personally hope they never come back.
Instead, focus on your MVP: Minimum Viable Product. Ask yourself, what is the most basic goal of my product? Don’t solve every problem or include every feature. Break it down to the most basic, central feature, then build that. With that done, pick another feature that builds on your first one, then deliver that. Regular deliveries keep the pace of progress moving forward and create opportunities to engage users through demos. Even more importantly, watching your product evolve through regular deliveries is hugely satisfying.
Regular deliveries have another important advantage. They allow you to constantly re-evaluate your plan with fresh eyes. You can learn from experience and re-think features that you planned out earlier. This leads to far better solutions, and it generally yields a better program because code is being constantly tested and re-factored.
One of the biggest difficulties with building software in-house is that software development is rarely part of the core business. This is especially true in localization (even if it’s localization in a software company). Business happens every day, and can often interfere with initiatives and side projects. In the same way that part-time developers can be a drag on progress, a product owner whose attention is dominated by the day-to-day running of the business may not be able to give the project the care it deserves. Bringing in an outside product owner guarantees that your product is getting priority, even when you are too busy to give it priority yourself.