Build or Buy: Ownership, Not Cost

From the field: a two-sprint reconciliation

Reconciliation is a boring but vital job that a brokerage does every morning. Customer cash and positions in our records are compared, line by line, with the statements sent by the banks and the custodian (the institution that holds the securities). Every line that does not match lands on the operations team’s desk.

There was a SaaS product that did this job, and the offer was $1,800 a month. That is $64,800 over three years. My maths in the meeting was: two engineers, two sprints, four weeks. At a full cost of $6,000 per engineer per month, that is $12,000. “A fifth of the price, and it will be ours.” Nobody objected.

The first version took seven weeks, not four. Everybody knows that part; estimates always slip. The real surprise came later. In the nine months since January:

• Three banks changed their statement format 7 times in total. Each time, the morning report broke.
• A new bank was added. The integration took 2 weeks.
• On two mornings the report did not run at all. The operations team reconciled by hand, and both times it took more than 3 hours.
• Every one of these jobs went to the same person: Burak, the engineer who built it and the most senior engineer on the order management team.

We looked at Burak’s calendar. The nine-month average: about a third of his week went to reconciliation. Two items on the order management roadmap had slipped by a quarter because of this, and nobody had connected the delay to it.

My mistake: I asked build or buy as a price comparison. But the question was not “which is cheaper”. It was “who will own this thing for three years”. My answer had been “us”. “Us” is not a name.

Doing the maths properly: three years, both sides

When I redid the calculation I had two rules. The period is three years, because a one-year view does not see maintenance. And both sides use the same items. A system you buy also needs maintenance; it just looks different.

# assumption: full cost per engineer 6,000 $/month, period 36 months

FIRST ESTIMATE (November)
  build: 2 people x 1 month                      =  12,000 $
         maintenance                             =       0 $   <-- the mistake
  buy  : licence 1,800 $ x 36                    =  64,800 $
  result: "a fifth of the price"

REALITY (October, with 9 months of data)
  build: first version 2 people x 7 weeks (3.5 person-months) =  21,000 $
         maintenance 0.3 person x 36 months      =  64,800 $
         total                                   =  85,800 $

  buy  : licence 1,800 $ x 36                    =  64,800 $
         integration 2 people x 3 weeks (1.5 person-months) =   9,000 $
         vendor follow-up 0.1 person x 36 months =  21,600 $
         exit reserve (1 person-month)           =   6,000 $
         total                                   = 101,400 $

  gap: ~15,600 $ over 3 years (in favour of build)
  error in first estimate: 12,000 -> 85,800 = ~7x

Two things stand out. First, when you build, the biggest item is not the first version. It is maintenance: $64,800 against $21,000. That line did not exist in the first estimate, which is why we were off by seven times.

The second point matters more. Even with correct numbers, the gap between the two options is about $15,000 over three years. Our estimates have a bigger margin of error than that. So money does not make this decision. The money only tells you that both options weigh the same, and the answer has to come from somewhere else.

Do not skip the “vendor follow-up” line on the buy side. Someone will read the vendor’s release notes, adapt to API changes and open support tickets during incidents. That line is not zero. For us it is 0.1 of a person.

The five questions that decide

When the money ends in a draw, these are the questions left on the table. We now start the meeting with this table, not with the price:

Reconciliation fell on the “buy” side in all five rows. The strongest signal was the third row: if change comes from outside, someone already exists who splits that work across hundreds of customers. We were paying for every bank format change alone. The vendor makes the same change once and ships it to all its customers.

The reverse is also true. Our order routing rules, our commission rates, the risk warnings we show customers — these are core. Change comes from us, and the owner is clear. Buying them would mean accepting that we sell the same product as our competitors.

How it breaks: when you build

The classic failure of building is the one we lived through. The system does not stay unfinished. It stays without an owner. Nobody calls it a product, so it has no roadmap, no budget and no on-call. But it has to run every morning. The gap gets filled by the person who knows the system best, by taking time from their own team’s work.

The second failure is the hidden assumption in “it will be ours”: we can add whatever we want, whenever we want. True, we can. But in nine months we did not add one new feature to reconciliation. All the time went to keeping up with changes from outside. Flexibility is only worth something if you have time to use it.

The third failure is the quiet one: on-call. Reconciliation runs at 06:30, and the report has to be on the operations desk by 08:00. On both mornings when the report did not run, the first call went to Burak, because nobody else knew the system. Once he was on holiday, and the operations team called him there. His name was on no on-call list, but in practice he was the system’s only on-call engineer. Every system you build will one day make someone’s phone ring. If you have not written down whose phone that is, the person who knows best will answer — every time.

How it breaks: when you buy

Buying has its own failure, and we lived through that too. Two years ago we bought a platform for customer notifications (email and SMS templates). The price was good and the integration took a week. The only person who read the contract was from procurement. Nobody in engineering asked “how would we leave?”

At the second-year renewal the price went up 40%. We thought about leaving, and only then did we see it: our 140 templates lived only in the vendor’s web panel, and there was no export API. The exit estimate was 6 weeks. We paid the increase. We had negotiating power before signing. After signing, we had none.

Sunk cost: throwing away what you built

Once the table was on the screen, the decision was clear: we buy reconciliation. The hardest part of the meeting was not a number. It was a feeling. “We spent seven weeks on it, it works. Are we going to throw it away?”

You have to separate two things here. The $21,000 already spent will not come back. It is spent whichever path we choose. The decision is about the next three years. Looking forward, keeping our own system is still cheaper in money: maintenance is $64,800, buying is $101,400. So by buying, we pay about $36,000 more over three years. We chose that knowingly, because we pay for our own system with Burak’s time, which means with the order management roadmap. That team’s work is core. Reconciliation is not. Tying the most senior engineer of core work to non-core work was the most expensive item, and it did not appear as a line in the table.

The migration is in January. This time the contract includes the export format, a three-year cap on the price and 90 days of data access after leaving. We tested the export with our own data before signing.

What to track

The decision is not made once and forgotten. If you were wrong in either direction, you will only see it by measuring:

What did not work for me

• A scored decision matrix. Twelve criteria, weights, a total score. Everyone set the weights to get the result they wanted. Five plain questions turned out more honest than twelve scored criteria.
• “Let us buy it now and build it later.” A system bought as temporary does not stay temporary. Only the exit cost grows a little every month. If you buy, buy as if it is permanent.
• Leaving the decision to procurement. Procurement reads prices and contracts well. It cannot read the integration surface, whether the export really works, or who will do the maintenance. That part is engineering’s job.

Checklist

Conclusion

Last November, when I said “a fifth of the price”, the number was not the problem. The question was. If I had asked the right question, the answer would have come in the same meeting: it is not core, change comes from outside, and we cannot name the owner.

Build or buy looks like a purchasing decision, but it is really an ownership decision. If you build, you are the owner: with the maintenance, the on-call, and the format change three years from now. If you buy, the vendor is the owner, but the key to the exit door has to stay in your pocket.

The test: can you write down, today, the name of this system’s owner three years from now? If you cannot, you are not choosing what to build. You are choosing whom to burn out.