When a Free SaaS Becomes an Expensive Responsibility

For the past few months, I was obsessed with an idea: build a genuinely free ERP and CRM platform for small businesses in Vietnam (customize ERPNext open source).

I wasn't looking to build another heavy enterprise monster with enterprise sales calls, paid consultants, and six months of onboarding. I wanted something simple enough that a coffee shop with three staff, a neighborhood curtain shop, or a family-run grocery store could sign up and start using immediately. The core product would be free, funded by paid tiers for bigger workloads or advanced modules. With modern tools, I pictured scaling to hundreds of thousands of users.

Technically, building it felt completely doable. I already had the stack mapped out: multi-tenant MariaDB, clean data isolation, role permissions, lightweight mobile apps, and LLMs handling onboarding and invoice scanning. Cheap to run, fast to ship.

My early questions were typical engineering problems: How do I partition the database for a million users? How cheap can I push the free tier? How do I automate support?

Those are easy questions because they have technical solutions.

Then I looked into Vietnamese data law, and everything changed.

Vietnam passed the Law on Personal Data Protection (Law 91/2025/QH15) alongside Decree 356/2025/NĐ-CP, both taking effect in January 2026. For an ERP, "personal data" isn't a side concern. It is the entire product. You are storing employee phone numbers, salaries, customer addresses, bank accounts, and daily sales receipts.
For ten businesses, you can manage that casually. For ten thousand, you are running a serious data operation.

At first glance, the law seems friendly to small players. Article 38 lets startups and micro-businesses skip certain data protection officer requirements and impact assessments for five years. But that exemption drops away if you process data as a service, handle sensitive categories, or manage records for 100,000 data subjects or more.

Think about that number for a second. In a consumer or micro-business SaaS, 100,000 cumulative individuals happens surprisingly fast. A few thousand small shops uploading their staff rosters and regular customer lists blow past that limit in no time. Suddenly, the very thing I was optimizing for (massive, rapid adoption) turned into an immediate liability multiplier.

It gets more complicated once you look at cloud architecture. The natural instinct for most solo developers is to use foreign managed infrastructure: Singapore cloud regions, Cloudflare, foreign email delivery, and US-hosted AI APIs. But under Article 20, sending data to overseas servers or using external platforms to process Vietnamese user data counts as a cross-border transfer. That triggers mandatory impact assessments and filings with the Ministry of Public Security. If you fall into the regulated category of data-processing services under Decree 356, you also need certified in-country personnel and formal eligibility clearances.

Violations are not pocket change. Fines for cross-border transfer breaches can reach 5% of annual revenue, or up to 3 billion VND when revenue is low.

When your business model is "free software with tiny margins," that risk math breaks immediately. The infrastructure cost per user might be near zero, but the legal and operational overhead per user is definitely not.

I don't think these rules are unfair. ERPs hold the keys to a company's livelihood. Nobody should trust a solo dev with their payroll and customer records just because the app is free and looks slick.

Could I still build it? Sure. I could host locally, hire Vietnamese compliance specialists, draft formal data-processing agreements, set up incident response teams, and charge high enough prices to cover the overhead.

That is a viable business, but it is not the business I set out to build.

I started by asking: "Can one engineer build a lightweight, free ERP for everyone?"

I ended up at: "Do I want to build a compliance-heavy, high-touch security organization?"

As engineers, our default reflex is to code around roadblocks. Slow query? Cache it. High traffic? Scale horizontally. Expensive API? Run local models.

Being a founder means learning a different skill: knowing when to stop.

Walking away stung at first. It felt like wasting months of design work and prototypes. But stepping back actually saved me three to five years of running a company I never wanted in the first place.

Deleting an idea isn't giving up. Sometimes, killing the project is simply protecting your most limited asset: your own time.