Adam Haney

I'm an entrepreneur and hacker living in #cha. Working on a few different projects. You can find me on github, twitter and angel list.

Sitemap •  RSS Feed

Services I'm Happy to Pay For

Dec. 16, 2013

I've worked on several startup teams that had a shoestring budget. The battle cry was always, "decrease the burn rate". I love lean startups as much as the next person, but the problem is that the mindset of "let's spend no money" often misses the expense that your time or the time of your early employees costs. Because of this I've started to change philosophy when it comes to purchasing outside software. It turns out that developing things in house not only has the cost of development hours, it also has the opportunity cost of other things that you *could* be working on if you weren't working on billing, or quality assurance, or a million other problems that you could throw money at. So, I've compile a list of things that I'd recommend paying for, instead of building in house, or going without.


Your team should be using version control, and there's no reason for you to maintain it. This isn't that controversial, but I have run across a few teams that think github isn't worth the money. Yes, you can run your own git server but you miss out on the ability to do Pull requests, easy forks, @mentions for developers, and easy authentication. Just use github, most of your developers already know how to use it anyway.

Pivotal Tracker

Yes, postits and google docs are free, but your development team's time isn't. It quickly becomes very difficult for teams to manage the priority of tasks that they're working on and the sooner you can establish processes (agile processes) for managing what needs to be done right now and what needs to be done next week the faster you're going to be able to bring new and innovative products to market.

Zen Desk

Post launch I've been in the position of fielding hundreds of emails from customer and team members about support related tasks (often times I've worked on teams that were more technical than business). Having the ability to categorize information about known issues and solutions and to split up the work of operating support between multiple team members is invaluable. I've tried to live without help desk software for live products before, I don't want to do it again.


One of the startups I worked on had a very simple solution for sharing passwords among team members for shared accounts, we just used the same password for everything, for two years. Ouch. It makes sense, security is a struggle to find a balance between confidentiality and accessibility, in that battle most startups take a 'get shit done' attitude and ignore glaring security problems (this is anecdotal, but I've seen it happen at many startups). Instead of ignoring security issues until they cost you money I recommend Meldium, it allows you to create access control lists for your shared accounts and determine which team members need access. It also has github, heroku, and google app support for products that do support team based authentication. It ties everything together nicely and makes it easy to hire a new employee and give them access to everything they need. No post-its, excel spreadsheets or frantic phone calls to team mates required.


Not everyone likes flowdock, but I believe that team chat is something that you should start using early. For flowdock or hipchat the first 5 users are free so there's no reason not to go ahead and get everyone used to logging in to a team room everyday. This has a few benefits. First, it means that if someone needs to work remotely for the day, or if you have remote employees its easy to pose questions to the team without interrupting an individual. Another benefit that we've seen is that it makes our conversations searchable, which is a big win for design decisions. One feature of flowdock specifically that I like is that it integrates with github, heroku, circleci, pivotal tracker and zendesk and posts notifications of the things that are going on in those rooms. This allows our team to have a 'timeline' of things that have happened related to our project today, which helps everyone to see the project moving forward and be able to do the most good for the team. Also, we've taken to using hubot, which has allowed us to to not only have fun automatically posting funny pictures to our room, but to also automate some of the common tasks that we have as a team such as searching the knowledge base, closing tickets or changing the song for the office music.


I've worked on projects that had tests "as needed" and I've worked on projects that did test driven development. Since embracing TDD I've seen the quality of the projects I'm working on sky rocket, and, once you overcome the initial hurdle of learning and implementing the groundwork to do TDD I actually find that the velocity of the team goes much faster (not even including the benefit of less support, bugs and headaches). One of the most important aspects of adopting TDD for me has been a continuos integration server. You can set one up using Jenkins, but then you have to provision a machine (physical or cloud based), then install and finally configure everything. Circle CI introspects your code, syncs with github and runs your tests and pushes your build status back to github so you can see if a pull request breaks the test suite.

These are just a few of the services that I use regularly while working with development teams who are primarily coding web applications. I'll update the list as I find more services that help us be more productive.

Next entry

Previous entry:

comments powered by Disqus