The third time: when a customer's integration bug is the platform's bug

Imagine you are the first FDE at a bank that sells APIs to developers. In your third week you fix the same bug for a third customer: everything works in the sandbox, but in production a money transfer gets created twice.

By the third time, you have two paths. The first is to keep fixing it customer by customer, which anyone can do. The second is to treat that third repeat as data and fix the root cause, so the fourth customer never hits the bug at all.

This article teaches the second path. It is the skill that separates an FDE from a good support engineer, and some financial-services employers now write it straight into their job postings.

When the API is the product, customer friction is your job

Column describes itself as the first nationally chartered bank built to serve developers and product teams.

Its API is defined by an OpenAPI spec, so customers can generate SDKs, load it into Postman or Insomnia, or run a local mock.

The bank also offers a sandbox where developers can write software that works directly with bank accounts.

The most important detail for an FDE lies elsewhere. According to Column’s founder, because the bank owns its core system and developer platform, it needs no middle layer, and its developer customers integrate directly with the bank. There is no vendor in between to blame, but there is also no vendor in between standing in your way when you want to fix something.

So at a bank like this, any place where customers get stuck should be read first as a signal about the product. Three FDE job postings in finance, from Monumint, Bretton AI and ModernFi, do not say so in those words, but all of them give the FDE the job of feeding customer feedback back into the product.

Monumint wants its FDEs to turn customer feedback into product improvements, and wants quick, patched-together fixes to grow into durable systems used by thousands of customers.

Bretton AI asks for connectors, configuration tools and internal frameworks that turn solutions built for one customer into a repeatable capability.

Which layer should the fix live in?

The hard part is not making the fix but choosing where to put it. Think in four layers, from cheap and fast to expensive and durable:

Layer	When to use it	Example for the duplicate-transfer bug
On-the-spot fix	First occurrence, customer is blocked	Fix the retry logic in the customer’s code
Documentation	Repeats, cause is a misunderstanding	Add a warning and an example to the endpoint description in the spec
Tooling	Repeats even though the docs are clear	Add a retry check to the onboarding process
Platform	Many customers, high risk	Propose that the SDK attach a deduplication key automatically

The rule of thumb: always fix at the lowest layer first so the customer can keep going, then let the repeat count decide whether to climb higher.

ModernFi’s job posting shows that the middle layers are real FDE work, not side tasks. FDEs there own and improve the public API documentation, and work with the customer success team to take in feedback and optimise the self-serve onboarding tools.

A worked example, all the way round

Go back to the scenario at the top, now treated as a hypothetical exercise. Suppose your API supports idempotency keys, but the documentation mentions them only on a page few people read.

The first customer is a payroll startup. Its code retries on timeout without sending a key, so a flaky production network is enough to create duplicate transfers. The sandbox does not expose the bug because timeouts rarely happen there.

Bretton AI describes exactly this kind of work: edge cases that only surface once a system is running in real production. In week one you fix it on the spot by correcting the customer’s retry function. But before closing the ticket, you add an entry to the friction log:

- date: 2026-10-05
  customer: payroll-startup-a
  env: production
  endpoint: POST /transfers
  symptom: transfer created twice after timeout
  root_cause: retry sent without idempotency key
  tag: retry-duplicate
  workaround: fixed client retry, added key from payroll_run_id
  time_spent_hours: 3

By week three there are two more entries with the same tag. A short script is enough to turn the feeling that “this bug seems to come up a lot” into numbers:

import collections, yaml

entries = yaml.safe_load(open("friction_log.yaml"))
by_tag = collections.Counter(e["tag"] for e in entries)
for tag, n in by_tag.most_common():
    hours = sum(e["time_spent_hours"] for e in entries if e["tag"] == tag)
    flag = "ESCALATE" if n >= 3 else ""
    print(f"{tag:20} {n}x  {hours}h  {flag}")

With three repeats, you move up to the documentation layer. Because the API is defined by an OpenAPI spec, put the warning and the example directly into the endpoint’s description in the spec rather than writing another wiki page. That way the generated SDKs, the Postman collection and the customer’s local mock all carry the warning, right where developers are looking.

Next comes the tooling layer: add a step to the onboarding checklist, “simulate a timeout in the sandbox and check that no duplicate transfer is created”.

For the platform layer, you write a one-page proposal for the product team covering the three affected customers, the hours spent, the current workaround and the option of having the SDK attach the key automatically.

Bretton AI calls this turning how customers use the product into insight for the engineering and product teams.

Doing it yourself from tomorrow

Start keeping a friction log from the very first ticket, even before you see any pattern. Without early data, by the third time all you have is memory. Each entry needs the endpoint, the environment, the root cause, the workaround and the hours spent, because those are exactly what the product team will ask about.

Then set yourself a clear threshold, say three repeats, and review the log every week rather than waiting for inspiration. When you hit the threshold, choose the lowest layer that addresses the root cause.

If customers misunderstand, fix the documentation; if they understand but still get it wrong, they need tooling. And if both have been done and the bug keeps coming back, it belongs to the platform.

The step most often skipped is going back to tell the customers who hit the bug that the fix is in. It closes the feedback loop and gives customers another reason to keep telling you where they get stuck.

Common traps

The most common trap is getting stuck at the on-the-spot layer. Customers are happy and you feel useful, but six months later you are just a consultant following individual customers around, and the platform is exactly as it was.

The opposite trap is demanding a platform fix the first time you see a problem, with no evidence yet that it repeats.

Another trap is bringing anecdotes to the product meeting. “Customers often complain about this” loses badly to “three customers, nine engineering hours, the same endpoint”. Nor should you treat a working sandbox as done: the hardest bugs at a bank often show up only in production, so the onboarding checklist needs a step that simulates bad conditions.

Turning this skill into an edge in your job search

When reading FDE job postings, especially at fintechs or companies selling infrastructure to banks, look for phrases such as “turning customer feedback into product improvements”, “repeatable” or “own API documentation”.

Those phrases mean the company expects you to work across all four layers, not just fix bugs. Monumint also asks for integration with the systems customers already run, such as Salesforce, nCino, Fiserv or Jack Henry, so anyone with real integration experience has an advantage.

On your CV, describe the full loop rather than listing tasks. A line like “Identified a retry bug affecting three customers through a friction log, fixed the spec and onboarding checklist, and proposed an SDK change that was added to the roadmap” shows a recruiter that you can see from one customer to the whole platform.

If you are not yet an FDE, you can practise this loop with any public API: try an integration, log where you get stuck, then submit a proposed documentation fix.

The fourth customer will never know which bug they avoided. An FDE who does this well leaves more of a mark on the platform than in the support inbox.