MVP Curveball

This is a bit of a rambling post (I didn’t even bother to spellcheck it), but I thought it was important to capture this moment during the creation of the MVP release. Today was a rough day. I’ve been working on a tool called Review Cadence, which is designed to walk a person through a basic self-assessment process. I started the project about two weeks ago and have gone through the process of outlining MVP functionality and building out a good framework that is extremely close to being ready to ship.

Or so I thought.

As I was going through the last few tweaks on my checklist, a sense of dread shot through my veins. You see, I built the MVP so that a user would not have to authenticate to use the application. The idea behind this was that it would lower the barrier of entry and provide less friction to try the product out. Because of this decision, I also piggy-backed another big decision on top of it which was to not have a persistent database holding the data under the hood. Rather, I used the Entity Framework’s InMemoryDB functionality to store a user’s information while they were going through a session.

I tested and tested the product and everything worked well enough that I felt very comfortable in releasing what I had as an MVP version. I could always go back and plug-in a database and authorization scheme later on. But at least I had something that I could start getting user feedback on.

Here’s where I went wrong…

I mistakenly thought that the InMemoryDB functionality was tied to a user’s session. Meaning, that each user would have their own “copy” or in-memory database to be working with.

That’s not how it works.

I don’t know why it hit me all at once, right as I was about to prep for the release, but something inside me started feeling off. A feeling as though I had missed something. And I was right. Rather than each user having their own in-memory database, the database is shared between all users. And this is a massive problem. What it means is that if I was in the middle of a review and someone else came to the site and started the process, they would see my answers. They could edit them, delete them, print them off, etc.

In other words - review information for a user is not private.

Unfortunatly, this blew away my initial celebration of the fact that I was going to be able to get away with not having an authentication system or a backend database for the initial release. I may still be able to get away with using the in-memory functionality, but I am definitely forced to figure out a way how to not commingle data. This almost guarantees that I’ll have to build out some sort of user authentication system or at least ensure that data is tied to a unique user.

Giving each review a unique GUID is an option. I can then store the guid in a session cookie that can be used as a cross check against the data. It’s not perfect, but it may be the easiest way to get the MVP out the door without having to build a full-blown authentication system yet.

All this to say - I’m glad I didn’t release the bug into production. I’m willing to take the extra time to fix the issue in order to prevent a major data disaster like that from happening.

My immediate plan is to take a step back from the project - to go outside and do a little yard work to let my subconcious muddle over the problem. This evening, I’ll try to put together some sort of proof-of-concept around the unique GUID/cookie idea that I mentioned above. If all goes well, I’ll then roll through the codebase and start implementing some better data constraints based on the unique id. Optimisitcally, should only take a few hours to fix if the guid idea works. Otherwise, I’m probably looking at a few days to build out an authentication system and overhaul the backend.