TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: Founding a remote-first startup – takeaways and tips?

11 点作者 soroushjp将近 2 年前
I&#x27;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.<p>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&#x2F;growth. This new startup would be in the early discover (pre-product market fit) stage.<p>I&#x27;d like to hear experiences &amp; tips from startup founders&#x2F;employees that started from team member #1 as remote and before they found product-market fit.<p>What worked for you? What didn&#x27;t? Would you found a remote-first startup again given the chance?<p>Other details, in case helpful to think about:<p>* NewCo&#x27;s product would be in AI space and purely digital * NewCo&#x27;s customers would be globally spread out, with a decent concentration in San Francisco but otherwise very globally spread out<p>Thanks and keen to learn from the HN community!

3 条评论

AlexITC将近 2 年前
We did it and I&#x27;d definitely do it again but my whole team is in the same timezone.<p>Our situation is a bit particular because we sell software development services while using the funds to create our own product.<p>I&#x27;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.
cushpush将近 2 年前
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&#x27;s gotta take one for the team for timezones. But maybe that&#x27;s fine in this situation. It&#x27;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&#x27;ll need a fairly clear vision of what you want to bring into the world, and be able to convince other people it&#x27;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 &lt;language you like&gt;
评论 #36841883 未加载
__d将近 2 年前
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.<p>You need some facilitating technology:<p>* 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.<p>* A shared whiteboard. Lots of people think well while diagramming, and it&#x27;s a great way to communicate ideas and evolve them. There&#x27;s a lot of bad whiteboards out there. It&#x27;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&#x27;s Visio, you&#x27;ve killed it before you start.<p>* Integration between your repository (git?), your CI system, and your chat tool. When people aren&#x27;t in the same room, or at the same coffee machine, this is a great way to build peripheral awareness of what&#x27;s being done.<p>* A wiki, but ... it&#x27;s useless unless the culture is built to make curating it part of everyone&#x27;s responsibilities. Given timezones, you need information to be available in written&#x2F;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!).<p>* A final tech thing: we found that keeping a daily, public log of what we&#x27;d done and how we&#x27;d solved issues was useful. Just a few bullet points, a few cut&#x27;n&#x27;pasted command lines, and some text explaining what and why. Aside from documenting solutions to problems, it&#x27;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.<p>So far as timezones go, there&#x27;s advantages to being far apart: Asia&#x2F;Australia and east-coast US for instance means you get two chances to catch up in real-time every day, whereas Asia&#x2F;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&#x27;t be _every_ day.<p>Calls&#x2F;video&#x2F;meetings are productivity killers if they happen too often, or run too long. Treat them like they&#x27;re costing you a lot (and they are).<p>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.
评论 #36841944 未加载
评论 #36873611 未加载