LinkedIn Carousel: The 9 Commits

Post type: Technical · 10 slides
Blog post: https://www.nuvikatech.com/blog/posts/nine-commits-claim-filing

SLIDE 1 — Cover

Headline: 9 commits. 3 cloud providers. Here’s the honest story of shipping our SLA claim filing module.

Sub-line: Including the three bugs we caught before they reached a single customer — and the one that would have silently written wrong data to production.

SLIDE 2

Label: WHAT WE BUILT

Headline: When a cloud SLA breach resolves, Fintropy auto-files the credit claim. Across AWS, Azure, and GCP.

Body: The flow: breach resolves → check tenant settings → build provider connector → file claim via Support API → poll daily for approval. Simple to describe. Complex to get right.

SLIDE 3

Label: COMMIT 1

Headline: ConnectorFactory: one unified way to build authenticated provider connectors.

Body: Before this, connector logic was scattered across two files. The factory unified it. Bug caught in review: the initial version called authenticate() but ignored the return value — returning a broken connector with no error raised.

SLIDE 4

Label: COMMIT 5

Headline: Auto-file hook: the most complex commit, and the most instructive bug.

Body: file_claim() legitimately returns {"status": "assisted"} for AWS Basic plan accounts. The initial implementation treated anything except “submitted” as an error. That logged a misleading warning for normal, expected outcomes.

SLIDE 5

Label: COMMIT 6 — THE CRITICAL BUG

Headline: AWS get_claim_status() returned “resolved”. Our code checked for “approved”. They didn’t match.

Body: “resolved” hit the else branch and marked the claim as “Credit Denied.” No exception. No warning. Just a wrong value in the database — on every successfully resolved AWS case.

SLIDE 6

Label: THE PATTERN

Headline: 3 bugs caught before shipping. All three looked correct at the function level.

Body: The critical one — the vocabulary mismatch — only became visible when you traced the full flow from provider API response to database write. That’s what the two-stage code review exists for.

SLIDE 7

Label: THE LESSON

Headline: Design your vocabulary contract before your provider implementations.

Body: We designed the poll endpoint first, then built the providers, then discovered the mismatch. Starting from the contract and building the providers to satisfy it would have caught this at design time.

SLIDE 8

Label: WHAT WE’D DO DIFFERENTLY

Headline: Extract shared data earlier. DRY violations are free to avoid when you’re writing — expensive to fix after.

Body: The AWS service code map existed in two identical 27-entry dicts in two different files. We noted it, deferred it, and now every new service requires updating both files.

SLIDE 9

Label: THE TAKEAWAY

Headline: Two-stage review catches system-level bugs, not just function-level ones.

Body: Stage 1: spec compliance — did you build what was designed? Stage 2: code quality — does it behave correctly in context? The second stage is where the vocabulary bug was caught.

SLIDE 10 — CTA

Headline: Want the full story?

Body: All 9 commits, the bugs that almost shipped, and what we’d do differently — an honest shipping story from the Fintropy engineering blog.

Link: nuvikatech.com/blog/posts/nine-commits-claim-filing