What building with AI actually costs

What building a fintech application alone in ninety days taught me about the real AI opportunity — and why most executives are asking the wrong question.

What building a Fintech app alone taught me about the real AI opportunity — and why most executives are asking the wrong questions.

Ninety days ago, I started designing a Fintech app. I am not a developer. I have not written a line of production code in fifteen years. My career has been spent inside COO teams at large regulated financial institutions — designing operating models, running technology-intensive transformations, managing the messy gap between what strategy decks promise and what operations can actually deliver.

What I built is KadoPool: a platform that fixes three stubborn problems with group gifting — trust, privacy, and logistics. No contribution leaderboards, no social pressure, no awkward money conversations. Just a clean, digital process from pool creation to thank-you note, designed to bring communities closer rather than rank them. The app is live. The build is done.

But this article is not really about KadoPool. It is about what the experience of building it — alone, in ninety days, using AI as a workforce — revealed about the state of enterprise AI adoption. Because what I saw from the inside of that build should concern every COO, CEO, and founder currently planning an 'AI transformation.'

The myth that started this

The story the tech press tells goes something like this: AI has democratized software development. Anyone can build anything. The age of the expert is over.

I wanted to test that claim rigorously — not as a tech journalist, but as someone who has spent years watching corporates spend enormous sums on digital transformation projects that deliver very little. If the tools were really as powerful as advertised, what could one person with domain knowledge but no active coding skills actually build?

The answer surprised me. Not because of what the AI could do — but because of how precisely it exposed the difference between people who understand a domain and people who do not.

I call it the Vibecoder Myth: the idea that domain expertise is now optional when you have AI. It is not. It is more important than ever. AI does not replace judgement. It amplifies the misjudgment risk dramatically.

Managing a synthetic workforce

The first thing that became clear within days of starting the build was that using AI to write code is nothing like what the demos suggest. The tools are not autonomous. They do not understand your business. They do not remember yesterday's decisions. And they have absolutely no sense of self-preservation.

My working description became: a brilliant, manic intern who has read every 'X for Dummies' book and had six espressos, with zero hours of sleep. The AI would satisfy a prompt with impressive-looking code — and simultaneously introduce a security vulnerability three layers down that it would not mention unless you specifically asked.

The management analogy is closer to outsourcing than to automation. You have to be specific about what you want, communicate it clearly, monitor execution, and evaluate the results at every step. If you are not doing that, you are not building a product. You are building a liability with a beautiful interface.

I created a memory.md file — a literal employee handbook — to stop the AI from rediscovering the project from scratch at the start of every session. Over time, this focused less on what to build and more on the why behind every architectural decision, and on minimum standards: test your code before releasing it, update non-regression protocols when we validate a new feature, do not change a working integration without flagging it. The AI needed rules, and the rules needed an owner.

This matters enormously for the executive framing of AI. The question is not 'how do we automate this function?' The question is 'who is the adult in the room, and do they know enough to catch the machine when it makes a confident mistake?'

The day the AI tried to commit a felony

In Fintech, the words 'easy' and 'simple' are dangerous. During the build, I hit a broken API integration for Know Your Customer verification. The AI's proposed solution was elegant and completely illegal.

Its logic: since the verification link is unreliable, why not just have the user check a box confirming they are a non-profit? Save it to the database. Move on.

In AI-land, that is a frictionless user experience. In the finance world, that is an unlicensed institution assuming KYC liability — the kind of 'simple fix' that results in a regulatory investigation.

The AI was not malicious. It was trained for the Happy Path. In regulated industries, the business actually lives on the Unhappy Path — the edge cases, the exception handling, the compliance guardrails that exist precisely because someone, somewhere, tried the shortcut and paid for it. The AI had no concept of this. I did. That is the difference.

The broader lesson for executives is this: your downside risk has been fundamentally repriced by AI. The same velocity that lets you ship three iterations in a week also lets you ship three regulatory disasters in a week. The control framework has never mattered more — but it needs to be redesigned to control for the right thing. Not the usual IT project risk, but divergence between probabilistic AI output and the deterministic requirements of your business. 'Mostly compliant' is a fancy word for 'fined.'

The synthetic boardroom: don't trust a single model

One of the more counterintuitive lessons from the build was about AI models themselves. They each have what I would call engineering personalities — systematic biases in how they approach problems. Claude favors elegant, minimal solutions. Gemini tends toward expansiveness but can lose the thread, and is weaker on the code for the app itself. However, Gemini was a saver for cloud infrastructure setup. I used OpenAI’s a bit but ended up finding it average for what I needed. I have not seriously tried other models. The point is that none of them is right all the time.

My response was to stop treating any model as an oracle and start treating them collectively as a vendor panel. When I designed my data architecture, I did not simply accept Claude's proposal. I took it to Gemini and said: tear this apart. Find the security holes. Tell me where it will not scale at ten thousand users.

The most powerful prompt is not 'write this code.' It is 'what am I missing?'

The cross-examination surfaced missing database indexes, overly complex joins, and zero-security table configurations that would have been invisible to anyone who simply accepted the first output. Later, when new model releases arrived, I ran another audit. The results improved again. With zero knowledge and understanding of what the right question is, where the risks are and of the overall business and operating model you want, this will fail spectacularly. You need to know what question to ask and this is a little thing called experience that costs money but is valuable even in the age of AI.

For executives considering AI vendors: you would never build critical infrastructure on a single technology provider. Apply the same discipline to AI. The model layer is not a commodity yet — diversity of perspective is a feature, not a complication. Expect change because the “upgrade” can break your stack so the capability you really need is adaptability. This is not new, but this is going to put even more pressure to see if your organization can bend.

Navigating 2026 with a 2023 map

