The 6 Core Principles That Guide Our Engineering
Every engineering team has a culture. The only question is whether that culture is accidental—formed by the loudest voices in the room—or intentional. At our scale, relying on "common sense" isn't enough because common sense isn't common.
We wrote these principles not to hang on a wall, but to be used in code reviews, design docs, and post-mortems. They are tie-breakers. When two smart engineers disagree on a direction, these principles decide the winner.
Ship to Learn
Perfect code that hasn't shipped is worth less than imperfect code that is in users' hands. We don't optimize for lines of code; we optimize for feedback loops. The longer you wait to ship, the higher the risk that you built the wrong thing.
The Litmus Test
"If we slice this feature in half, can we ship it this week instead of next month? If yes, do it."
Boring is Beautiful
We choose "boring" technology. We use Postgres, not the latest graph database. We use standard REST, not experimental protocols. We spend our Innovation Tokens on the product, not the infrastructure.
- Resume Driven Development
- Maintenance Driven Development
Write Code for Humans
Code is read 10x more than it is written. Clever one-liners are forbidden. If you have to explain how your code works in a comment, refactor it. If you have to explain why you wrote it, keep the comment.
You Build It, You Run It
There is no "DevOps team" that deploys your code. If you merge it, you monitor it. This aligns incentives: developers write reliable code when they are the ones getting paged at 2 AM.
Disagree and Commit
Consensus is slow; commitment is fast. We encourage rigorous debate during the design phase. Challenge assumptions. But once a decision is made, we all row in the same direction—even if you voted against it. Passive-aggressive "I told you so" behavior is a culture killer.
Automate the Pain
If you have to do it twice, document it. If you have to do it three times, script it. We don't tolerate manual toil. This applies to deployment, testing, and even onboarding new engineers.
> make test
> make db-migrate
# If it isn't in the Makefile, it doesn't exist.
Want to work this way?
We are always hiring engineers who care more about the product than the stack.
Inquire about Jobs