i'm also equally impressed by their background, and puzzled that they choose to target frontend developers rather than backend developers (who presumably they would be much better able to solve problems for?)
Hi Shawn. I don't remember you bringing this up when we spoke in person recently, but it's a great question.
In our opinion, the very best way to evaluate yourself as a backend developer is how directly you solve problems for frontend developers. We believe in the merit of customer obsession, and the customers are not buying queues. They're buying the product as they see it: its surfaces, workflows and experience. And that's what the frontend developers, PMs, and designers are creating.
Historically, all these backend technologies that only interoperate with each other are only useful so long as they make product creation and improvement easier, more reliable, etc. We strongly believe as soon as you don't need them anymore, you should toss them out. They're complex and not proprietary to your product.
Convex (and serverless in general) is just the next step in providing more powerful abstractions that allow companies to double down on frontend engineering (work that adds product value) instead of reimplementing the same backend/devops plumbing the users never see (work that, at best, merely sustain product value).
So, given that we recognize this need, I respectfully disagree that we're not well equipped to solve these problems for frontend developers! Most of our team's recent our work has been designing synchronization and storage platforms to enable product development, including work on web, desktop, and mobile libraries/SDKs. We feel like we have both a lot of empathy and experience for this space, and we're very proud of our early product and the enthusiasm from the web dev community.
hey jamwt! no i wasn't thinking about this at the time, someone mentioned it when discussing Convex and I thought "huh, thats an interesting way to look at market-founder fit" so I just tossed it out there.
great answer :) if you can solve DX for frontend you're solving it for everyone.
I was the one of the original TLs of Google Photos, specifically on Android and eventually managed all of the frontend teams for Google Photos. So I hope it's not a stretch to say that I have deep empathy for frontend problems. We also have great frontend oriented folks on the team.
I also worked with jamwt at a previous company (Bump) doing frontend work. When we worked together, I remember the acceleration of our ability to execute when the backend people were closely involved in our data syncing problems. Heck jamwt and team even wrote most of the initial client syncing code. When backend and frontend folks work closely together to solve data problems you can make magical things happen. In the end we're just product oriented engineers trying to ship delightful experiences.
Hi Shawn. I don't remember you bringing this up when we spoke in person recently, but it's a great question.
In our opinion, the very best way to evaluate yourself as a backend developer is how directly you solve problems for frontend developers. We believe in the merit of customer obsession, and the customers are not buying queues. They're buying the product as they see it: its surfaces, workflows and experience. And that's what the frontend developers, PMs, and designers are creating.
Historically, all these backend technologies that only interoperate with each other are only useful so long as they make product creation and improvement easier, more reliable, etc. We strongly believe as soon as you don't need them anymore, you should toss them out. They're complex and not proprietary to your product.
Convex (and serverless in general) is just the next step in providing more powerful abstractions that allow companies to double down on frontend engineering (work that adds product value) instead of reimplementing the same backend/devops plumbing the users never see (work that, at best, merely sustain product value).
So, given that we recognize this need, I respectfully disagree that we're not well equipped to solve these problems for frontend developers! Most of our team's recent our work has been designing synchronization and storage platforms to enable product development, including work on web, desktop, and mobile libraries/SDKs. We feel like we have both a lot of empathy and experience for this space, and we're very proud of our early product and the enthusiasm from the web dev community.