Ask HN: Founding a remote-first startup – takeaways and tips?
I'm currently considering founding a new startup in a fully distributed fashion, where the first team members would be located across geographies and (to a less broad extent) across timezones.
A lot of the tips online about remote-first orgs are targeted towards orgs at a later stage where they already have a mature product and are focused on maintenance/growth. This new startup would be in the early discover (pre-product market fit) stage.
I'd like to hear experiences & tips from startup founders/employees that started from team member #1 as remote and before they found product-market fit.
What worked for you? What didn't? Would you found a remote-first startup again given the chance?
Other details, in case helpful to think about:
* NewCo's product would be in AI space and purely digital * NewCo's customers would be globally spread out, with a decent concentration in San Francisco but otherwise very globally spread out
Thanks and keen to learn from the HN community! We did it and I'd definitely do it again but my whole team is in the same timezone. Our situation is a bit particular because we sell software development services while using the funds to create our own product. I'd suggest you to think again about being fully distributed, getting it right is hard and you may want to invest such a effort in the product itself. If you can find someone like-minded who knows the stack you want to use to build the product and you can get along with them well, consider doing weekly (or more frequent) zoom calls. Globally distributed means somebody's gotta take one for the team for timezones. But maybe that's fine in this situation. It's just hard to vet people and be sure that your intentions are connected and calibrated unless you spend a lot of time together, so if you can bridge that via Discord and Zoom and texting you might be able to make it work. But you'll need a fairly clear vision of what you want to bring into the world, and be able to convince other people it's your strongest idea and you wanna roll forward with it all the way. I have had varying levels of success making cofounder friends in online slack programming channels for <language you like> Super helpful take, thanks! I worked with a small (4 to start, then up to 20-ish) group of people for about 20 years, starting at a university research group, moving to a startup, through prototype, early product, pivot, and finally to mature products. Always spread over multiple continents: Europe, US, and Australia. You need some facilitating technology: * A good chat system. Slack is ok, but its message threads are terrible. And threads are really good for context, which is really important if conversations need to spread out over time. * A shared whiteboard. Lots of people think well while diagramming, and it's a great way to communicate ideas and evolve them. There's a lot of bad whiteboards out there. It's probably worth buying a big iPad and pen for everyone just for this: if you have to use a mouse and draw like it's Visio, you've killed it before you start. * Integration between your repository (git?), your CI system, and your chat tool. When people aren't in the same room, or at the same coffee machine, this is a great way to build peripheral awareness of what's being done. * A wiki, but ... it's useless unless the culture is built to make curating it part of everyone's responsibilities. Given timezones, you need information to be available in written/drawn form. A badly manged Wiki is just a dead zone, but a good one is a fantastic resource for coworkers (and your forgetful self!). * A final tech thing: we found that keeping a daily, public log of what we'd done and how we'd solved issues was useful. Just a few bullet points, a few cut'n'pasted command lines, and some text explaining what and why. Aside from documenting solutions to problems, it's also a great resource for seeing how things developed to where they are, and why. If you keep it in the wiki, it can be easily searched, and becomes part of the shared knowledge. So far as timezones go, there's advantages to being far apart: Asia/Australia and east-coast US for instance means you get two chances to catch up in real-time every day, whereas Asia/west coast is usually just one. Realistically, you need to be flexible about work hours: a quick check of messages when you wake up (possibly logging in to resolve urgent stuff), early calls, then a break before work proper, then a break in the late afternoon before a late evening check, answer questions, and maybe another quick call. Everyone kinda needs to be committed to this, while realizing that it can't be _every_ day. Calls/video/meetings are productivity killers if they happen too often, or run too long. Treat them like they're costing you a lot (and they are). So far as early-stage customers go, having folks in different timezones can help a small company to be super responsive: someone can work on a customer query or issue overnight, and you can get back to them first-thing the next day. It really helps you look professional. I should add one thing: It's really far, far better if there's no "head office". Once you do that, everywhere else becomes second-class by default, and suddenly it's up to them to bend their schedule to fit with call times that suit head office, or people have meetings at head office that don't include remotes, and so their opinion isn't considered and often they're not even told what was discussed or decided. It's hard to do, but making sure that everyone is treated the same is really important to making remote team members work effectively. This is much easier when you're super small, but maintaining it as you grow is crucial. Amazing concrete, thorough advice -- thank you so much for taking the time to share it with me and others in the same boat! > Integration between your repository (git?), your CI system, and your chat tool. When people aren't in the same room, or at the same coffee machine, this is a great way to build peripheral awareness of what's being done. Can you please elaborate? I mean technically do you mean just something that takes git PRs. CI statuses, error traces, etc. and sends push notifications to Slack/Teams/etc., or something more sophisticated like GitHub Actions committing realtime meeting transcripts and their AI geenerated summaries to a git repo? The former. We found it really useful to see, in a way that you could read and ignore, who was committing what to where. It helped you keep up with what was going on, who was working where in the codebase, when things that might impact you changed, etc, all without any explicit effort save for writing decent commit messages. Particularly when you're all in different timezones, that kind of casual background knowledge is really useful for keeping everyone on the same page. You can scan through the messages to see what's happened in the code overnight in a few minutes. In my expirience people tend to ignore autogenerated messages in Slack. The problem is non-technical people who are too lazy to read git commit messages, or PRs. I had some Scrum PM who was bothering me with updates, so I was just copy-pasting git commit messages into Jira tickets (commit messages even mentioned the Jira ticket numbers - so it was just one hyperlink click away) ;) Only top-level executives deserve carefullly drafted repoorts and presentations, PMs should be able to use the same tools as their teams. We didn't use Slack, and I think the difference was that our chat tool didn't split up the display of channels. The thing we used had a scrolling tickertape-style window. Commit messages would scroll across once, and then they were in the history. So if you were online, you could glance at the committer, and commit message, and that was it. No need to switch to the channel, click anywhere, or do anything, it was just ... there, and then gone. The history window was similar. It was threaded (replies indented under the message they responded to), but everything was in one list by default. So you could just skim down, and catch up on what was done pretty simply: no clicking into groups, no looking at message counts, etc. Slack is really not the best UX, in my experience.