Smart teams don't sacrifice security for speed when building an MVP, they maintain a balance, building fast but laying the foundation for a successful product post-MVP.
Speed is the most valued asset when building an MVP. It makes sense. You don’t know if you have a paying audience yet, so why invest a lot of effort into a product that might not work? While that’s justifiable, completely ignoring security in favour of speed could lead to severe consequences, like getting a jail sentence. Yes, you read that right, jail. It’s that serious.
But you don’t have to compromise on speed for security. Let’s consider how.
It is difficult to think about every way in which your product can be compromised and even more difficult when building an MVP, where speed is the priority.
Libraries are your friends. Rather than waste time reinventing the wheel, you can use existing libraries to make your MVP relatively secure. An obvious one is form Validation. User inputs create an avenue for users to inject malicious code into your app, the most common being SQL injection. Libraries such as Validator.js (if you’re building with JavaScript) allow you to quickly sanitize and validate user inputs before they get to your server. However, in an attempt to save time through libraries, you don’t want to introduce vulnerabilities into your MVP.
You need to ensure that the libraries you choose are well-maintained, as outdated libraries could expose your product to more recent exploits.
Using existing services is similar to using a library, they help you avoid reinventing the wheel.
Using existing services, however, removes many of the edge cases that you still have to consider when using the libraries. By using an external service, such as an authentication service, you are sure that your product is more reliable (at least as reliable as the auth service) and caters to all those edge cases that you might have missed.
For example, if you decide to build your own authentication system, you might not think about adding a rate limiter that prevents users from attempting brute force exploits. If your MVP were ever to go viral, you would probably be susceptible to spam or bots. Implementing a rate limiter if you were using a service like Supabase is as simple as installing PG_HeaderKit, a Postgres extension. With this setup, you would be able to check the number of requests made by a user or a client and enforce a limit based on IP addresses or user IDs, adding an extra layer of security without compromising on development time.
When you use existing services when building your MVP, you can address security without sacrificing development velocity.
It doesn't matter whether you are building an MVP or a full-fledged product; if you don’t comply with the law, you’ll get into trouble.
Whether your product is in beta or alpha, it needs to be legally compliant in terms of security. Failure to do so could lead to severe consequences like hefty fines, seizure or worse, jail. Building a product from Jail would be really difficult, don’t you think?
An example of security laws you should be legally compliant with is GDPR laws. This law was designed to protect users’ personal data, meaning your MVP needs to protect user data for you to be compliant with them. Another example is PCI DSS compliance, which protects users' financial data when they use their cards for payment. So, if you are building in the finance industry, you still have to comply with these rules. You can research these laws using governmental resources that are related to your target audience’s location or research industry-specific standards that are particular to your industry.
By incorporating legal considerations into your security considerations when building your MVP, you’ll protect both yourself and your users.
Pro Tip: Add a disclaimer and require users to agree to use your product when it is still in development. This will give you a measure of legal protection if something unexpected happens.
When building an MVP, technical debts are unavoidable which could include security debts.
Although it might sound reckless to intentionally incur security debts, this is not necessarily the case. For instance, you could choose to use a simple authentication system over a multi-factor authentication system, which is more secure but not necessary at the MVP stage.
What you shouldn’t compromise on is taking note of the technical debts. If you don't track the technical debts you take on, especially security debts, you will be creating an avenue for vulnerabilities to trickle into your major release. Although tracking technical debts can be tricky as some are in the scope of unknown debts, tracking the “known” debts is imperative to building a reliable product post-MVP. You can use tools like ClickUp or Notion, which have existing templates for such a task.
By tracking security debts when building your MVP, you would know where to focus when you’ve found product market fit and can tackle them by priority. This approach allows for quick iterations while still maintaining awareness of potential security issues, leading to a more reliable product when you’re ready to scale.
So you can take on security debts, but ensure that you track them.
Building an MVP doesn’t mean throwing every rule out the window. It requires balancing speed and security.
By:
You can create a build quickly with security in mind and set the foundation for a successful product post-MVP.