All posts
3 min readAI StrategyEngineeringDecision Making

Build vs fold into existing

Most build-vs-buy decisions are actually build-vs-fold-into-existing. Two projects, five days apart, taught me the same lesson.

I do AI automation consulting for SMBs. This month I caught myself making the same mistake on two unrelated projects, five days apart.

Project one. I had been building two separate web forms for a client's intake workflows. Two domains, two repos, two deploy pipelines, two sets of templates that were practically 80 percent the same. Every functional change had to be made twice. We sat down and decided to merge them into one codebase with route-based variants. One engine, two front doors. The cleanup took half a day.

Project two. I had been building a CLI tool to give a non-technical team access to some admin functions. Spent a week reverse-engineering endpoints until I realized I was looking for answers in the wrong places. Hopped on a call with the engineering lead and he showed me their internal config tool. It already did what mine was reaching for, through templates and YAML files. The right move was not to keep building. It was to fold my features into theirs and become the team's teacher on the existing system.

Same lesson, both times. I had been building parallel infrastructure when the right move was to share the engine or just reach out and collab.

My natural instinct is always to try and build something new. New tool, new app, new workflow. But the bigger payoff usually comes from looking at what is already in the stack and folding the new surface into that. One codebase. One source of truth. One thing to maintain.

Most build-vs-buy decisions are actually build-vs-fold-into-existing. The hardest pattern to spot is when you are so deep into the wrong abstraction you forgot to look up.

Adapted from a LinkedIn post that ran on 2026-04-30.