# The first hire who touches your billing should be boring on purpose

The engineer who owns revenue early should reach for idempotency, audit logs, and reconciliation by reflex. How to screen for the boring hire, and the danger signals to reject.

Author: Hasan Misbah
Published: 2026-06-24
Reading time: 7 min read
Canonical: https://misbah.co/blog/the-first-hire-who-touches-your-billing-should-be-boring

---


## TL;DR

Hire the engineer who reaches for idempotency, audit logs, and reconciliation by reflex before you ask. Screen with real scenarios like a double charge or a silent webhook failure, not raw velocity, which is the wrong first filter for billing.

The engineer who owns revenue early should be the least exciting person in the room. You want someone whose first question about a payment webhook is "what happens if this fires twice", not "can we rewrite this in the new hotness". Boring here is a compliment. It means they have been burned before and they build like it.

I have shipped billing and licensing for WordPress plugins and Laravel apps for years. The pattern that separates the people you want from the people who will cost you a weekend of refunds is not raw intelligence. It is what they reach for by reflex when money is on the line, the same reflexes I [insist on before writing any billing code](/blog/three-questions-before-i-write-billing-code).

## What boring actually looks like

Boring is a set of habits, not a personality. When I interview or review someone for a revenue-critical role, I am listening for these reflexes:

- They ask about idempotency before I bring it up.
- They assume every external call can fail, retry, or arrive out of order.
- They want an audit log of state changes before they want a dashboard.
- They treat the payment provider as the source of truth and reconcile against it.
- They know the difference between "the charge succeeded" and "our database believes the charge succeeded".

None of that is clever. All of it is the difference between a quiet Monday and a support queue full of people charged twice.

## Danger signal one: no idempotency

Ask a candidate how they would handle a Stripe webhook that Stripe retries three times because your server was slow to return 200. If the answer is "we would only get it once", pass. Providers retry by design, and duplicate delivery is one of the [payment edge cases that bite at 2am](/blog/six-payments-edge-cases-that-bite-at-2am). Your handler has to be safe to run more than once with the same event.

The boring version is unglamorous:

```php
public function handle(WebhookEvent $event): void
{
    // Stripe (and every serious provider) can deliver the same event
    // more than once. The unique index on provider_event_id is the guard.
    $seen = ProcessedEvent::where('provider_event_id', $event->id)->exists();
    if ($seen) {
        return; // safe no-op, we have handled this one already
    }

    DB::transaction(function () use ($event) {
        ProcessedEvent::create(['provider_event_id' => $event->id]);
        $this->applyToSubscription($event);
    });
}
```

The unique index does the real work. If two retries race, the second insert throws on the constraint and the transaction rolls back. No double credit, no double email. A candidate who reaches for the database constraint instead of an in-memory check has done this before.

## Danger signal two: no audit log

If state changes to a subscription or a license leave no trail, you are one confused customer away from a debate you cannot win. "You cancelled on the 3rd." "No I didn't." Without an append-only record, that conversation ends in a goodwill refund every time.

I want a table that answers "what changed, when, triggered by what, and what was the value before and after". Not a mutable status column you overwrite. An event stream you append to. When a founder tells me support takes hours because nobody can reconstruct what happened to an account, the missing piece is almost always this.

The person who builds the audit log before anyone asks for it is the person you want on billing.

## Danger signal three: no reconciliation

Your database and your payment provider will drift. It does not matter whether you [bought a hosted processor or built the billing layer yourself](/blog/build-vs-buy-for-billing): a webhook gets dropped, a deploy eats an event, a network blip lands mid transaction. Over a month, small drift becomes real money and real angry customers. The boring engineer expects this and builds a reconciliation job that compares your records against the provider's records on a schedule and flags the gaps.

I do not trust any billing system that has no answer to "how do you know your database matches Stripe right now". If the answer is "it should", that is a system waiting to be wrong quietly. Reconciliation is the smoke detector. It is cheap, it runs nightly, and the first time it catches a dropped webhook it pays for itself.

## Danger signal four: "we'll test in prod"

There is a healthy version of shipping fast and there is the version where someone runs an untested refund path against live customer cards because setting up the provider's test mode felt slow. On billing, the second one is disqualifying. Test mode exists. Sandbox keys exist. Replaying real webhook payloads against a staging handler is a ten minute setup.

The tell is not that they move fast. Good billing engineers move fast. The tell is what they are willing to be careless about. Careless about a CSS regression, fine. Careless about the code that moves money, no.

## Velocity is not the metric here

Founders hire for velocity because everything else in an early product rewards it. Billing is the one area where velocity is the wrong first filter. A fast engineer who ships a charge path with no idempotency and no audit log has not saved you time. They have moved the cost to a future month, with interest, and added your customers' trust to the bill.

The good news is that boring is teachable and testable. You do not need to find a genius. You need to find someone who, when you say the word "webhook", immediately says "we need to make that idempotent". Ask three or four questions like the ones above. The right person answers them before you finish asking.

## How to actually screen for it

Skip the abstract system design puzzle. Hand them a real scenario:

1. A customer says they were charged twice. Walk me through how you would confirm it and fix it.
2. A webhook handler failed silently last night. How would you have known?
3. We need to give annual customers a refund for the unused months. How do you build that safely?

You are not grading the final answer. You are listening for whether reconciliation, audit logs, and idempotency show up on their own. If they do, you have found your boring hire. Hold onto them. The exciting hires will thank them later, usually right after an incident.

The engineer who makes billing boring is doing the most valuable thing an early engineer can do: making sure the part of your product that pays for everything else never becomes the story.

## The takeaway

Boring is not a lack of talent, it is a set of reflexes you can screen for in an afternoon. The engineer who makes idempotency, audit logs, and reconciliation non-negotiable is protecting the part of your product that pays for everything else. Hire for that, not for the flashiest line of code, and billing stops being the thing that ruins your weekends.

## FAQ

**Is a boring billing engineer just a less ambitious hire?**
No. Boring here means disciplined about money code, not slow or unskilled. Good billing engineers still move fast, they just refuse to be careless about idempotency, audit logs, and reconciliation.

**What is the single fastest way to screen for this in an interview?**
Ask how they would handle a webhook that fires three times. If they reach for a database unique constraint instead of an in-memory check, they have done this before.

**Can I train an existing generalist into this role instead of hiring for it?**
Yes, these habits are teachable and testable. You are looking for someone who says "make that idempotent" when they hear "webhook", and that reflex can be coached.

**Why not just optimize for velocity like every other early hire?**
Because on billing, velocity without idempotency and audit logs moves the cost to a future month with interest, plus your customers' trust. It is the one area where speed is the wrong first filter.

**What if we cannot afford a dedicated billing hire yet?**
Then make the three habits a review requirement for whoever ships revenue code. The reflexes matter more than the title.