Hey there!
As a collective, we make tech products with a heavy data bias, like CheckStack, FRLi and Superflow.
One common thing about all of them: we like to get our stuff out there, fast!
We think it’s better to show people what we’ve made sooner & get them to actually use it rather than waiting forever to make it perfect.
As we build, maintain & improve more products, we wanted to highlight some of the core beliefs of shipping at PlayTheory:
Perfection Trap
Most things in tech are over-engineered.
Which makes changes slow & cumbersome. So when we set out to build products, we didn’t want to get stuck trying to make it perfect. This is a big problem because while you’re trying to fix every little thing, you’re not showing it to the people who will actually use it. Waiting too long can mean someone else might do something similar before you or you’ll get lost in trivial details (dark mode for example)
Product Development
Core Functions Over Non-Core: We focus on the most important parts of our products. This means we don’t spend time on stuff that doesn’t really matter right away.
Prioritizing Speed Over Technique: Too many people in Tech are too romantic about the technique they use. Languages, Tools, Frameworks, Compilers – unless it materially improves the end user experience/outcome, we don’t spend too much time debating what to use.
Most of the time, our test is “is it simple to understand, quick to implement & stable enough to maintain”
Focusing on Functionality Over Names/Tech Stacks: What our product does is more important than what it’s called or the fancy tech stuff we use to build it. If it works and helps people, that’s what matters.
Speed Doesn’t Mean Sacrifice
Some people think making things fast means they won’t be good. That’s not true. We can make stuff fast and still make it really good. We just have to be smart about how we do it.
Method-Agnostic Development
This means we don’t always stick to one way of doing things. If there’s a better way to build something, we’ll use it. This helps us be more flexible and creative.
Our tech stack can shrink or expand depending on needs.
Engineering is a verb
There’s no value in solving LeetCode problems if you can’t solve for practical application.
All that ‘engineering theory’ needs to translate to action – ultimately.
We believe that at our core & expect the same from every member joining the team from day 1. We’re not romantic about what Engineering is as a domain but rather what it can do when you apply it to problems. We’ve seen non-engineers ship better, faster, cheaper than experienced engineers because they practice engineering instead of just talking about it (or worse hoarding related engineering information).
Early?
‘Early’ can mean different things. For some, it takes a long time to make their first version of a product. For us, we try to do it faster. We use things that are already out there – like component libraries, middleware packages, other SAAS tools ready to plug-and-play for auth, payments – to help us move quicker.
So, that’s how we do things. We make stuff and get it out there fast. We don’t wait to make it perfect, but we still make sure it’s really good.
This way, we can keep making new things and improving the stuff we already made.
Thanks for reading!
