Third-party system integration is the real challenge in software today

The hardest part of a software project is rarely writing new logic. It's getting that logic to talk to what already exists.

ERP, a management spreadsheet, a tax filing system, a logistics platform, a legacy database nobody can fully explain anymore — any company that's been operating for a few years has an ecosystem of systems that were never designed to talk to each other. And that's exactly where most technology projects lose time, budget, and patience.

Why integration is harder than building from scratch

Building a new, isolated feature is a well-defined problem: you know the input, you know the output, you control both ends. Integration is the opposite. You don't control the system on the other side — the API docs might be outdated, a field that should be required sometimes comes back empty, the system version changes without warning.

This is even more true for ERPs like Protheus, SAP, or Senior: they're robust systems, built for internal operations, not necessarily to expose data simply to outsiders. Integrating with them isn't "connecting an API" — it's understanding the business logic the system carries inside before trying to pull data out of it.

The most common mistake: treating integration as a technical detail

Development teams tend to leave integration for the end of the project, as if it were just one more connector. In practice, it's the opposite: integration should be one of the first questions, because it defines what's actually possible to build on top.

When we run Agro Consulting, ERP integration isn't a project phase — it's the starting point. Before designing any agile solution on top, we already know what can be pulled from Protheus, SAP, or Senior, and what needs a different path.

Integrating without duplicating, without migrating, without breaking what already works

The most expensive temptation in integration projects is "let's just switch systems." Replacing an entire ERP to solve a data visibility problem is using a sledgehammer to drive a nail. The approach that actually works is building the agile layer on top of what already exists — no duplicated systems, no risky migration, no stopping operations to "modernize."

It's less flashy work than "building from scratch." But it's what separates a project that ships from one stuck in requirements meetings forever.