How to Build a Product Configurator

CPQ Product Configurators: Build vs. Buy?

This article helps you weigh the pros and cons of each choice when bringing CPQ into your organization.

Table of Contents

    Share this article

    Get A Demo

    So, You Want to Know How to Build a Product Configurator…

    More than half of our customers previously used some kind of in-house product configurator before coming to Epicor CPQ to look at our cloud CPQ solution. Those solutions range from simple pricing tables in spreadsheets, to complex Excel macros, to full-blown multi-year custom development projects.

    As companies assess CPQ vendors and compare them against what they have built for themselves, they are once again weighing the factors of buying versus figuring out how to build a product configurator for themselves – the same quandary that they faced when they made the choice to go with a home-grown solution those months or years ago. The good news is that there are a growing number of cloud SaaS solutions that provide major benefits vs building something custom. Let’s unpack the question and the options out there.

    Top 10 Reasons to Choose Epicor CPQ

    This quick-reading download walks you through the top 10 reasons that customers choose us for their CPQ. From our 2D/3D visualization and robust rules engine technology to our great people, learn about the qualities that make Epicor CPQ used and loved by over 10,000 customers globally.

    How to Build a Product Configurator:
    Weighing the Build vs. Buy Question

    Build vs. buy is one of those fundamental questions in IT when looking at a new software solution. Now, there is no “right” answer to this question, and like with most difficult decisions, you are weighing positives and negatives while trying to predict all possible outcomes that the decision (or indecision) will have on the business.

    1. Building a Product Configurator with Microsoft Excel

    For many years, and for many businesses, Microsoft Office Excel has been a heartbeat application—from accounting to front-end sales, procurement to analytics. It’s a superb application on its own and continues to serve small businesses as their core solution, but it isn’t without its failings.

    Many organizations start with trying to standardize pricing in Excel. Then they are trying to drive quotes with it, or get fancy and try to start building logic and inventories in their spreadsheets to drive product configuration.

    As small businesses grow into medium-sized or enterprise businesses, they find that their needs to collaborate and maintain a single-source-of-truth mean that they have outgrown Excel as an option. Things can become unpredictable when trying to scale beyond a project or team challenge, attacking key business operations employing Excel as the backbone. Let’s look at the pros and cons of choosing this option:

    • Cheap, robust, and ubiquitous application
    • Easy and familiar to most users
    • Able to handle a light to medium duty of complexity
    • Only as good as your best Excel expert
    • Ensuring accuracy of formulas
    • Consistent output by different users
    • Data management
    • Hard to customize or maintain
    • Difficult version control
    • Doesn’t work with complex products
    • Requires too much training
    • Lack of integration to other systems or processes

    Our VP of Research and Development, Luigi Ottoboni has a lot more to say about the choice of Excel as a configurator or CPQ application. Check out his blog post: Can an Excel Spreadsheet Be Made Into Actual Quoting Software?

    2. Custom Coding a Homegrown CPQ Solution

    You are a brave one aren’t you?! This option isn’t for someone who is just confident in their knowledge of their products and how to sell them. They are also signing up for a job in organizational development, requirements gathering, project management, software development lifecycle management, system/end-user/acceptance testing, change management – oh, and the list goes on.

    But hey, we’re following a Pros vs. Cons construct here, and it can’t all be bad, so let’s play it out:

    • Somewhat flexible since you own the code base
    • Ultimate level of control
    • Build to your exact requirements
    • Can be perceived as ‘cheaper’ or can live in a budget gray area (eg. putting idle resources to work)
    • Propensity for hard coding of rules that are hard to maintain
    • Complexity of creating custom software (see the rant above)
    • Can get expensive if/when the project gets out of hand
    • The project is only as good and stable as your best CPQ expert and developer – trial knowledge overload
    • Maintainability and integrations will always be hard
    • Better keep those resources happy, employed, and alive if you want your application to continue to deliver value

    The takeaway here is that if you choose this route, you should probably have an internal workforce that is used to spinning up custom development projects, and better, knows specifically how to build a product configurator. It will take a small army to create something of real value, and if you were serious about doing it right, would take a serious amount of outside guidance and counsel. Honestly, it’s hard to see how this could ever save money over a “buy” option, but if control and flexibility is the utmost concern, this works for some companies.

    3. How to Build a Product Configurator Using a ‘Job Shop’ (Contracted Third-Party)

    Similar to the option above, there are going to be some challenges with owning the development of the software. Your role in this case will be more of a guiding one and less focused on delivery. So you’d still better have a clear vision of what exactly you are building, with budgets, timelines, and resources ready to hold your contracted vendor accountable.

    • Somewhat flexible since you own the code base
    • Ultimate level of control
    • Build to your exact requirements
    • Less risk than developing in-house
    • Propensity for hard coding of rules that are hard to maintain
    • Complexity of creating custom software (this doesn’t change)
    • Can get expensive if/when the project gets out of hand
    • The project is only as good and stable as the chosen vendor and the stability of their teams
    • Maintainability and integrations will still be hard and expensive
    • You are married to this Job Shopt for the useful life of the product

    Much like developing in house, this is probably even more of a wildly expensive way to re-invent the wheel that will drive higher risk than buying and deploying ready-made CPQ software. But, if you have to have custom functionality, a high level of control, and don’t want the risk of owning development it might be your only option.

    4. Buying (or Subscribing to) a CPQ Solution

    Companies that are graduating beyond using Excel and homegrown tools to run their sales functions will find a number of CPQ vendors ready to accept their business. Choosing a CPQ vendor (or any software vendor for that matter) is not an easy task. You have to look past slick pitches and shiny objects to dig in and find if there is a good requirements match, and they have the customer evidence to prove they can deliver and keep a customer happy. The tendency when evaluating is to try to compare apples to apples – and that can be challenging these days with how segmented the CPQ market has become.

    Here we compare the positives and negatives of buying your way out of the problem:

    • Easier and faster to get running than custom development
    • A SaaS solution will deploy and scale easily
    • The problem is already solved for you
    • Get expert guidance and support
    • Minimal training
    • Potentially cheaper than building yourself
    • Easy to maintain and update
    • May not 100% match your requirements
    • It is a vendor to manage
    • Potentially more expensive than building

    Ok, we cheated on this last one, saying it would be both potentially cheaper AND more expensive to build yourself versus buy. You’re probably thinking, “Hey, which is it pal?” Well, if you’ve been in the tech world for any period of time you’d know that it is the promise of cheap custom development that woos you. But often, the price of implementing a platform that can be maintained will save you more money in the long-run.

    Some custom coded solutions will provide short-term value before becoming unmanageable, while many never reach deployment. Building your own may seem like a faster and cheaper method than going with a vendor, but the horror stories we’ve seen tell a scarier tale of crippled businesses trying to swim with an anchor tied around their neck.

    Kris Goldhair

    Kris Goldhair

    Kris enjoys working with customers, helping them to understand the power and scalability of our technology, and getting them to be forward thinking about cloud-based enterprise software.

    Posted in: Configurator