My Startup Graveyard: App Review

So the other day I was perusing through some Indie Hacker threads and got pulled into a conversation that was titled “What is your greatest struggle right now?”. In my comment, I mentioned that throughout all my goings on, I’ve amassed quite the large graveyard of side projects that I abandoned shortly after starting, for one reason or another. One individual mentioned that I should consider bringing some of them to the surface for people to see, which I thought was a great idea. So this is the first post in a series that I’m labeling “My Startup Graveyard”.

The nature of contract work often leaves me with one to two months of “free time” when I’m transitioning between contracts. For my most recent free time, I decided to build something I thought could be valuable. Of course, being the average developer with little to no sales or marketing experience, I spent zero time validating my idea and proceeded to write code for six weeks while using new tech that I was unfamiliar with. Once I started a new contract the idea no longer seemed like a viable product, so I tossed it on the pile. Without further ado, I give you App Review.

The Idea

The idea behind app review was simple enough. People use github to submit pull requests to have their code reviewed before merging it. Code reviews are great but what really matters at the end of the day is testing the changes to make sure they work. This means managing a local version of the app, which I know some QA testers find daunting. Cue App Review, an application that allows you to spin up a version of your application using the pull request code. This could be done manually using an easy to use interface, or you could have it work automatically when pull requests are created.

Rationalizing Self Validation

Like I mentioned, I spent zero time validating the idea behind App Review. I was able to rationalize to myself that I knew it was a good idea because I had seen Heroku offer it as a product. The feature that would differentiate my product from Heroku’s, was that my project would allow you to run custom bash scripts on the VM and configure them in any way you wanted. With that value proposition in mind, I set out to build my MVP.


This is always the golden age and my fellow developers will know what I’m talking about. You first start development on your project and you’re filled with the sense of being unstoppable. You’re creating something amazing from absolute scratch and you genuinely feel like it’s going to change your life this time. All your code adheres to your own principals, styles, and meaning. No one has any say on what you are building or how it should be built. It’s truly one of the greatest feelings you can obtain as a developer. It’s unfortunate that, in these instances, the feeling is so short lived and superficial.

I started building App Review with a list of MVP requirements and for the most part it was going well. I’m not a designer by any means, so I stuck to templates and relied on the functionality to speak for it’s self. It was an MVP, after all, and I knew the important part was getting something users could try.

Here are some screenshots of the application in it’s current state


Users would be able to link a repository, which would provide them the ability to create Instances for pull requests for that repository. You can see I linked a public repo for the html5 boilerplate project that I forked. The instance could be created/started/stopped/terminated from the dashboard if the user preferred.

Recipe Management

Recipes were my conception for handling custom bash provisioning scripts. Users could created/edit/delete Recipes that could then be assigned to a pull request or a repository as default. Included was a variable system that allowed you to define reusable values within your Recipes. When the instance would spin up for the first time it would run the assigned Recipes.

Instance Management

Instances were AWS EC2 instances that housed the application and ran the User’s Recipes on startup. You could manually start/stop/terminate the instances, choose a Recipe, and receive output from the instance startup provisioning process.

The Upside

I have to admit, App Review was not a complete waste of time. I thoroughly learned React, Redux, and a variety of other tech, which gave me more contract leverage. It also made me realize how out of tune I was with understanding the size of my ideas. I’ve never had illusions of grandeur when it comes to software development. Ideally, the products I create would be small but useful. App Review made me realize that a lot of the project ideas that I come up with are WAY larger than I would probably like.

Even writing this now, I still look back fondly on the time I spent writing App Review and wish that I had finished it, if for nothing else but a sense of accomplishment. Ultimately I think there is a solid business idea somewhere in there and maybe, just maybe, I’ll finish it one day.

My guess is that I’m not the only one out there with a startup graveyard. What’s in yours?


Connect With Me

1 Comment My Startup Graveyard: App Review

  1. Phanor Coll

    I’m actually doing the same thing after readying through some Indie hackers threads, finally decided to start working on a couple ideas I wrote down last year, while working on full time projects, its a slow process but It’ll be worthwhile


Leave a Reply

Your email address will not be published. Required fields are marked *