Lessons From Building a Fintech Platform With AI

Eighty-six sessions of building a payment orchestration platform with an AI CTO produced a set of lessons that no textbook covers. Some of these lessons are about fintech specifically. Some are about AI-assisted development. Some are about the unique intersection of both -- building a system that handles real money using a development model that has never been tried at this scale before.

This article captures what worked, what was hard, what surprised us, and what we would tell another team attempting the same thing.

What Worked

Session-by-Session Development

The single most effective practice was the session model itself. Each session had a defined scope, a clear deliverable, and a session log that documented every decision. This produced several benefits:

Accountability. Every feature, every bug fix, every architectural decision is traceable to a specific session. When something breaks, the session log tells you exactly when and why it was introduced.

Resumability. Claude does not have persistent memory across sessions. The session log serves as the handoff document. At the start of each session, Thales provides context from the previous session's log, and Claude picks up exactly where the last session ended.

Velocity tracking. With 86 sessions across 80 days, we know the exact pace. We know which sessions were productive (the December 12 marathon) and which were debugging sessions (WAL race conditions). This data informs how we plan future development.

The session model is not something we invented for AI development. But it works remarkably well with AI because it compensates for the lack of persistent context.

The Provider Adapter Pattern

The decision to use the adapter pattern for payment providers was made in Session 001 and never changed. Every provider -- Stripe, PayPal, Hub2, PawaPay, BUI, PaiementPro -- implements the same BaseProvider interface:

pythonclass BaseProvider(ABC):
    @abstractmethod
    async def create_payment(self, params: PaymentParams) -> PaymentResult: ...

    @abstractmethod
    async def get_payment_status(self, provider_id: str) -> PaymentStatus: ...

    @abstractmethod
    async def verify_webhook(self, body: bytes, headers: dict) -> bool: ...

    @abstractmethod
    async def validate_credentials(self, credentials: dict) -> ValidationResult: ...

This pattern meant that adding a new provider was always the same task: implement four methods. No routing changes, no database changes, no API changes. The adapter pattern is well-known in software engineering, but its value in a fintech context is extraordinary because every payment provider is different in exactly the ways that the adapter abstracts away.

The Unified Payment Format

PAYIN_ORANGE_CI encodes three pieces of information in one string: the operation type (payin), the payment method (Orange Money), and the country (Ivory Coast). This format eliminated an entire class of ambiguity bugs where different parts of the system disagreed about how to identify a payment method.

Aggressive Simplification

The most impactful sessions were not the ones that added features. They were the ones that removed complexity:

In a traditional engineering team, removing features requires consensus building, stakeholder alignment, and deprecation planning. With a CEO+AI CTO model, simplification happens in a single session. This speed of simplification is one of the most underrated advantages of the model.

What Was Hard

Currency Conversion Correctness

Currency handling was the single largest source of bugs in the entire codebase. The issues manifested in every layer:

• Storage format: Major units vs. minor units confusion
• Display format: Which decimal places for which currency
• Provider format: Each provider expects amounts differently
• Cross-currency: Source and destination amount tracking
• Zero-decimal currencies: XOF, JPY -- no sub-units
• Floating-point arithmetic: 5.99 * 100 = 598.99999...

The lesson is not "currency is hard" (everyone knows that). The lesson is: define your currency conventions in a single document before writing any code, and reference that document in every session. We did not do this, and the conventions drifted across sessions until the Big Currency Update (Session 032) forced standardization.

SQLite Limitations at Scale

SQLite served us well for the first 60 sessions. But as we added concurrent webhook handlers, Celery workers, and API request handling, the single-writer limitation became untenable. The WAL race conditions (detailed in article 059) cost approximately 15 hours of debugging time.

The lesson: start with PostgreSQL for any application that will have concurrent writes. The zero-configuration convenience of SQLite is not worth the migration cost later.

Amount Display Precision

The amount display bugs (article 060) persisted for 49 sessions. The root cause was simple (dividing by 100 when you should not), but the manifestation was spread across 50+ files. Every new feature that displayed a monetary amount had a chance of reintroducing the bug.

The lesson: create a single, canonical formatAmount function from day one and use it everywhere. Do not let each component format amounts independently.

What Surprised Us

The December 12 Marathon

Thirteen sessions in one day was not planned. Thales started the day intending to do 3-4 sessions. But the momentum was extraordinary -- each session's output created the foundation for the next session, and stopping felt like wasting that momentum.

