Queryless
AI add-on layer for PortalJS — natural language querying over data portals.
| Metric | Status |
|---|---|
| Demos delivered | KAUST, Malmo (upsell), City of Ann Arbor, Transport Data Commons, Singapore (AST — partial) |
| Planned demos | Gov of Bhutan |
| Upsell in progress | Malmo — existing PortalJS client adding Queryless |
What Queryless is
Queryless is an AI layer that sits on top of PortalJS — not a standalone product. It lets users query data in natural language against an existing portal's datasets. The primary go-to-market is as an add-on or upsell to existing PortalJS clients and prospects, not as an independent sale.
What shipped
- 2 demo sites live: civic/cities use case (demo.portaljs.com) and research data portals use case (datopian-research.portaljs.com)
- Demos delivered: KAUST (new prospect), Malmo (existing PortalJS client — upsell), City of Ann Arbor, Transport Data Commons Initiative
- Small Queryless demo as part of a larger demo for Agency of Science and Technology, Singapore
- Gov of Bhutan demo planned
Why still an idea
Queryless demos land well but it is not yet independently packaged or sold. The clearest path is upsell to existing PortalJS clients (like Malmo) and bundling into new PortalJS proposals (like KAUST). Standalone enterprise sales remain blocked by unresolved questions around sensitive data, custom DB connectivity, security/access control, and deployment model.
The core uncertainties blocking productisation:
- Sensitive data — enterprise data portals often hold restricted or confidential data. It is not clear how Queryless deploys in environments where the underlying data cannot leave the client's infrastructure.
- Custom database connectivity — clients run many different backends (Postgres, Oracle, proprietary APIs, data lakes). Reliably connecting Queryless to arbitrary customer databases is unsolved.
- Security and access control — how do we enforce row-level security, existing permissions models, and audit requirements through a natural-language interface?
- Reliability and hallucination — enterprise buyers need predictable, auditable query results. LLM-generated queries can be wrong in subtle ways that are hard to detect.
- Deployment model — SaaS vs on-premise vs hybrid. Each has very different engineering and commercial implications.
Until these questions have clear answers it is hard to write a proposal, price it, or support it post-sale. The concept stays as an idea while we gather signal from the KAUST and Malmö conversations on what they actually need.
Where it sells — and where it doesn't
Primary motion: upsell to existing PortalJS clients (Malmo is the live example) and bundle into new PortalJS proposals where AI differentiation helps close (KAUST). The data is already there, governed, and accessible — Queryless adds a natural language interface on top.
For net-new clients with no existing portal, the sell is much harder: they'd buy portal and AI layer simultaneously with no data pipeline to plug into. Avoid leading with Queryless for those segments.
Relationship to AutoClaw
Queryless is built on OpenClaw and DuckDB. Exploring OpenClaw in depth led us to build AutoClaw — now our primary enterprise/SMB product and Upwork reference project. AutoClaw absorbed the near-term commercial focus that might otherwise have gone into productising Queryless.
Assessment
Strong demo conversion — multiple orgs progressed to serious conversation. Good vertical range: civic, research, government, transport. Priority now: close the Malmo upsell (lowest friction — existing client) and use KAUST proposal to test Queryless as a deal differentiator. Bhutan demo is next pipeline entry.
Next
- Close Malmo upsell (Queryless on existing PortalJS instance)
- Support KAUST proposal with Queryless as differentiator
- Deliver Gov of Bhutan demo