Privacy as Architecture, Not Afterthought

A conversation with Ernests, Founder and CEO of LuceneX

There's a version of "privacy-first" that lives in marketing copy: vague commitments, checkbox compliance, reassuring language in a terms of service nobody reads. Then there's the version that shapes how systems actually get built. The database schemas, the vendor choices, the features you decide not to offer.

Ernests, the founder of Latvian software and cybersecurity company LuceneX, operates firmly in the second category. In a recent conversation, Ernests walked me through what privacy-first development actually looks like when you're making technical decisions, and why the common approach of "build now, add privacy later" fails so catastrophically.

Privacy as Ownership

"We treat privacy as ownership," Ernests explains. "Everyone should have full ownership over their data. The client whose data we have knows it's safe, and at any time they can delete it from our servers and know we're fully compliant with that request."

This isn't just philosophical positioning. It's a response to what Ernests sees as an ethical problem endemic to the tech industry: data as currency.

"Data is very valuable. It can be used for marketing campaigns, to target specific populations, age groups, genders. For us, this brings an ethical concern. How do we want our clients to see us? As another data collector who sells information to make a quick buck? No. We want to be seen as reliable, trustworthy."

Ernests offers an analogy that cuts through the abstraction: "We all love to have privacy. We love to have our own apartments, our own things. And similarly, like you wouldn't take someone else's toothbrush, you also shouldn't take another person's data to profit from it."

The Architecture of Not Collecting

The most striking aspect of LuceneX's approach isn't how they protect data. It's how much they simply don't collect.

"Most data we don't even store anywhere on our servers," Ernests says. "We want only as much as needed to identify that this specific person is our client. We don't store additional information, and we explicitly ask permission before giving anything to third parties."

When data must exist, LuceneX pushes storage to the client side. "We prefer that users have their data stored locally. By deleting an app or ending collaboration with us, the only data we preserve are legally binding documents: receipts, contracts. Nothing exposing or otherwise leverageable."

This is data minimization as a default architectural principle. If you never collect data in the first place, you don't have to worry about deleting it, securing it, or explaining a breach.

Peer-to-Peer: When Less Infrastructure Means More Security

LuceneX's secure messaging platform, Astra, demonstrates this philosophy in practice. Rather than routing messages through central servers (the standard approach that leaves metadata trails even in "encrypted" apps), Astra uses peer-to-peer communication.

"No data is stored on our servers," Ernests explains. "We're currently exploring whether we should offer backup servers accessible only to the client and not to us. That would be expensive at scale, running millions of small servers for message exchange. But our focus remains on users having full ownership of their data."

Here's the counterintuitive part: this privacy-first architecture actually reduces development complexity.

"By having a peer-to-peer approach, it's very cheap development-wise. You don't have to worry about complex AWS architectures. You also avoid having a broader attack surface, because you don't have any data. You're not exposed. You don't have to worry at night whether your databases are getting breached."

The Trade-offs Are Real

Ernests doesn't pretend this approach works for everyone.

"P2P communication brings trade-offs. Transferring messages from one device to another, when a user upgrades their phone for example, becomes complex. We have to work on protocols that let a device be cloned while preserving messages. And if a device gets stolen or broken without backup, unfortunately, all messages are lost."

This is a deliberate limitation. "P2P communication is not for an average user. It's for complex situations where you have to preserve anonymity or ensure maximum-grade security without worrying about data loss. That's why we're building Astra alongside Arcanum, our cryptography library. It's for enterprises, military, use cases where decentralization matters more than convenient backups."

The honesty here is instructive. Privacy-first architecture involves genuine sacrifices. The question is whether your threat model and use case make those sacrifices worthwhile.

Why "Add Privacy Later" Fails

I asked Ernests about the opposite approach: building first, retrofitting privacy afterward. The answer was blunt.

"The early days, the MVP phase, that's when the biggest mistakes happen. If you're building credibility as a business and then it turns out your product was selling client information to third parties, what does that say about your practices? How can a client trust you after their data got sold? And in the worst case, what happens if there's a data breach?"

Ernests shared a personal example: "In my junior years, I made reckless decisions. Hardcoded variables in a public repository. Not a good look. Luckily, that was my own personal project with no clients. But if that had been a monetized product, my reputation would have been smeared across a wall. Reputation is something very hard to build and very easy to lose."

When companies try to retrofit privacy onto systems built without it, Ernests has observed a consistent pattern. "The most common finding is a huge attack surface. Each function, each connection to an outside service, is a liability. If one piece falls, you're responsible for what happens."

The conclusion is often grim: "It frequently comes down to the fact that the system is incompatible with privacy functionality. It's cheaper and easier to build from scratch than to maintain and fix what was totally ignored. Privacy is an expensive mistake to make after the fact."

Thinking Three Steps Ahead

For technical founders tempted to cut corners on privacy to ship faster, Ernests offers a direct recommendation: "Think three steps ahead. Not only profit-margin-wise or maintainability-wise, but privacy-wise."

The specifics matter. "Be considerate about your data flows, about how you handle data. Don't pick the cheapest vendor if its reputation is questionable. Ensure users have access to their data regardless of what region you're operating in. EU, US, China, doesn't matter. Make sure the data you have about each user is accessible to them and not scattered across a hundred different vendors. If you're outsourcing data, make sure you have access to it yourself. Otherwise, it becomes a really complicated mess."

The Regulatory Tailwind

Operating from Latvia under EU data protection law, LuceneX benefits from, and advocates for, strong privacy regulation. But Ernests's support isn't uncritical.

"These regulations align with our mission. It's nice to see the EU taking initiative to ensure data doesn't travel to third parties as much as it did before. But I see room for improvement. There are controversial regulations, like the AI surveillance proposals that were debated in 2025. LuceneX publicly spoke against them, and I personally wrote to my country's politicians about my concerns."

This willingness to advocate, even against regulations, underscores that LuceneX's privacy stance isn't about compliance. It's conviction.

LuceneX builds privacy-first software for European businesses that can't afford to get data protection wrong. Their products include Specter (OSINT), Astra (secure messaging), and Arcanum (post-quantum cryptography). Learn more at [lucenex.lv](https://lucenex.lv).