Third Party Administrator

Dec 31 2024 · 3min · projects

vibe check

This isn’t a normal onboarding task

In my second week as a Team Lead, I needed to deliver a project within fourteen days, and because of the upcoming holidays, I was the only option. To accomplish this technically, I needed to build a front-end admin portal and a backend CSV retrieval, parsing, and storage service. My VP of Engineering recognized what he was asking, and we both knew I could deliver.

wiring it up

This project was true full-stack, so I needed to own the delivery all the way through.

First, I built a service that connected to an sFTP server hosted by our third-party, with credentials mounted as secrets in Kubernetes pods instead of using .env files in source. Since we only need the latest file, I set up a file naming convention that ensures consistency (over date-based shenanigans). Once we have the file, the ssh2-sftp-client parses the file into a buffer, which then gets converted to JSON and PATCHed to the database. It was a pretty straightforward service that let me touch routes, services, helpers, mongoose schemas, and convert several files to TypeScript.

Next, I knocked out an Angular route and the simple card UI. We didn’t have a design system, so I used the patterns I could find elsewhere in the repo. From there, I needed to dig into permissions, which involved Permit.io for SaaS RBAC-style permissions, Firebase’s auth and access rules, and touching our front-end and api repositories. While this was more straightforward technically, I had to understand our entire access model as both a legacy system and our future architecture plans.

calls i made and missed

I let my newness override my judgement in a few places . When scoping the project, I didn’t clarify the CSV file structure, fields, and delimiter since I had an example file that turned out to be completely incorrect. I also missed how we track and report our claims internally, so I focused only on the external component. This meant we had to do a couple of fast-follow updates to ensure that our UI and slack channels were following the previous convention. The easy read is that someone else should have provided a better brief to the new developer, but I should have owned my role and done the diligence myself.

I offset the misses with strong intuition and experience though. I updated the mongoose schema to accommodate the legacy hardcoded formats while also removing virtual fields and future-proofing for later TPA changes. A couple of TypeScript updates mean that we can catch basic errors before we get too far as well. Then, because the data can be sensitive, I made sure that we didn’t write temporary files as a “just get it out” solution. Instead, we’re using an in-memory buffer that makes processing both fast and secure. Taken together, these changes led to a more resilient claims service that would be useful for the next update.

the outcome

The project set us up for not only switching to another TPA if ever necessary, it also became the foundation for bringing claims in-house. My team has since become the technical owner of all claims ingestion, reporting, and automated communication, which has elevated our profile and stakeholder trust. It also reminds the team that I am equally comfortable executing technical projects as I am delegating projects out to them.

under the hood

frontend: Angular (routing, permissions, UI) backend: Node.js (readstreams, mongoose, ssh2-sftp-client) data sync: Mongo infra: Kubernetes, .env extras: Permit.io, sFTP, CSV files