There is a practical failure mode that no AI demo ever shows you: the training cutoff problem at the level of specific software interfaces.

I spent two hours trying to configure a Firebase authentication loop because the model was confidently directing me toward buttons and menu paths that had not existed since 2023. The underlying logic was sound. The instructions were useless. It is like getting directions from someone who last visited the city three years ago, gives you a restaurant recommendation but does not know it closed 12 months ago.

The fix was not to find a better prompt. It was to change the interaction model. I stopped asking for directions and started using the AI's vision capabilities — feeding it live screenshots of the current interface and asking it to bridge the gap between its training knowledge and the reality on screen. I also started asking specifically for “the latest” or anticipating some of these risks to make sure I would get the freshest information.

The principle generalizes: verify and pivot is more important than prompt and trust. In a world of moving targets — changing APIs, updated SDKs, new regulatory guidance, evolving market conditions — the competitive advantage belongs to organizations that can close the loop between AI output and ground truth quickly. So the reality is that this slows the whole process down because you cannot fully trust the body of knowledge that the AI model has and uses as a standard. You need to challenge this as well, depending on what you are undertaking.

The $50k hostage situation: what corporate DNA actually costs

At the large regulated institutions I have worked in, approving a $50,000 experiment with a six-month payback is not a decision. It is a workstream. You need Third-Party Risk Management to vet a five-person startup as though they were IBM. You need 'socialization.' You need a Steering Committee. You need executive sponsorship. A budget. A cybersecurity risk assessment. You need slide 14 of the TPRM deck to be word-perfect.

I built a functional Fintech application for much less than that. Alone. In ninety days.

This is not primarily a technology story. It is an operating model story. Large regulated corporations are structurally optimized for risk avoidance, not value capture. That was a reasonable trade-off for decades. It is increasingly a catastrophic one.

Three failure modes I observed from the inside:

• The Startup Size Trap — corporations systematically kill the best early-stage technology because the vendor is 'too small to be trusted.' This is amplified by regulation and by procurement processes designed for a different era.
• The Success Lie — in large organizations, every project is officially a success. Frontier technology, including AI, fails sometimes. If your culture cannot tolerate failure, it cannot take technology risk. It can only avoid it.
• The Adoption Abandonment — executives celebrate Go-Live. Nobody celebrates the twelve-month change management slog that determines whether the investment ever produces returns. The AI initiative that never embeds is not an AI failure. It is a leadership failure.

The institutions that are winning right now are not the ones with the biggest AI budgets. They are the ones that have restructured their decision-making to match the speed of the technology — while maintaining the domain expertise to know where the guardrails must stay fixed. To me, these winners should be small-to-medium size companies but if you are an existing business outside of technology, you are likely operating with no technology team and so the challenge becomes how to structure the way forward to make the leap. That is scary for most leaders and difficult to carry forward so most stand still right now.

The verification tax and the real cost of speed

AI makes you ten times faster. It also makes you ten times faster at driving off a cliff.

There is a seductive narrative that AI replaces engineering skill. The experience of this build suggests the opposite. Because AI output is probabilistic — it guesses, with impressive accuracy, most of the time — the speed it provides comes with what I call a Verification Tax. You are no longer paying for construction. You are paying for discipline.

When I built the backend, the AI generated code at remarkable speed. I spent twice as much time auditing its security logic, stress-testing its data model, and checking its assumptions against my knowledge of what a production-grade Fintech system actually requires. Without that discipline, the 'speed' simply accumulates as technical debt — and technical debt in a regulated Fintech environment does not just slow your growth. It can end your operation. AI is not a lateral thinker. It goes deep, not wide. This in effect, for a COO like me, is a problem because it does not think process unless you force it to. This means it can fix something that will break something else downstream and that creates rework.

The critical executive insight here is about risk velocity. The downside risks are not just larger with AI — they materialize faster. A misconfigured testing strategy, for example, can burn through hundreds of dollars of API credits in hours before anyone notices. At enterprise scale, the same dynamic plays out with data exposure, regulatory breach, and reputational damage. The control framework needs to match the velocity of the risk, not the velocity of the old world.

The talent question nobody wants to answer

The most dangerous boardroom conversation happening right now is about headcount. 'Why hire a junior analyst when AI can do it nearly for free?' It is a compelling short-term calculation and a potentially catastrophic long-term one.

If you stop hiring juniors today, you will not have seniors in five years. You are consuming your talent pipeline to protect quarterly margins. I call it Institutional Alzheimer's: if nobody is learning the operational guts of the business because the AI handles the execution, eventually nobody in the building actually understands how the company works. The C-suite will be leading a black box they cannot diagnose and cannot repair.

After this build, my view of ideal hiring has changed substantially. I would not want single-skill specialists. I would want dual-sided profiles: engineers with genuine business acumen, or business operators with real technical credentials — not enough to write production code from scratch, but enough to design a system, evaluate its output, and know when to hit the brakes.

The resume that only lists technical languages — with no business outcomes — is now competing with a tool that does not take lunch breaks and does not ask for equity. Straddle both worlds, or prepare to be disintermediated by someone who does.

Where this ends

KadoPool is live. It works. It celebrates communities, protects privacy, and removes the friction from something people actually want to do for each other. That is the product.

But the build was always also an experiment — a stress test of the AI hype. The conclusion is not that AI is overhyped. It is genuinely transformative. The conclusion is that it reinforces the need for generalist profiles that can straddle technical and business topics to extract its value, as well as mitigate the risks of it being misapplied, where mistakes compound at enormous speed.

The organizations that navigate this transition successfully will be the ones that treat AI not as a cost-reduction exercise and not as a technology project. Separating “business” from “technology” has even less meaning now than it did before. To harness the power of AI to re-design your business and operating model, you need these profiles because they navigate both worlds.