Top 10 Fears of Custom Software Development

Whether you’re a relative newcomer about to embark upon a new custom software development project or have been battle-hardened by years of experience in the realm, you may be experiencing your share of apprehension in either starting down the path on your own, or hiring a vendor to help you.

This article lists the top 10 fears we’ve heard from experiences and conversations we’ve had with our customers over the last 20 years, and provides some commentary on how to work through them. I hope to boost your confidence with respect to pursuing that project, or shelving it in favour of another path, if that’s ultimately the better decision.

1.?????It's going to be too expensive!

Software solutions are expensive to build. To know whether or not your money is well spent, you should of course evaluate corresponding business value received for that investment. What will the increased efficiency in your organization look like over the next 5 years? Will it open up a new business model or extend an existing one? What about the costs of the legacy systems that will be replaced? Is there reputational risk for remaining with the old system? What is the value of having a solution that fits the problem space exactly? How will it activate your users?

These are good old-fashioned business case questions. A good development partner will help you develop the case for your solution, and support the go / no-go decision based on the prospective value it brings to your business. They also won’t try to externalize or hide the ongoing cost of maintaining the system from you.

Additionally, modern development tools and techniques are making advances all the time. Agile methodologies, convention-over-configuration RAD scaffolding tools, and commercial PaaS and IaaS offerings can make custom solutions cheaper to implement than off-the-shelf products, especially considering you’ll be using 100% of the features you build, rather than paying for a raft of features you’ll never use. And then there are those pesky license fees, which completely vanish in a custom solution scenario.

Focus more on the business case as opposed to the cost. If there’s a good case to be made then go forward!

2.?????It’s going to take too long!

In our always-on, hyper-digitized world replete with millions of free apps, it may not seem that it takes very long to build software, but in reality it does. Contrary to popular conception, most of the effort isn’t really hands-on-keyboard belting out the code with a steady stream of pizza and coke always at the ready. Most of the work is in the communication, research, analysis, design, quality assurance, management, and operational support required to shepherd the code to the finish line.

On the other hand, choosing to buy off-the-shelf still means that you have to account for the time to do the product research, procure the software, customize it, install it, train users on how to fit your process to the product, and integrate it with your legacy systems (which can be painful with boxed products). And then there’s the fact that further customizations and configuration of out-of-the-box functionality will be just as expensive as custom work (if not more so), owing to fact that you’ll still have to communicate vision, goals, and understanding to the COTS vendor for them to get the integration right.

To address the “long wait” quandary, your development partner should be able to sketch out a plan and cost for the product MVP, with reasonably low error bars. If you can come to trust the estimate, then you should be able to easily evaluate the present value of the system relative to the deferred delivery time. And as the proverb says, though the best time to plant a tree was 20 years ago, the next best time is now.

3.?????I don't understand technology, and my technology partner won’t understand my business.

How do you bridge the gap between you and your technology partner? With requirements written at the appropriate level of abstraction, and by selecting an experienced partner who knows what that looks like.

Experience will eventually tell you that on any software project, thousands of requirements never get documented – it’s simply too expensive to try, and needs change too quickly to be overly prescriptive. This is why it is important to communicate both the “what” and the “why” of your product requirements. Knowing “why” increases the probability that your delivery team will make the right decisions to serve your cause, even in the absence of a specific written requirement.

Look for a development team that won’t simply work down a checklist. They should ask questions until they understand why you want to do something. Make sure you see empathy for your cause in their eyes before you begin.

That said, you might be surprised at how quickly you can explain the high-level picture of your business to someone who knows how to ask the right questions and guide the conversation. This initially depends on their ability to engage with you at the vision level. A good Business Analyst or Technical Architect will seek to understand that vision without getting bogged down in the technical details that aren’t relevant at that stage. They’re there to listen to you, first and foremost – all you really have to do is transmit your vision and scan for empathy, understanding, and excitement coming back in return.

4.?????I've never done this before.

You don’t have to be a software development or process expert – you’re an expert in your own business! Your development partner should be able to receive your problem in plain English, write down what they’ve heard in plain English, and tell you how they will address it in plain English. They should also be able to explain what risks there might be, how they will mitigate them, and who will be responsible for them.

Visual artifacts can also be used to convey design intent. It's not your responsibility to understand how the sausage is made, to draw up the blueprints, dig the foundation, assemble the materials and talent, and manage the implementation of your idea. Your partner should make you feel understood and conveyed, and you should be able to get a sense of that, pre-sale. Move on if they don't make you feel comfortable!

5. There will be hidden fees.

Hidden fees are aggravating! Nothing comes for free, of course, but your vendor should deliver you a simple fixed fee quote or hourly rate for each resource on the project. That's it. If the latter, they should additionally give you a cost estimate. Never begin a project without an idea of what the final charges will be, unless the project scope can’t be reasonably defined at the outset.

