A while back I introduced myself here with the standard founder-story framing: decades running databases, saw the same problem everywhere, decided to build the fix. All true. What I left out is everything I got wrong once I actually started building it -- so here's the part I skipped.
I underestimated how different "connect your cloud" actually is per provider
The pitch sounds simple: connect AWS, connect GCP, connect MongoDB Atlas, see everything in one place. The pitch does not mention that each provider's credential model is a completely different mental object.
AWS gives you IAM roles and access keys -- account-scoped by default, one policy document, reasonably familiar if you've touched AWS before. GCP gives you service accounts that are project-scoped, authenticated with a JSON key instead of a password, where the same "viewer" role has to be granted separately in every single project you want visibility into. Atlas has its own API-key-and-project-scoping model that resembles neither of the other two.
I budgeted a few weeks to build "cloud connectors." It took a full quarter longer than planned, almost entirely because every provider needed its own permission model documented, tested, and explained to users who'd only ever worked deeply in one cloud. The connectors themselves were the easy part. Teaching people (and our own onboarding docs) what a least-privilege read-only credential looks like on three different platforms was the actual work.
I had the build order backwards at first
The early plan was to ship the natural-language querying piece -- what became Query1AI -- as the headline feature, with the unified inventory as a supporting dashboard around it.
That ordering doesn't work, and it took an embarrassing amount of time to admit it. Query1AI turns a plain-English question into SQL by reading schema metadata -- table names, column names, relationships -- that has to already be mapped before any question can be answered correctly. Without the inventory and schema-discovery layer built and working first, there's nothing for the natural-language layer to ground itself in. It's not two features that happen to pair well together; one is a strict prerequisite for the other. I rebuilt the roadmap around that dependency instead of around which feature looked more impressive in a demo.
"No agents" was the right call, and also the hardest sentence to say out loud
Read-only, API-based, nothing installed on a database node -- that was non-negotiable from day one, because I'd spent too many years cleaning up after agents and sidecars that someone forgot about, that broke on an OS upgrade, or that a security review flagged as an unexplained process with database access.
What I didn't expect: how often that constraint sounds like a weaker pitch in a first conversation. An agent-based competitor can promise deeper metrics, finer-grained monitoring, more knobs. We can't match that list, because matching it would mean breaking the constraint. The lesson wasn't to second-guess the decision -- it's held up. The lesson was to stop trying to win that feature comparison and instead lead with what the constraint actually buys: nothing to deploy, nothing to patch, nothing running on infrastructure we don't own the risk for.
Azure demand showed up faster than the honest answer could
AWS and GCP covered the large majority of early conversations. Then enterprise prospects started asking about Azure sooner than the roadmap had room for it -- a Microsoft-shop acquisition here, a data-residency requirement there.
The tempting move is to say "yes, supported" and scramble to catch up quietly. We didn't do that, and I'd make the same call again: Azure is still in active development, and every piece of content and every conversation says exactly that instead of implying otherwise. It has cost some deals that wanted all three clouds on day one. It's also meant nobody who signed up based on what we said felt misled by what they got. Given the choice again, I'd rather lose the deal that needed something we hadn't built yet than win it on a sentence that wasn out true at the time.
The non-technical side wasn't a stretch feature, it was half the point
I originally scoped this as a tool for DBAs and platform engineers -- people like the one I used to be. Non-technical, self-service access via plain-English questions was on the roadmap, but mentally filed as a secondary audience.
It wasn't secondary. Once the inventory and schema mapping existed, the question "can a PM or a support lead just ask this in English and get a real answer" turned out to matter as much as anything built for engineers -- because the ticket queue of "can someone pull me a number" is exactly the tax non-technical teams pay today, and it's one of the clearest places read-only, schema-aware querying actually removes work instead of just moving it around.
What this adds up to
None of these were catastrophic mistakes -- nothing got rebuilt from scratch, nothing shipped and had to be pulled. They were sequencing and communication mistakes: underestimating the unglamorous work of credential models, getting the dependency order backwards, undervaluing a constraint I was already committed to, and being too slow to take a growing audience seriously. The common thread is that the actual engineering judgment calls -- read-only by default, no agents, say what's not ready yet -- all held up fine. It was the plan built around them that needed the corrections.
If you've built something in a space you used to work in professionally, I'm curious what you got wrong going in versus what you expected to get wrong. The gap between those two lists is usually the interesting part.
Top comments (0)