A letter to Convex
December 20th, 2024
All of these are my opinions/perceptions as an outsider. If my tone is arrogant, it’s only because I prefer to advance a strong opinion and have it taken apart, instead of putting around politely.
Convex originally aimed to be a general tool for frontend developers. Like Parse or Firebase before it. However, the database market has grown much more crowded since then, with incumbents and startups alike. “Convex vs X”’s writeups are testament to this. In such a red ocean, Convex needs to target a narrower segment. Who is the customer? What problem does it solve for them?
You told me it was for hobbyists. Internal or weekend apps. If that’s the case, Convex needs to stop building more features.
It’s tempting to “round out the platform” with features. Functions, scheduling, etc. Remove all the objections someone might have to using Convex. Features are great for enterprise sales teams, where you’re rip&replacing an existing database. But Convex is chasing the bottoms-up go-to-market, like GitHub, Segment, Sentry, Vercel, etc. Lots of product people do this, mostly because they hate the idea of sales people pestering them to build out SSO/RBAC/SOC2.
But bottoms-up means you need to be really good at evangelizing. Not only do you need to solve an unsolved problem, you need to convince people it’s a fucking problem.
“Perforce checkouts are fine.” No, it fucking sucks when someone in India forgets to check the file back in. Decentalized VCS is the right thing to do. “Logs do the same thing.” No, they’re fucking awful because they’re a bunch of garbage when you REALLY need to get to work. In fact, Sentry wasn’t even about monitoring. It started off being about continuous deployment. When you’re continuously deploy code, you need to know immediately when something breaks so you can roll it back or better yet, deploy a fix. Cramer’s earliest evangelizing wasn’t “your monitoring sucks.” It was “your once-a-week deploy sucks.”
Sure, frontend APIs and syncing code sucks, but Convex is far from the only solution. You’re not evangelizing the problem because you’re one of the smaller names. Maybe in 2020, Supabase hadn’t built up such a large presence, but it’s 2025 (almost) and Supabase is yelling “Build in a weekend; Scale to millions” much louder than y’all and it’s too late to catch up: https://npmtrends.com/@supabase/supabase-js-vs-convex-dev-vs-edgedb.
Time to go back and ask: who is the customer and what problem are we solving for them?
When asking this question, a sneaky mental block is that Convex already has written so much code. Code’s a prison. It literally codifies your thinking, limits your flexibility.1 After all, maybe the smart thing to do is throw it all away and just become an AI company, whatever that means. But now, it’s like you’ve written the most beautiful wedding speech ever…if only you could find the right wedding to read it at.
Forming hypotheses on a “product-market fit” is weird process. Testament to this is how the weirdest things become companies. Remember jsfiddle.net? Well now, codesandbox.io is a VC-funded company. Gem used to be just a chrome extension for filling in Linkedin fields. Sentry used to be a django plugin. Segment was a script to test out their competitor’s analytics. How about jekyll.rb? Eventually gatsby.js came along became a company. Facebook didn’t monetize yarn, but Astral is gonna try and monetize ruff and uv. vite is a bundler…that is also a company. How about ngrok? Or asciinema? Or requestbin? I suspect a lot of these tools didn’t think they were “markets” at first, just useful little hacks. But I suspect because didn’t intend for them to be businesses, the “founders” were much better at filtering for usefulness and not lucrativeness. Not all of them became businesses either: lunr.js, flask, tons of open source libraries. But the ones that could be monetized necessarily were great bottoms-up businesses.
At Numeracy, we tried “analysts at startups”, which is not too far from Convex’s “hobbyist developers.” And the people who used us, liked us, but they didn’t LOVE us. I remember there was a feature that they loved: a csv uploader. It was a gross feature: it just generated a huge INSERT statement. We mostly had it for loading test data for ourselves. But for a few people, their eyes lit up. Real world analysts do a lot of ugly data loading. Maybe we should have just created a Numeracy chrome extension. “CSV to SQL” or something. Let you copy paste INSERT statements into Mode or Tableau. Maybe it wasn’t a business, but maybe it could have been our wedge into building an audience.
I don’t really have much specific advice. After all, I failed to find an answer for Numeracy. We did the same thing you did: set a goal to grow X every month. It was good, mostly because it forced us to face the music. And I don’t mean for this to be some kind of treatise or thesis, despite its rambling length, just a background to my thinking. What I’d really love to discuss next time is still the same questions I raised in the beginning: Who is the customer? What problem does it solve for them?
-
Even after Snowflake acquired Numeracy, our code limited our thinking. ↩