Why building privacy-first is finally practical

Descodify is my third fintech startup. The first two taught me patterns I thought were fixed: how you structure a product, how you think about compliance, and what it costs to ship fast. The third forced me to re-examine almost all of them, because it's the first one I've built in what I'd genuinely call the agentic era.

Building software in 2026 is faster and more capable than it's ever been. The range of what a small team can ship has expanded dramatically. But I'll be honest about the other side of that: in some ways it's harder to get right. Good architecture and high quality take more deliberate discipline now, not less, because the tools that help you move fast will also help you move fast in the wrong direction. In fintech that discipline isn't optional. Descodify holds sensitive data. Your invoices, your NIF, your income month by month, eventually your whole IRS filing. Agents don't lower the quality bar; you still have to enforce it.

One assumption that didn't survive the re-examination was a tradeoff I'd taken for granted across the previous two products. If you want to ship fast, you assemble the product from other people's services. One for analytics, one for error tracking, one for email, one for payments, one for every monitoring and compliance function you don't feel like writing yourself. The list grows quickly. And each entry is another company touching your users' data, another jurisdiction to think about, another business whose interests are not quite the same as yours.

The privacy-first alternative was slower almost by definition. You build instead of buy. You run your own servers instead of spinning up AWS. For a solo founder, the math usually didn't work.

Infrastructure is where this shift shows up most concretely. You no longer need the big cloud providers. An EU VPS is simpler, and with agentic devops you can stand up a redundant, high-standard setup almost as easily as before, but this time in the EU, under EU law, with full control over the data and its jurisdiction. Almost as easily. Not identically, not effortlessly. The work is real. But the gap between "responsible choice" and "practical choice" has narrowed enough to cross.

That shift wasn't luck. Two things drove it.

The previous post explained the why behind keeping Descodify's data under EU law. This one is about why that turned out to be practical.

The two things that broke the tradeoff

First: EU suppliers finally matured. For most of the last decade, "use the European option" was a compromise. The European payment processor, the European email provider, the European host. Good enough, maybe, but usually more friction and fewer features than the American default. That gap has genuinely closed in the last few years. The tools I use for payments, email delivery, and hosting are not compromises. They're the right choices on their own terms, and they happen to keep data under European law.

Second: agentic tooling collapsed the cost of building it yourself. This one took me longer to fully appreciate. The monitoring, compliance, competitive-intelligence, and security layers you used to have to buy as SaaS subscriptions, you can now build and run in-house without the old development-time penalty. An error tracker, a legal-pages monitor, an SEO agent, a competitor-watch agent. These used to be a collection of specialist tools, each with its own account and data processing agreement. Now they're software I run on European infrastructure, produced by the same agentic workflow I use for everything else.

Together, these two changes mean that for the first time you can build genuinely privacy-first without paying a speed penalty that makes it impractical for a small team. I didn't expect that conclusion when I started. I arrived at it because the evidence kept pointing that way.

What runs Descodify, and what we chose instead

Job	What we use	What most teams pay for
Payments	Mollie (NL)	Stripe (US)
Website analytics	Umami, self-hosted	Google Analytics
Hosting	Hetzner (Germany)	AWS / Google Cloud / Azure
Email delivery	AhaSend (NL)	Resend (US)
Error tracking	In-house agent	Sentry
Competitor monitoring	In-house agent	Crayon / Klue
Legal pages (privacy, terms, GDPR)	In-house agent	Termly / iubenda
SEO monitoring	In-house agent	Ahrefs / Semrush
Marketing content	In-house agent	Jasper / Copy.ai
Security monitoring	In-house agent	Snyk / Semgrep

The table shows the thesis directly: a handful of EU suppliers for the things that need an outside company, and in-house agents for the monitoring and compliance layer that would otherwise be a SaaS subscription. No Google Analytics, no Mailchimp or Customer.io, no American infrastructure.

Payments: Mollie instead of Stripe

Stripe is the obvious choice for a new product. The documentation is excellent, the developer experience is genuinely good, and it works everywhere. For most founders it's a 30-minute integration and done.

The problem is jurisdiction. Stripe is an American company, and a payment processor holds real financial data: billing amounts, payment method details, billing frequency, the whole transaction history. For a product built around the idea that your fiscal data stays under European law, running payments through a US company felt like a contradiction I couldn't paper over.

