Rapidly Deploy a Proof of Concept Using Mongo, Express, Angular, and Node.js (Part 1: Setup)

As an investor, I hear a lot of moaning and groaning about the time it takes to build a proof of concept or MVP to show us. To me, having such a thing is now considered absolute table stakes. If all you’ve got is an idea, unless you’ve made me money in the past, I’m going to turn you away until you’ve brought something to market.

Gathering data on your product/market fit is critical in helping me understand how to set or negotiate your valuation. If you can’t produce something I can see, touch, and hear the feedback of others about, then even the greatest ideas are going to be a quick “no” for me.

Let’s dive into how easy it actually is to produce an MVP, so that I can just send people to this series of articles in the future instead of having the same conversation over and over.

For our MVP, I’m going to build a platform that actually enables founders to show me what they have, link in their beta customers for ease of due diligence, and aggregate key digital marketing data. Let’s knock out the easy stuff, like getting the framework in place and implementing version control:

Angular-CLI 1.0.6, reporting for duty. Project created.
The finished package.json, with some version tweaks.
Up to Github you go!
Ok, we have a repo. Yours should likely be private, unlike mine.

Notice that we aren’t adding any sort of quality engineering (QE) here, such as unit tests, system tests, or the like. Those aren’t part of an MVP, unless you’re really an insufferable asshole — and even insufferable assholes like me often skip them. After all, if the market doesn’t like what we’re building, we’re going to fail fast and scrap this, right? So why waste time on beautiful code and unit testing? Don’t. I’ve never been interested in investing in a company because their codebase was beautiful.

Now it’s time to pick a UI. Obviously, we want to agonize over just the right colors, presentation, and style, right? Fuck off. I chose the third one I saw on Envato Elements, and downloaded it. It’s called Flatkit, whatever that is. Looks okay-ish. Whatever.

It ain’t pretty, but if it was, you would have spent WAY too much time.

Next, let’s build out a simple API to interface with our UI components. Starting, of course, with version control.

Git initialized. Giddy up.
Here we go, new repo up and running.

We are going to need some help from npm to rapidly deploy this API. Let’s add express, body-parser, config, morgan, mongoose, and password-hash. These should all be familiar faces to most Node.js developers.

nano implies that you’re old — and I am.

Let’s now define the skeleton of our Node.js API.

Our main file, which starts our server and connects to the database
The config file for our default configuration
Our routing
The main (root) route, which identifies the API
Our Dockerfile … because you ARE using Docker, right?

Next, we will need a database to store our information. Sure, we could spin one up with another Docker container, and implement Docker Compose, but we are trying to do the MINIMUM amount of work here. We’ll just use mLab’s free offering to create a sandbox Mongo database.

Congrats: we’ve got a skeletal framework ready to go. In the next article in this series, we’ll start implementing a user login and the first product features.