The First Product Decision Is What Not to Build

A feature request is not a reason to create a codebase. It is a prompt for a decision, and the decision should happen before any ticket is written.

My rule is the one we publish on the Nebula site: every engagement starts with a build-versus-buy audit. If a $50-per-month tool solves the problem, use it. Reserve engineering time for what differentiates the product. I want to explain how I run that audit, because the interesting part is not the buy side. It is understanding what you commit to when you choose to build.

The audit comes before the backlog

A backlog is a list of things to make. The audit is the step that decides whether making belongs to you at all. It runs on a feature request, before scoping, and it has three questions in this order.

First, does an adequate purchasable tool solve this problem? Not an imagined ideal version of the tool, the one that exists and can be bought now. If the answer is yes, the audit stops there. Buy it.

Second, does this capability differentiate the product? Differentiation is the test, not preference. If the capability is a commodity, something any competitor can acquire the same way, custom engineering on it is effort spent where the product gains nothing.

Third, are we prepared to own this capability after launch? This is the question that changes the answer most, and it is the one I will spend the rest of this piece on.

A hybrid answer is allowed. The differentiated core can be custom while the surrounding commodity capabilities stay purchased. The audit applies capability by capability, not product by product.

Differentiation decides, in both directions

Three products from our public portfolio show how wide the range of answers is.

Connectere is a full-stack real estate CRM that automates the settlement lifecycle, agent workflows, and client management. Starmoire's disclosed product-leadership scope included technical architecture and build-versus-buy strategy, spanning the product lifecycle from concept to production. These are different product contexts, and the audit produces different results for each capability inside them.

Workforce is the example on the other end. It is a custom product written in Rust whose agents coordinate across codebases and tickets, work through GitHub and Linear, and perform software-delivery tasks such as creating and reviewing pull requests. The orchestration layer is the differentiated product core. That is where custom engineering earns its place, because the capability itself is the product.

The pattern I want the reader to take is not about any one of these products. It is the test: custom code belongs where the product's differentiation lives, and purchased tools belong where it does not.

Building means owning the lifecycle

Choosing custom code means choosing to own that capability after launch. The code is not finished when it ships. It has to be maintained, secured, and corrected for as long as the product depends on it.

This is not rhetorical. The NIST Secure Software Development Framework (SP 800-218) recommends integrating secure software-development practices into each software-development lifecycle implementation, to reduce released vulnerabilities, mitigate exploitation, and address root causes to prevent recurrence. That is a continuing practice, not a launch-week task. When I decide to build, I am accepting that practice as part of the product's cost.

This is the real weight of the third audit question. A feature that clears the differentiation test but fails the ownership test is still a buy. Differentiation tells you where custom code can pay off. Ownership tells you what holding it actually involves.

Run the audit, then scope

The sequence I use, stated plainly:

1. Take the feature request as a decision prompt, not a work order.

2. Check whether an adequate purchasable tool exists. If yes, buy it.

3. If not, test whether the capability differentiates the product. If no, find the closest purchasable answer.

4. If it differentiates, test whether you are prepared to own the lifecycle, including secure development after launch. If yes, build it, and scope only then.

Custom engineering is a commitment to own a capability, so I spend it where the product is actually different. Everything else is a purchase.