Be clear with your development partner as to whether the number supplied is a “quote,” in which case they will be responsible for overages, or an “estimate,” in which case you may be responsible. You must both clearly understand the answer to the question “if you get to the end of the budget and the system isn’t complete, who is responsible for the additional costs to finish the project?” Throughout the project, this will depend on negotiation on the cause for each overage, and who is primarily responsible for those. But at the outset, the default responsibility should be clear.

Loose language at the contract stage is definitely a risk factor, and could be a sign that the vendor is not mature, or worse: untrustworthy. Ask about additional charges that may not be covered by the contract, like maintenance contracts, after-hours support, warranty, and stray "photocopying and faxing" riders or other hidden gotchas. Look for contracts that are written very clearly and in plain language, and that specify all fees very clearly. Your partner should also commit to informing you of budget use and variation, weekly. Nobody likes surprises.

6. I don’t want to be locked in to my vendor and I want to own my own customer data and product IP

Typically, on custom software projects, your vendor assigns all of the intellectual property to you. If they retain any of the IP you paid for, there should be a corresponding concession on the cost of the project. Consulting shops typically have less of a need to own software because the software they produce for you isn’t really re-sellable. There may be indeed be some re-usable components in their arsenal that your project can make profitable use of, but which the vendor would retain control over, but again, these would make the project less expensive in return.

Look for signs of a commitment to employ free, open-source software licenses, including database management systems, application servers, open-source components, etc. so that your IP and data are portable should you wish to change vendors. Try to ascertain if there is a willingness to deliver any reports, web services, or custom extractors you might need to allow you to use your data in any way you or your customers might dream up in the future. And of course, never concede to anything but 100% ownership of, and control over, your own customer data.

Off-the-shelf product owners are usually much cagier about letting you access your data because it lives within their proprietary data stores, which are a part of their IP. A custom solution simply gives you access to whatever you need.

7. My brand's reputation and image is at stake.

“It might not scale according to the needs of my growing user base. It might have security holes. It might have lots of bugs. It might perform poorly. It might frustrate my user base. If this happens, my brand’s image will be damaged.” Recognize these feelings?

Yes, your end customer will be less than forgiving about breaches, errors, and mistakes, unless they themselves are already fans and are truly vested in the success of your product. Jeopardizing your hard-won brand is a no-no.

This is where evaluation of your vendor or team is important; not just in terms of their technical prowess, but also with respect to their methodical approach to delivering a system of professional quality. Evaluate their approach to quality, attention to detail, and willingness to provide SLAs to fix the problems that do eventually arise. Ask about their management methodology, and request redacted samples of their work product. If you’re satisfied that you’ve found capable, experienced and passionate collaborators, and that jointly you have the institutional knowledge to embark on your new project, then it should feel like “all systems are a go.” Finally, look for signs that they take your brand’s risk exposure as seriously as you do.

8. My users expect engaging and intuitive UX; enterprise solutions are often unpolished and not easy to use

We know! Enterprise software tends to focus on functionality at the expense of user experience, and can be downright frustrating, painful, and ... just plain ugly. Your vendor should be able to show that they place a high priority on great design. Hardcore doesn't have to mean “hard to use” or “hard on the eyes.” And a custom look and feel is optimized to promote your brand and business intentions, not your vendor’s. Ask for design samples and evaluate what you see.

9. How do I know I can trust my vendor?

If they take the time to explain things to you thoroughly, if they don't pressure you into making premature decisions, if their process is transparent, if they seem calmly confident, and they have references that can attest to their integrity, then you're likely in good shape.

Trust develops over time. Be wary of vendors who are eager to jump into a large new engagement with you. They should be cautious enough themselves not to engage with you either if together you haven’t fully fleshed out how the working relationship looks and feels. This is often accomplished with a small initial project that carries less risk. Build trust over time.

Don’t be afraid go with your gut - if it doesn't feel right, it probably isn't.

10. If things go wrong, I'm going to look bad.

This is a valid fear, and it’s well-founded. But with any worthwhile endeavour, there is risk. Your partner should have an excellent record of delivering on-time and on-target relative to industry. And when things get bumpy (let's not fool ourselves - projects always have issues), your partner should be able to show you how they work quickly and efficiently to get back on track. Look for signs of “head-in-the-sand” management, and a blame-anyone-but-me attitude. See to it that you are in it together. A satisfied client is a good vendor’s real measure of success, so they should stand behind both their reputation and yours.

It should be noted that if you choose the wrong off-the-shelf solution, you're also going to look bad! Beware confusion due to unnecessary feature bloat, off-brand user experience, and in general all problems associated with forcing a square peg into a round hole.

Finally – what if things go right? Don’t underestimate the power of a successful project to transform your business. If you succeed in producing a custom solution that solves the exact problem the company faces, you're going to look like a star!

A well-designed custom solution will have your users wondering how they ever survived without it.

Jeremy Chan is a co-founder of Jonah Group, a software consultancy based in Toronto, Canada, and acquired in 2022 by 3Pillar Global.