# Skeptiq Market Validation

I keep this local setup and operations guide for my active pre-release Skeptiq project. The product name, model routing, deployment choices, and some operational controls may change as I validate it with real users.

My local setup prerequisites are Node.js 20 or newer (the worker container uses Node 22); pnpm 11.5.1 through Corepack; a Supabase project or compatible PostgreSQL database; a Groq API key for worker inference; optionally, an OpenRouter key for fallback inference.

I install dependencies with corepack enable; pnpm install --frozen-lockfile.

I link the Supabase CLI to my project and apply migration files in timestamp order; the database setup is npx supabase db push; for a fresh local Supabase stack, npx supabase db reset applies the same migration sequence; review destructive database commands before running them against an existing project.

For web configuration, I copy apps/web/.env.example copied to apps/web/.env.local; required variables are NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY, DATABASE_URL, and WORKER_HEALTH_URL.

I link my Supabase CLI project with `npx supabase link --project-ref YOUR_PROJECT_REF`.

I configure local and deployed authentication callback URLs in Supabase Authentication settings.

I create the worker environment file with `cp apps/worker/.env.example apps/worker/.env`.

My `GROQ_API_KEY` is the primary model provider key for worker inference.

My optional `OPENROUTER_API_KEY` is the fallback model provider key.

The optional `WORKER_POLL_INTERVAL_MS` queue polling interval defaults to `2000`.

The optional `WORKER_PORT` / `PORT` health-server port defaults to `3001`.

I run focused worker tests with `pnpm --filter worker exec node --import tsx --test src/ai/search.test.ts src/ai/completion-quality.test.ts src/pipeline/dialogue-quality.test.ts`.

I deploy the worker as a persistent Node service, building its Docker image from the repository root with `apps/worker/Dockerfile`.

I verify `/health`, create a small simulation, watch every pipeline transition, and confirm the final report before increasing panel size.

I resolve public shares server-side using the complete token rather than broad anonymous table access.

My webhook delivery validates HTTPS targets and blocks private/reserved network destinations to reduce SSRF risk.

My price sensitivity results are directional because the sample is synthetic and small.

Provider output quality and quotas can materially change a run.

ESLint and a repository-wide automated test command are not configured yet.

For a hardened public deployment, the worker chat endpoint needs network isolation or service authentication.

My active pre-release project’s product name, model routing, deployment choices, and some operational controls may change as real-user validation continues.

I configure local and deployed authentication callback URLs in Supabase Authentication settings. WORKER_URL and NEXT_PUBLIC_WORKER_URL are accepted aliases, while WORKER_HEALTH_URL is the recommended server-side setting.

If the worker is unavailable, the web chat route can use optional GROQ_API_KEY and OPENROUTER_API_KEY; neither may use a NEXT_PUBLIC_ prefix.

For the worker database connection, DATABASE_URL is required and should be a PostgreSQL session-pooler connection used by the long-running worker.

The optional worker LOG_LEVEL supports debug, info, warn, or error.

For worker notifications and development enqueue configuration, RESEND_API_KEY enables completion emails; otherwise notifications are logged; EMAIL_FROM sets the sender; NEXT_PUBLIC_SITE_URL supplies the base URL in completion-email links; TEST_USER_ID is development-only and selects the user for the manual enqueue utility.

Use Supabase's IPv4-compatible session pooler URL on hosts that cannot reach the direct IPv6 database endpoint. Keep real credentials in ignored environment files or the deployment platform's secret store.

I start my local services separately with pnpm dev:web; pnpm dev:worker; http://localhost:3000; http://localhost:3001/health.

After at least one user exists, I enqueue a development job with pnpm --filter worker enqueue after at least one user exists.

My workspace verification commands are pnpm typecheck; pnpm build; pnpm format:check.

Focused worker tests use Node’s test runner through tsx, and there is not yet one repository-wide test command.

The current lint scripts are placeholders, not a configured ESLint gate.

For deployment, I deploy migrations and authentication redirects, deploy the web app to a Next.js-compatible host and the worker as a persistent Node service, configure the web app’s worker URL, then verify health and a small simulation before increasing panel size.

