Start with the job, not the feature list
The right choice depends on the job to be done and the constraints you care about: time to value, total cost, risk, and differentiation. Write those down first. Name the users and the one or two workflows that create real value for them. Agree on what “good” looks like in concrete terms: faster cycle time, fewer errors, or better visibility.
When to buy
Buy when the workflow is common, integrations are standard, and your team has higher‑leverage work elsewhere. Mature tools cover 80% out of the box. Your job is configuration, not invention. Favor vendors with open APIs and clear permission models so you can stitch them into your stack without surprises.
When to build
Build when the workflow is unique to your business, the data model does not fit off‑the‑shelf, or speed and UX are themselves the advantage. A small, focused app beats a heavy system everyone works around. Keep scope narrow: solve the core job beautifully, then layer on the next most valuable path.
Hybrid is often best
Use a platform for identity, audit, and CRUD scaffolding. Build custom modules for the high‑leverage paths. Keep your data in your own warehouse so switching costs stay low. This gives you speed now and flexibility later.
Evaluate with a time‑boxed spike
Give each option two weeks. Can you get the core path end‑to‑end, with data flowing and basic permissions? Measure build time, fit gaps, and ongoing ops cost. Decide with evidence, not decks. Bring a real user to watch a demo of each spike—what confuses them will guide the choice.
Budget the real costs
License fees are the easy part. Count onboarding, customization, vendor lock‑in, and change requests for buy. Count maintenance, on‑call, and roadmap drag for build. Put numbers against both. A simple three‑year model helps you see beyond the first quarter.
Bottom line
Pick the path that gets a reliable core workflow in users’ hands soonest, with acceptable risk and room to grow. Whichever way you go, keep data portable and keep the surface area small at the start.
Implementation checklist
- Write the job to be done and constraints
- Identify the 1–2 core workflows to cover
- Run a two‑week spike for buy and build
- Compare fit gaps, ops burden, and total cost
- Keep data portable and modularize custom parts
- Include a user demo in each spike evaluation
Common pitfalls to avoid
- Long RFPs with abstract requirements
- Over‑customizing a bought tool into fragility
- Building a platform instead of an app
- Ignoring switching costs until it is too late
- Deciding from slides instead of working spikes
