Dispel the myths

Some believe that a custom solution costs more money and takes more time than buying an existing product. Others believe prebuilt products are more affordable with less maintenance and less risk. Reality isn’t as rigid. Let’s break this down, focusing on facts, not fiction.

Time: Custom products take a long time to build.

Using an agile development approach, teams build and ship smaller increments of software more frequently—often demonstrating go-to-market times of three to four months. Releasing an application incrementally allows enterprises to test the investment with customers and pivot along the way, preventing lengthy investments that don’t necessarily drive results.

Funding: Fixed bid contracting is the only way to limit risk.

Traditional funding cycles are destined to fail. When tethered to a failure averse culture and dated waterfall methodology, the build gets too big, moves too slow, and, in reality, is much riskier. Failure on that scale and timeline can be detrimental to an enterprise. A better way to de-risk is micro-funding for dual-track scrum and agile development. The product gets into the hands of users faster, at a fraction of the total investment. Using a build-measure-learn approach, teams iterate swiftly making sure the software enables the user while achieving the desired results for the business. Using an iterative funding approach aligns the investment with the features that directly support the preferred outcomes.

Maintenance: Custom software requires a lot of work.

Maintenance implies a combination of defect resolution and incremental improvements to accommodate changing business needs. With the build-measure-learn loop, custom product releases improve the application incrementally. The delivery frequency mitigates issues that arise vs. waiting on an annual product release drop. Defect resolution is faster when using DevOps best practices to allow engineers to develop, check-in, automatically test and push code out to production.

Implementation: Building custom locks enterprises into a vendor.

By using smart architecture decisions, it is possible to avoid vendor lock-in. Remaining platform and technology agnostic give enterprises greater flexibility to scale or change development resources. Whether buying or building, there is always a risk of coupling too tightly with a vendor—especially if the vendor and their product underperform. Always require full ownership of developed IP.

Reminder: A benefit of building is that the organization owns the code and data, which offers more flexibility to add or change vendors compared to a licensed product.

Time: Purchased products get up and running fast.

Adopting a new product takes time no matter what. But how much time? For some products, it’s quick with a direct implementation. However, there are factors that add time, such as integrating a complex product into an existing ecosystem, building elaborate customizations, and reworking processes to adapt to software limitations. Not to mention, onboarding users.

Expiration date: The average support lifecycle for an application is ten years. It’s possible—even likely—that the purchased product suite’s code is outdated and lacks modern software development best practices.

Funding: Buying a product is a small investment and cost-effective.

Enterprises sometimes overpay significantly for functionality that extends outside the organization’s needs. Pricing is based on using the full product. In reality, many enterprises don’t use all the functionality. The initial investment at first blush appears to be less than a custom build. In reality, there are hidden costs of ownership. Scaling, user headcount, long-term maintenance needs, increasing rates, upgrade requirements, and variable contract terms add up over time.

Maintenance: A pre-built product requires less work.

While security patches and updates are delivered, they’re not always guaranteed to work with customizations and integrations. Ongoing maintenance takes time, adds to the long-term cost, and could result in unforeseen complications. Support contracts often considered low risk for the provider are anything but that.

Implementation: Off-the-shelf products are easy to implement.

Integrating and implementing into the existing ecosystem requires an experienced team. Extending the products to meet the desires of the business is often more complicated than building applications from scratch. Working within the product network also requires a specialized skill set (e.g., Salesforce using a unique pseudo-language for customization).