Rapidly building and MVP with Rails and Vue

Image from https://mobilunity.com/blog/mvp-development-for-startups/

I spent the last month or so iterating on a MVP with Rails and Vue, as a solo developer, and here’s what I learned.

Understand the problem you want to solve

This might seem obvious, but you should know what you want to achieve. If it’s a problem you personally experience, all the better — knowing the domain and understanding the problem is the first step towards a successful MVP. Many great products are born from necessity.

Use a proper Git workflow, with PRs and Reviews

Even as the sole developer, I found making PRs for each feature, and reviewing them myself was very beneficial. The workflow I used for this went something like this:

1. Make feature branch.
2. Implement feature, in most simple manner possible. Don’t worry about styling, or even proper test coverage (for now).
3. One the feature is working and bringing value to the app, make a PR.
4. Wait 24 hours. Work on other features in the meantime.
5. Review the PR yourself. Having a day away from code, even code you wrote yourself, does wonders. You’ll see little mistakes you made, unused files, etc.
6. Now the code looks good, and the feature is working correctly, improve test coverage. Onto my next point…

Even an MVP needs tests

In large, established applications, test coverage is a no brainer. However, I found writing tests for my MVP very valuable, as well. It makes iteration faster overall, since you don’t waste energy checking if existing code still works, etc. Since I’m using Rails and RSpec, the specs also help add clarity to what the code actually does.

TL;DR: tests bring value and save time, even in the early days of an application. Get good at writing tests. I have lots of unit tests, and at least one E2E test around the happy path for each feature. These are more or less sanity tests, and leave a lot to be desired, but it’s fine for an MVP. If the MVP goes well and I want to grow the product, then I’ll look into adding more thorough tests.

Tests themselves don’t deliver value, but neither does a broken website, so they are very much part of the process, even in the early days.

Check out my Vue.js 3 course! We cover the Composition API, TypeScript, Unit Testing, Vuex and Vue Router.

Use JS until you are happy with the feature, then move to TS (optional)

TypeScript is growing on me. I believe it makes long term maintenance easier, and helps catch little bugs. However, TypeScript is certainly slower to prototype in than regular JavaScript. When I’m validating an idea, I don’t want to mess around with types; I want to get it working and see if it’s useful or not.

That said, when I am improving existing code, I value type safety, not rapid development. My workflow, as such, as been:

1. Rapidly iterate a feature in JS, until I’m happy with it.
2. Add some tests around it.
3. In a week or two, if the feature seems like a keeper, move the code to TypeScript.

Moving JS to TS is a low energy task, at least for me. I’m working on my MVP 8–9 hours a day, but can only really focus on creative work for 3 or 4 hours. I use the remaining time on low energy coding tasks, like moving JS to TS, or non technical tasks, like research, reading, talking to early users, or thinking about new features.

That said, if your app is really light on JS (hopefully it is), you can just skip TypeScript, and just roll with jQuery, or even plain old ES6. You don’t even need babel — it’s an MVP, supporting old browsers is not a priority at this point in your product’s lifecycle.

Don’t mess around with tech stack/config; focus on what the MVP should deliver, and stay simple

I like optimizing my workflow — docker, CI, dev/staging/prod env, Vim plugins… but when working on an MVP, with limited time, I tried to stay away from this kind of work. Having a good workflow is invaluable… however, when you have limited time and are focused on validating a concept, perfecting your editor config, or messing around with docker is time spent not building useful features.

As such, I chose the following stack:

1. Ruby on Rails backend. Rails is tried and tested, and I know it well. No surprised, just fast development.
2. Vue with the Webpacker gem. Webpack can be a huge time sink, so use a template like vue-cli, or create-react-app, that is preconfigured and works out of the box. I went with Vue since I know it well. If you don’t need much JS, just use jQuery. Or better yet, server render the entire app.
3. Deployment with Heroku. I spent a total of about 2–3 hours setting everything up, and have touched nothing since. It has a free tier, it’s crazy simple, and requires little to no config for common stacks. It’s an MVP — I don’t have time for AWS’s complicated UI and hundreds of services, or to figure out how GCP works.

Don’t write too much JS, avoid SPAs

Although my MVP uses Vue lightly, I tried hard to do as much server rendering as possible, using Rails’ built in erb templating engine. Laravel has blade, and other server frameworks have something similar. Less JS and less SPA like applications means less debugging and generally a more simple deployment pipeline. MVPs don’t need to be single page applications — you can validate an idea with page refreshes, it’s not a big deal. If your MVP is really solving the problem you think it is, your users won’t mind a less sexy, non SPA.

Don’t get stuck on small things

If you are anything like me, you want your personal projects to be beautiful — the code, the UI, the readme… but for an MVP, things don’t need to be perfect.

• That button text looks a little large? Who cares, it’s obviously a button. The important thing is does it work when you click it, and does it deliver value.
• Still on heroku’s free tier, when you have .herokuapp in the domain? Don’t worry about it, people are visiting your site for the product, not the URL.
• Linter complaining about your code, since the line is over 80 characters? Turn the linter off for that file.

My MVP

You might be thinking “what is this MVP he keeps talking about?” I’m mainly writing this to share my developing experience, not to market my product. I think these tips are useful for any kind of MVP. If you are really interested in my project, you can find the landing page here, and some screenshots in my previous articles about League of Legends.

Conclusion

• simple is best
• focus on the problem. Don’t worry about technical things, like your how cool your modern stack is
• tests are useful
• don’t get stuck on small things
• stick to what you know

Thanks for reading. Please share your MVP experiences with me. Or better yet, the MVP itself, I don’t care about an ugly UI, or some missing links, I’m interested in the problem you are solving!