The real cost of a broken integration
Clients ask us to price automation projects by build time. That's the wrong unit. The build is a few days of work. The thing that actually determines cost is what happens when the integration breaks at 2am on a Tuesday and nobody notices for a week. We've started pricing projects around failure cost, not feature count, and it changes almost every conversation.
Why silent failure is the expensive kind
A loud failure is cheap. The script throws, someone gets paged, it's fixed in an hour. The expensive failure is the one that doesn't throw: an API starts returning partial data, a field gets renamed upstream, a rate limit silently drops half your requests. The pipeline keeps running. The dashboard keeps updating. It's just wrong, and it stays wrong until someone notices the numbers don't add up, which can be weeks.
- A pricing sync that drops rows quietly undercharges customers for a month before anyone reconciles it.
- A CRM integration that fails on unicode characters silently skips every non-English lead.
- A reporting job that times out halfway through ships a report that looks complete but isn't.
- An inventory sync that double-counts on retry oversells stock nobody has.
Build for detection, not just correctness
You can't test your way out of every edge case an external API will eventually throw at you. What you can do is make failure loud. Every automation we ship gets a row count check, a checksum against the source, or a simple sanity bound, something that says 'this run looks abnormal' and stops before it writes bad data downstream. It's less code than the happy path and it's the difference between a five-minute fix and a week of forensic accounting.
The goal isn't a pipeline that never fails. It's a pipeline that fails loudly, in the first five minutes, instead of quietly, in the fourth week.
Price it into the scope
When a client pushes back on the cost of monitoring and alerting, we walk through what one silent failure actually costs: the hours reconciling data, the trust lost with a customer who got the wrong invoice, the manual audit of every run since the bug shipped. That conversation usually ends the pushback. Monitoring isn't a nice-to-have on top of the automation. It's the part that makes the automation safe to leave alone, which is the entire point of building it.