Build vs fold into existing
Two projects, five days apart, where the right move was to fold new work into an existing system instead of building alongside it.
Twice this month, five days apart, I caught myself building parallel infrastructure when the right move was to fold the new work into something that already existed.
Project one: two separate web forms for a client's intake workflows. Two domains, two repos, two deploy pipelines, two sets of templates that were about 80 percent identical. Every change had to be made twice. We merged them into one codebase with route-based variants, one engine with two front doors. The cleanup took half a day.
Project two: a CLI tool to give a non-technical team access to some admin functions. I spent a week reverse-engineering endpoints before a call with the engineering lead, who showed me their internal config tool. It already did what mine was reaching for, through templates and YAML files. The right move was to fold my features into theirs and teach the team the existing system.
My instinct is to build something new: new tool, new app, new workflow. The bigger payoff usually comes from looking at what is already in the stack and adding the new surface there. One codebase, one source of truth, one thing to maintain.
Most build-versus-buy decisions are build-versus-fold-into-existing. The hard part is noticing, because you are usually deep in the new build before the existing option comes up.
Adapted from a LinkedIn post that ran on 2026-04-30.