A Happy Path to an MVP
Building a functional and stable Minimum Viable Product is essential for anyone looking to start a new venture. The timeline has gone from months – then to weeks – and now to days in which companies are launching product MVPs to test and determine market share and position or establish a product-market fit.
The reality is, most developers struggle to maintain quality and quantity when it comes to the ever-accelerating pace required to keep up with market demands. One of the best things any developer can do is pick a stack and build a starter based on your ideal workflow. This article is going to walk you through building out one of these for a GraphQL API with a ReactJS frontend and TypeScript backend.
Warning - Not A Complete Example
Just a warning to anyone looking to grab a git repo with a starter in it – there isn't one. This article isn't going to give you a complete example for use, but instead, walk you through the steps at which I use to go about setting up a project for MVP success.
The Stack
Current, my preferred stack for building out a functional prototype during a greenfield project is the following.
TypeScript - I think that when building out GraphQL APIs, substantial use of types across both Frontend and Backend code lead to much better outcome.
NOTE: I have started experimenting with Reason as a replacement for TypeScript but found not all of the toolings I prefer is compatible yet.
React - I have used Angular 2+, Vue and several others, but have found the available resources and component libraries available in React have given me the best launchpad for moving quickly. I would say that it's best to use whatever you're most comfortable with or fit's with the needs of the project.
Heroku / AWS - For hosting, I use either Heroku and AWS - depending on the regulatory requirements. I believe in infrastructure as code as a must have when trying to iterate quickly.
CI/CD - This is absolutely dealers choice. Depending on your project needs and environment, there is a wide array of options, make sure you have automated the test suite and deployments from day one.
Git - Yes. Do it.
The Process
Now that we have set up the scene let's get started! Create a new, empty folder and cd into it.
#1 Folder Structure
I know, you have your thoughts or ideas about where to put things and want to tell me where to put it. Hear me out.
mkdir code docs design
I start by creating three folders - code, docs, and design. Not starting with a clear folder structure can create a mess of files that leave you searching email for hours. FAIL. I like to keep things tidy with the following:
code - Here is where you create your project repo to keep your code.
docs - This is not your code documentation, that should be in code/docs - this is for business docs, and client provided assets around requirements or domain resources related to the project.
design - This folder is pretty essential (see what I did there?). One of the often overlooked aspects of a solid MVP is design. Success doesn't look like Bootstrap out of the box. Even themeable UI kits require a color pallet related to the brand or other various elements and assets that aren't ready to go into the codebase without additional work.
#2 Git to it.
cd code && touch README.md && git init && git add . && git commit -a -m 'PROJECT START'
Yes, I start with README.md - not npm init. Why? Simple, I don't always know if the project will be a single app or multiple apps in a mono-repo until I get further into it. I am starting with a blank folder and README set up the git safety net without forcing my hand.
#3 Divide and Init
Next, I like to think about the current companies existing infrastructure. Are the API and UI going to be deployed separately? Is the UI part of a microservice UI system (yes, this is a thing)? Answering a couple of questions can help to figure this out quickly.
- How is it currently being done?
- What is the simplest way that I can still change later?
- Are you overcomplicating things?
- Re-read #3.
- Setup the base API and UI with a simple test, hello world API call and UI with watchers and testing and make it run with a single script. The build step has tons of options (npm scripts, nodemon, PM2, Lerna).
#4 Don't start in the UI.
I know, the client wants to see progress early. Don't worry, GraphQL has your back. The first thing I do is start with the Schema, either DSL or code based and get GraphQL Playground up and running. With this, you can show the client a schema modal that isn't implemented yet but can show a nice visual - trust me - they are impressed.
Having the domain fleshed out, I can now think about how to ensure the domain stays intact by setting up types and interfaces to represent the established schema.
#5 Testing, Testing 1...2...3
Ugh, not another TDD fanatic. Don't fear; I am a recovering TDD'er. But, when working on a greenfield project - it is a must, and to do it with confidence, you need to do some testing. Approach this in whatever method you like - but do not skip it. If you skip it, they will come - and by they I am referring to bugs and unhappy clients.
By building your API around tests, you know when you get to building out your UI that the GraphQL APIs are going to work and don't require you to context switch between frontend and backend trying to hammer out features.
#6 To build or not to build.
Pick a mature UI Kit or build it from as few as libraries as possible. DO NOT roll your own for an MVP. When moving quickly, it's not hard to double-bind click actions or poorly memoize components that can create a kluge. I love AntD, and it's design system because of the quality and ease of use of the components.
#7 Find someone else to QA or automate this as well.
Click testing works excellent, the problem is that you probably are only testing the happy path. You also don't want to waste time clicking when you could be coding. You need to either find a QA, get the client involved with this - or if you have the time, set up automated smoke tests to ensure things are working as expected. Anyways, take final testing out of your hands. If you built it, you can't test it without bias. Finding edge cases early can lead to better products without costing too much time in the long run.
#8 Doc it like it's not.
Leave code comments, and create clear, usable documentation for the other developer that will come after you. And no, "code as documentation" is not the right answer here. I have yet to come across a development team that has maintained code so well with SOLID and DRY principles that it requires NO documentation. Also, reading hundreds of files to trace stack calls is a pain, and no one wants to have to do that. Robust documentation and comments around what and why you chose to do something will go a long way down the line.
#9 Ship. Ship. Ship.
It is an absolute must that you push code daily and several times a day. Shipping daily serves two purposes: first, you are iterating which is essential and secondly, you can show the client you are doing work even though it could feel like the project stalled shortly after getting started.
#10 Talk to the client.
Talking to the client may seem like an obvious thing to do - but seriously, you need to consistently be talking to the client about what you are doing and what your planning on doing. Over-communication can very quickly suss out miscommunications early before they become harder to revert.
Conclusion
It is my sincere hope that this helps someone, somewhere with something while building an MVP. If you have questions or what to know more about how I think about delivering software, please feel free to comment.
