How We Build

  • We want to be a team that ships. Most importantly:
    • “People choose what to work on. Better they ship what they want than not ship what you want.”
    • “No tasks longer than one week. You have to ship something into live production every week – worst case, two weeks. If you just joined, ship something.”
    • “Peer-management. Promise what you’ll do in the coming week on internal [chat]. Deliver – or publicly break your promise – next week.”
    • “One person per project. Get help from others, but you and you alone are accountable.”
  • Fixing bugs takes priority over everything else.
  • We have to optimize for speed. Why? Because everything is changing — constantly. If we’re too slow, we fall behind.
  • Optimizing for speed means: keeping the surface area small (less features that allow you to do more; when in doubt: no feature; see FIF), shipping constantly, asking “how will we debug this?” and “how easy to remove is it?” from the start.
  • We have to optimize for robustness. Every pixel matters and every millisecond matters.
  • We don’t do big releases. We constantly merge and constantly release.
  • No code reviews for core committers. You merge it, you own it. Owning it means: you make sure it works, you keep fixing it, you are responsible for it. Conversely: don’t merge things you can’t own.
  • We must build for where the puck is going, not for where it is.
  • Every member of this team must talk to customers and users. Join the Discord, reply in the Discord.
  • People on this team share and promote their work. The product is how we sell this. It’s not only marketing’s job to make sure you have a product that users want to use.
  • Treat this as if it were your own project.
  • Dogfooding is a superpower. Ship, use, iterate.
  • Embrace how AI is changing how we develop software. Prototypes over RFCs and discussions.
  • Hours and days over weeks and months. Instead of “next week”, why not “this week”? Instead of “tomorrow”, why not “today”?