Everyone has a take on whether AI is going to eat SaaS. The optimists say AI agents will replace entire software categories — that any workflow a platform currently handles can be replicated by a well-prompted model with the right tools attached. The skeptics say software is more than functionality — it's trust, compliance history, a decade of edge cases hardened through production use, and institutional relationships that don't transfer. Both sides are generating enormous amounts of content. Neither side seemed to be running the actual experiment. So I ran it. I've spent 6+ years building a specific category of software: white-label mobile platforms for B2B2C use cases. Financial institutions, gaming operators, hospitality companies — organizations that need consumer-facing digital products but don't want to build and maintain the underlying infrastructure themselves. They license a platform, put their brand on it, and their customers never see the vendor. Underneath, the same core system powers dozens or hundreds of different clients, each with their own configuration, their own regulatory requirements, their own integration stack. The business model matters for understanding the threat — so it's worth explaining what these platforms actually do before getting into what I found. What white-label platforms actually are A white-label banking platform doesn't just display account balances. It connects to a core banking system that holds the actual ledger. It connects to a KYC/AML provider for identity verification. A notification platform. A card processor. A bill pay provider. A remote deposit vendor. A data aggregator. An open banking layer. Each of those connections is a contract — an API schema, an integration specification, a set of behaviors the platform has to implement correctly to make the whole thing work. Historically, that's where the value lived. Not in the UI. Not even really in the product logic. In knowing how to stitch all of those services together into something coherent that a financial institution could deploy, brand, and put in front of their members without it falling apart. The implementation partners who lived in that space — systems integrators, professional services teams, platform vendors themselves — built their businesses on that stitching knowledge. The schemas, the integration contracts, the tribal knowledge about which core banking system behaves how under which conditions. That's the moat. That's what I wanted to test. What I actually did I built a digital banking platform from scratch. Consumer banking, business banking, FI administration, compliance scaffolding, public website, CMS, A/B testing framework. The full surface area of what a white-label platform ships. I was watching TV for a good chunk of it. That's not a throwaway line. That's the most honest description of the methodology. I was on the couch. I would fire off short questions between whatever I was watching. "Find other bill pay providers." "What cores should I integrate with to go to market internationally? What markets?" "How do I make it easier for a new developer to onboard?" The kind of half-formed questions you'd scribble on a sticky note. Not structured prompts. Not carefully engineered instructions. Just the way I think out loud when I'm working through a problem. I didn't write a single product requirements document. I didn't produce design specifications. I established a domain-driven architecture at the start — bounded contexts, clear separation between the core banking primitives and the surrounding service layers — and used that as the directional frame. Then I pointed AI at vendor documentation and said go. I pointed it at Braze's docs and said build the notification integration. I asked it to reason from inside domain functions, not just implement against a spec. I ran parallel agents across workstreams rather than working sequentially. I also asked what it would take to enter adjacent markets. It came back with a plan I hadn't asked for. Competitive positioning, market sequencing, the works. I hadn't prompted for any of it specifically. The whole thing took a week. But here's what the TV-watching obscures If you read that and thought "I could do this" — maybe. But probably not yet. And the gap isn't technical. AI has no memory. Every session starts fresh. It doesn't remember that you rejected a particular approach and why. It doesn't remember the architectural debate that led to the adapter pattern. It will confidently re-suggest the thing you already ruled out. It will re-introduce the pattern you already refactored away. You are the persistent memory layer. If you don't carry the context — in your head, in a living document, somewhere — it's gone. Early on I had AI generate the README and architecture documentation — not as an afterthought, but as infrastructure. As the project grew, those documents became the context I fed back in to keep it oriented. The MDs were the memory. Without them the project would have drifted beyond recovery. A less experienced person lets the project get big first and then tries to document it. By then the AI has no idea what decisions were made or why, and what you produce is a reconstruction, not a guide. You have to build the memory layer early, while the decisions are still clean. There's also the context window problem — and this one is insidious because it doesn't announce itself. Here's what actually happened repeatedly: I'd point AI at a substantial new feature. It would commit fully, build extensively, and arrive at the end of the session having consumed most of the available context. Test coverage? There was no runway left for it. Not because AI deprioritized testing — because the context window was gone. The feature had spent it. What you get at the end is a working feature and a test suite that's nowhere near what it should be, and the next session starts fresh with no memory of what just happened or why the coverage is thin. My commit history reflects this honestly. There are more commits in that repository than there should be. Some of that is me watching TV. Some of it is AI building ambitiously into an empty context window while I wasn't managing the session budget. The discipline this requires is something nobody talks about: checkpoint before you're out of runway. Explicitly scope what a session is responsible for — feature build OR test coverage, not both if the feature is large. Start a fresh session specifically for tests after the feature lands, and feed it the right context to understand what it's covering. Treat the context window as a finite resource with a budget, not an infinite conversation. And beyond the context window, there's the broader SDLC. AI will not remind you that you need a testing strategy. It will not flag that your CI/CD pipeline has gaps. It will not ask whether you've thought about how a developer deploys this in production. You have to know to ask. You have to know when to stop building and run the documentation loop. When to trigger a refactor. When to ask it to critique its own output from the perspective of someone onboarding for the first time. I knew to ask those things because I've lived that process enough times that it's internalized. I wasn't consciously running an SDLC checklist. I was watching TV. But when it mattered, I knew what question to ask next. That's not nothing. That's sixteen years. The thing I didn't do that would have made this better If I'd formalized agent personas — a dedicated architecture reviewer, an SDLC guardian, a security auditor, a documentation writer, each with defined skills and scope — the whole process would have been more efficient. Less context drift. Fewer shiny object detours. Cleaner output. That's essentially a properly staffed team modeled in AI. Specialized roles, defined handoffs, persistent context per domain. But I was one person on a couch. The overhead of building that scaffolding for a solo experiment is its own kind of distraction. I would have spent days architecting the agent team and never shipped the platform. The persona framework matters if you're doing this seriously, at scale, with real delivery commitments. For a one-person experiment watching TV — I shipped anyway. Both things are instructive. Where it actually broke down Here is the finding that reframed everything I thought I understood about where these platforms derive their value. AI did not struggle with complexity. It struggled with information access. Every integration where the vendor had published documentation — notification platforms, mobile deposit providers, open banking specs, ISO 20022 message formats — AI consumed the contract and built. Not always perfectly, but correctly enough to work from and iterate on. The integration became a documentation consumption problem. AI is extremely good at that problem. Every integration where the schema was proprietary — closed core banking APIs, undocumented KYC/AML vendor formats, integration contracts that live inside NDAs and implementation guides — the process stalled. I was hunting for documentation. Reconstructing interfaces from partial sources. Doing the work that has historically justified entire implementation teams and multi-month project timelines. That boundary is the actual finding. The moat was never the software The conventional AI-eats-SaaS argument focuses on functionality — AI can replicate what the software does, therefore the software is threatened. That framing misses the real question. What this experiment demonstrated is that AI replicates functionality trivially when documentation is public. The constraint isn't capability — it's information asymmetry. The moat protecting legacy white-label platforms isn't architectural sophistication or accumulated domain logic. It's the closed ecosystem of schemas, API contracts, and integration specifications that aren't published anywhere. That live inside sales relationships, implementation agreements, and tribal knowledge accumulated over years of production deployments. The moment a vendor publishes clean documentation, that portion of the moat is gone. Anyone with a structured domain model and an afternoon — or a couch and a TV — can build the integration. The corollary is uncomfortable for anyone in the implementation business: the pure connectivity layer is commoditizing faster than the pricing reflects. Where documentation is public, the stitching is already gone as a value driver. Where it isn't, the clock is running as open banking mandates push disclosure and vendors standardize their APIs to compete. What the implementation partner has to become This isn't an argument that implementation partners disappear. It's an argument about where the work has to move. AI can consume documentation and build integrations. It cannot determine which integrations matter for a specific institution's strategy. It cannot assess regulatory exposure before the architecture is committed. It cannot establish the testing discipline that makes autonomous execution trustworthy. It cannot design the governance layer above the automation. It cannot recognize when the plan it generated is confidently wrong. It cannot keep track of what you decided last Tuesday and why. The guardrails, the judgment, the prioritization, the context management — none of that is automated. What's being automated is the execution layer that used to be the deliverable. The implementation partner who survives this moves up the stack. Not integration delivery — strategic integration selection. Not hosting — architectural governance. Not connecting the services — knowing which schemas to go find, understanding the regulatory implications of how you connect them, and building the framework that makes the whole thing trustworthy at scale. Value-add work. Or commodity pricing. Those are the two options. There isn't a third. What I ended up with The output is called Fiducia. Multi-tenant digital banking platform for credit unions and community banks. MIT licensed. Live on GitHub. Consumer banking with the full product surface — accounts, loans, cards, bill pay, remote deposit, open banking consent management. Business banking with AI-powered accounts payable, smart cash sweeps, just-in-time approval workflows, liquidity forecasting, and treasury vaults across four providers. FI administration, compliance scaffolding mapped to SOC 2 and FFIEC controls, and a core banking simulator that mocks three real core systems — CU*Answers, Symitar, and Fineract — with chaos engineering built in. 180+ API endpoints. 23 adapter domains. I built a competitive table against the major incumbents in the space. Fiducia ships capabilities some of those platforms don't have at all — AI invoice processing, just-in-time permissions, autonomous execution governance, an open-source core simulator. It also lacks years of production hardening, regulatory certification, and the institutional relationships that make enterprise sales possible. That's an honest accounting and I'm not trying to obscure it. What it demonstrates is specific: one person, on a couch, watching TV, asking short lazy questions, with enough product and SDLC experience internalized to keep it oriented, produced architectural output at a scope that would have required a coordinated team and a multi-quarter roadmap not long ago. The economics of what sits between a product vision and a working platform have changed. The question isn't whether that's true. The question is how fast everyone else catches up to what that actually means. The code is at github.com/danweis07/Fiducia. Fork it. Break it. Find everything that's wrong with it. You be the judge.
