Build, buy, or partner?

Every meaningful piece of technology starts with the same fork: do we build it ourselves, buy something off the shelf, or bring in a partner? Choose well and everything downstream gets easier. Choose by default and you'll feel it for years.

Most teams don't actually decide this — they drift into it. A confident engineering lead means everything gets built. A tight budget means everything gets bought. A moment of overwhelm means everything gets outsourced. Each can be right, and each can be quietly expensive in the wrong context. Here's a cleaner way to think about it.

When to buy

Buy when the capability is essential to run but not the thing that makes you different. Email, payments, payroll, analytics plumbing — these are solved problems where someone else's product will be better, cheaper and safer than anything you'd build. The test: if a competitor used the exact same tool, would it matter? If not, buy it and move on. Spending your scarce engineering attention here is a quiet form of waste.

Build what makes you different. Buy what merely makes you run.

When to build

Build when the capability is the difference — the part of the product your customers actually feel, the thing you want to own and improve forever. Building gives you control and compounding advantage, but it costs the most over time: you own it, you maintain it, you hire for it. Build deliberately, for the few things worth owning — not reflexively, for everything.

When to partner

Partner when the work is important and ambiguous, but not something you want to staff up for permanently. A new product line. A move into a new market. A capability you need built well and handed over — without carrying a full team through the quiet periods afterwards. A good partner gives you senior judgment and momentum now, and leaves you owning the result, rather than locking you into a dependency.

The failure mode to avoid: partnering with someone who builds at you, throws it over the wall, and disappears. Done right, partnering should feel less like outsourcing and more like temporarily borrowing a team that has done this before.

A simple test

When you're stuck, three questions usually settle it:

• Is this a core differentiator, or just table stakes? Differentiator leans build; table stakes leans buy.
• Do we want to own and improve it forever? Yes leans build; no leans buy or partner.
• Is it important, ambiguous, and time-bound? That's the sweet spot for a partner.

Most real products are a blend: buy the plumbing, build the few things that make you you, and partner for the ambitious middle where you need senior hands without a permanent hire. That ambitious middle — idea to working product to market — is precisely where Indot lives. If you're staring at the fork, that's a good first conversation to have.