Mollie is Dutch, founded in Amsterdam, regulated under Dutch and European financial law. The integration is also good. The documentation is solid. Most of the things Stripe makes easy, Mollie also makes easy, and a few things I expected to be harder were actually fine.

One question that comes up: why Mollie (a payment service provider) rather than something like Paddle or Lemon Squeezy (a merchant of record)?

The distinction matters. A payment service provider moves the money. You remain the seller. VAT, invoicing, tax compliance are your responsibility. A merchant of record becomes the legal reseller on your behalf, handling VAT and invoicing for you, in exchange for a noticeably higher cut of each transaction.

For an early-stage product at Descodify's current scale, the merchant-of-record premium isn't worth it. But there's a second reason, and it's the more interesting one: VAT compliance and certified invoicing is exactly what Descodify does. Handing that to a merchant of record would mean outsourcing the one thing we're built to be experts at.

So we eat our own cooking. Every sale Descodify makes is invoiced through Descodify itself, running through the same certified-invoice engine our customers use. When a customer subscribes, the invoice they receive is generated by the same system they're paying for. That's not just a nice story for a blog post. It means every edge case the invoicing engine hits in production, we hit it first on our own transactions.

Analytics: Umami instead of Google Analytics

This one is less about jurisdiction and more about principle. A product built for people who want to understand where their data goes, running Google Analytics on every page, felt wrong in a way that was hard to ignore. Google Analytics sends behavioral data about your users to an advertising company. That company's product is building a picture of people across the web.

Umami is open source and self-hosted, running on the same European servers as everything else. It collects no personal data, requires no cookie consent banner, and the data stays inside the system. There's no black box I'm handing data to.

What I gave up: Google Analytics is more powerful on raw feature set. Multi-channel attribution, cohort analysis, the full audience intelligence layer. Umami is simpler and tells me what I actually need to know: which pages people read, where they come from, what they do on the site.

Hosting: Hetzner instead of a US cloud

This is where the thesis gets its clearest proof point.

The conventional argument against EU self-hosting is that it's too hard. AWS and Google Cloud turn difficult problems into checkboxes. Scaling under load, redundancy across machines, offsite backups, all of it. On your own servers, the argument goes, it's all manual work, and a small team can't absorb that.

Two things wrong with that argument now. First, Hetzner is not a bare VPS. It has its own load-balancing and scaling options in the portfolio. The gap between Hetzner and a major cloud is smaller than its reputation suggests, and it keeps shrinking as the European hosting market matures. Second, and more important: agents now help set up and manage infrastructure. Infrastructure-as-code that used to be a specialist's slow job is now something you work through with an agent. The setup and ops work that felt like a ceiling for a solo founder is not what it was.

I said this in the previous post and I'll say it again here: there is still real work involved. Scaling under load, redundancy, offsite backups, all of it takes deliberate effort instead of a settings page. None of it is unsolvable. But it's exactly the kind of work that erodes fastest as agentic tooling matures. The EU self-hosting tradeoff is eroding in real time, and Hetzner is a German company (Hetzner Online GmbH, based in Nuremberg and Falkenstein) under German and European law, with no American parent company who can be compelled to reach in.

The previous post goes into more detail on why a European AWS region doesn't solve the jurisdiction problem, and why where the hardware sits matters less than who controls the company.

Email: AhaSend instead of Resend

Transactional email isn't something users think about. But the email provider sees everything that goes through it: magic-link login emails, deadline reminders with account context, billing notices, the IRS analysis emails that go out when someone uploads their income statement. The transactional email provider sees it all.

Resend is American. It's well-designed and the developer experience is good, but it's subject to the same jurisdiction issue as Stripe and the rest. AhaSend is a Dutch transactional email provider, and we moved to it in both dev and production.

Email is high-stakes: every authentication email, every billing notice, every deadline reminder runs through it. So I checked deliverability carefully before flipping. AhaSend delivered. That's a committed switch, not a trial.

The agent fleet: in-house instead of a SaaS stack

This is where the thesis shows up most clearly.

Error tracking is the narrow version. The obvious tool is Sentry. It's good. It catches exceptions, groups them, tells you what went wrong and where, shows frequency and trends. The product is solid. The company is American. I built my own error tracker instead. It runs as an agent that watches production logs, groups and fingerprints new errors, surfaces them in the daily brief, and tracks whether they're getting resolved. So far that's Sentry territory.

