Integrations are the product

Ask most small businesses what software problem is costing them the most, and the answer is rarely “we need a new feature.” It’s “our systems don’t talk to each other.” The CRM doesn’t know what the calendar knows. The inventory count doesn’t match what the storefront says. Someone re-types the same order into two places every day. None of that shows up on a homepage, and that’s exactly why it gets ignored until it’s expensive.

The unglamorous majority of the work

Across our projects, integrations quietly account for more of the actual engineering than any single feature does. Wiring a payment processor to a booking system, syncing a point of sale system to three suppliers, connecting a support inbox to a database so a question only has to be answered once. None of it demos well. All of it is usually the thing standing between a business and its own data working for it instead of against it.

Why it’s harder than it looks

Every system you connect to has its own idea of what a customer, an order, or a payment actually is, and those ideas rarely agree. A lot of the real work is reading documentation, understanding a vendor’s edge cases, and deciding what to do when two systems disagree about the same fact. This is where a model actually helps a lot: reading API docs and drafting a first version of a sync job is exactly the kind of unglamorous, high-volume reading it’s good at. It doesn’t decide what happens when the systems disagree. A person still writes that rule, and still checks the model’s mapping against a real sample before anything goes live, because a confidently wrong mapping between two systems is the kind of bug that looks fine until it silently sends the wrong order to a warehouse.

Why we treat it as a product decision, not plumbing

Calling integrations “plumbing” undersells what they actually do for a business. When a business’s tools finally agree with each other, people stop doing the manual work of reconciling them, and that time goes somewhere else, usually somewhere that makes money instead of just accounting for it. We’ve watched an integration project move a client’s numbers more than a redesign did, simply because it removed a daily task that used to eat an hour of someone’s morning.

If we had to bet on which part of a project actually changes how a business runs day to day, we’d bet on the integration every time, over the feature that gets the screenshot. It’s just usually invisible, which is probably why it gets underrated.