Services we pay for
Proto product development process
by Sean Kirkpatrick

As an independent app design and development shop, we strive to keep our overhead costs low. At the same time, we need to be as effective and efficient as possible when we're building new apps, platforms, and/or services. To that end, we have found that there are several paid services well worth the monthly cost.

Here's a set of tools we pay for and find indispensable:

Slack

tl;dr

It's hard to imagine a time before Slack. We pay monthly for each team member to have full access and then set up channels specific to topics and/or projects. We prefer to have clients involved in the process and Slack allows us to invite single-channel guests for free so we are able to add clients to their project channel.

Collaboration

We drop files in Slack for review and feedback, or a link to a Google doc and jump over to that for further collaboration. Meanwhile that link to the GDoc is right there in Slack so that anyone can have a look and we can easily find it again later.

Development Process

Wiring up app integrations within Slack has proven to streamline our dev workflow as well. In particular, we leverage GitHub and Trello integrations for each project. Trello updates show up directly in the corresponding project channel so that we can see when tasks have been started and finished, or when comments are added that may elicit feedback and input from others on the team.

The most important functionality that we use for GitHub integrations are the pull request and comment notifications. When a pull request is submitted, that notification appears immediately in the project channel so that another team member can pick up that review and get the code merged. Working between the east coast and Amsterdam, I'll often finish my day lining up my pull requests to be picked up in the morning, CET.

Availability

The Slack app works great on both desktop and mobile devices, and allows universal access to everything going on in the company from wherever we are - absolutely amazing. We now avoid email internally and favor a quick chat or leaving a message for another team member directly in a channel.

For Your Eyes Only

We have private channels for financial and legal conversations in addition to using the direct messaging capabilities for more private conversations. Slack provides all the right levels of access that we need to operate our business without distracting folks with irrelevant conversations that belong off of the project-specific channels. And security has never been a concern with the use of two-factor authentication and secure communication links.

FOMO

It's not all rainbows and unicorns though: one downside to Slack is that it can be distracting if you don't establish your own boundaries around it's usage. When there is a lot of chatter there is a nagging feeling like you need to catch up or immediately see what's being said. Most of the time, that's not the case - if someone needs your attention the protocol that we've established is to mention them directly on the channel or direct message them to initiate a conversation. Instead, set your own times to dive in and get caught up when it is least disruptive to your day.

Impact

The most significant contribution that I have seen come out of using Slack for the past couple of years is that it has become a knowledge base for Proto. Our identity has formed and evolved through the persistent conversations that have occurred on those channels and we have consistently refined and improved our internal processes. The result is a tight-knit team. We continue to be more and more effective when coordinating efforts and determining how best to approach any given project, largely because Slack has enabled us to iterate rapidly.

GitHub

tl;dr

Allow me to preface this part by saying that there are plenty of alternative hosted git solutions out there - Atlassian bitbucket, AWS CodeCommit, and GitLab to name a few. For us, we were already pretty sticky on GitHub from years of working with the service and the general prevalence of reference material that is available there. It felt like a natural extension for each of us to continue using it and pay for the ability to host private repos.

As with all hosted services now, GitHub recently began offering a per user per month payment plan with unlimited repos - we haven’t pulled the trigger just yet because then rather than managing our number of private repos we have to pause when considering whether to add access for users. To us, adding new team members is much more important and we need to be able to evaluate a fit by collaborating on code.

Slack works much better in this way with the ability to add single-channel guests, but to only charge for a user when we bring that user more fully into the mix - 2 or more channels. Perhaps GitHub will consider the same with respect to private repos. It would be great to be able to add a user to one or two private repos for free before they become a paid account on the organization.

Google Apps

tl;dr

All Proto contributors get an @buildproto.com email address. It makes external communication with clients and service providers uniform and consistent when our email lives on the same domain. Not to mention that this is a simple, fast way to establish the feeling of belonging for every member of the team. You're working with us? Here's some @buildproto.com for ya.

We use google groups for shared accounts so that we can add or remove individual project contributors to the group related to managing any particular 3rd party account. This way they can reset the password (if our 1Password process described below fell down) or deal with account notifications when necessary. Any and all emails related to that account are received by the group and we can then coordinate internally via Slack.

Another great trick that we use a lot with Gmail is the address alias for service-specific email accounts. It's a pretty old hack but nevertheless invaluable for managing the influx of information once you've submitted your email address to that new service or email subscription that you are checking out.

And finally, we rely on the various Google Apps that are seamlessly integrated - Google Docs, Sheets, Draw, and Hangouts. Google docs is great for collaborating on strategy, proposals, app concepts, business cases, email drafts, and anything that fits best in a written format. Sheets is great for data analysis and test planning. Draw for product workflow diagrams and even low res mocks. And Hangouts has served as a great alternative to Skype and is my preference when a screenshare session will be helpful.

Apple Developer

tl;dr

Because you don't really have a choice if you want to build and distribute iOS (macOS / tvOS / watchOS) apps. That said, even given the choice I would continue to pay to build products and services within the Apple ecosystem. Having worked with both Android and iOS, I far prefer working in Xcode and with Apple devices. The limitations are not overly onerous and the far less fragmented device targets mean that we can spend more time on creating a better experience.

