What Product Engineering Means to Us

"Product engineering" is one of those phrases that can mean everything and therefore nothing. So let me be precise about what it means to us, because it is the belief the entire company runs on. Development asks whether a feature works. Product engineering asks whether it will still be a good decision in a year — under load, under change, and under a team that has grown. Those are different questions, and answering the second one well is the whole job.

The data model is the product

The most expensive decisions on any build are made before a single screen is styled. They live in the shape of the data — what an entity is, what it owns, how it relates to everything else, and which of those relationships can never be undone cheaply. Get the model right and features fall out of it naturally. Get it wrong and every feature becomes a fight against the foundation.

So we design the model first, on paper, where a mistake costs an eraser instead of a sprint. Only once the entities, the boundaries, and the read/write rules are clear do we build the interface against them. The screen is the last mile, not the map.

Make the wrong thing hard to build

Good engineering is not about being careful enough to avoid mistakes. Careful does not scale, and it fails exactly when people are tired and rushed. The better move is to arrange the system so the wrong thing is genuinely hard to express — so a mistake fails loudly and early rather than quietly and in production.

// One type, defined once, describes the row, the API payload, and the props.
// Rename a field in the schema and every stale call site fails to compile —
// the mistake surfaces in the editor, not in production.
import type { Article } from "@iwc/types";

type CardView = Pick<Article, "slug" | "title" | "excerpt">;

Types are the cheapest version of this idea, but the principle is broader than types. A clear service boundary makes it hard to reach into a database from a component. A single source of truth for design tokens makes it hard to hard-code a colour. Every one of these is the same move: encode the right way to do something into the structure, so the wrong way requires effort.

Optimise for the second year

Almost every bad decision in software looks good in the first week. It saves time now and pays for it later, when the person who made the trade is no longer around to feel it. Product engineering is largely the discipline of refusing those trades — of weighing a decision against the second year of the product's life, not the first sprint.

Why we prove it on our own products

It is easy to write philosophy. The test is living with it. That is why we build our own products — Pulse, the Pulse CLI, and Business OS — and hold them to exactly the standard we hold client work to. When you have to maintain your own decisions for years, you learn very quickly which ones were principled and which ones were just fashionable.

If you want to see the practical side of this philosophy, read How We Structure Modern Full-Stack Applications — it is these beliefs turned into an actual project layout.