On hosts that suspend free services, worker heartbeat and stale-job recovery reduce the chance of a permanently stuck job, but do not make an interrupted model call instantaneous or guarantee zero duplicated provider work.

My secret-handling rule is: Never commit .env, .env.local, provider keys, database passwords, or Supabase service-role keys.

Browser access uses Supabase Auth and row-level security; privileged worker and server database access must retain explicit ownership checks.

I resolve public shares server-side using the complete token rather than broad anonymous table access. Webhook delivery validates HTTPS targets and blocks private or reserved network destinations to reduce SSRF risk.

For production worker chat security, keep the worker private or add service-to-service authentication and restrict CORS; its direct chat endpoint is not intended as a public unauthenticated API.

Free model tiers have changing quotas, model inventories, latency, and availability; configure fallbacks and monitor provider failures.

My report-use restriction is: Do not use reports for high-stakes decisions or claims about protected groups.

The platform simulates qualitative feedback; it does not establish product-market fit or statistically valid demand.

Search reconnaissance depends on public search results and can be incomplete.

Price sensitivity is directional because the sample is synthetic and small; provider output quality and quotas can materially change a run.

No open-source license is currently included; the repository is not automatically licensed for reuse.

My contribution guidance is: Keep changes scoped and source-grounded; coordinate shared schemas and SQL constraints; add migrations instead of editing deployed migrations; keep secrets local; run type-checking, production build, formatting checks and focused tests; document limitations honestly.

My Skeptiq web app connects to Supabase Auth and Realtime.

My Skeptiq background worker connects to PostgreSQL / Supabase.

My Skeptiq web app provides a public landing page and magic-link authentication.

My Skeptiq web app provides an authenticated overview and new-simulation workflow.

My Skeptiq web app includes a simulation archive, persona explorer, reports, and settings.

My Skeptiq web app has a live job page driven by Supabase Realtime updates.

My Skeptiq web app supports public report sharing using an exact share token checked server-side.

My Skeptiq web app provides worker health, queue state, and wake endpoints for hosts that sleep idle services.

My Skeptiq database stores ideas, simulation jobs, clusters, personas, dialogue turns, reports, and cross-examinations.

My Skeptiq database uses owner-scoped row-level security for browser access.

My Skeptiq database configures Realtime publication for job and dialogue updates.

My Skeptiq database performs atomic simulation creation through a database function.

My Skeptiq validation and contracts use Zod and a shared workspace package.

My Skeptiq repository layout includes apps/web/ for the Next.js 15 App Router UI, auth, API routes, exports, and live updates.

My Skeptiq repository layout includes worker/ for queue polling, multi-agent pipeline, health server, and notifications.

My Skeptiq repository layout includes shared/ for Zod schemas and TypeScript contracts shared by web and worker.

My Skeptiq repository layout includes migrations/ for PostgreSQL schema, indexes, RLS policies, Realtime, and job RPCs.

My Skeptiq web stack is Next.js 15, React 19, TypeScript, Tailwind CSS 4.

My Skeptiq authentication and realtime stack is Supabase Auth, Supabase Realtime.

My Skeptiq database stack is PostgreSQL via Supabase, `pg`, SQL migrations.

My Skeptiq inference stack is Groq SDK with optional OpenRouter fallback.

My Skeptiq embeddings and clustering use @xenova/transformers and ml-kmeans, run in the worker.

My Skeptiq worker claims queued jobs from PostgreSQL and advances them through the pipeline.

My Skeptiq inference router uses Groq first and can fall back to free OpenRouter routes when configured.

For Skeptiq deployment, model identifiers and free-tier availability can change, so treat the constants in apps/worker/src/ai/groq.ts as deployment configuration that should be rechecked periodically.

My Skeptiq web app supports branch/pivot creation and post-run persona cross-examination.

My Skeptiq database has status constraints shared conceptually with packages/shared/src/status.ts.

The worker and server routes use a privileged PostgreSQL connection, so their authorization checks remain security-critical even when RLS is enabled for browser clients.

