What founders should look for in their first fintech engineer

In most software a bug is an annoyance. A button does nothing, a page loads slowly, someone refreshes and carries on. In financial software a bug is someone's money: a deposit that was paid and never credited, a withdrawal sent twice, an account still trading after it should have been stopped.

Your first engineer sets the habits the whole codebase inherits. People copy the code they find, so the way a repeated payment notification is handled in month one is the way it will be handled in year three. That makes this hire matter more than its size suggests.

You may not be able to judge code. You can still judge the person, because the habits that matter show up in conversation and in what they write down. Below are eight things to look for, a short piece of code explained in plain language, questions for a first call and a list of red flags.

1. They ask how it fails before how it looks

A careful engineer's first questions are about failure: what happens when the provider's notification arrives twice, arrives late or never arrives. You will hear three words. Idempotency means doing a thing twice has the same result as doing it once, retries are the repeat attempts every provider makes, and reconciliation is a regular comparison of your records with the provider's.

Most payment bugs I have fixed were not on the checkout page. They were in the callback, the message a provider sends to say a payment went through. On a ticketing project in a previous job, status polling, idempotent fulfilment and an automatic reconciliation job were what kept a missed callback from becoming a lost order.

2. They tell you what they have not done

Fintech is several specialities sharing one word. A specialist who has built a broker's payment flows has not automatically built a trading engine, and someone who has built an exchange has not automatically integrated a card provider. A good candidate draws that line for you before you ask.

My own version: as a freelancer I built the MetaTrader 5 integration and real-time risk monitor for a live prop-trading firm, and in my current job I build deposit and payment flows at a live broker. I have not shipped a proprietary trading engine in production, and my site says so. If your product needed one, I would call it a design to be proven with tests, a proof of concept and independent review before client money went near it.

3. They prove a cause before they change code

When something breaks, the careless response is to change the most suspicious line and see whether the problem goes away. The careful response is to find evidence first. In a money system a fix aimed at the wrong cause leaves the real fault in place and adds a second one.

At the broker, an HTTP 500 error on crypto trades was traced by correlation id, a tag that follows one request through every log, to duplicate asset-pair records. The fix made symbol lookup deterministic instead of hiding the error. At the prop firm, some accounts briefly read another account's figures under load. The cause was a trading platform SDK that is not thread-safe (it cannot safely be called from several places at once), so every call now goes through one lock and a guard checks that the account returned is the account requested.

Ask a candidate for a story like these. Listen for how they knew, not for how fast they fixed it.

4. They write things down

Look for a written scope, a list of what is out of scope, the deploy order, and runbooks: short instructions for routine and emergency operations. Documents are how you check the work without reading code. They are also how the next engineer avoids relearning everything.

At the prop firm the deployment runbook had four steps: stop both services, deploy, check a known-bad and a known-good account by hand with the risk monitor switched off, then switch it on. It is short, and it removes a whole class of incident. Be wary of anyone who says the documentation will come later.

5. They keep the first release small and the architecture boring

A first release that touches money should do few things and do them correctly. In practice that means one deployable program where possible, one integration route to each provider, and manual operations where automation can wait. A person approving withdrawals from an admin screen is a perfectly good first version.

The usual name for this shape is a modular monolith: one program, deployed as a single unit, divided inside into separate parts with clear boundaries. SolveMY, my own product, is a live marketplace I built alone on one deployable Go service with 235 endpoints across 31 domain services. One person can run that. Be cautious of a proposal with many small services and a queue between each of them for a product that has no users yet.

6. They can run production, not only write code

Code that works on a laptop is the start. Someone also has to make sure there are backups that have actually been restored, monitoring that notices a failure before a customer does, alerts that reach a person, and a staging environment where changes are tried against the provider's test mode first.

On the prop-firm work that meant health monitoring with alert emails, crash notifications, automatic reconnection and separate demo and live services. I run SolveMY's production myself, with Docker, backups and monitoring. If your first engineer has never been responsible for a live system, plan for someone who has.

7. They are honest about AI tools

Most engineers now use AI coding assistants, and that is fine. I use them daily. They are fast for drafting, for exploring unfamiliar code and for writing tests.

What matters is how the output gets checked. On any path that moves money, generated code is a draft: a person reads every line of the change (the diff) and tests prove the behaviour. An engineer who cannot explain a line should not ship it, whoever wrote it. Be wary of a timeline that only works if nobody reads what the tool produced.

8. They know where engineering stops

Licences, KYC and AML policy (identity checks and anti-money-laundering rules) and legal structure belong to you and your advisers. Whether you need a licence, who may hold client funds and what you may promise investors are legal questions. An engineer who answers them confidently is guessing.

A good engineer designs the system so those controls can be met: an audit trail, approval steps, limits, records your compliance adviser can export. They also tell you when a feature needs a lawyer before it needs code. I am not a lawyer or a compliance officer, and I would rather say so on the first call than in month three.

What care looks like in about twenty lines

You do not need to read code to follow this example. It is the part of a payment system that receives the provider's message saying a deposit was paid. The three numbered comments mark the lines that separate a careful engineer from a careless one.

const rawBody = express.raw({ type: 'application/json' });

app.post('/webhooks/payments', rawBody, async (req, res) => {
  // 1. Prove the message came from the payment provider before reading it.
  if (!signatureIsValid(req.body, req.get('x-signature'), WEBHOOK_SECRET)) {
    return res.sendStatus(401);
  }
  const event = JSON.parse(req.body.toString('utf8'));

  await db.transaction(async (tx) => {
    // 2. The table accepts each provider event id once. A repeat saves nothing.
    const saved = await tx.query(
      'INSERT INTO payment_events (provider_event_id) VALUES ($1) ' +
        'ON CONFLICT (provider_event_id) DO NOTHING',
      [event.id],
    );
    if (saved.rowCount === 0) return; // seen before: change nothing
    await creditDeposit(tx, event); // saved together with the row above
  });

  // 3. Reply "received" only after the transaction has committed.
  res.sendStatus(200);
});

Step 1 is there because the address that receives these messages is public, so anyone can send a fake 'payment succeeded' to it. Step 2 is there because providers repeat a notification whenever they are unsure you received it. Without that rule in the database, a repeat credits the customer twice.

Step 3 is about order. If the server replies 'received' first and saves second, a crash in between loses a real payment and the provider has no reason to send it again. Replying last means a failure leads to a retry, and step 2 makes the retry safe.

A version without these three lines passes every demo. It fails only on the bad day. I go through the full checklist in payment webhooks that never double-credit.

Questions to ask on a first call

None of these needs a technical background. Listen less for jargon and more for whether the answer is specific.

Red flags

• A fixed price in the first conversation for a scope nobody has defined.
• A promise of everything in two months.
• No questions about your licences or your payment provider's approval of the business.
• No staging environment, so every change is first tried on the system that holds real money.
• A balance stored as a single number, with no history of the entries that produced it.
• Unwillingness to hand over the source code and access to the accounts it runs on.

One of these is a reason to ask more questions. Several together are a reason to keep looking.

How to start small

You do not have to commit to a full build after one conversation. The cheapest way to see how someone thinks is a paid discovery or architecture sprint: a short, fixed piece of work that ends in a written deliverable.

That document should set out the scope, what is out of scope, the main risks, the integration route, a plan for the first release and the open questions for your lawyers. The test is whether any other team could build from it. If they could, you have lost nothing by starting small. If the document is vague, you found that out cheaply.

This is how I try to work, and you are welcome to hold me to this list. If you want that kind of help with a product that touches money, my fintech technical partner page describes it, and you can contact me to talk it through.