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.
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.
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.
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.
We believe in working together towards a common goal, without rigid boundaries on what you can and cannot do. We'll come together and define outcomes as a team, bring intensity and urgency to achieve them, and reflect afterwards on what we could've done better. This means a high degree of autonomy, but also a deep responsibility to work with the rest of the team to figure out what's next.
If you think we should have an engineering design review for a new feature, then let's set it up. Think we're not investing enough in our testing automation? Propose a better plan to the team.
It's up to you to determine the best way we can achieve our outcomes, and your ownership is not limited by your title. Stir is your company as much as it is anyone else's and if you see something anywhere in the company that could be improved, you should jump in (and expect others to do the same). We're all owners - what matters is the quality of the end result, not where it came from.
We want to change how the next generation of businesses operate. That's a big goal, and it's not something we're going to achieve without constantly trying new things and learning from our mistakes.
Have strong conviction in an idea that's not currently on our roadmap? Talk to users, design mockups, build an MVP - whatever it takes to convince the team (and yourself).
We're also not afraid of throwing code away. We work hard at making sure developer productivity and velocity are high, so hacking together new ideas is easy. Build something quickly, get it out in the world, and learn whether or not it solves a real problem.
If you want to see this in action, take a look at some of our Drops. Drops go from idea to launch in under 3 days and have been used by 100k+ creators so far.