The part that isn't: when the agent spots a new error, it doesn't just surface it. It opens a pull request with a proposed fix. That's the step Sentry doesn't take. Monitoring tools tell you what broke. This one proposes the patch.

I review where it's needed: the autonomous fixes, and anything that touches a sensitive part of the app. What's surprised me is how rarely I touch them. I honestly can't remember the last time I changed one before merging it. In practice it's close to autonomous already, and for now I keep myself in the loop anyway. That isn't loose review. It's that the controls run while the code is being written, not just at the end. The same layers of gates, tests, and QA checks run throughout, so by the time a change reaches review it has already been cleaned and tested several times over.

It's just a matter of time before the high-confidence fixes go straight to production without me in the loop. But this is fintech, and that changes things. There will always have to be several layers of tests and gates here. The business logic and the tax rules have to stay correct, and they have to stay tied to the legislation they are based on, which is exactly what another one of these agents is watching. The sensitive parts of the architecture need that scrutiny even more: security, authentication, authorization. Loosen the checks there and quality drops fast. So more autonomy doesn't mean fewer checks. It means the checks move to where they matter most: the rules, the tests, the law underneath them, and the parts of the system you can never get wrong.

The result: I get roughly what Sentry provides, the system runs on European infrastructure, no crash data leaves to a US company, and sometimes the fix is already waiting in my inbox when I sit down in the morning.

But that's just error tracking. The broader pattern is more significant.

The same loop repeats across the fleet: the agent monitors its domain, finds something, and opens a pull request with the proposed change. Monitoring tools tell you what's wrong. These propose the patch.

The tax agent watches Portuguese legislation and tracks changes that affect the product. When something shifts, it doesn't just surface a flag, it opens a PR proposing the update the product needs. Every proposal so far has been right. I review each one before it merges, same as with errors.

The legal agent reads through the privacy policy, GDPR documentation, and subprocessor list after every code change, doing what Termly or iubenda would handle on an automated basis. When it finds a gap, whether that's unclear language or a new external supplier that should be disclosed, it opens a PR proposing the fix. The payment-processor and email-provider disclosures in the privacy policy were updated that way. Each one arrived correct; I reviewed and merged.

There's an agent that monitors competitors and surfaces relevant moves, replacing what a tool like Crayon or Klue would do. There's an agent for SEO monitoring (Ahrefs / Semrush territory), one for marketing content production (Jasper / Copy.ai territory), one for security scanning (Snyk / Semgrep territory).

None of these are sophisticated enough to replace a team of specialists. But they cover the monitoring and compliance layer that a solo product would normally buy piecemeal through a dozen separate SaaS subscriptions, each with its own data processing agreement and its own jurisdiction to check.

The email row is part of this story too. There's no marketing email platform, no Mailchimp or Customer.io. The agents decide what lifecycle and notification emails to send and when. AhaSend is just the delivery pipe. The decisions are made inside the system, on European infrastructure, not by an American marketing automation platform that's built a model of your users' behavior to optimize send times.

This is the change the thesis points at. Three years ago, building this layer yourself was a meaningful speed penalty. You'd spend weeks setting up something that a $100/month SaaS subscription already did. That cost was real, and it's why most products don't bother. What changed is that agentic tooling collapsed the production cost of building it. The privacy-first choice is now closer to the default-fast choice than it's ever been.

What still takes work (and what doesn't)

The claim is the tradeoff shrank dramatically, not that it disappeared.

A few dependencies stayed American. The site runs behind Cloudflare for speed and protection against attacks. Push notifications go through Apple and Google, because on a phone there's no other path. Sign-in works with Google if you prefer it. I said this in the previous post and I'll keep saying it: this isn't a "we solved EU data sovereignty" announcement. It's an honest account of how far the stack has gotten, and where the gaps are.

The hosting and ops work are real. Self-hosting still requires more attention than a hyperscaler. The agent fleet required actual development time to build. None of this was free.

What I'm saying is that the old framing, "you either ship fast with US SaaS or build right and fall behind," doesn't hold the way it used to. The EU supplier landscape is better. The agent tooling is better. The cost of doing it properly dropped enough that a solo founder can make these choices without paying a speed penalty that kills the product.

That's new. It wasn't true three years ago.

I'll go deeper on specific pieces in later posts, particularly the agent layer and what it actually cost to build. If you're weighing the same tradeoffs and want the specifics, the numbers are more useful than the summary.