Skip to content
MV

Narrowly Scoped Products Is an Advantage

By

01 / Published

14.09.2026 Updated 14.09.2026

02 / Read time

4 min read

03 / Tags

  • golang
  • product-management
Narrowly Scoped Products Is an Advantage cover image

I recently forked sqlc-dev/sqlc to create a specific version for andurel v2 that I've been working on for some time now.

sqlc supports a bunch of languages and has to be careful about what it adds. One of the most requested features, dynamic queries, has been very hard to land. The deeper reason isn't only that the project is broad. It's that sqlc's contract is hard to bend: one SQL text becomes one typed Go method, with the compiler validating that text against the schema. Open-ended filters and sorts mean the SQL that runs is no longer fully known at generate time, so you weaken the guarantees people come to sqlc for. Languages and careful review make shipping slower; the analysis contract is why the feature keeps stalling.

I don't get to ignore that contract entirely. I still want typed methods and schema-valid SQL. What I don't have is sqlc's obligation to stay general. Andurel is the product; narsilc only has to serve it. My primary goal is the best developer experience, while staying as close to idiomatic Go as possible, and I'm willing to give up some of Go's core beliefs when I think it creates a better experience for the developer.

The forked repository is called narsilc, staying with the Lord of the Rings themed naming, and can do things much more specific to Andurel's needs.

What I'm currently toying with is a narrow form of dynamic queries: whitelist @filter and @order on a :many query, keep the base SQL as the source of truth, and have codegen own the fragments. The method stays typed; optional predicates, order, limit, and offset are assembled at runtime, but only from pieces narsilc wrote. That keeps the one-query analysis guarantee for the base text, without inventing an open-ended query builder sqlc would never accept.

As a contractor I see the same pattern on client projects: they try to do too much before the core is solid. Breadth feels like progress; it usually just makes the important decisions harder. I try to keep products almost useless on purpose: few features, little complexity, and only add something when living without it is nearly impossible. sqlc can't make that trade. narsilc can, because Andurel is the whole job. That's how you keep the complexity demon away.