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, including a new API layer, policy-data migration, and messaging infrastructure.

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 difficult-to-maintain codebase with little separation of concerns, which became especially problematic when integrating a new system: the API wasn't structured around clean integration boundaries, while the new component needed a reliable, well-defined way to communicate with QCS.

Policy data needed for migration was scattered across many tables, so a raw database export wasn't sufficient — the external team needed it in a genuinely usable format.

The integration spanned multiple companies without effective project coordination, so I increasingly had to identify dependencies and risks myself rather than rely on an established process to surface them.

Solution

I treated this as an integration problem rather than a set of API endpoints to implement. The first priority was understanding how the existing system actually worked — tracing behavior through an inconsistent, convoluted codebase to establish a reliable integration layer.

I built the additional API functionality the new web component needed and the supporting infrastructure for the integration, implementing MassTransit for messaging rather than extending the legacy, older-.NET messaging approach.

For the data migration, I identified the relevant policy data across the existing schema, transformed it into useful representations, and produced structured CSV and JSON exports the external team could work with directly, rather than raw table dumps.

Throughout, I acted as the technical bridge between the two organizations — understanding what the external team needed, spotting where assumptions about the legacy system would cause problems, and resolving integration issues before they became blockers. With project coordination largely absent, I also took ownership of dependency-tracking and requirement clarification that would normally sit with project management.

Result

The integration was completed and functional, taking roughly two additional weeks beyond the original four-month timeframe given the scope for a single engineer. The resulting API and integration infrastructure gave the external team the interface they needed, and the structured exports gave them the policy data required for migration.

More importantly, the project demonstrated my ability to operate where the technical and organizational structure was incomplete — understanding an existing system, identifying what would block the integration, and taking ownership of resolving it rather than waiting for problems to be assigned.

It reinforced an approach I keep coming back to: with a difficult existing system, the goal isn't necessarily to fix everything — it's to establish the right boundaries around the complexity and give the people building on top of it a clear path forward.