Lesson 4.2: Build, configure or buy for a customer
Each part of a customer solution can be built, configured or bought. Learn six criteria, a scoring table and a three-year cost model to choose well.
By the end of this lesson you will be able to break a customer's solution into parts and decide, for each part, whether to build it yourself, configure something that already exists or buy a ready-made product. You will learn six criteria that decide the choice, a weighted scoring table you can fill in with the customer, a plain way to compare costs over three years and a rule for what a forward deployed engineer should almost never build. You will see three decisions made with numbers and use a simulator to find the point at which building becomes cheaper than buying. This lesson follows 4.1, where you learned to build a rough version quickly and then make it safe. Here you decide what is worth building at all. You do not need to be a programmer, though some of the examples mention code.
Engineers like to build. It is what most of us are trained for and often what we enjoy most. In customer work, that preference is a hazard. Every line of code you write for a customer is a line somebody must keep running after you leave, and much of what a solution needs, such as sending messages, drawing charts, storing documents or checking identity, already exists in tools that other people maintain. The skill is not to build the most. It is to build the least that gets the customer their result, and to be able to explain why.
Three ways to get a capability
For any part of a solution, there are three broad routes. Real projects mix them, often within a single week.
Build. You write the software yourself, in code, to do exactly what is needed. You have full control and a perfect fit. You also own everything: the bugs, the upgrades, the security fixes and the questions of the person who inherits it.
Configure. You use an existing platform or tool and set it up for the customer: rules in a workflow tool, dashboards in a reporting product, forms in a data-collection system, formulas in a spreadsheet. You write little or no code. The fit is close but not perfect, and you work within what the tool allows.
Buy. You adopt a ready-made product or service for the whole capability, such as a messaging provider, an identity service or a payments gateway. You pay a fee, connect it to the rest and rely on the supplier to run and improve it. The fit depends on how well the product's idea of the job matches the customer's.
A fourth option often appears as a corollary: use what the customer already has. Large organisations own many tools, some of them licensed and barely used. A feature that exists inside a system the customer already pays for may cost nothing extra and will already have been through their security review.
Six criteria
Choosing among the routes comes down to a handful of questions. Ask them about each part separately, because the best answer for the messaging component may differ from the best answer for the decision rules.
1. Fit. How closely does each option do what the customer needs? A product that does 90 per cent of the job may be better than a custom build that does 100 per cent, but one that does 60 per cent will frustrate everyone.
2. Speed. How quickly can each option be working for real users? For a pilot, speed often matters more than anything. A tool that can be set up in days beats a build that needs weeks.
3. Cost over time. Not only the price on day one, but the total cost over three years or more, including running, fixing and changing it. Cost of ownership is the section where building most often loses without anyone noticing.
4. Risk. What could go wrong with each option? Building has delivery and quality risk. Buying has supplier risk: the product changes, the price rises or the company disappears. Configuring has risk in the limits of the tool.
5. Control and lock-in. How much freedom do you have to change things later, and how hard is it to move away? A custom build is fully yours. A product that holds your data in a format you cannot export is a trap.
6. Fit with the customer's world. Does it meet their security and compliance rules, run where they need it to run and use skills their team has? A product the customer's security team will not approve is not an option, however good it is. A build that needs a language nobody on their side knows is a burden.
A seventh question belongs to this role in particular: who will keep it running? When your engagement ends, someone at the customer, or on your company's product team, must own it. If the answer is "nobody", that route is too risky, whatever its other merits.
What should an FDE rarely build?
A useful rule of thumb separates the parts of a solution into two kinds. The first kind is what makes this customer's solution different: their rules, their data, their way of grouping accounts, the logic that expresses what they know about their business. The second kind is what everyone needs and nobody does better than anyone else: sending an email, storing a file, logging in, drawing a chart, scheduling a job.
Build, or at least carefully configure, the first kind. Buy, or reuse, the second. The reasoning is simple. The differentiating part is where your effort turns into value that no product can offer. The common part is where your effort turns into a maintenance burden with no advantage, because a specialist supplier has already done it better and spreads the cost across thousands of customers.
If you notice yourself designing your own message queue, login system or charting library for a customer, stop and ask whether a standard tool would do. Occasionally the answer is no, because of a security rule or a special need. More often it is yes, and the project gets there faster.
Predict first: a lender's reminder pilot needs to send text messages to borrowers. The engineer is deciding between writing a small sender that talks directly to the telecom network and using an existing messaging provider's interface. Which would you choose, and what are the one or two things you would still build yourself? Decide before reading on.
Use the provider. Sending messages reliably at scale involves delivery reports, retries, regulatory registration of senders and templates, spam rules and relationships with carriers, all of which a messaging provider handles as its business. Writing your own would take weeks and be worse. What you would still build is the part that is specific to this customer: the logic that decides who receives which message and when, the templates in the borrower's language and the checks that stop a message going outside permitted hours. That is where the lender's knowledge lives, and no product can supply it.
A scoring table
When the choice is not obvious, a weighted table helps, mainly because it makes the discussion explicit. Write the options as columns and the six criteria as rows. Give each criterion a weight from 1 to 5 for how much it matters in this case, and score each option from 1 to 5 on each criterion. Multiply and add.
Here is an illustrative table for a reporting dashboard in the hospital group example.
Criterion · Weight · Build a custom web page · Configure the group's existing reporting tool · Buy a bed-management productFit · 4 · 5 · 3 · 4
Speed · 5 · 2 · 5 · 2
Cost over three years · 4 · 2 · 4 · 2
Risk · 3 · 3 · 4 · 3
Control and lock-in · 2 · 5 · 3 · 2
Fit with the customer's world · 4 · 3 · 5 · 3
Weighted total · · 69 · 91 · 59
The totals come from multiplying each score by its weight and adding. For the custom build, that is 4×5 + 5×2 + 4×2 + 3×3 + 2×5 + 4×3 = 20 + 10 + 8 + 9 + 10 + 12 = 69. For configuring the existing tool it is 4×3 + 5×5 + 4×4 + 3×4 + 2×3 + 4×5 = 12 + 25 + 16 + 12 + 6 + 20 = 91. For the bought product it is 4×4 + 5×2 + 4×2 + 3×3 + 2×2 + 4×3 = 16 + 10 + 8 + 9 + 4 + 12 = 59. Configuring the existing tool wins clearly, mainly because it is fast, cheap and already approved.
The score is not the point. The point is that filling the table with the customer forces everyone to say what matters. A sponsor who wanted a custom build because it sounded impressive may discover that speed and approval count for more. And the table gives you something to point to when the choice is questioned later.
The weights are the discussion. Change them and the winner can change. The simulator below holds the scores from the table fixed, so you can set what matters to your own customer and see how the totals move.
At the defaults the totals are 69 for the build, 91 for configuring the existing tool and 59 for buying, the figures in the table. Set the weight on control to 5 and on speed and cost to 1, which describes a customer who cares only about owning the result, and the custom build moves ahead.
Cost over three years
Costs are where choices are most often misjudged, because the visible price is usually only part of the total. A fair comparison counts everything over a period such as three years.
For building, count the effort to build (people's time, which is a real cost even when it is not billed), plus the running cost: servers, monitoring, and above all maintenance. Software needs continuing work, to fix bugs, update components that become unsafe, adapt to changes in other systems and answer questions. A common rule of thumb is that yearly maintenance costs a meaningful fraction of the original build, perhaps a fifth or more, and it never goes to zero while the system is in use.
For buying, count the licence or usage fees over the period, the effort to connect it to the customer's systems and the effort to keep that connection working when either side changes. Fees can rise, and usage-based charges can grow as volume grows.
For configuring, count the setup effort, the licence for the tool and the ongoing effort of someone who understands the configuration. Configurations also need maintenance, even though there is less code.
Beyond direct costs, include three that people forget. The cost of delay: every week before a solution works costs the customer the problem's price, as the simulator in Lesson 1.1 showed. The cost of the person who must maintain it: if only one engineer understands a custom build, their absence is a risk. The cost of switching: how expensive it would be to move to something else later.
Where building starts to win
Buying and configuring usually win for the first years, because their upfront cost is low, and building can win later, if the system is stable and the licence fees are high. The question is when. The simulator below compares building with buying over time. Set the cost to build, the yearly maintenance as a percentage of that cost, the one-off cost to connect a bought product and its yearly licence. It shows the total cost of each over the period you choose and the year in which building would become the cheaper of the two, if ever.
The numbers are illustrative assumptions, not a quote. Real costs include many things the model leaves out, such as the cost of delay, the cost of switching and the benefit of a closer fit. The model is useful for the shape of the comparison: building costs a lot early and a little each year, while buying costs little early and a lot over the long run, so the crossing point depends on how long the system will live.
Try three experiments. First, keep the defaults and read the total costs at three years. Second, raise the licence from 12 to 25 lakh a year and see the crossing point move toward the near term. Third, raise maintenance to 40 per cent of the build cost and see building lose its long-run advantage. Notice that if the system will live for only a year or two, as many pilots do, building almost never wins.
At the defaults, building 40 lakh with 20 per cent yearly maintenance costs 64 lakh over three years, while buying with a 10 lakh connection and 12 lakh a year costs 46 lakh. Buying is cheaper by 18 lakh. The lines cross after about 7.5 years, which is longer than most customers expect a system to stay unchanged. This is the common pattern. For a pilot or a first version, almost any reasonable estimate favours buying or configuring.
Worked example 1: the reminder messages
For the lender's pilot, the engineer splits the solution into four parts and decides each separately.
Sending messages: buy. A messaging provider already handles delivery, retries and sender registration. The customer's compliance team has approved two providers, so the engineer picks one of them. The one-off connection takes three days.
Deciding who gets what, and when: build. This is the lender's own logic: the grouping, the language rule and the contact-hour limits. It is small, about two weeks of work, and it is where the customer's knowledge sits.
The review screen for callers: configure. The lender already uses a reporting tool, and a simple dashboard in it takes two days. A custom screen would take two weeks.
Storing the results: reuse. The lender's cloud account already has a database with backups. The engineer adds a table.
The result: the part that needed building was two weeks, and the rest took under a week. If the engineer had built everything, the pilot would have taken more than two months. The choice was not a matter of laziness. It was a matter of spending effort only where it produced value that nothing could supply.
Worked example 2: the bed screen
For the hospital group, the table above shows configuring the group's existing reporting tool as the winning choice. The engineer builds nothing for the screen itself. Work goes into the data: a small pipeline loads the bed status from each hospital and applies the agreed definition of a free bed from Lesson 1.1, and the reporting tool displays it.
Two things follow. The nurse managers can adjust the screen's layout themselves, with a day of training, which would not have been possible with custom code. And the hospital group's IT team already knows the reporting tool, so there is someone to maintain it. The engineer's effort went into the definition and the data quality, the parts that no tool could supply, and the screen cost almost nothing.
The trade-off was control. The reporting tool could not show a particular alert in the exact form the chief operating officer first imagined. The engineer explained the limit, showed a close alternative and the COO accepted it. In a pilot, a close alternative in a week often beats the perfect version in two months.
Worked example 3: when building was right
A logistics company needs a check on delivery promises that applies its own rules about which routes, vehicle types and customers combine in which ways. The rules are numerous, specific and change every few weeks. The engineer looks at three rules engines and workflow tools. Each can express some of the rules, but not the combinations, and each would need a specialist to change it.
The scoring table puts building ahead on fit and control, because the rules are the company's competitive knowledge. The speed penalty is small, since the logic is a few hundred lines. The engineer builds it, in a clean, well-tested module with the rules written as data in a single file that the operations manager can read and edit, with a review step.
This is the "build" case in its proper place: small, central to the customer's advantage and unavailable elsewhere. It is also built with the next person in mind: documented, tested and simple, so that the company's team can keep it going.
Making the decision with the customer
The choice should not be made alone. Customers hold knowledge you lack: which tools they already own, which suppliers they are allowed to use, which licences they have and which skills their team can maintain. A short conversation often changes the answer.
Ask what they already have. "Which tools do you already license that could do this?" can save weeks.
Ask what they are allowed to use. Many organisations keep an approved list of suppliers. Buying from outside it can take months.
Ask who will maintain it. The answer shapes the choice. A tool the customer's analysts can adjust is worth more than a cleverer one only you can change.
Show the table. Walk through the scoring and cost with the sponsor and the system owner, and let them change the weights.
Write down the decision and why. A short note in the project file, "we chose to configure the reporting tool because...", will be valuable when someone asks in a year why it was done that way.
Common mistakes
Building because you can. Spend effort only where it creates value that nothing else can supply.
Counting only the build price. Include maintenance, running costs, the cost of delay and who will keep it going.
Ignoring what the customer already owns. Ask first. A licensed tool that is already approved can be the fastest route.
Buying without checking the exit. Ask how you would get the data out and what happens if the supplier changes.
Choosing a tool nobody can maintain. If the customer's team cannot run it, you have built a dependency.
Over-configuring. A tool stretched far beyond its design becomes as hard to maintain as custom code.
Perfect fit as the goal. A close fit in a week often beats an exact fit in two months, especially in a pilot.
Deciding alone. Include the people who know the licences, the suppliers and the skills.
Key takeaways
Every part of a solution can be built, configured from an existing tool, bought or reused from what the customer already owns. Decide part by part.
Six criteria decide: fit, speed, cost over time, risk, control and lock-in, and fit with the customer's world. A seventh matters in this role: who will keep it running.
Build what makes this customer's solution different, and buy or reuse what everyone needs. Sending messages, logging in and drawing charts are rarely worth building.
A weighted scoring table makes the discussion explicit, and a three-year cost comparison shows what the build price hides.
Building usually costs more early and less later, so for pilots and short-lived systems buying or configuring almost always wins.
Decide with the customer, who knows their licences, approved suppliers and skills, and write down the decision and the reasons.
Check yourself
1. Name the three routes, and a fourth option that often applies.
Build, configure and buy. The fourth is to reuse what the customer already has.
2. A pilot needs to send text messages. What would you build, and what would you buy?
Buy the sending from a messaging provider. Build the logic that decides who receives which message and when, because that is specific to the customer.
3. Why is the build price a poor guide to the cost of building?
Maintenance, running costs and the effort of whoever keeps it going continue for as long as the system is used, and often add up to more than the original build.
4. Building costs 30 lakh with 20 per cent yearly maintenance. Buying costs 8 lakh to connect and 10 lakh a year. Which is cheaper over 3 years, and by how much?
Building: 30 + 6 × 3 = 48 lakh. Buying: 8 + 30 = 38 lakh. Buying is cheaper by 10 lakh.
5. What is the question that matters in this role and often not elsewhere?
Who will keep it running after the engagement ends.
Try this
This exercise takes about forty minutes and gives you a build, configure or buy decision. Use the pilot you scoped in Lesson 2.3, or any project you know.
1. List the parts of the solution, such as getting data, applying rules, sending messages, showing results and storing records. Aim for at least four.
2. Mark each part as "specific to this customer" or "what everyone needs".
3. For each part, name one option for build, one for configure or reuse, and one for buy. Where you do not know of one, write who you would ask.
4. For the most important part, fill in the scoring table with weights and scores, and work out the totals. Check your sums.
5. Use the simulator with your own estimates to compare building and buying over the number of years the system will probably live.
6. Write who would maintain each part after you leave.
7. Write the decision in three lines: what you chose for each part, why and what would change your mind.
A good result is a one-page table of parts with a choice and a reason for each, a worked scoring table for the key part and a cost comparison. It is the architecture section of your plan, and you will refer to it when someone asks why you did not build more.
Sources
The three decisions, the scoring table, the cost figures and the simulator's defaults are the author's illustrations for teaching, not data from real companies, suppliers or quotes. The six criteria and the rule of thumb about what to build are practical guidance written for this lesson. The yearly maintenance share is a common rule of thumb and varies widely.
Tags: Forward Deployed Engineer Build vs buy Architecture Cost of ownership Beginner