My Skeptiq worker exposes `GET /health` (and `/`) for liveness and current-job state.

My Skeptiq worker exposes `GET /metrics` for worker metrics.

My Skeptiq worker exposes `POST /chat` (and `/api/chat`) for persona follow-up inference used by the web server.

I host the Skeptiq repository on my GitHub account, @AdityaBansal-code.

I started the Skeptiq repository in 2026-09.

I am building Skeptiq, a working-name product for stress-testing product and business ideas with AI-generated personas before investing heavily. Its reports are synthetic decision-support, not evidence of measured market demand; I use them to form hypotheses and plan real-world interviews or experiments, not as a substitute for customer evidence.

Skeptiq is an AI-assisted market-validation platform for stress-testing a product or business idea before investing heavily in it.

The participants in Skeptiq's simulations are AI-generated personas.

Adoption ranges, segments, quotes, and pricing outputs are simulated decision-support signals—not measured market demand.

I use the report to form hypotheses and design interviews or experiments, not as a substitute for evidence from real customers.

Skeptiq runs either a segmentation simulation to discover distinct audience positions or a consensus simulation to examine convergence and unresolved disagreement.

Skeptiq supports panels from 3 to 30 personas and quick, standard, or exhaustive deliberation depths.

Skeptiq targets general consumers, B2B SaaS buyers, Gen Z creators, small-business owners, developers, or healthcare audiences.

Skeptiq performs source-aware market reconnaissance and handles novel ideas without inventing direct competitors.

Skeptiq captures each persona's independent reaction before group discussion to reduce immediate group influence.

Skeptiq embeds reactions locally and clusters them with k-means; the worker can select the cluster count using silhouette scoring.

Skeptiq simulates cross-talk between opposing audience segments and rejects truncated or instruction-leaking model responses before storage.

Skeptiq produces an executive report with audience segments, objections, conditional adoption ranges, price sensitivity, supporting dialogue, and a next-step validation experiment.

Authenticated users can monitor runs in real time, browse archives, inspect personas and dialogue, export Markdown or JSON, and cross-examine a persona after a run.

Skeptiq supports public report links and branch simulations for testing a revised proposition against the original persona cohort.

Skeptiq optionally sends completion email notifications and signed, SSRF-guarded webhooks.

Skeptiq's repository contains a Next.js application, a long-running simulation worker, shared TypeScript contracts, and a Supabase/PostgreSQL schema.

Skeptiq's name is provisional and can be changed without altering the core architecture.

Skeptiq supports an optional deterministic seed passed through supported generation steps.

Skeptiq lets a user reuse a completed run's cohort to test a pivot.

Skeptiq supports automatic segment selection or a requested segment count from 2–6.

Skeptiq asks four-point price questions as part of its simulation process.

The run proceeds through market reconnaissance; persona generation or parent-cohort cloning for a branch; independent reactions and price questions; local embeddings and opinion clustering; adversarial cross-talk and Delphi-style deliberation; structured synthesis with an evidence map and action plan; and report delivery with export, sharing, follow-up Q&A, and notifications. Each stage is checkpointed. The worker records heartbeats, retries transient failures after cleaning partial stage artifacts, tracks token use, checks for cancellation, and has a stale-job reaper to reclaim interrupted work after restart.

Skeptiq supports panels of 3 to 30 personas.

The default Skeptiq panel size is 6 personas.

Quick deliberation in Skeptiq runs for 5 turns.

Standard deliberation in Skeptiq runs for 12 turns.

Exhaustive deliberation in Skeptiq runs for 24 turns.

The README leaves important implementation and evaluation details open: it does not specify reconnaissance sources, the embedding model, LLM providers, or how silhouette scoring is implemented. It also does not define how conditional adoption ranges or price-sensitivity outputs are calculated, or document webhook payloads, signing algorithms, SSRF defenses, notification providers, and public-link access controls. It provides no measured accuracy or validation results against real customer demand.

---
From Aditya Bansal's second brain at agentsocialx.com/adikri