Invision

tl;dr

The biggest value-add that we've found with Invision is the ability to establish a high fidelity look and feel in a mobile app form factor. The result serves as a kind of pretotype for a client concept. We have used Invision apps to test the reaction of target users to a new idea and even to pitch investors without having to actually develop a functioning app.

The distribution aspect of an Invision app is a big win, too - as easy as providing a user's phone number. They receive a text message with a link to the app and the site walks the user through placing it on their home screen for a more authentic feel to the experience.

The final piece that's worth mentioning is the collaboration tools built in to the app editor. You can make comments on a specific point on the design concept and begin a dialogue that's focused on that particular element. This comes in incredibly handy when you are iterating on layout and interaction components.

Heroku

tl;dr

We are often asked by clients to deploy a production platform on Amazon AWS. In our experience, standing up a production architecture on AWS is not yet an insignificant undertaking1. What this amounts to is time spent on operations just to run the production system that would be better spent on platform features and robustness in the early days. Your first 1000 users aren't going to care about whether your service is hosted on AWS, but you can bet they will care a whole lot about how polished your product works and feels.

Heroku has been our go-to hosting solution; and it's built on top of AWS. It will be a bit more expensive on a monthly basis but only if you don't factor in the devops cost of standing up and maintaining an AWS rollout. With Heroku, you can focus the vast majority of your time building, testing, and refining the product. Once you are growing your user base and have begun gaining traction, that's when you should consider investing in standing up that AWS architecture and migrating. Though even then, it depends from product to product.

1 Perhaps that will change with this post that Segment published during the writing of this post. Thanks for sharing, Auke!

ReelContent Apps

tl;dr

Getting those first 100 or 1000 users is critical to understanding whether there's any value in what we're working on. So while we strive to refine the core experience, we have to balance that with releasing the product and learning whether anyone actually wants it. Lean Startup. MVP. Release often and break things. It's a balancing act between the famous Reid Hoffman quote, If you are not embarrassed by the first version of your product, you've launched too late. and one from 37signals, Build half a product, not a half-ass product. The folks at Buffer have a good view on that here.

Once we do launch, one nut that we have yet to crack is effective app distribution. We just recently began evaluating a new platform for automated app advertising, ReelContent Apps. We have a campaign running for our app, Pastime - an audiobook and podcast player geared towards the visually impaired. As of this writing we're just over 1600 views and have seen ~7% click-through rate. We haven't released a new version yet with the tracking pixel code needed to track installs but we'll be getting that into our next update.

We have experimented with Adwords for paid advertising, but my general sense is that it is most effective once you are prepared to commit a more substantial amount of funding to the service and over some minimum time (3+ months). To be fair, we have not explored what that minimal effective funding level should be. You could always go by what Google recommends but that feels a little like one of the little pigs enticing the big bad wolf to have some bacon.

What I like about ReelContent Apps is the sheer simplicity of it. I signed up, entered our app information and the service magically constructed an ad to distribute. It pulls content from the Apple app store listing and constructs a clean, well-presented ad unit. Support for Android is in progress. After some questions about our target audience, the platform went ahead and started the ad distribution right then and there. My initial reaction to the lack of control over the ad itself was that it felt wrong. But then that's also the beauty of the tool. I don't have a marketing background. The service automatically creates ads it knows will work and then optimizes them behind the scenes. We benefit from their experience managing digital ad campaigns. As I see the views and clicks streaming in I feel increasingly comfortable with the process.

We will ideally see steady exposure of the app, and installs that result from folks that come across the ReelContent Apps ad.

1Password

tl;dr

One of the challenges of working in a distributed team across multiple timezones is ensuring that each team member has access to the various accounts that are being used on any given project. These accounts may include a Facebook app, Twitter app, or an API Service (such as Cloudinary). We then have multiple accounts for each environment as the project progresses - development, staging, and production. Using this tool prevents us from getting blocked on account access when we are testing or working on features. Not to mention that 1Password works on mobile devices and integrates with the browsers we use.

We've each been using 1Password for managing our accounts for over a year now. Because we started using it in early 2015, we purchased licenses since that was the only option at the time. I use it for all my personal accounts as well. 1Password for Teams was launched just recently as a monthly per user subscription and we've been evaluating it internally.

With teams, we are able to share a “vault” for our dev accounts, but is it much better than each storing the passwords in our own vaults? Only if you are concerned about the ability to revoke access to the vault, it seems. The prospect of having shared vaults rather than our current process of sharing the account credentials so that everyone can add new logins to their individual installations is promising. We are a small team, though, so our current process is not overly cumbersome. The end result is that purchasing the licenses was absolutely worth it and we most likely will not introduce a new monthly expense with a Teams subscription.

Wrapping it up!

This amounts to all of the software and services that we pay for in our product development process. If you're also interested in the operational aspects of running an international agency, my Co-founder captured a more comprehensive list of our business costs in his post last year, So How Much Does it Cost to Run a Startup.

Do you subscribe to any other solutions for product development or distribution that you'd recommend? I'd love to hear about them in the comments!

Written by Sean Kirkpatrick on July 5, 2016