Vibecode Eloqra
track this build5 steps, step by step0%KINDA · weekend project
price $4.99/moyou'd save $59.88/yrbuild time multi-daycategory 🛟 customer supportreplaced by 0 people
The first half is a one-sitting build and the second half isn't. A script tag that injects a chat panel, a websocket, and a bot that forwards messages so your native Telegram reply reaches the visitor · that works by dinner, and the prompt below builds it. The gap is the operator side. Replying inside a bot chat is fine for one conversation a week; the moment you have several going you want a real inbox, and in Telegram that means a Mini App, which is a second application with its own platform rules: auth is HMAC-validating initData against your bot token, the webview lies about its own height so you size from viewportStableHeight instead of dvh, fullscreen hides content under the status bar until you combine two different safe-area insets, and it disables text selection outright, so even copying a message means hand-rolling a long-press with a clipboard fallback. None of that is hard. All of it is discovered the slow way, on a phone, after the prompt has finished.
the project pack4 files · fastest path to a working personal build
You are building a lean indie version of Eloqra. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== README.md ===== # Eloqra indie build ## Goal Build the smallest trustworthy replacement for the core Eloqra workflow for one developer or a tiny team. ## Scope One script tag injects a chat widget into your site, messages arrive in your Telegram, and replying to the bot message replies to the visitor · one conversation at a time. ## Quick start 1. Install the documented dependencies. 2. Copy `.env.example` to `.env`. 3. Run the development command chosen during implementation. 4. Complete the acceptance checks in `BUILD_PLAN.md`. ## Honest limits This build deliberately does not replace: - a real operator inbox · the Mini App console with a combined thread list across sites, unread badges, typing indicators and deep links from a notification straight into the conversation · bot replies cover one chat at a time, not five at once - the week you spend learning Telegram's webview rather than writing features · initData HMAC auth, sizing from viewportStableHeight because dvh overshoots, two safe-area insets to stay clear of the status bar in fullscreen, and text selection disabled so copying a message needs a hand-rolled long-press - a free tier · you would be spending days plus a monthly VPS bill to replace something that costs nothing for one site - everything that isn't the happy path · socket reconnects, duplicate sends, message ordering on flaky mobile networks, Telegram rate limits and retry queues, bot token rotation - always-on hosting · your widget is dead whenever your box, your TLS cert, or your websocket is, and a chat that silently stops connecting reads to visitors as you ignoring them If those capabilities are essential, use Chatwoot instead of pretending the gap is solved. ===== AGENTS.md ===== # Agent instructions - Optimize for a working, understandable weekend build. - Prefer the fewest moving parts that satisfy the brief. - Do not invent cryptography, security guarantees, APIs, or compliance claims. - Keep secrets out of source control and logs. - Add focused tests for destructive, security-sensitive, and data-loss paths. - Run the project checks before declaring the build complete. - Record any deliberate shortcut in the README under "Tradeoffs". ===== BUILD_PLAN.md ===== # Build plan ## Original build brief Build me a self-hosted live-chat widget whose inbox is Telegram. Requirements: - Stack: a single Node + TypeScript service (Fastify) with SQLite via better-sqlite3. No Docker, no separate frontend build, no accounts system. - Embeddable widget: GET /widget.js returns a script that injects a launcher button and chat panel into any page via one tag with data-site-id, rendered in a shadow DOM so the host page's CSS can't leak in. No iframe. Read theme (light/dark), accent color, and corner position from data- attributes. - Transport: a websocket (ws) between visitor and server, with a long-poll fallback when the socket won't open. Persist every message. Give the visitor a signed cookie id so their thread survives a reload. - On a conversation's first message, capture page URL, referrer, and user agent parsed to device/browser/OS, plus coarse IP geolocation from a free API. - Telegram: a grammY bot posts each new conversation to OWNER_CHAT_ID with that visitor context. The operator answers using Telegram's native reply-to-message · map the replied-to message id back to its conversation and push the text to the visitor live. - Typing indicators in both directions, and an optional pre-chat form (name + email) toggled per site. - An /admin page behind basic auth listing conversations, each full thread, and a reply box, so the widget still works when Telegram is unreachable. - Secrets in .env: BOT_TOKEN, OWNER_CHAT_ID, ADMIN_PASSWORD, ALLOWED_ORIGINS for CORS. - Ship a README with the exact snippet to paste and VPS deploy steps (systemd + Caddy for TLS, since websockets need it). - Deliberately out of scope: a phone operator console. That is a Telegram Mini App, a second project with its own rules (initData HMAC auth, viewportStableHeight sizing, safe-area insets); budget separate days for it. Also out: multiple operators, billing, canned replies, AI autoresponders, and analytics dashboards. ## Required capabilities - a Telegram bot token from @BotFather - an HTTPS host for the websocket · Telegram will not load a Mini App over plain http - BotFather registration of the Mini App URL and menu button, if you want a real inbox rather than bot replies ## Delivery order 1. Scaffold the smallest runnable application and document its commands. 2. Implement the primary data model and core workflow. 3. Add validation, safe failure states, and persistence. 4. Cover the critical path with automated tests. 5. Exercise a clean install from the README and fix every missing step. ## Done when - A new user can go from clone to first successful workflow using only the README. - The core workflow works without paid infrastructure unless the brief requires it. - Tests cover the highest-risk behavior. - Known limitations are explicit rather than hidden. ===== .env.example ===== # Copy to .env and document every variable when it is introduced. # Never put real credentials in this file. APP_ENV=development # Add only values required by the selected implementation.
You are building a lean indie version of Eloqra. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== README.md ===== # Eloqra indie build ## Goal Build the smallest trustworthy replacement for the core Eloqra workflow for one developer or a tiny team. ## Scope One script tag injects a chat widget into your site, messages arrive in your Telegram, and replying to the bot message replies to the visitor · one conversation at a time. ## Quick start 1. Install the documented dependencies. 2. Copy `.env.example` to `.env`. 3. Run the development command chosen during implementation. 4. Complete the acceptance checks in `BUILD_PLAN.md`. ## Honest limits This build deliberately does not replace: - a real operator inbox · the Mini App console with a combined thread list across sites, unread badges, typing indicators and deep links from a notification straight into the conversation · bot replies cover one chat at a time, not five at once - the week you spend learning Telegram's webview rather than writing features · initData HMAC auth, sizing from viewportStableHeight because dvh overshoots, two safe-area insets to stay clear of the status bar in fullscreen, and text selection disabled so copying a message needs a hand-rolled long-press - a free tier · you would be spending days plus a monthly VPS bill to replace something that costs nothing for one site - everything that isn't the happy path · socket reconnects, duplicate sends, message ordering on flaky mobile networks, Telegram rate limits and retry queues, bot token rotation - always-on hosting · your widget is dead whenever your box, your TLS cert, or your websocket is, and a chat that silently stops connecting reads to visitors as you ignoring them If those capabilities are essential, use Chatwoot instead of pretending the gap is solved. ===== AGENTS.md ===== # Agent instructions - Optimize for a working, understandable weekend build. - Prefer the fewest moving parts that satisfy the brief. - Do not invent cryptography, security guarantees, APIs, or compliance claims. - Keep secrets out of source control and logs. - Add focused tests for destructive, security-sensitive, and data-loss paths. - Run the project checks before declaring the build complete. - Record any deliberate shortcut in the README under "Tradeoffs". ===== BUILD_PLAN.md ===== # Build plan ## Original build brief Build me a self-hosted live-chat widget whose inbox is Telegram. Requirements: - Stack: a single Node + TypeScript service (Fastify) with SQLite via better-sqlite3. No Docker, no separate frontend build, no accounts system. - Embeddable widget: GET /widget.js returns a script that injects a launcher button and chat panel into any page via one tag with data-site-id, rendered in a shadow DOM so the host page's CSS can't leak in. No iframe. Read theme (light/dark), accent color, and corner position from data- attributes. - Transport: a websocket (ws) between visitor and server, with a long-poll fallback when the socket won't open. Persist every message. Give the visitor a signed cookie id so their thread survives a reload. - On a conversation's first message, capture page URL, referrer, and user agent parsed to device/browser/OS, plus coarse IP geolocation from a free API. - Telegram: a grammY bot posts each new conversation to OWNER_CHAT_ID with that visitor context. The operator answers using Telegram's native reply-to-message · map the replied-to message id back to its conversation and push the text to the visitor live. - Typing indicators in both directions, and an optional pre-chat form (name + email) toggled per site. - An /admin page behind basic auth listing conversations, each full thread, and a reply box, so the widget still works when Telegram is unreachable. - Secrets in .env: BOT_TOKEN, OWNER_CHAT_ID, ADMIN_PASSWORD, ALLOWED_ORIGINS for CORS. - Ship a README with the exact snippet to paste and VPS deploy steps (systemd + Caddy for TLS, since websockets need it). - Deliberately out of scope: a phone operator console. That is a Telegram Mini App, a second project with its own rules (initData HMAC auth, viewportStableHeight sizing, safe-area insets); budget separate days for it. Also out: multiple operators, billing, canned replies, AI autoresponders, and analytics dashboards. ## Required capabilities - a Telegram bot token from @BotFather - an HTTPS host for the websocket · Telegram will not load a Mini App over plain http - BotFather registration of the Mini App URL and menu button, if you want a real inbox rather than bot replies ## Delivery order 1. Scaffold the smallest runnable application and document its commands. 2. Implement the primary data model and core workflow. 3. Add validation, safe failure states, and persistence. 4. Cover the critical path with automated tests. 5. Exercise a clean install from the README and fix every missing step. ## Done when - A new user can go from clone to first successful workflow using only the README. - The core workflow works without paid infrastructure unless the brief requires it. - Tests cover the highest-risk behavior. - Known limitations are explicit rather than hidden. ===== .env.example ===== # Copy to .env and document every variable when it is introduced. # Never put real credentials in this file. APP_ENV=development # Add only values required by the selected implementation.
You are building a production product version of Eloqra. Create the following project files first, then implement the application by following them. Keep the files updated as decisions change. Do not collapse this into a single README or prompt. ===== PRODUCT.md ===== # Eloqra product brief ## Problem The first half is a one-sitting build and the second half isn't. A script tag that injects a chat panel, a websocket, and a bot that forwards messages so your native Telegram reply reaches the visitor · that works by dinner, and the prompt below builds it. The gap is the operator side. Replying inside a bot chat is fine for one conversation a week; the moment you have several going you want a real inbox, and in Telegram that means a Mini App, which is a second application with its own platform rules: auth is HMAC-validating initData against your bot token, the webview lies about its own height so you size from viewportStableHeight instead of dvh, fullscreen hides content under the status bar until you combine two different safe-area insets, and it disables text selection outright, so even copying a message means hand-rolling a long-press with a clipboard fallback. None of that is hard. All of it is discovered the slow way, on a phone, after the prompt has finished. ## Product outcome One script tag injects a chat widget into your site, messages arrive in your Telegram, and replying to the bot message replies to the visitor · one conversation at a time. ## Target user A serious builder who needs a maintainable product foundation rather than a one-off demo. ## Required capabilities - a Telegram bot token from @BotFather - an HTTPS host for the websocket · Telegram will not load a Mini App over plain http - BotFather registration of the Mini App URL and menu button, if you want a real inbox rather than bot replies ## Explicit non-goals for v1 - a real operator inbox · the Mini App console with a combined thread list across sites, unread badges, typing indicators and deep links from a notification straight into the conversation · bot replies cover one chat at a time, not five at once - the week you spend learning Telegram's webview rather than writing features · initData HMAC auth, sizing from viewportStableHeight because dvh overshoots, two safe-area insets to stay clear of the status bar in fullscreen, and text selection disabled so copying a message needs a hand-rolled long-press - a free tier · you would be spending days plus a monthly VPS bill to replace something that costs nothing for one site - everything that isn't the happy path · socket reconnects, duplicate sends, message ordering on flaky mobile networks, Telegram rate limits and retry queues, bot token rotation - always-on hosting · your widget is dead whenever your box, your TLS cert, or your websocket is, and a chat that silently stops connecting reads to visitors as you ignoring them ## Success criteria - The primary workflow is measurable end to end. - Setup is reproducible in a clean environment. - Failure, recovery, and support paths are documented. - Product claims match what the implementation actually guarantees. ===== ARCHITECTURE.md ===== # Architecture ## Starting brief Build me a self-hosted live-chat widget whose inbox is Telegram. Requirements: - Stack: a single Node + TypeScript service (Fastify) with SQLite via better-sqlite3. No Docker, no separate frontend build, no accounts system. - Embeddable widget: GET /widget.js returns a script that injects a launcher button and chat panel into any page via one tag with data-site-id, rendered in a shadow DOM so the host page's CSS can't leak in. No iframe. Read theme (light/dark), accent color, and corner position from data- attributes. - Transport: a websocket (ws) between visitor and server, with a long-poll fallback when the socket won't open. Persist every message. Give the visitor a signed cookie id so their thread survives a reload. - On a conversation's first message, capture page URL, referrer, and user agent parsed to device/browser/OS, plus coarse IP geolocation from a free API. - Telegram: a grammY bot posts each new conversation to OWNER_CHAT_ID with that visitor context. The operator answers using Telegram's native reply-to-message · map the replied-to message id back to its conversation and push the text to the visitor live. - Typing indicators in both directions, and an optional pre-chat form (name + email) toggled per site. - An /admin page behind basic auth listing conversations, each full thread, and a reply box, so the widget still works when Telegram is unreachable. - Secrets in .env: BOT_TOKEN, OWNER_CHAT_ID, ADMIN_PASSWORD, ALLOWED_ORIGINS for CORS. - Ship a README with the exact snippet to paste and VPS deploy steps (systemd + Caddy for TLS, since websockets need it). - Deliberately out of scope: a phone operator console. That is a Telegram Mini App, a second project with its own rules (initData HMAC auth, viewportStableHeight sizing, safe-area insets); budget separate days for it. Also out: multiple operators, billing, canned replies, AI autoresponders, and analytics dashboards. ## Boundaries Separate the product into replaceable modules for interface, application logic, persistence, external integrations, and operational concerns. Keep domain logic independent from delivery frameworks and vendors. ## Production baseline - Configuration: validated at startup with safe local defaults where possible. - Security: least privilege, input validation, secret redaction, rate limits on abuse-prone paths, and no invented security primitives. - Data: explicit schema and migrations, transactional writes where integrity matters, backup and restore instructions. - Integrations: adapters around third-party providers, idempotent webhook or job processing, bounded retries, and timeouts. - Observability: structured logs with request or operation IDs, an error-tracking hook, and health/readiness checks where a server exists. - Quality: unit tests for domain rules, integration tests at module boundaries, and one end-to-end critical-path test. ## Decision records For each major dependency, document why it was chosen, its failure mode, and how it can be replaced. Do not introduce infrastructure until a requirement justifies it. ===== AGENTS.md ===== # Agent instructions - Read `PRODUCT.md` and `ARCHITECTURE.md` before changing code. - Implement milestone by milestone; keep each change reviewable and leave the application runnable. - Treat authentication, payments, encryption, imports, webhooks, and destructive actions as high-risk boundaries when present. - Never invent cryptography or silently weaken a requirement to make a test pass. - Use provider interfaces for external services and deterministic fakes in tests. - Add migrations and rollback or recovery notes for persistent data changes. - Log useful operational context without credentials, tokens, passwords, or personal data. - Update documentation and run all checks before completing a milestone. ===== MILESTONES.md ===== # Delivery milestones ## M0 — Decisions and scaffold - Confirm the runtime, persistence model, threat boundaries, and deployment target. - Create a reproducible local environment and continuous checks. ## M1 — Core workflow - Implement the smallest end-to-end product path with validation and tests. - Keep integrations behind interfaces. ## M2 — Trust layer - Add secure failure behavior, recovery paths, audit-relevant events, and data safeguards. - Test abuse cases and destructive operations. ## M3 — Operability - Add structured logs, error reporting hooks, health signals, backup/restore documentation, and deployment configuration. ## M4 — Release gate - Run a clean-install test, critical-path end-to-end test, dependency review, and documented rollback exercise. - Compare the shipped behavior with `PRODUCT.md` and publish remaining limitations. ===== OPERATIONS.md ===== # Operations ## Before release - Validate configuration and secrets at startup. - Define backup, restore, and rollback procedures and test them. - Document logs, error tracking, health signals, and alert ownership. - Set dependency update and vulnerability review expectations. ## Incident checklist 1. Contain the issue without destroying evidence or user data. 2. Record the timeline and affected scope. 3. Rotate exposed secrets and revoke compromised sessions or credentials. 4. Restore from a verified source when needed. 5. Document the root cause, remediation, and regression test. ## Launch constraint Do not market omitted Eloqra capabilities as implemented. The v1 non-goals in `PRODUCT.md` remain user-visible limitations until they are deliberately delivered.
README.md
# Eloqra indie build ## Goal Build the smallest trustworthy replacement for the core Eloqra workflow for one developer or a tiny team. ## Scope One script tag injects a chat widget into your site, messages arrive in your Telegram, and replying to the bot message replies to the visitor · one conversation at a time. ## Quick start 1. Install the documented dependencies. 2. Copy `.env.example` to `.env`. 3. Run the development command chosen during implementation. 4. Complete the acceptance checks in `BUILD_PLAN.md`. ## Honest limits This build deliberately does not replace: - a real operator inbox · the Mini App console with a combined thread list across sites, unread badges, typing indicators and deep links from a notification straight into the conversation · bot replies cover one chat at a time, not five at once - the week you spend learning Telegram's webview rather than writing features · initData HMAC auth, sizing from viewportStableHeight because dvh overshoots, two safe-area insets to stay clear of the status bar in fullscreen, and text selection disabled so copying a message needs a hand-rolled long-press - a free tier · you would be spending days plus a monthly VPS bill to replace something that costs nothing for one site - everything that isn't the happy path · socket reconnects, duplicate sends, message ordering on flaky mobile networks, Telegram rate limits and retry queues, bot token rotation - always-on hosting · your widget is dead whenever your box, your TLS cert, or your websocket is, and a chat that silently stops connecting reads to visitors as you ignoring them If those capabilities are essential, use Chatwoot instead of pretending the gap is solved.
AGENTS.md
# Agent instructions - Optimize for a working, understandable weekend build. - Prefer the fewest moving parts that satisfy the brief. - Do not invent cryptography, security guarantees, APIs, or compliance claims. - Keep secrets out of source control and logs. - Add focused tests for destructive, security-sensitive, and data-loss paths. - Run the project checks before declaring the build complete. - Record any deliberate shortcut in the README under "Tradeoffs".
BUILD_PLAN.md
# Build plan ## Original build brief Build me a self-hosted live-chat widget whose inbox is Telegram. Requirements: - Stack: a single Node + TypeScript service (Fastify) with SQLite via better-sqlite3. No Docker, no separate frontend build, no accounts system. - Embeddable widget: GET /widget.js returns a script that injects a launcher button and chat panel into any page via one tag with data-site-id, rendered in a shadow DOM so the host page's CSS can't leak in. No iframe. Read theme (light/dark), accent color, and corner position from data- attributes. - Transport: a websocket (ws) between visitor and server, with a long-poll fallback when the socket won't open. Persist every message. Give the visitor a signed cookie id so their thread survives a reload. - On a conversation's first message, capture page URL, referrer, and user agent parsed to device/browser/OS, plus coarse IP geolocation from a free API. - Telegram: a grammY bot posts each new conversation to OWNER_CHAT_ID with that visitor context. The operator answers using Telegram's native reply-to-message · map the replied-to message id back to its conversation and push the text to the visitor live. - Typing indicators in both directions, and an optional pre-chat form (name + email) toggled per site. - An /admin page behind basic auth listing conversations, each full thread, and a reply box, so the widget still works when Telegram is unreachable. - Secrets in .env: BOT_TOKEN, OWNER_CHAT_ID, ADMIN_PASSWORD, ALLOWED_ORIGINS for CORS. - Ship a README with the exact snippet to paste and VPS deploy steps (systemd + Caddy for TLS, since websockets need it). - Deliberately out of scope: a phone operator console. That is a Telegram Mini App, a second project with its own rules (initData HMAC auth, viewportStableHeight sizing, safe-area insets); budget separate days for it. Also out: multiple operators, billing, canned replies, AI autoresponders, and analytics dashboards. ## Required capabilities - a Telegram bot token from @BotFather - an HTTPS host for the websocket · Telegram will not load a Mini App over plain http - BotFather registration of the Mini App URL and menu button, if you want a real inbox rather than bot replies ## Delivery order 1. Scaffold the smallest runnable application and document its commands. 2. Implement the primary data model and core workflow. 3. Add validation, safe failure states, and persistence. 4. Cover the critical path with automated tests. 5. Exercise a clean install from the README and fix every missing step. ## Done when - A new user can go from clone to first successful workflow using only the README. - The core workflow works without paid infrastructure unless the brief requires it. - Tests cover the highest-risk behavior. - Known limitations are explicit rather than hidden.
.env.example
# Copy to .env and document every variable when it is introduced. # Never put real credentials in this file. APP_ENV=development # Add only values required by the selected implementation.
PRODUCT.md
# Eloqra product brief ## Problem The first half is a one-sitting build and the second half isn't. A script tag that injects a chat panel, a websocket, and a bot that forwards messages so your native Telegram reply reaches the visitor · that works by dinner, and the prompt below builds it. The gap is the operator side. Replying inside a bot chat is fine for one conversation a week; the moment you have several going you want a real inbox, and in Telegram that means a Mini App, which is a second application with its own platform rules: auth is HMAC-validating initData against your bot token, the webview lies about its own height so you size from viewportStableHeight instead of dvh, fullscreen hides content under the status bar until you combine two different safe-area insets, and it disables text selection outright, so even copying a message means hand-rolling a long-press with a clipboard fallback. None of that is hard. All of it is discovered the slow way, on a phone, after the prompt has finished. ## Product outcome One script tag injects a chat widget into your site, messages arrive in your Telegram, and replying to the bot message replies to the visitor · one conversation at a time. ## Target user A serious builder who needs a maintainable product foundation rather than a one-off demo. ## Required capabilities - a Telegram bot token from @BotFather - an HTTPS host for the websocket · Telegram will not load a Mini App over plain http - BotFather registration of the Mini App URL and menu button, if you want a real inbox rather than bot replies ## Explicit non-goals for v1 - a real operator inbox · the Mini App console with a combined thread list across sites, unread badges, typing indicators and deep links from a notification straight into the conversation · bot replies cover one chat at a time, not five at once - the week you spend learning Telegram's webview rather than writing features · initData HMAC auth, sizing from viewportStableHeight because dvh overshoots, two safe-area insets to stay clear of the status bar in fullscreen, and text selection disabled so copying a message needs a hand-rolled long-press - a free tier · you would be spending days plus a monthly VPS bill to replace something that costs nothing for one site - everything that isn't the happy path · socket reconnects, duplicate sends, message ordering on flaky mobile networks, Telegram rate limits and retry queues, bot token rotation - always-on hosting · your widget is dead whenever your box, your TLS cert, or your websocket is, and a chat that silently stops connecting reads to visitors as you ignoring them ## Success criteria - The primary workflow is measurable end to end. - Setup is reproducible in a clean environment. - Failure, recovery, and support paths are documented. - Product claims match what the implementation actually guarantees.
ARCHITECTURE.md
# Architecture ## Starting brief Build me a self-hosted live-chat widget whose inbox is Telegram. Requirements: - Stack: a single Node + TypeScript service (Fastify) with SQLite via better-sqlite3. No Docker, no separate frontend build, no accounts system. - Embeddable widget: GET /widget.js returns a script that injects a launcher button and chat panel into any page via one tag with data-site-id, rendered in a shadow DOM so the host page's CSS can't leak in. No iframe. Read theme (light/dark), accent color, and corner position from data- attributes. - Transport: a websocket (ws) between visitor and server, with a long-poll fallback when the socket won't open. Persist every message. Give the visitor a signed cookie id so their thread survives a reload. - On a conversation's first message, capture page URL, referrer, and user agent parsed to device/browser/OS, plus coarse IP geolocation from a free API. - Telegram: a grammY bot posts each new conversation to OWNER_CHAT_ID with that visitor context. The operator answers using Telegram's native reply-to-message · map the replied-to message id back to its conversation and push the text to the visitor live. - Typing indicators in both directions, and an optional pre-chat form (name + email) toggled per site. - An /admin page behind basic auth listing conversations, each full thread, and a reply box, so the widget still works when Telegram is unreachable. - Secrets in .env: BOT_TOKEN, OWNER_CHAT_ID, ADMIN_PASSWORD, ALLOWED_ORIGINS for CORS. - Ship a README with the exact snippet to paste and VPS deploy steps (systemd + Caddy for TLS, since websockets need it). - Deliberately out of scope: a phone operator console. That is a Telegram Mini App, a second project with its own rules (initData HMAC auth, viewportStableHeight sizing, safe-area insets); budget separate days for it. Also out: multiple operators, billing, canned replies, AI autoresponders, and analytics dashboards. ## Boundaries Separate the product into replaceable modules for interface, application logic, persistence, external integrations, and operational concerns. Keep domain logic independent from delivery frameworks and vendors. ## Production baseline - Configuration: validated at startup with safe local defaults where possible. - Security: least privilege, input validation, secret redaction, rate limits on abuse-prone paths, and no invented security primitives. - Data: explicit schema and migrations, transactional writes where integrity matters, backup and restore instructions. - Integrations: adapters around third-party providers, idempotent webhook or job processing, bounded retries, and timeouts. - Observability: structured logs with request or operation IDs, an error-tracking hook, and health/readiness checks where a server exists. - Quality: unit tests for domain rules, integration tests at module boundaries, and one end-to-end critical-path test. ## Decision records For each major dependency, document why it was chosen, its failure mode, and how it can be replaced. Do not introduce infrastructure until a requirement justifies it.
AGENTS.md
# Agent instructions - Read `PRODUCT.md` and `ARCHITECTURE.md` before changing code. - Implement milestone by milestone; keep each change reviewable and leave the application runnable. - Treat authentication, payments, encryption, imports, webhooks, and destructive actions as high-risk boundaries when present. - Never invent cryptography or silently weaken a requirement to make a test pass. - Use provider interfaces for external services and deterministic fakes in tests. - Add migrations and rollback or recovery notes for persistent data changes. - Log useful operational context without credentials, tokens, passwords, or personal data. - Update documentation and run all checks before completing a milestone.
MILESTONES.md
# Delivery milestones ## M0 — Decisions and scaffold - Confirm the runtime, persistence model, threat boundaries, and deployment target. - Create a reproducible local environment and continuous checks. ## M1 — Core workflow - Implement the smallest end-to-end product path with validation and tests. - Keep integrations behind interfaces. ## M2 — Trust layer - Add secure failure behavior, recovery paths, audit-relevant events, and data safeguards. - Test abuse cases and destructive operations. ## M3 — Operability - Add structured logs, error reporting hooks, health signals, backup/restore documentation, and deployment configuration. ## M4 — Release gate - Run a clean-install test, critical-path end-to-end test, dependency review, and documented rollback exercise. - Compare the shipped behavior with `PRODUCT.md` and publish remaining limitations.
OPERATIONS.md
# Operations ## Before release - Validate configuration and secrets at startup. - Define backup, restore, and rollback procedures and test them. - Document logs, error tracking, health signals, and alert ownership. - Set dependency update and vulnerability review expectations. ## Incident checklist 1. Contain the issue without destroying evidence or user data. 2. Record the timeline and affected scope. 3. Rotate exposed secrets and revoke compromised sessions or credentials. 4. Restore from a verified source when needed. 5. Document the root cause, remediation, and regression test. ## Launch constraint Do not market omitted Eloqra capabilities as implemented. The v1 non-goals in `PRODUCT.md` remain user-visible limitations until they are deliberately delivered.
$ choose a build depth, inspect the files, then open the complete pack in your agent
Mostly they don't · for one website there is nothing to pay. Free is forever, with unlimited conversations, the full Telegram inbox and mini-app, and every widget option; 4.99 buys an extra project slot for a second site and nothing more, and the 'powered by' badge appears on paid tiers too. So the usual death-list logic inverts here. You aren't weighing a weekend against a subscription, you're weighing a weekend plus a VPS, TLS renewals, reconnect logic, and Telegram retry handling against zero. Live chat is also a promise that someone is actually there, which makes it a bad thing to hang off a box you maintain between other work. The one honest reason to build your own: you want visitor conversations on your own hardware instead of someone else's. That is the entire argument, and it isn't a financial one.
xa real operator inbox · the Mini App console with a combined thread list across sites, unread badges, typing indicators and deep links from a notification straight into the conversation · bot replies cover one chat at a time, not five at once
xthe week you spend learning Telegram's webview rather than writing features · initData HMAC auth, sizing from viewportStableHeight because dvh overshoots, two safe-area insets to stay clear of the status bar in fullscreen, and text selection disabled so copying a message needs a hand-rolled long-press
xa free tier · you would be spending days plus a monthly VPS bill to replace something that costs nothing for one site
xeverything that isn't the happy path · socket reconnects, duplicate sends, message ordering on flaky mobile networks, Telegram rate limits and retry queues, bot token rotation
xalways-on hosting · your widget is dead whenever your box, your TLS cert, or your websocket is, and a chat that silently stops connecting reads to visitors as you ignoring them
share on X ↗"I just replaced Eloqra ($4.99/mo) with one prompt"
Don't feel like building it? These folks already made it free.
Live Helper ChatWebsite chats can land in Telegram and replies go back; exact trick, decidedly non-trivial setup.open source↗no votes, no pay-to-list · just what's real
Eloqra pricing
| plan | monthly | annual (per mo) | what you get |
|---|---|---|---|
| free | $0/workspace | $0/workspace | 1 website project; unlimited operators/seats and no per-message metering |
| pro (each additional project) | $4.99/workspace | $4.17/workspace | 1 additional project per subscription; no per-seat or per-message charge |
free tier1 project forever; no seat cap and no message cap stated
billingmonthly $4.99 or annual $49.99 per additional project; first project stays free
hidden costsPricing scales per additional website project, not per seat or message; there are no stated overages.
verified 2026-08-12 · source ↗
Vibecode Eloqra
Kinda. The core of Eloqra is buildable in a weekend with the prompt on this page, but there are real gaps: a real operator inbox · the Mini App console with a combined thread list across sites, unread badges, typing indicators and deep links from a notification straight into the conversation · bot replies cover one chat at a time, not five at once, the week you spend learning Telegram's webview rather than writing features · initData HMAC auth, sizing from viewportStableHeight because dvh overshoots, two safe-area insets to stay clear of the status bar in fullscreen, and text selection disabled so copying a message needs a hand-rolled long-press. Read the honest list above before committing.
How much does Eloqra cost?
Eloqra costs about $4.99/month (Pro, checked 2026-07-31), which is $59.88 per year.
What do I lose by replacing Eloqra?
Honestly: a real operator inbox · the Mini App console with a combined thread list across sites, unread badges, typing indicators and deep links from a notification straight into the conversation · bot replies cover one chat at a time, not five at once; the week you spend learning Telegram's webview rather than writing features · initData HMAC auth, sizing from viewportStableHeight because dvh overshoots, two safe-area insets to stay clear of the status bar in fullscreen, and text selection disabled so copying a message needs a hand-rolled long-press; a free tier · you would be spending days plus a monthly VPS bill to replace something that costs nothing for one site; everything that isn't the happy path · socket reconnects, duplicate sends, message ordering on flaky mobile networks, Telegram rate limits and retry queues, bot token rotation; always-on hosting · your widget is dead whenever your box, your TLS cert, or your websocket is, and a chat that silently stops connecting reads to visitors as you ignoring them. If any of those are load-bearing for you, keep paying.
Is there an open-source alternative to Eloqra?
Yes: Live Helper Chat (Website chats can land in Telegram and replies go back; exact trick, decidedly non-trivial setup.) The prompt is for when you want it exactly your way.