The Features I Said No To (and Why)

The hardest part of building QueryBear hasn't been writing it. It's been not writing things. Every week brings a reasonable-sounding feature request, and most of them I've turned down, and turning them down was usually the right call and always the uncomfortable one. Here are a few of the no's, because the no's say more about a product than the yes's.

"Can it write to the database too?"

This is the most common request, and it's the one I'm most certain about. People want the agent to not just read but also update records, run migrations, fix data. And I get it, because once the agent can read fluently, the next thought is naturally "why can't it just fix the thing it found."

The answer is no, and it's load-bearing. The entire trust model of QueryBear is that it physically cannot mutate your data. The moment it can write, every customer has to re-evaluate whether they trust it, because the blast radius changed from "a wrong number" to "a wrong UPDATE." That asymmetry is the whole product. Reading wrong costs you a re-ask. Writing wrong costs you a restore. I'd rather be the tool people trust completely with reads than the tool people trust nervously with everything.

There's a version of write access that's safe — scoped, on a branch, heavily gated — and maybe that's a separate product someday. But bolting it onto the read tool would poison the thing that makes the read tool trustworthy. So, no.

"Can you build the dashboards too?"

Several people have asked for saved charts, scheduled reports, a dashboard view. It's a reasonable thing to want and a real market. It's also a different product, and saying yes would have quietly turned QueryBear into a worse version of the BI tools it's supposed to be an alternative to.

The thing I keep coming back to: my whole argument is that the future of ad-hoc data questions is conversational, not pre-built dashboards. If I build a dashboard feature, I'm hedging against my own thesis, and a hedged thesis is a weak product. Better to be sharply one thing than blurrily two. So when someone needs scheduled dashboards, I tell them honestly that a BI tool is the right call for that, and that QueryBear is for the other half — the messy, exploratory, one-off questions. Pointing people to a competitor for the thing I'm not has cost me approximately nothing and bought me a lot of trust.

"Support every database under the sun"

There's always pressure to add the next database. Mongo, Snowflake, BigQuery, the long tail. Each one is a real customer saying "I'd buy if you supported X." It's the most tempting kind of no to give up on, because there's a name attached to every yes.

I've mostly held the line on doing the core databases genuinely well before spreading thin. Each new database isn't just a connector. It's a new query dialect to validate safely, a new set of ways a query can go wrong, a new surface to keep secure. Adding one badly is worse than not adding it, because "we support Snowflake" followed by a sharp-edged Snowflake experience does more damage than an honest "not yet." Breadth is a promise, and a half-kept promise costs more than an unmade one.

The pattern in the no's

Reading these back, the no's all share a shape, and naming it helped me make the calls faster.

I say no when yes would dilute the one thing the product is. The write feature dilutes the trust model. The dashboard feature dilutes the thesis. The fifth database dilutes the quality. Each individual yes is defensible, even good. The cost isn't the feature. It's that the product stops being a clear answer to one question and becomes a muddy answer to several, and muddy products don't get recommended, because nobody can explain in one sentence what they're for.

The discipline I'm trying to keep, especially as a solo founder who could technically build any of these, is to evaluate features not on "would this be useful" — almost everything is useful — but on "does this make the core thing sharper or blurrier." Sharper, build it. Blurrier, no matter how reasonable the request, no.

It's an uncomfortable way to run a roadmap, because it means disappointing people who are politely asking for sensible things. But every product I've admired was defined by what it refused to do as much as what it did, and QueryBear being a clear, trustworthy answer to "let an agent read my database safely" is worth more than it being a cluttered answer to five things at once. The no's are the product. I just didn't expect them to be the hardest part.