[Draft note for Manuel]: grounded directly in your own "engineering fingerprint" from Tech Profile (edge → gateway → domain service → events → systems of record) and the integration work already mentioned in the AI adoption service ("integrations to systems like Salesforce, SAP, and legacy systems"). Confirm this reads as a real, separate offering and not just a restatement of custom software development.

Most real systems aren't built from scratch in a vacuum — they need to talk to something that already exists: a CRM like Salesforce, an ERP like SAP, a legacy system nobody wants to touch, or another team's service. Getting that integration wrong is usually where a project actually breaks, not in the new code itself.

I design APIs and build the integration layer between systems, following the same shape that's worked across the enterprise projects I've owned: a thin edge, a gateway that handles auth/routing/rate limits, a domain service that holds the real business rules, events instead of tight point-to-point coupling between services (Kafka, RabbitMQ), and a data layer nobody queries directly. What that covers:

API design — REST or event-driven, contract-first when a frontend or another team needs to build against it in parallel.
Integration with existing systems (CRM, ERP, legacy platforms) without those systems' constraints leaking into the new codebase.
Idempotent event handling, so a retried message or a duplicate webhook doesn't corrupt data.
Documentation the next engineer can actually use, not just a contract sitting in someone's head.

This is the connective layer between systems — it pairs naturally with custom software development or legacy modernization when the new system's real complexity is in what it has to talk to, not in the new code itself.

Have a system that needs to integrate with something it doesn't control? Let's talk.