The first architectural decision I made on AryaWealth was that it would have no servers.
Not "minimal servers", not "serverless in the AWS Lambda sense" — no servers at all. Portfolio data, banking data, tax calculations, AI context, everything would live on the user's iPhone or iPad in an encrypted SwiftData store. The only network traffic would be to providers the user had explicitly configured: their market data feed, their AI inference, their open banking connection. If I succeeded, there would be no database I controlled, no backend I would need to keep running, and no data of anyone else's that I could lose.
At the time I thought this was mostly a privacy decision. Nine weeks later, with around 137,000 lines of Swift in production-grade beta, I realised it had also been an economic one — in ways I had not fully anticipated.
What follows is a set of notes on what that project actually demonstrated. I'll give them with the caveat I would give any client: this is analytical framing rather than a marketing claim, and it concerns the architecture and its economics rather than any commercial outcome, which depends on many other things.
The architecture, specifically
AryaWealth's data model spans investments, banking, real estate, tax across multiple jurisdictions, asset research, net worth tracking with scenario projection, briefings, alerts, and on-screen annotations — breadth that is comparable to the core transactional model of an institutional wealth platform, delivered as a single-user iOS application.
Three on-device AI surfaces sit on top of it: a conversational analyst, a transaction categoriser backed by Apple Foundation Models, and a note-interpretation pipeline for OCR cleanup. Each operates under structured guardrails covering prompt injection, tiered consent, and cross-model validation for any output that carries a claim. There is a passphrase-encrypted format for peer-to-peer sharing over AirDrop. TLS certificate pinning covers ten domains, with backup pins so that routine certificate rotation doesn't break the app. The test suite runs to around 53,000 lines — a high test-to-source ratio for an application at this stage.
I include this detail for calibration, because the argument that follows rests on the artefact being what I'm describing rather than a prototype wearing the vocabulary of one. What the essay is actually about is the implications of an architecture this broad, built this way.
Why the architecture is unusual
The consumer wealth-management category has, without exception that I have been able to find, adopted a cloud-first default. Every named product I surveyed — across the iOS portfolio trackers, net-worth aggregators, AI-first advisors, budgeting apps with wealth features, and privacy-marketed fintech challengers available as of April 2026 — runs on servers the company operates, holding user financial data in databases the company owns. They vary enormously in product quality and design philosophy, but the underlying architecture is the same. The user's device is a thin client with a local cache; the company ultimately holds the data.
AryaWealth inverts this. The device is the authoritative local store. Servers, where they exist in the user's flow, fall into two categories. Some are services the user pays for directly and configures themselves — their AI provider, their market data feed. Others are the authoritative source for institutional banking or trading data by design. In neither case is there per-user infrastructure on my side that scales with the user base, because there is no infrastructure on my side holding user data at all. An optional stateless Cloudflare Worker relays AI and market data traffic for subscribers who'd rather not manage their own API keys, but it forwards requests without storing, logging, or inspecting portfolio content.
This produces an architectural position — on-device first, zero-server by construction, enterprise-scope schema, real-time external integration with local authority, multi-surface on-device AI, peer-to-peer encrypted sharing, and a free bring-your-own-key tier that is the full product rather than a limited trial — that, on the competitive research I could do, appears to be currently unoccupied in the category.
I want to be careful with that claim. The individual properties exist in various products; it is the combination I haven't been able to locate elsewhere. The intersection may eventually fill in as the pattern becomes visible, but it is empty today, and the forces that have kept it empty — funding models, aggregation dependencies, the gravitational pull of the cloud-first default — will take time to weaken.
The economics that follow
The economic consequence of this architecture is not a percentage improvement over the category. It is a category change.
A cloud-first consumer fintech incurs, by conventional benchmarks, somewhere between five and fifteen US dollars per user per month in infrastructure, aggregator fees, AI inference, and compliance surface, and the figure scales with use. AryaWealth incurs effectively zero per-user cost beyond the App Store's cut. Each additional user brings their own storage (their device), their own compute (their device), their own AI budget (their API key or their own subscription to a third-party provider), and their own open banking connection. My operating cost is structurally independent of my user count.
There is a corresponding inversion on liability. I hold no user financial data. There is no data-subject-request infrastructure I need to build, no breach surface on my side to defend, no service-level obligation to my users for the uptime of their data because their data is on their device and has been the whole time.
I noticed this somewhere around week six. I had been calculating what I would need to charge to break even on a hypothetical user base of a few thousand. The answer was "almost nothing", and the reason was not that I was being clever about pricing. It was that there was almost nothing to pay for. The entire cost column that defines unit economics for the category didn't exist on my balance sheet.
What the timeline actually implies
The build itself — three months of evenings alongside my consulting work, at a total capital outlay of under NZD $3,000 — is the part that invites the most scepticism, and I'd rather address it directly than dress it up.
The honest answer is that this is not possible without an AI coding partner, and it is not meaningfully possible with one either unless the human brings specification discipline as the primary contribution. The arithmetic is not subtle. The industry rule of thumb is that typing is roughly ten to twenty percent of engineering time, with the remainder going to design, reading, debugging, and rework. A codebase of this size, produced under that ratio, is four to eight thousand hours of conventional human work. Compressed into two hundred-odd hours of evenings, that is a 20- to 40-fold compression. No human nervous system produces that by trying harder.
What the AI did was provide implementation throughput. What I did was specify what was to be built: the entities, the contracts, the acceptance criteria, the non-goals. The ratio of effort was roughly ninety percent mine on design, architecture, review, and integration, and a much smaller share on code the model then generated against those specifications. The architecture — the layering conventions, the service protocols, the centralised key registries, the three-beat plan/generate/review rhythm — is what made each specification short enough to be unambiguous, and therefore short enough to be generated correctly on the first attempt.
Solo developers building impressive software quickly is not new; the history of the field has plenty of examples, many of them more impressive than this. What I think is new, or at least very rare, is the simultaneity — the combination of breadth, depth, velocity, and architectural restraint on a single artefact, by one person, in this span of time. That's a more defensible claim than "unprecedented", and it's the one I'd stand behind.
What I take from it
On the evidence, the capital requirements the category has treated as inherent to consumer fintech are in substantial part the cost of a specific architectural choice, not of the product problem itself. The alternative has been technically viable for years; it has been absent from the market because the forces that shape product development have selected against it, not because it didn't work. AryaWealth is an existence proof that it does.
Whether AryaWealth itself becomes a commercial success is a separate question, governed by distribution, positioning, and partnerships that architectural and economic superiority do not on their own resolve. Those are the honest boundaries of what I think this work demonstrates.
The first decision was that it would have no servers. The rest of the project was an exercise in finding out what that implied.