Integrating with customer systems
Your software only creates value when it fits into the systems people already use. Integration is where forward deployed work differs most from product engineering: you don't control the environment, the network or the security rules, and the "legacy" system you must connect to may be older than your career.
Understand the deployment model first
| Model | What it means | Typical implications |
|---|---|---|
| Multi-tenant SaaS | Customer uses your hosted platform | Fastest; security review focuses on your controls and data handling |
| Single-tenant hosted | Dedicated instance per customer | Stronger isolation; more operational work for you |
| Customer cloud (their VPC) | You deploy into the customer's cloud account | Their IAM, networking and approvals; you may not have direct access |
| On-premises / air-gapped | Inside their data centre, maybe no internet | Offline installs, no external model APIs unless approved |
Clarify this in qualification. It changes your architecture, your timeline and which models you can even use.
Identity and access
Enterprises expect users to sign in with their existing identity provider, typically via SAML or OpenID Connect. Plan for:
- SSO with the customer's identity provider, often with group-based roles.
- Authorisation that mirrors their rules — if a user can't see a document in the source system, your AI assistant must not show it either.
- Service accounts for system-to-system access, with narrowly scoped permissions and rotated secrets.
Permission-aware retrieval is non-negotiable for enterprise AI. An assistant that leaks a document a user isn't allowed to see is a security incident, not a bug.
Network realities
Corporate networks are locked down by design. Expect allowlists for outbound traffic, private connectivity requirements, proxies that interfere with TLS, and long lead times for firewall changes. Ask early: "What will need to talk to what, over which ports, from where?" — and draw it.
Integration patterns
| Pattern | Use when | Watch out for |
|---|---|---|
| REST / GraphQL APIs | The system exposes a supported API | Rate limits, pagination, auth token expiry |
| Events and webhooks | You need near-real-time reaction to changes | Delivery guarantees, retries, idempotency |
| Batch file exchange | Legacy systems, nightly processes | File formats, partial files, schedule drift |
| Database replica / CDC | Read-heavy analytics or search | Schema changes, replication lag, access approvals |
| UI automation | Truly no other option | Brittle; treat as temporary |
Build integrations to fail gracefully: retries with backoff, idempotent writes, dead-letter queues for poison messages, and clear alerts.
The security review
Almost every enterprise deployment goes through a security review. Make it easy:
- A data flow diagram — what data goes where, encrypted how, stored for how long.
- Answers to the security questionnaire, prepared with your own security team.
- Your controls — authentication, encryption, logging, vulnerability management, incident response.
- For AI: which model providers see data, whether it is retained or used for training, and how prompt injection and data leakage are mitigated.
Request the security questionnaire in the first week. Reviews often take weeks, and they run happily in parallel with your build if you start them early.
Never work around a customer's security controls to hit a deadline — no personal tunnels, shared credentials or copied data. It destroys trust instantly, and it may breach the contract.
System design rounds for FDE roles often add customer constraints: "Same design, but the bank requires everything to stay in their VPC and users sign in with their SSO." Show how the architecture changes, and name the approvals you'd need.
Senior Full-Stack Engineer · AI & AWS. I turn ambiguous customer problems into production systems — cloud, data and AI.