If you’re about to invest in custom software, you have high hopes for what it can do for your business. As my colleague Mike wrote recently:
Building custom software is like sculpting with clay—you can create just about anything you can imagine. Whatever your business process is, custom software can be coded to handle it in a streamlined and elegant way. It enables you to differentiate your product offerings and create repeatable value for a large number of users.… But here’s the catch. Custom software isn’t cheap.
– from Should you build custom software? by Mike Marsiglia
Unfortunately, even with a great idea and a talented team, a properly capitalized project can still experience issues. When you can make “anything you can imagine,” you can get off track and spend a lot of money on the wrong things.
The best way to avoid that and get real value from your investment is to take a flexible, collaborative approach and watch out for these six pitfalls.
1. Don’t Withhold Information from Your Development Team (Accidentally or Deliberately)
One way to introduce extra cost into your project is to be too sparing with information about your organization, your users, your project goals, or your motivations for building certain features or including certain requirements.
Atomic software consultants are hungry to learn everything they can about your domain, your organization’s needs, and your users’ habits, preferences, and goals. While our makers are curious people who love to learn, our real motivation for asking so many questions is to save you money and build you a great product.
By knowing as much as possible about the roadmap or the context, we can optimize even the low-level decisions for the best cost-and-value tradeoffs. We might decide to invest extra effort into creating greater leverage and reusability for key features, or opt for quick, but less flexible, solutions in other areas.
2. Don’t Over-engineer a Solution
On the other hand, I often challenge my customers on whether they (or their users) really need a given feature, or need it to work in a certain way. Believe me, I don’t do this to be difficult (conflict is one of my least favorite things).
When I ask questions or suggest compromises, it’s because there are often opportunities to slightly tweak a feature or its underlying business model in order to realize a significant savings in development cost. Sometimes, the savings can be enough to allow you to release early or build an entirely different feature that may otherwise have been outside of the budget.
As responsible consultants looking to maximize value whenever possible, we challenge our customers to take a minimum viable product approach: build the smallest thing you can, launch it as soon as you can do so responsibly, and adjust or add more features based on feedback.
3. Don’t Build the Wrong Thing
This builds on my last point. Often, your initial assumptions about your needs or your customer’s needs will be incorrect or incomplete. Building a highly engineered solution working with incomplete assumptions is a waste of your time and money, and our energy. User testing (either with prototypes, or with an MVP approach to your software) can help validate assumptions, show us where to adjust, and create confidence that we are building the right thing.
4. Don’t Ignore Progress Updates
When you work with an Atomic Object team, we demo working software to you at a minimum interval of every two weeks, and we deploy working software to a staging server where you can review it, either before or soon after that demo. We also deliver itemized lists of each feature that was completed, so that you can go in, exercise the features for yourself, and make sure that they meet with your approval.
One of the ways I’ve seen customers introduce needless pain points and surprises into projects is to postpone this work until the bitter end. They wait until right before launch to get everything set up and really use their software.
Exploring unfinished software can be difficult—a bit like walking around a construction site. You may need to wear the proper safety gear, and be mindful of holes in the floor. But just as it’s much easier to catch problems with a floor plan or a paint color you don’t like before the installation is finished, so, too, you can avoid costly surprises or scheduling issues by poking around your software early and often.
5. Don’t Rule Out Off-the-Shelf Components
Even when you’re building custom software, there may be ways to economize on cost by using plugins, external services, or pre-built libraries for portions of your project. Our teams have saved customers hundreds of thousands of dollars by suggesting clever reuse of off-the-shelf tools.
Sometimes, we’ll run into a situation where an off-the-shelf tool meets 95% of the requirements, but the cost to reach that final 5% is exponential. In those situations, I press my customer very hard to re-consider that extra 5%. If those requirements are the market differentiator, then of course, it makes sense to pursue them. However, if they aren’t truly important to the product, being a little flexible with your business requirements can save significant cost and time, allowing you to get to market sooner.
6. Don’t Introduce Thrash
At Atomic, we work in a specific way that allows our teams to be extremely efficient. Our SCRUM process of two-week cycles of planning, build, and review is specifically tuned to be as efficient as possible. Delivery leads and designers work with our customers to plan two to four sprints of the development team. This allows for adequate cycles of planning and review so that the work is very well defined before the development team goes to work on it.
Constantly changing priorities or injecting high-urgency hotfixes into the current sprint can severely slow down the progress of a project. If a pair of developers needs to drop an in-progress feature to investigate a bug or make a last-minute change, they need to check in/check out the appropriate code, and make a mental context switch. Every context switch comes with this overhead cost, so we do our best to work bugfixes into the next sprint plan, or at the very least, wait until a feature is complete and we’re at a good breaking point to work on a new thing.
Of course, we’re always willing to help out with issues that are truly high-stakes, but if an issue can wait a day or two, you’ll get better throughput overall.
Conclusion
If there’s one thing we’ve observed over 15+ years in the custom software business, it is that our customers will always have more great ideas than they have time and money. Because of this, we’re motivated to help you get the most value out of the resources that you do have.
The most rewarding thing for our makers is helping customers achieve success, and the more efficient we are, the more success we can help you achieve. By sharing as much information as possible, engaging positively in the process, being open to ways of economizing your project, and helping the team stay on track, you’ll be able to receive as much value as possible.