We're on a mission to grow the size of the creator economy. Our customers trust us to help them run their businesses, and we work tirelessly to build great products that do just that.

Engineer with purpose

Our creators want us focused on building mission-critical tools to help them run their businesses, not managing servers or spending countless hours thinking of the "perfect" abstraction. We actively work to outsource everything we do that isn't core to our mission.

We won't be building our own database or hosting logging infrastructure in-house, and we never engineer for engineering's sake. If you ever encounter work that doesn't line up with this, you're expected to speak up and remind us all that the real goal is always solving problems creators face, and that code is just another tool to help us do that.

Form an opinion

We're in the first inning of a global shift in how people view their relationship to work. Many of the tools that will power the next generation of businesses don't exist yet, and they will look unlike the tools used today.

Here are some questions we find ourselves thinking about:

Engineering at Stir is much more than just writing code. We care a lot about finding the truth and developing an opinion on what needs to exist in the world.

Sometimes this requires writing code, other times hacking together a mockup in Figma and showing it to users (and sometimes, you just have to get really good at searching comments on Reddit). You don't have to come in being an expert at operating this way, but you should have a drive to learn.

Balance speed and focus

We don't believe the choice between "move fast and break things" and "build it right the first time" is a binary one. Each comes with tradeoffs and requires a different mindset, but we believe the two can coexist.

Building a payments product? Creators entrust us with their businesses and we cannot afford to make mistakes here. This means we move carefully, write design docs, run exhaustive testing, and don't take any shortcuts.

Building a never-before seen invoicing product? We bias towards rapid iteration so we can learn from real users and better understand what they want. We may have bugs (that we quickly fix), but in the long run this approach helps us build better products.