How GDPR Will Change The Way You Develop

This is a great question that unfortunately doesn't have a good answer. Ignoring the question of backups, GDPR's requirements have the implication of imposing a workload on database engines that, in most modern architectures, is either pathologically expensive or not currently possible. Some companies are approaching this from a "best effort" standpoint rather than conforming to the spirit of the regulation because the technology simply isn't there to make it feasible for some cases. I've been working on this problem for the last year and this is (IMO) a major gap in the regulation; it presumes that something is possible that isn't for existing applications that are otherwise universally viewed as harmless and permissible.

Scalable database engines that can support the letter of the GDPR in terms of data handling don't really exist. This is not a problem that can be trivially solved by patching an existing database engine; the requirements of strict GDPR data handling violates fundamental design assumptions of common database architectures. If you look at, for example, high-assurance databases which have a similar set of requirements for data handling as GDPR, they are never used when at all possible because their performance and scalability is terrible. (These databases are conventional architectures with GDPR-like data handling controls added.)

A database engine capable of strict conformance with GDPR while maintaining vaguely comparable performance and scalability relative to what we are used to would require a comprehensive new database engine design from first principles. This is something only a small number of people are capable of designing and implementation would be a very substantial engineering effort. Possibly a business opportunity -- one of the reasons I've been thinking about it, having worked on high-assurance databases in the past.

He'd be exposed to increased risk by not complying(lawsuits, criminal action, etc.). It's based on his risk tolerance, the problem is it's hard to quantify at this point.

The realistic consequences would probably be the following:

1) When you grow sufficiently large to go global, it will suddenly start to matter a lot, as EU is one of the largest markets worldwide. In the best case scenario you'd have to change your processes and systems to comply (i.e. you'd have technical debt which you could've avoided if you did it properly in the first place); in the worst case you'd have some complaints from EU users resulting in fines that aren't enforced yet but would be as soon as you'd want to actually get money from EU. This would be a meaningful impact to your valuation at that point.

2) As the risks implied in the first part have an impact on your valuation if you succeed and go global (which is the only scenario that matters to investors, the exit valuation about which they're thinking), you'd expect this compliance to be included in the due diligence done by series B/C investors and any acquisitions; if you've made no effort to comply, this will result in a lower valuation in those rounds of funding.

If you're a high-growth startup whose valuation is not based on current revenue but on the (long) future market size and you declare that you're choosing to be incompatible with, say, 25% of the global market (to a very rough approximation, EU revenue share is something like that for many major tech companies), then investors will discount your future value (and thus current value) by 25%. So at the very least this is something that you should have on your roadmap for investors i.e. "we're planning to do that diligence and related work in quarter X after we've done A, B and C" instead of simply ignoring the issue.

American engineer building a bridge or tunnel in EU is certainly going to know EU regulations. An EE designing circuits for EU needs to know about lead-free solder requirements. On the other side, Mies van der Rohe needed to work with a US-certified architect to build the Seagrams.

Having been in the software industry for a while, it is often discouraging to see how both explicitly and often inadvertently move-fast-and-break-things has resulted in some pretty bad software industry wide.

Just look at the sense of most of the comments here--there seems to be a consensus of how to get around this, or how it doesn't apply to me.

To further emphasize your point You could encrypt everything and still be wildly GDPR non-compliant, we need to be able to respond to a request by each and every individual user to delete the information that they no longer wish us to carry.