Control Your User Data

In the early days of web application development, the golden standard for data storage was the database.

A developer would write their app on their local computer, develop some features, and then push that code to a server. Alongside the application, a database server like MySQL would be spun up. Connect the dots and within a few minutes, you'd have a web application up and running. Nice and simple.

Around 2013 or so, as cloud computing started to become the norm, this started to change.

A new class of development platform started to emerge that moved data away from databases and toward fully hosted—often proprietary—data stores. Services like Firebase and the now-defunct Parse cropped up as a way to shorten development cycles and reduce the number of considerations for developers looking to ship a product.

On the surface, this was great. Developers could focus wholesale on their product and leave the development stack and infrastructure primarily to the service and its platform.

As languages like JavaScript have grown in popularity, so too, have tools like these. Now, it's often recommended to start with one of these services and reconsider later (if at all).

Albeit convenient, there are several issues with this approach:

• Using a non-standard API for reading and writing data means struggling to find resources to figure it out yourself or having to hire specialists to work on your app.
• You will be charged to host, retrieve, scale, and backup your own data. As your app grows, so too does this cost.
• If the service you're using is proprietary and doesn't offer flexible exports, migrating elsewhere as you grow or a service goes away could prove difficult and costly.
• Though privacy policy and terms of service should protect you, you're ultimately at the mercy of Service X to not snoop on your data or users.
• You don't (necesasrily) control your data. If Service X decided to shut off their servers and take your data with them, it's game over.
• If you're censored, your data could go poof overnight.

If you're just building prototypes or hackathon-style apps, none of this should bother you.

Where it becomes problematic, though, is if you're building a business or hit pay dirt with your startup. By handing over the keys to your data to a third-party service, what you gain in convenience you lose in control.

That control is essential for things like:

• Scaling and improving performance
• Having proper backup and recovery systems to comply with SLAs and Terms of Service
• Ensuring uptime and flexibility when migrating or expanding to new service providers
• Being the legal owner of the data created in your application
• Being able to respond to technical incidents quickly instead of being at the mercy of a third-party

Without control, you're placing a gigantic sword over your head. If and when it drops depends on the company you've entrusted with your data, their long-term focus, and how well your use case fits into their offering.

My opinion here is to follow Murphy's Law: "Anything that can happen, will happen."

Without absolute control over your user's data, you're forever at the mercy of the third-party. Price changes? Get out your wallet. Downtime? Twiddle your thumbs and apologize profusely. Politically incorrect? See ya later, dude.

Though it does put a burden on you and your team early on in the development process, having control of your data means having more escape hatches for common struggles. Often, too, if handled intelligently, it can lead to lower costs.

Control your data. Own your data. Sleep well.