When Anthony and I started working together to prototype ideas for how to make sharing easier, we knew we didn’t want to drown in different tools and processes. We wanted to focus on learning from each other, having fun, and building something great we are proud of. Now that we are a team of three we are even more aware how easy it is to accidentally add way too many tools or processes. We try to weigh the cost of adding yet another tool to our mix each time something new comes along.
Here are five tips we believe can help make it easier to work together, get an app built, and out to the world. The gist is: keep the total number of tools and processes to a minimum and keep communication simple, fast, and available at a fixed URL.
Tip 1: Use 1Password
You will need a place to store passwords, secrets, company credit cards, and notes that need to be kept secure and private and 1Password is the best place to keep that stuff. We recommend 1Password because all data is encrypted before leaving your devices, so the 1Password team cannot see inside your “Vaults.”
They have also spent the time to make a very nice Web SPA using WebCrypto so you can get to everything directly in your browser if you ever need it. And the Team accounts are easy to setup on the web and super quick to get everyone going.
We cannot recommend 1Password enough.
Tip 2: Use GitHub
No matter what you are making, you’ll need a place to keep source files and keep track of what’s next to do. We use GitHub to store the source of everything we create. We use a GitHub Project to have a board to show what is upcoming, in-progress right now, and completed. And we use GitHub Issues for writing about any idea, bug, or just to have a home for a conversation or decision.
If you are making an app, a website, or writing a movie script, you can keep those files in a git repo and get versioning and collaboration through Pull Requests. Having a history of all the changes for a project in one place is incredibly valuable. Create a new Organization to keep all the repos for your app/service together.
We have repos for important business documents, design files and discussions, journals for each of us, links and books we have read or want to read later, and of course apps and services in a variety of languages. We use Issues so every conversation has a URL and we use Pull Requests to signal big changes, even for simple repos like a reading list. The built-in code editor is OK for making quick changes and the upcoming Codespaces could make quickly collaborating on code even easier.
We cannot recommend GitHub enough. We use it everyday, we pay for it, we ❤️ it.
Tip 3: Don’t Send Emails
Give every conversation a URL. For a longer conversation or anything that needs to come to a decision or resolution: we create an Issue inside GitHub. We have an
hq repo in GitHub and it has become a place to have our more general conversations. We cannot stress this enough: giving every conversation a URL is a super power.
Emails are too easy to lose or forget. Also, adding someone else into an existing conversation is not easy by email: it requires us to include the entire message history inside every reply which is super noisy.
If you need to write up a document of some sort, then make a shared note or document and collaborate there. This is useful to get a first draft ready before posting it to a repo (hopefully as Markdown), collaborate on a response to some important correspondence, or just to have a place to dump random thoughts that don’t need discussion or iterations.
If you have a question and need an answer quick then go for a messaging app. Just be aware that chat programs are ephemeral. Everything you send will slowly scroll back into time and be lost into the ether. Also, consider: do you really need an answer right now? Defer to asynchronous communication as much as possible. However, don’t wait too long to ask a question and waste time when a 5 minute conversation could have saved hours or even days of effort.
Remember: take any idea, decision, document, presentation, or anything else and move it over to an issue or a file in a repo so it gets a permanent URL.
Tip 4: Use a PaaS
Don’t waste time on DevOps when you don’t have to. It can take a lot of time to get your servers, deployment pipeline, websites, etc setup and it’s almost always not worth it at first. Spend time on your app and get it out to customers. We recommend Netlify and Heroku to speed up getting your stuff onto the internet.
If you are developing a service or API then deploy it to Heroku. Don’t try to get setup with AWS or DigitalOcean before you’ve gotten everything running on Heroku’s Hobby tier. You can run rails, python, phoenix, go, anything and you can even deploy docker containers if you want. The question to ask is “Why won’t Heroku work for you?” Heroku’s professional-level dynos and managed databases are 2–3× the cost of AWS’s EC2 and RDS and they are 100% worth it.
If you are a building a website or SPA then we recommend using hugo, eleventy, or next to build it statically. Deploy your website to Netlify: full-stop. We also like Vercel, but we’ve found Netlify to be a bit easier for us with our particular setup.
If you are not a web developer then we recommend Webflow for building a website. If you need an e-commerce site then go for Shopify. Try to get as much from these platforms as you can without too many customizations: simpler is easier to maintain. You don’t want to be stuck fixing your website when you could be working on your app.
Tip 5: Everyone Uses the Same Platform
We use Mac’s and iPhone’s and we recommend them. By using the same OS you get a ton of functionality “for free” like messages, video calls, screen sharing, and more from macOS and iOS. Sure, there are tons of tools which try to help with cross-platform collaboration, but we’ve had trouble sharing and working with each other even when we are all on the same platform. This is one of the original reasons we started prototyping ideas for Shareup: to make working with each other across devices and platforms possible and easy.
By using macOS, we get a lot of built-in functionality that we use every week to work together. The first is Messages for private group messaging. We use FaceTime Audio or Video for group calls. We think the quality of FaceTime is the best available and FaceTime Audio is way better than a phone call. Sometimes hoping on a quick voice call for 5 minutes can save hours of back and forth.
Screen sharing can be initiated from Messages to collaborate on code and designs. The built-in screen sharing automatically sets up an audio call so you can talk while either observing or controlling each other’s screens. We think the OS-native screen sharing is the most reliable available; however, it is only 1-to-1, so it’s not possible to share a screen with a larger group. Related: screen recording on both macOS (⌘⇧5) and iOS (keep it in Control Center) makes it easy to make demonstrations and send them for asynchronous review.
Pages and Keynote are good for collaborative documents and presentations. The collaboration is “good enough” and the apps are reliable and stable. Similarly, Notes and Reminders can be used to share ideas, meeting notes, lists, and important things to remember. We don’t use “cloud drive” products because they have syncing problems, are slow, and we don’t want to deal with folders, permissions, etc.
brew makes getting setup for development quick and we 💯 expect everyone to be using
brew. We use
brew in our
setup scripts for each project to keep our development dependencies in sync. We setup our projects assuming all tooling is installed with
brew’s defaults to keep things simple and predictable: for example,
postgresql are up to date and haven’t deviated from the defaults. We have not have good experiences trying to use docker for development and we don’t use containers in production, so it’s just not something we need or want to get into.
If a built-in tool isn’t good enough then by all means find an alternative and be happy 😎. We just know the cost of adding more and more tools to our toolkit and how it can slowly grow over time. We’d rather be biased toward less tooling and process.
Related: Making an iOS App Requires macOS
We are Swift programmers and we used to be Objective-C programmers, so we are very biased here. In some ways this makes it simple and easy: use macOS and Xcode. Sure, we do like Android, but we definitely always use iOS to prototype and get initial customer feedback for new ideas since it’s the platform we know best. We also are web developers and macOS is also a great place for modern web development.
What About Other Platforms?
Sure, Windows is a great OS. Android is also great 🤖. Adam is doing all our wonderful illustrations and artwork on a Windows computer and uses Android as his daily-driver. However, be aware that some things become less convenient in a heterogeneous environment. You’ll lose the built-in messaging, calling, screen sharing, document collaboration, and more and you’ll need to spend the time to find alternatives to replace each of those. You’ll need to remember “where did we collaborate on that document last week?” or “where did the URL for that presentation go?”
We can recommend Telegram for messaging and Whereby for video calls and screen sharing. We like Dropbox Paper for collaborative documents and Pitch for presentations. There are endless apps and services one could try.
Getting a development environment setup consistently on multiple platforms is more complicated and we honestly don’t have any good tips to help with that right now since it really depends on the languages and servers you use. Using the WSL (Windows Subsystem for Linux) along with the new Windows Package Manager could help get things going on Windows.
We have heard that WSL can be slow for projects with lots of little files, but we don’t have any direct experience with it so good luck. And like I said above, we have not had good experiences trying to use docker for development and we don’t use containers in production, so it’s just not something we need or want to get into.
We hope these tips can maybe help you focus and keep things simple. Did you find these tips useful? Do you disagree? What you are building? Shoot us an email or @mention us, we are interested. 🚀🆙