Four ways to ship AI in your fintech (and how to pick)

A typical question from a fintech founder: "Should we build this AI feature in-house or pay a vendor?"

The framing is too narrow. There are four real options, and the right one depends less on the AI itself and more on what kind of company you want to be in 18 months.

The four paths

Buy an off-the-shelf product. A vendor has built the AI feature you want as a SaaS. You integrate it, configure it, and pay per seat or per call. Examples in fintech: fraud-scoring APIs, document extraction services, KYC tooling with AI on top.

Build it in-house. Your own engineers build the feature using AI APIs from OpenAI, Anthropic, or others. You own the code, the prompts, the evaluations, the operational story.

Hire an outside engineer or small team to build it for you. Independent consultants or specialist firms come in for a defined engagement, build the feature with you or for you, and hand over a working system. Sometimes they stay on for maintenance. Sometimes they hand off to your team.

Wait. The fourth option is the most underrated. Wait six months. The tooling will get cheaper, the models will get better, and the use case will be clearer. For some features, this is correct.

What each one costs

This is where founders usually get the numbers wrong.

A vendor product looks cheap at first. Then you add seats, then API calls, then the integration work to make it fit your data, then the workarounds for the things it does not do well. Real cost over two years is often higher than founders model on the first pass.

Building in-house looks expensive at first because you see the engineering salary. Then you discover the AI part is 20% of the work and the data plumbing, evaluations, observability, and rollout machinery are the other 80%. If you do not have engineers experienced in shipping AI features in production, the calendar cost dwarfs the salary cost.

Hiring an outside engineer is somewhere in between. You pay a senior rate for a defined window. You skip the hiring time (months) and the ramp-up time (more months). What you get is leverage on someone else's experience, applied to your specific problem. You also keep the code, which is the part that matters in 12 months.

Waiting costs you nothing up front. It costs you whatever you would have learned from shipping, and whatever competitive position you would have built.

What each one actually gets you

A vendor product gets you speed and a known quantity. You ship in days, not months. The ceiling is whatever the vendor's roadmap allows. The data and decisions are not really yours.

Building in-house gets you ownership and customization, eventually. The cost is calendar time and the risk that your first attempt is the wrong shape. Most first attempts are.

An outside engineer or small team gets you a working system, built with your data and your constraints, plus knowledge transfer. The risk is picking the wrong outside party. Senior independents and small specialist firms vary widely. Reference checks matter more than rate cards.

Waiting gets you better tools and a clearer problem statement, at the cost of momentum. If you are still in the "is this even the right feature" phase, waiting is often the right answer.

How to actually decide

A short checklist. Answer honestly.

1. Does the feature use your unique data, your unique workflow, or your unique users? If yes, a vendor product probably will not fit. Build in-house or bring in an outside engineer.

2. Do you have engineers on staff who have shipped AI features in production before? Not "are interested in AI". Have actually done it. If yes, in-house is more realistic. If no, in-house will take 2-3x longer than you think.

3. Is the feature on a critical path for a launch, a fundraise, or a contract you are trying to close? If yes, calendar time matters more than monthly burn. An outside engineer who can ship in 8 weeks is often the right answer.

4. Could you ship a smaller version of this with no AI at all, learn something, and revisit in 6 months? If yes, do that. AI is rarely the only way to solve a product problem, and the version without AI is faster and cheaper to test.

5. What does your AI infrastructure look like 12 months from now? If you cannot describe it, decide whether you want to figure that out on this feature or on a smaller one.

If you are in the middle of this decision and want a second pair of eyes, the contact page has the details.