Vendor Integration Platform

At Simply Source I led the backend team on a US-based, AI-powered cybersecurity SaaS platform. The product's job was to look at the security tooling an organization already runs — endpoint protection, DNS and edge services, and dozens of others — and recommend what to change. That framing has a direct engineering consequence: the product's usefulness is bounded by how many vendors it can read, and the surface I owned was 90+ third-party APIs feeding a single recommendation engine.

Ninety integrations is different in kind from nine, not just in degree. At that count, "every upstream is healthy" stops being the normal state and becomes a rare one. On any given day something is rate-limited, rotating credentials, timing out, or returning a payload shaped differently than it was last week — and none of that is a bug in my system. A design that treats vendor failure as the exceptional case is therefore wrong on most days of the year. The question is not how to prevent upstream failure; it is what the product should correctly do while some of it is failing.

The answer was to stop treating the integrations as ninety separate pieces of work. Authentication and error handling were standardized across the surface rather than written per vendor — one shape for how a vendor is authenticated, one shape for what a failure looks like coming back. The payoff is containment: a vendor outage surfaces as that vendor's signal being unavailable, which the engine can reason about, instead of an exception escaping from an integration nobody had thought about in months and taking a recommendation run down with it.

The part I would point to as the actual leadership work is that the same decision solved a team problem. A uniform contract is not only a runtime property — it is what makes a large integration surface reviewable by a small group. With one shape, a reviewer checks whether an integration matches it, instead of re-deriving correct authentication and error handling ninety separate times. Choosing what had to be uniform is what made the rest safe to delegate across five remote developers, alongside sprint planning and code review.

The internal surface got the same treatment: 20+ RESTful endpoints in ASP.NET Core, designed and optimized for throughput and reliability, backed by unit and integration tests in xUnit and Moq. Mocking mattered more here than it does on a typical service. You cannot call ninety partner APIs from a test suite — there are no credentials in CI, hitting a partner's production API on every commit is not acceptable, and real upstreams will not fail on demand. Mocking at the vendor boundary is what made the failure paths testable deliberately, rather than discovered in production.

• Led 5 remote backend developers on a US-based AI-powered cybersecurity SaaS platform, owning sprint planning, code review, and architecture decisions.
• Integrated and documented 90+ third-party vendor APIs (including ESET and Cloudflare) into an AI recommendation engine.
• Standardized authentication and error handling across the integration surface so a single vendor outage degrades one source rather than failing a recommendation run.
• Treated the integration contract as a review tool as much as a runtime one — a uniform shape is what makes ninety integrations reviewable by a small team.
• Designed, optimized, and tested 20+ internal RESTful API endpoints in ASP.NET Core, improving data throughput and reliability.
• Built unit and integration tests with xUnit and Moq, mocking the vendor boundary so failure paths could be exercised without calling partner APIs from CI.
• Worked on a system where partial upstream failure is the normal operating condition, not the exception case.