Making A Simple App Takes A Serious Commitment

Even since I started working with Rails, I’ve been looking to build “simple” apps that would only take me a week or even a weekend to finish. The problem is that an app is never truly finished. And it is much easier to start an app than to actually finish it.


Sure, you can build an MVP (minimum viable product) pretty fast with Rails, but who wants just an MVP?! When I build an MVP, I imagine all kinds of must-have and fun add-on future features that I truly want to add in the future.

Take, for example, something fun I was building this weekend. I was learning Backbone.js, so I wanted to build something simple using Backbone.js and Rails. I decided on a hacker news / reddit for Backbone.js resources. Here is what I have so far. As you can see, I have A LOT more work to do – adding voting, karma calculation, user login, commenting, etc.

 

Suddenly, what was a small simple app turns into a giant project I don’t want to commit all my free time to. After all, there is always a more fun-sounding project right around the corner!

I hate the feeling of having a ton of unfinished projects I’m not happy with and don’t want to continue building. So it is time to move on to something big, long-term, that will take a while but will be beautiful and a lot more satisfying.

Enjoy the article? Join over 14,500+ Swift developers and enthusiasts who get my weekly updates.

  • Jenna

    I think it may be a free time thing. That is, if I had a lot of free time, then I’d spend more time building a better app, versus, if I had little free time (Saturdays & Sundays only) then I would rather spend time doing other things than coding like watching a movie or relaxing…

  • Nathan

    This happens a lot in both scripting and programming. The best solution I’ve found is to sketch out what you want the app to do before even touching a keyboard and prioritizing the core features above what can be added later. (Sound a little like MVP?) After that when you start work on the individual features write it in a way that you won’t have to recreate the effort in the future. Eventually you’ll have a working library of code where you can just throw those features in as quickly as you put together a MVP. I’ve found knowing software design patterns helpful in writing that kind of code. If your interested I’d checkout a book like “Head First Design Patterns. It contains the first 10 or 12 most commonly used patterns and strategies and for something more technical and deeper you can check out “Design Patterns: Elements of Reusable Object Oriented Software” which has most if not all common patterns (very hard read).

    • Great advice! I usually go back to my old projects and just copy the features I need for my new projects. There is probably a better way to do that. I’ll make sure to take a look at the book you mentioned!