3 Biggest Misconceptions About Building Custom Software

At Atomic, we work with many clients who are first-time custom software buyers. The process can be really intimidating. We’re often having conversations about investing hundreds of thousands of dollars into creating something that might feel a little bit like magic to them. Our goal is to be as transparent as possible throughout the sales process and, additionally, to equip them with the information they need to make a good business decision. Here are some of the most common misconceptions first-time buyers have when building custom software.

1. Software is a commodity.

Because software is largely a black box (dollars go in, UI and workflows come out) it’s tempting to approach buying it by controlling cost.

Sometimes, this is the right way to go. For example, if a company is still experimenting with product-market fit, building a cheap solution to test an assumption is a great investment.

It’s easy to fall into a trap here. They have a good experience with a low-cost provider and better yet they’ve validated their assumption and their prototype is gaining traction. They go back to the well, investing a much larger amount with the same provider.

Then, as the project moves along, they notice that feature delivery steadily slows down. Eventually, it’s taking nearly a sprint to build something that used to take a few days. On top of that, existing features seem to break every time new functionality is delivered.

Eventually, the project timeline starts to slip, the company team is spending more time QA testing the product, and they are discovering more bugs.

At this point, the company feels stuck. They’ve invested nearly $75,000 of their $100,000 budget and there’s no way they’ll be able to launch the product in its current state. They don’t feel like they can go away from their current partner because that partner knows their product and knows the solution. They end up investing $200,000, double their original budget, for a buggy initial release they don’t love.

The best way to avoid this situation is to know what you expect to get out of this investment. If you’re looking to validate assumptions, find product-market fit, and attract more investment, controlling cost may be the right option. If you’re looking to build scalable, production software rather than evaluating on cost, you should evaluate a partner on:

• previous experience delivering complex software (case studies, client referrals, independent ratings, etc.)
• a thorough and thoughtful project approach
• organizational values alignment

Evaluating a partner on these criteria will help you find partners with a proven track record that act transparently and think long-term when working with clients.

2. You must know exactly what you want before you build it.

Custom software is a significant investment for an organization. Because of that, they might feel a need to spend months planning out the exact functionality for the first several releases of the product. After they’ve agreed on exactly what they want to build they start looking for a partner to build it all.

Before building anything, it is important to align on three things.

1. The problem we’re trying to solve
2. The budget we’re willing to invest in solving that problem
3. The time we’re willing to invest in solving that problem

Having a clear problem to solve is a great guiding force for a custom software product. You can settle debates amongst stakeholders by asking what direction better aligns with the problem we’re trying to solve. You can avoid scope creep by questioning how new functionality helps achieve the goal we’ve set out toward.

Budgeting for custom software solutions is difficult. After all, good software is never done. You’ll carry an operational cost for the software you built, which will be used to maintain security standards and fix bugs. However, you should work to set a reasonable capital investment for version one and subsequent feature work. You can engage with potential partners, like Atomic, to help inform you on what a responsible budget is. Then, a disciplined partner will help you continuously manage the scope to deliver something of value within that budget.

Aligning on a timeline before building can be crucial in certain situations. If you’re developing a new product and you know first-to-market is important, the timeline is invaluable. Time can also be a great constraint for building only the most valuable things before shipping to production.

If you’re looking to partner with a firm like Atomic and you are time-constrained, you should start a conversation immediately. The sooner conversations start, the sooner you can work through legal documents, project proposals, and staffing plans. It’s a process that likely takes weeks.

3. A committee can manage the project.

With large investments, it’s common for organizations to create committees to manage them. The thinking is fairly straightforward; if there are more smart people in the know, the product will be the best version it can be. While this is somewhat true, it’s important to identify one directly responsible individual.

A directly responsible individual owns one project or product. They can and should take input from other stakeholders, but the buck stops with them and they have the ultimate product decision-making authority.

One of the biggest benefits of this approach is the speed of decision-making. Hiring a team to build custom software is expensive. The last thing we want is for a team to sit idle waiting for product decisions to be made. If one person is responsible for decision-making, it speeds the entire process up.

If you’re looking to build custom software and are unsure where to start, don’t hesitate to contact Atomic. We’d be happy to have a conversation!

‍