Introduction
A fractional CTO earns their fee in the gap between what a development vendor reports and what the code does. This case study covers one engagement where I filled that role for a German fintech startup whose product was built by an external software house. If you are a founder paying an agency to build your product, or you are deciding whether you need senior technical oversight at all, this is what the work looks like from the inside.
I am writing it without the client's name or the vendor's name. The details that matter are the decisions, the evidence behind them, and the mistakes we caught before customers did. Every number below comes from the project's own documents, code, or measurements.
The Project: a German Fintech SaaS With an External Build Team
The client is a founder building a multi-tenant SaaS for German small and mid-sized companies. The product combines invoicing that follows German tax rules, e-invoicing in the ZUGFeRD and XRechnung formats, bank account sync through a licensed bank-data aggregator, AI extraction of invoices and contracts, cash-flow forecasting, and an AI assistant that answers questions about the company's finances.
The stack runs entirely in the client's AWS account in Frankfurt: a NestJS API and Next.js web app on ECS Fargate, Aurora PostgreSQL with Prisma, SQS for document processing, Cognito for login, Textract for OCR and Amazon Bedrock for the language models. Infrastructure is Terraform, and deployments run through Bitbucket Pipelines with OIDC, so there are no static cloud keys in CI.
The founder is not a developer. The build was contracted to an external team on a tight MVP plan. Our role was CTO as a service: review, validate and challenge what the vendor produced, and turn technical questions into decisions the founder could make with numbers on the table.
How we split responsibility
We kept three roles separate from day one, and that separation shaped everything that followed. The founder decides scope, budget, launch date and risk appetite, and we bring options with costs, never a commitment on the founder's behalf. The vendor owns implementation choices, as long as they hold up to review.
The fractional CTO verifies. Every claim of "done" stays a claim until it is checked against code, a running environment or a measurement. That one rule turned out to be the most valuable part of the engagement.
Why "Done" Became the Most Expensive Word in the Project
The single most useful habit we brought was treating status reports as claims, not facts. Vendor reports are written by people under delivery pressure, and they describe intent as often as they describe reality. A founder without a technical reviewer has no way to tell the two apart until users find out first.
The pattern showed up early. A forecasting feature was reported as complete in one monthly report. A month later, the same team's own working file listed gaps in it: partially paid invoices were forecast at their full amount instead of the open balance, which overstates expected cash. A cash-flow product that overstates cash is not "complete" in any sense that matters to the buyer.
Quality assurance was the second blind spot. Test case creation was part of the agreed QA scope, yet when we asked for the test cases, there was no test case repository to hand over. Without written test cases there is no repeatable release check, which explains why an acceptance build arrived with basic flows broken: users could not be invited and document extraction failed.
The evidence rule we applied
From that point we labelled every finding by the strength of its evidence. Something the vendor wrote themselves was the strongest class. Something we reproduced against source code we held came next. Something we read in code but had not run was marked as arguable, and anything we believed but could not prove was excluded from any conversation with the vendor. That rule kept every escalation factual, and it stopped provable problems from being dismissed as negotiating posture.
What an Independent Code Review Found (and What It Did Not)
Once we had access to the source, we ran a static review of the full application. The headline verdict surprised the founder: the code was competent. Type discipline was better than in most commercial codebases, the architecture was sound, and tenant isolation was implemented correctly almost everywhere. This was not a rescue situation, and saying so mattered as much as the defects did.
The defects were few and sat exactly where a bookkeeping product cannot afford them. Three were critical:
- Duplicate bank transactions. The table for bank transactions had no unique constraint on the aggregator's transaction ID, and the sync code did a read followed by a write. Amazon SQS standard queues deliver every message at least once, sometimes twice, so two deliveries of the same sync could both insert the same payment. A single EUR 4,200 payment would then appear twice in the ledger.
- Money math in floating point. Payment reconciliation converted database decimals into JavaScript numbers, summed them, and wrote the result back. In JavaScript, three transactions of 1234.10, 5678.20 and 999.70 add up to 7911.999999999999, not 7912.00, so a fully paid invoice stays partly paid with a residue no user action can clear.
- Cross-tenant bank account changes. One update method filtered by account ID alone, without the organisation. A user in one company who knew another company's account ID could modify or delete it, including the live bank connection.
The first two need no attacker at all. They corrupt financial records under normal operation, which makes them more commercially dangerous than the security finding. All three had small fixes: a one-line unique constraint with an atomic upsert, decimal arithmetic end to end, and an organisation filter that was already in scope at both call sites. If you want a broader view of which code quality signals predict problems like these, our guide to code quality metrics for fintech teams covers the measurable side.
Choosing the AI Model on Data, Not Deadline Pressure
Document extraction was the feature the founder cared about most, and it was the first one to fail in a live demo. The founder uploaded real invoices to the test build and got back blank fields: supplier "Unknown", amount zero. The vendor then presented a cost estimate of USD 0.08 per document, which the founder considered too high for the planned price point.
We refused to pick a model until the vendor produced per-document cost and accuracy data on real files. That pushback triggered a proper root-cause investigation, and the findings changed the project. The model had never been the problem. The live pipeline used Textract's premium analysis mode when plain text detection was enough, which made OCR 43 times more expensive than needed. It also sent the model raw OCR geometry instead of clean reading-order text, about 95,000 tokens per page where 3,000 would do.
| Configuration, measured on 85 real documents | Cost per document |
|---|---|
| Live build before the investigation | USD 0.35 |
| Estimate first shown to the founder | USD 0.08 |
| Basic OCR plus clean text input, same model | USD 0.015 |
| Same, with a smaller Claude model | USD 0.006 |
The fixes cut the cost per document by about 98 percent against the live build, with no change of OCR engine. A separate fix, rasterising every PDF before OCR, took page-level OCR success from a baseline where only 33 of 85 documents went through to 406 of 407 pages. At 50,000 documents a month, the difference between the live build and the recommended setup is USD 17,500 against USD 300.
What we checked before trusting the accuracy numbers
The extraction proof of concept reported 96 to 98 percent field accuracy on invoices and 83 to 91 percent on contracts, against a hand-labelled set of 19 documents. We accepted the invoice figures as a strong signal and flagged the method: part of the reference data for non-financial fields had been reconciled against one model's own output, so it measured agreement more than independent correctness. Financial fields lean on human review by design, and every assumed value, such as a default 19 percent VAT rate, is flagged for the user to confirm.
We also insisted that each AI use case gets its own model setting: document extraction, forecasting and the chat assistant. One global model for the whole product would force the most expensive choice onto the cheapest task. That separation later made it simple to move extraction to a smaller Claude model on Bedrock in the EU region, with an open-weight Gemma model as a fallback, without touching the assistant.
Build vs Buy: Keeping E-Invoicing Inside the Client's AWS Account
Germany made e-invoicing a hard requirement for this product. Every German business has had to be able to receive e-invoices since January 2025, issuing becomes mandatory from 2027 for companies above EUR 800,000 in prior-year turnover, and from 2028 for everyone else. A finance tool for German SMEs without it would not sell.
The founder asked for a recommendation: a hosted e-invoicing API or our own implementation. The founder's selection criterion was the security posture of the provider, and a hosted service failed it on principle. Sending every customer's invoice data, including names, addresses, amounts and VAT IDs, to a third party needs a processing agreement under GDPR, sub-processor audits and a permanent dependency.
We recommended self-hosting on two mature open-source libraries: node-zugferd (MIT) to issue ZUGFeRD invoices from Node, and Mustangproject (Apache 2.0) to read and validate both ZUGFeRD and XRechnung. The data never leaves the client's AWS account. The spike results were clear: PDF/A-3b compliance with 52,762 checks and zero failures, 82 EN 16931 business rules with zero failures, and validation at roughly EUR 0.0002 per run.
The cost we put in writing
Build vs buy recommendations often hide the downside, so we put it on the first page. ZUGFeRD publishes new versions and the German standards body updates its validation rules, and a SaaS provider would absorb that work. Self-hosting makes format updates a recurring maintenance cost. The founder signed off knowing that trade, which is the point of the exercise.
Two architecture rules made the build cheaper. The invoice data model was kept format-neutral, so adding XRechnung issuing later is a second serialiser, not a second project. And the per-rate VAT breakdown that German law requires on the printed invoice was built once and reused for the e-invoice, instead of being solved twice.
The Security Gate Before Launch
Before any external customer touches a product that holds bank data, a fractional CTO has to say plainly whether it is safe to launch. We ran a full security review of the application, the AWS environment and the marketing site. It found 8 critical and 27 high findings, and the summary for the founder opened with the good news, because it was true: login is handled by AWS rather than custom password storage, tenant separation was verified line by line, and storage is encrypted and private.
Three things stood between the product and a launch we could defend to a customer, a bank partner or a regulator. Two exploitable bugs, one around bank data and one around company invitations. No audit trail, so nobody could say who accessed what, which German data-protection law expects you to answer. And the legal side of GDPR, including data export, account deletion and a retention policy, had not been built.
Turning findings into founder decisions
A list of 35 findings is not something a founder can act on. We turned it into eight decisions, each with a recommendation, a monthly cost and a deadline:
- Switch on AWS audit logging and threat detection, roughly EUR 50 to 150 a month across environments.
- Make two-factor login mandatory first for companies that connect a bank account, then for everyone within three months.
- Set the invoice archive to the 8-year retention period that German law requires, instead of the 30 days configured at the time.
- Create a separate AWS account for production before production exists, when it costs two days instead of a migration.
- Book an independent penetration test after the first fixes, so the report becomes a sales asset for larger customers.
Access hygiene belonged on the same list. An earlier audit of the AWS account found four personal IAM users belonging to external developers, holding five long-lived access keys between them, one with full administrator rights. The deployment pipeline already used OIDC, so those keys were pure risk. We removed them and kept a backup of every policy as an audit record. If you work with any outside team, check who holds keys to your production account today, not when something goes wrong.
Matt Sadowski
CEO of Mobile Reality
Executive Tech Leadership with Fractional CTO as a Service
Drive strategic growth and innovation with expert technology leadership—personally delivered by Matt and Marcin, Mobile Reality Leadership.
- Access high-impact CTO-level expertise without the cost of a full-time hire.
- Personalized technology strategy, product roadmap, and architecture guidance.
- Specialized in scaling SaaS platforms, AI-powered solutions, and blockchain products.
- Hands-on leadership in team structuring, vendor selection, and cloud infrastructure (AWS & GCP).
- Ideal for startups, scale-ups, and non-tech founders seeking tech excellence and clarity.
- Deep technical know-how paired with business acumen, grounded in 10+ years of software delivery and company growth.
What Founders Should Demand From Any Outsourced Team
Most of what we did on this project transfers to any founder working with an agency. Whether you hire a fractional CTO or not, these are the controls we would put in place on day one:
- Source code and environment access from the first sprint. You cannot verify what you cannot see, and access negotiated late becomes leverage against you.
- A written test case repository, not only "manual testing". It is the only thing that makes a release check repeatable.
- Cost and accuracy measured on your own documents. An estimate built on vendor defaults hides configuration mistakes like the 43x OCR markup.
- Every "additional scope" request classified in writing, as either a fix to agreed scope or new work with an estimate, before budget is approved.
- Architecture decisions recorded as ADRs. This project ended up with 16 of them, and they answered most "why is it like this" questions without a meeting.
Our longer guide on fintech development outsourcing for executives covers vendor selection. This list covers what happens after you sign. For the earlier stage, when you are still scoping, see how we approach building an MVP for fintech and banking.
Honest limits of this case study
At the time of writing, in October 2026, the product is feature-complete on the test environment and moving through the security work toward its production release. The bank-data aggregator has granted production access. We are not claiming launch metrics, revenue or user numbers, because they do not exist yet, and a case study that invents them is worth less than one that admits it.
Not every startup needs this level of oversight either. If your build is small, your vendor is one you have worked with for years, and no regulated data is involved, a quarterly review may be enough. The case for continuous fractional CTO services grows with the amount of money, personal data and legal obligation that the product carries.
Conclusion
A fractional CTO does not replace the build team. On this project, the role was to make sure the founder made every important decision on evidence instead of on a status report or a deadline. The return showed up in the specifics: defects that would have corrupted ledgers, an AI cost that dropped by 98 percent, and a launch gate the founder can explain to a bank partner.
- Treat every vendor "done" as a claim until code, a running environment or a measurement confirms it.
- In fintech, the most dangerous bugs often need no attacker: duplicate transactions and floating-point money math corrupt data under normal load.
- Demand AI cost and accuracy numbers measured on your own documents before you choose a model.
- Build vs buy is a decision about data ownership and maintenance cost, not only price, so write the downside down.
- Turn security findings into a short list of founder decisions with costs and deadlines, not a 35-item report.
If you are paying an external team to build a product and nobody on your side can read the code, that is the gap to close first. Our fractional CTO guide explains how the engagement works, and our article on outsourced CTO services compares it with the other options.
Frequently Asked Questions
What does a fractional CTO actually do when overseeing an outsourced development team?
A fractional CTO bridges the technical gap between a non-technical founder and an external agency, providing senior oversight without the cost of a full-time executive hire. Rather than managing daily tickets or replacing the build team, the fractional CTO independently audits code, validates vendor claims, and converts complex technical risks into clear business decisions with costs and deadlines attached. Their primary responsibility is holding external teams accountable to verifiable evidence rather than self-reported delivery status.
Why should founders treat an agency's "done" status reports as claims rather than facts?
Agency status reports are frequently written under delivery pressure and tend to describe feature intent rather than verified implementation. Without independent technical review, flawed business logic—such as cash-flow forecasting calculating full invoice amounts instead of open balances—remains invisible until end users encounter it. Treating "done" as an unverified claim forces the vendor to prove functionality against running code, written test repositories, and measurable acceptance criteria.
How does independent technical oversight prevent runaway AI and cloud infrastructure costs?
External development teams often default to expensive managed presets and unoptimized pipelines that unnecessarily inflate token counts and cloud bills. In this fintech project, testing OCR performance on real documents revealed that raw geometry data and premium analysis modes created a massive 43x markup over basic text extraction. Refactoring the pipeline to supply clean reading-order text to right-sized models cut per-document AI processing costs by approximately 98% while improving extraction success.
What technical and security risks are most commonly missed in outsourced fintech products?
The most dangerous fintech bugs corrupt ledgers under normal operation, such as floating-point rounding errors in reconciliation or duplicate transactions caused by standard queue retries lacking unique constraints. Agencies also frequently overlook regulatory obligations, such as multi-tenant isolation safeguards, audit trails, and legal data retention rules. Additionally, infrastructure audits routinely uncover security hygiene issues like long-lived personal developer IAM keys remaining active inside production cloud environments.
Which controls should founders demand from an external software agency on day one?
Founders should mandate full repository and cloud environment access from the very first sprint so work can be verified in real time. Teams must maintain a written test case repository for repeatable quality assurance and record foundational technical choices in Architecture Decision Records (ADRs). Finally, every scope change should be classified in writing as either a defect fix or billable new work before additional budget is approved.
