There seems to be a service for almost every function of a web or mobile app, and we stumble across different and new flavors of the same type of services each and everyday. There always seems to be a few ‘winners’ and then niche products that sometimes are much better than the ‘winner’ if you fit into their target persona of a persona. We could probably make this list 2x what it is, and could also recommend another 100, but the below list is our “Service Stack” that we usually role into every new product that we build
Almost all of our apps are hosted on AWS at this point. It’s scalable, dependable, and low cost. They have a ‘free’ plan for many companies in accelerators and incubators, that covers almost all the cost for the first 2 years. Their admin view could use A LOT of work, but we are extremely comfortable with it by this point. We even use AWS for storage of pictures if we use Heroku.
We use heroku for staging servers and before we deploy to AWS. Heroku is extremely easy to setup, but can get quite pricey once you start getting significant traffic.
Our preferred hosting environment for small sites, apps, and blogs. It’s super easy to setup!
Pivotal Tracker is a great product made by an amazing agency called Pivotal Labs. We use Pivotal for all of our projects, and is how we orgnaize our days, weeks, and months. Pivotal is built for agile development, and moves from Right to Left. Here’s an example of one of our clients’s board:
Here are a few things to note:
- IceBox: The icebox is where we keep ‘ideas’ and login credentials for different services we use. We’ve consulted on projects where there are 100s of stories in the icebox and backlog, so one of our first steps is to “Clean out the Icebox” This involves going through “Story” (what the
- Cards: A card is the small block / cell that holds the User Story and all relevant information for it. You’ll see things such as who the card belongs to (who the developer is) what ‘state’ it’s in (working, finished, testing, etc) comments, and detailed explanation of the story if needed.
- Feature / User Story: A User story is a short, simple description of a feature told from the perspective of the person who will be using that feature. They typically follow this method…As a “type of user”, I want “some goal” so that “some reason”. You’ll potentially see 100’s of stories for your product, and we establish them in a compounding and chronological order during the initial setup.
- Points: We assign points to each story using the fibanocci sequence of difficulty. 0 point stories are quick fixes, 1 point stories are small, 3, 5, 8, etc. However, we limit our stories to 8 points (instead of 14+) and then just make a few smaller stories out of that large story.
- Chore: Chores are necessary tasks that usually shouldn’t be quantifiable like stories. An example might be “Update SSL Certificates”. The reason this isn’t a story is because we’re not progressing the product forward, but just providing maintenance.
- Bug: A bug is bug. It’s a defect in the software that either our team, or you found. We address these based on complexity and how urgent it is for the product.
- Velocity: Velocity is a measurement of the speed of development that we are moving. Depending on your project, this number could be anywhere from 1 – 50, with most averaging around 25-30 per week. We try and make sure this number is consistent from week to week.
- Epic: We don’t use epics too often, but for very large projects where we need to categorize a lot of user stories into one major feature, we’ll label those stories under one epic.
Trello is another project management tool that we use for business and personal things. We’ve worked with a few companies that use Trello as their primary project management tool, but we don’t think it’s robust enough for it. We use it for our sales pipeline (no need for Salesforce!) because we purposely only take on a limited amount of projects at any given time.
App Development Communication
We’ve tried a bunch of different video conferences over the years, but Google Hangouts has won because of it’s flexibility and ease of use. Skype was our cowbell for awhile, but asking people to download it starting to get more and more painful. We use Hangouts everyday multiple times, and use the google calendar invite functionality to schedule meetings with a Google Hangout attached. Sometimes, we’ll throw hats on if it’s been one of those days, OR if a developer ships their app to the app store or launches to the public ;P
Yes, we use slack like everyone else. We were using Hipchat for a long time, but they made it a HUGE nuisance to switch between ‘teams’, whereas Slack made it a simple toggle on their menu. We think that’s the only reason Slack took off, but we digress.
We use slack for ‘quick’ communication. So things like “Hey Guys, standup in 5 minutes” or for small clarifications. Otherwise we try to have these conversations be on Hangouts, or on the pivotal board (so things don’t get lost in the process)
We use Gmail for email, and try to keep it to a minimum. I get something like 150 emails a day, and unsubscribe as much as possible to things. Email is where proper project management goes to die, so we only use it when it makes sense.
Google Drive and Dropbox: While we prefer Drive because it works seamlessly within the Google App Ecosystem (Calendars, Hangouts, Email, etc) we all have Dropbox accounts.
Unless a client asks otherwise, we create a project folder for each client and we store images, invoices, wireframes, and really anything else that’s relevant to the project that we need to either reuse or look at later.
App Design Tools
Sketch is an awesome design tool that’s won many awards from Apple (it’s Mac only) and was originally built for Web UI and UX. It has every tool a web designer needs, and none of the clutter like Illustrator for Photoshop (which were not made for this reason).
There are a variety of plugins like a ‘random name generator’ that make mockups easier, and it’s rapidly improving as time goes on. We’re really excited to see where this product goes!
Photoshop / Illustrator
This tagteam from Adobe has been leading the design world for the past 25+ years. One of our designers still use it because of his affinity of PC’s… but we’re starting to convince him to come to the good side. I can’t count how many times these apps have crashed because of memory issues after using a high resolution photos in a mockup, BUT it’s what almost everyone started on and were originally trained on. It’s still apart of our toolbox, but just not preferred.
BitBucket: These are two apps that allow us to save the code for all the projects we work on in the cloud, but also for multiple developers to work on a single project without sending the file back and forth to each other. Developers ‘Commit’ their code to the ‘branch’ that they’re working on, then we have another developer do a review on the code. (You can read more about this in our tech process)
The actual products are pretty interchangeable at this point (even though we prefer the UX of Github) but it’s just a lot cheaper for us and clients to have one big BitBucket account hold everything.
Web and Mobile App Marketing:
Google Analytics: Google Analytics (GA) has the been the leader in web analytics for as long as we can remember (and I can’t think of anyone before them). GA can cover every basic tracking function of your website (visits, bounce rate, links clicks, etc) and also tells you where your traffic is coming from. There’s a lot more advanced features, but we’ll let you check it out for yourself.
Mixpanel: is by far our favorite Mobile analytics tool. They have a robust, but easy to use suite of tool that can provide almost enough tracking data to make a PhD Data Scientist happy. We particularly like their ‘people’ tool, which allows you to view exact user by user behavior, and to also create cohorts of users based on specific actions taken within the app.
App UX Tools
Optimizely: The leader in A/B testing.
UsabilityTools, CrazyEgg, ClickTail: A cool way to see and actually record how users are interacting with your website. Google Analytics is a great start, but seems very incomplete without this.
Distribution and Testing
Invision and Marvel: Invision has been a game changing prototyping and distribution tool that we use on every project. It’s a simple way to upload design files, share them with clients, get direct feedback (they have a point and click comment feature) and even create a “clickable” prototype from the original untouched design.
Fabric: Fabric is another awesome tool from Twitter that was built out of Crashlytics. Fabric is a distribution platform to send out test builds quickly and easily to testers for iOS and Android apps. It allows the development team to not only send, but to track down all crashes and any potential problems for the exact user that received the build. We can then figure out that bug much faster than if we were using various services.
Fabric / Crashlytics: We’ve been using Crashlytics for the past 4 years now, and is more important than the grand majority of the 3rd party apps we install for clients. While our apps generally don’t crash, when they do, we want to know the exact reason why and when it happened. Crashlytics sends us an email whenever there’s a crash and also gives us information to ‘where’ in the code the crash came from. We’re looking forward to product enhancements!
NewRelic: New Relic has gotten quite popular in the past 3 years, and for good reason. It allows development teams to view exactly how fast and efficiently their application is performing in the market, and provides insight into how they can optimize. New Relic is installed on every one of our apps (no matter the size) because we consider it that important to the stability of our server side code. Finally, we set up ‘alerts’ that hit our slack channel to let us know if the app isn’t scaling properly, or if the server is down for whatever reason.
Sendgrid: We’ve been using Sendgrid for the past four years and is typically the transactional email service we recommend to clients. Transactional emails are the type where users are going to receive them for doing a specific thing within the app. A few examples that come to mind include “Sign Up” “Confirming Sign Up” Reset Password, Signing up for a newsletter, not being active in the app for 3, 7, etc days, or if a security alert was triggered like “too many failed password attempts”.Sendgrid just makes it very easy for apps to send ‘transactional’ email and also gives data insights into what was opened, what was marked as spam, the best time to deliver etc. T
Mandrill: Mandrill is a Mailchimp product that we aren’t as familiar with as Sendgrid, but have implemented before. Typically, SASS apps such as these become very similar over time, and just differentiate on price, documentation easiness, or how they get customers.
MailChimp: Who doesn’t love their lovable mail delivering Monkey? Mailchimp has been around for a long time and is perfect for the 99% of businesses that just want to send out a basic newsletter to their audience. They have an OK email builder, but they also allow users to upload their own, custom designed email template to send out. Mailchimp is free up to 2k subscribers and 12k emails a month, which is more than enough for the standard startup that’s just starting out.
Braintree: is a Chicago based payment processing startup (recently acquired by Paypal) that has a super secure set of tools that makes payment processing super simple (well at least to what you used to have to do…) for mobile and web applications. Braintree gives all first time users $50k in free transactions, can implement with Venmo for easy payouts (one of their brands) and are obviously part of the paypal family so you can easily implement paypal as well if you wish. We love their documentation and super helpful service team who rarely leave you hanging on a call.
Stripe: is the much more ‘buzzy’ of the payment processing startups, but has quickly moved from ‘Developer favorite” to a giant company with a huge valuation. They have a great ‘payment widgets’ that users can put on their site that handles the encryption or general development issues that would trouble junior developers, but are also robust enough to handle million and million a year like Braintree. We wish their support wasn’t so email based for business issues, but otherwise it’s great!
Active Admin: We use Active Admin (which is a ruby ‘gem’) as our go-to dashboard for apps. It’s simple, light-weight, and comes with a ton of organizational features that a user would need for a dashboard. The best part is it works directly with the database so it’s a super easy and quick setup! Highly recommended!
Other 3rd party things we like:
Apptentive: Great for asking for feedback in app, Amazing at asking for a review!
If the client asks us to sign an NDA, we typically respond with something like “Any chance we could have a quick chat without signing an NDA first?” We’ve worked on hundreds of projects, and heard countless more pitches, but have realized how similar most ideas are, or how many of the ideas pitched to us we’ve thought of ourselves in the past…
It’s incredibly difficult to execute properly on your idea, and is even harder to execute and stay passionate about it for the next 3-7 years. It’s the last part that most people forget about!
Either way, (if asked of us) we typically will sign the NDA after we hear the initial quick pitch about it. We will NOT work on competing apps, so we’d probably end the discussion if it’s too similar.
Here’s an example- If we were building an “Uber for Waffle Delivery” we wouldn’t build another “Uber for Waffle Delivery”. However, our clients do know that it’s not feasible for us to have to turn down something like a “Uber for Flower Delivery” because we’ve worked with them already. These companies are in competing markets, and most companies that are “X for Y’s” have a similar core.
To summarize, we have no problem with signing an NDA, and will never take the stance of “We never sign NDA’s” like some VCs. Rather, we’d rather have a quick chat to make sure it’s a good fit for the both of us first!
Our proposals have taken many forms over the years and the end product has never ended up precisely as it was at the start. This is for a variety of reasons, but mostly because the product details are greatly under discussed by the client (of course we MUST have viral sharing mechanisms and an affiliate program.
We store contracts in Dropbox and have a series of folders for pending, current, past, and lost clients.