Skip to content
Kamil BinkoKB.
← Back to experience

~3–4 months, plus ~2 additional weeks

QCS Content AI Integration

Consultant — technical integration lead

  • .NET 9
  • Azure
  • SQL Server
  • REST APIs
  • MassTransit
  • CSV/JSON data export

Integrated an existing insurance policy management system with an externally built AI content platform: a new API layer, a MassTransit-based messaging layer, and a policy-data migration.

Team

  • Consultant via Swappsi, acting as the technical bridge between QCS and an external consultancy building the AI-based component
  • Multi-company project without a stable technical or project-management structure

Challenge

QCS's existing system had grown into a hard-to-maintain codebase with little separation of concerns. That made integration harder than it should have been: the API wasn't built around clean boundaries, and the new component needed a reliable, well-defined way to talk to QCS.

The policy data needed for the migration was scattered across dozens of tables, so a raw database export wouldn't have been usable — the external team needed it reshaped into something they could actually work with.

The integration spanned multiple companies without much project coordination, so I ended up identifying dependencies and risks myself instead of relying on an established process to surface them.

Solution

I treated this as an integration problem rather than a list of API endpoints to build. First I spent time understanding how the existing system actually worked, tracing behavior through an inconsistent codebase to figure out where a reliable integration layer could sit.

I built the additional API functionality the new web component needed, along with a MassTransit-based messaging layer, rather than extending the older, ad-hoc messaging approach already in the codebase.

For the data migration, I pulled the relevant policy data out of the existing schema, reshaped it into something usable, and produced structured CSV and JSON exports instead of raw table dumps.

I acted as the technical point of contact between the two organizations, figuring out what the external team actually needed and catching places where assumptions about the legacy system would cause problems before they became blockers. With project coordination largely absent, I also ended up tracking dependencies and clarifying requirements myself.

Result

The integration was completed and working, about two weeks past the original four-month estimate for one engineer. The API and messaging layer gave the external team the interface they needed, and the exports gave them usable policy data for the migration.

The bigger lesson was about working without much structure: understanding an unfamiliar system, figuring out what would actually block the integration, and dealing with it myself rather than waiting for it to be assigned to someone.