In this installment of the Web Setup, we spoke with John Sheehan, the CEO of Runscope, a small startup based in San Francisco. Runscope provides powerful automated testing tools for builders and consumers of web APIs. You can easily monitor your application's backend services or inspect and analyze your interactions with 3rd party APIs. In an era where every application is dependent on APIs, Runscope is a tool you should definitely try out.

Hi John, tell us about your team; what kind of office setup do you have?

We’re 5 people: four engineers and a designer. Our office is in an old textile factory in SOMA, San Francisco. We lucked out and got a good deal on a spacious place for our size. It’s more than we need, so we rent out one of the work areas to another friend’s startup. We use Noi and Brooks worktables from Ohio Design, which are designed and built in San Francisco. I made it eight months before putting a coffee ring on my desk.

We’re mostly an Apple shop, though one of our engineers uses Linux on a Thinkpad. Otherwise it’s Macbook Airs and iMacs all around, with plenty of screen real estate for everyone. Outside that, we have an Xbox 360 and Xbox One for feeding our FIFA and NHL rivalries.

What web apps can your team not live without? How do you pick them?

We use a TON of services we can’t live without:

Slack (group chat): Even though we all sit in the same room, our group chat is where everything happens. We have channels (rooms) set up for deployments, commits, exceptions, support, Asana, Jenkins, technical discussions and chatter (the only room gifs are allowed). We feed everything we can into chat. It’s our heartbeat. It’s in beta so there are some rough edges (particularly around notifications). Before Slack we used HipChat but it didn’t always deliver messages in a timely manor which was a deal breaker for a real-time chat service.

HelpScout (support): Simple UI, affordably priced, great 3rd-party app integrations (like Slack). Highly recommended.

Other tools we use: GitHub, Stripe, Sendgrid, Mailchimp, Asana, Jenkins, Bugsnag, Mixpanel, Heroku (for community projects), Dropbox, and Squarespace for the blog.

We use AWS for hosting across four different service regions. We have an in-house deployment and realm management tool called Prometheus for deploying any project to any of our instances in any realm and region. Prometheus makes deploys dead simple.

I’d say the biggest factors for picking an app are: actually solves our problems, isn’t broken, design/usability and 3rd-party service integrations.

How do you onboard new folks?

For onboarding, we try to eliminate the need for onboarding. As much as possible I get all the accounts set up for someone before they start and give them a checklist with instructions for how to get access. Whenever possible I give someone ‘admin’ access. If they run into a configuration issue with a particular service, they can fix it on their own. We have tons of docs on the ops side and a comprehensive guide for setting up a new dev environment. For everything else, we try to have a tool that automates the process (e.g. deploys) so that there’s no complicated, unrepeatable process to teach.

We don’t have any dedicated remote employees, but three weeks out of the year near holidays we close the office and everyone works remotely. Since chat is already the center of everything, it’s not that hard of a transition. Though we do miss our monitors.

What would be your dream setup?

My dream setup: it would be pretty hard to beat our current situation. I do wish software just generally worked more consistently though. It’s rare when a day goes by when I didn’t have to deal with broken software. Even with all the great apps out there, stuff is always broken. We’re by no means immune to it ourselves. I’d like to see dev tools get better at making it easier for devs to make software that breaks less.