The surprise was not the productivity (Claude can generate code indefinitely). The surprise was that the quality held up. The code generated in Session 019 (the 13th session of the day) was as structurally sound as Session 006 (the first). AI does not get tired.

How Fast SDKs Could Be Generated

Building 7 SDKs in a single session (Session 003) felt impossible before we tried it. The key insight: once the API is well-defined, an SDK is a mechanical translation. The same CRUD operations, the same error handling, the same retry logic -- just in a different language. Claude excels at this kind of translation because the patterns are consistent and well-documented.

The Value of Session Logs

We initially treated session logs as record-keeping. Over time, they became the most valuable artifact of the entire project. Session logs serve as:

• Onboarding documents for each new Claude session
• Decision records explaining why each architectural choice was made
• Debugging guides when something breaks months later
• Content for this article series -- every article references specific sessions

Currency Bugs Were the Dominant Bug Category

In 86 sessions, more debugging time was spent on currency-related issues than on any other bug category. Not authentication, not performance, not provider integration -- currency. This was surprising because currency handling seems straightforward (multiply, divide, round). But the interaction between storage format, display format, provider format, and zero-decimal currencies creates a combinatorial explosion of edge cases.

Advice for AI-Assisted Fintech Development

1. Define Financial Conventions Before Coding

Create a document that specifies: - Amount storage format (major units vs. minor units) - Decimal places per currency - How to convert for each provider - How to display to users - How to handle rounding

Reference this document in every session.

2. Start With PostgreSQL

SQLite is tempting for its simplicity. Resist the temptation. PostgreSQL's concurrent write support, strict typing, and MVCC will save you weeks of debugging.

3. Make Transaction Records Immutable

Once a transaction is created, it should never be modified. Create new records (refunds, adjustments) that reference the original. This is not just a best practice -- in many jurisdictions (including OHADA countries), it is a legal requirement.

4. Build the Adapter Pattern From Day One

If you are integrating multiple payment providers, the adapter pattern is non-negotiable. Each provider implements the same interface. New providers are isolated additions, not system-wide changes.

5. Log Everything, But Not Credentials

Log every payment state transition, every webhook received, every routing decision. But mask all API keys, secrets, and tokens in logs. The event history is invaluable for debugging; leaked credentials are catastrophic.

6. Maintain Session Logs

If you are using AI for development, maintain detailed session logs. They compensate for the AI's lack of persistent memory and provide institutional knowledge that no human engineer needs (because they remember) but every AI session requires.

7. Simplify Relentlessly

Every feature has a maintenance cost. Every tier has a decision cost for users. Every configuration option has a documentation cost. Remove complexity with the same urgency that you add features. The best sessions in 0fee.dev's history were the sessions where we deleted code.

8. Conduct Security Audits Early

We audited at Session 054 (63% through the build). We should have audited at Session 030 (35%). Security debt compounds faster than technical debt because the consequences are irreversible (a data breach cannot be patched retroactively).

The CEO+AI CTO Model: An Honest Assessment

The model works. 0fee.dev is proof. But it works differently than a traditional engineering team:

Strengths: - Unlimited engineering throughput (13 sessions in one day) - Perfect consistency across sessions (same patterns, same conventions) - Zero communication overhead (no meetings, no Slack threads) - Instant simplification (no consensus building required)

Weaknesses: - No persistent memory (session logs are essential, not optional) - No independent judgment (the AI does not say "this is a bad idea" unprompted) - No institutional knowledge (every session starts fresh) - Single point of failure (the CEO makes every decision; bad decisions cascade)

The biggest risk is not the AI's capability. It is the CEO's judgment. In a traditional team, a bad architectural decision is caught in code review. In the CEO+AI model, a bad decision is implemented immediately and perfectly. Speed amplifies both good and bad decisions equally.

The mitigation is session logs, security audits, and the willingness to simplify. If a decision is wrong, the session log tells you when it was made. The security audit catches systemic issues. And the simplification ethos ensures that complexity is regularly pruned.

0fee.dev was built in 80 days with zero human engineers. That is the headline. The full story is 86 sessions of decisions, bugs, simplifications, and lessons that no amount of planning could have predicted.

This article is part of the "How We Built 0fee.dev" series. 0fee.dev is a payment orchestrator covering 53+ providers across 200+ countries, built by Juste A. GNIMAVO and Claude from Abidjan with zero human engineers. Follow the series for the complete build story.