DEV Community: pante5ter

How Much Does a Custom Telegram Bot Cost in 2026? An Honest Breakdown

pante5ter — Tue, 02 Jun 2026 17:49:17 +0000

"How much for a Telegram bot?" is a fair question with an annoying answer: it depends. But it depends on a small number of things you can actually reason about. Here's the honest framework I use, so you can estimate before you ever talk to a developer.

What you're really paying for

The price of a bot isn't about message-sending — Telegram's API does that for free. You're paying for everything around the messages: the logic, the data, the integrations, and the reliability. Four factors move the price more than anything else.

The four price factors

1. How the bot decides what to do. A linear FAQ/menu bot is the cheapest tier; conversational flows that remember where the user is (booking, onboarding) cost more; an AI-driven bot that understands free text adds an AI/RAG layer.

2. Whether it needs to remember things. A bot with no memory is cheap. The moment it stores users, orders or bookings, you need a database (Postgres/Supabase), a schema and migrations — real engineering, not a script.

3. Whether money changes hands. Taking payments (Telegram Payments, Stars, Stripe) is where "a bot" becomes "a product": correct handling of success/failure/refund states, idempotency so nobody is charged twice, and a record of every transaction.

4. Who manages it. If you'll manage content, view orders, or broadcast, you need an admin surface — effectively a second small app bolted on.

Rough tiers (so you can budget)

Rather than quote numbers that go stale, here's how the tiers stack — each step roughly multiplies effort:

Tier 1 — Simple bot: menu, FAQ, a form that emails you. Days, not weeks.
Tier 2 — Stateful bot with a database: bookings, accounts, history. A small but real backend.
Tier 3 — Payments + admin panel: the full "product" — the biggest jump, because correctness and reliability matter most.
Add-on — AI assistant layer: sits on top of any tier; priced by how much custom knowledge and accuracy you need.

Questions a good developer will ask

If they don't ask these, be cautious: Does it store data, or is it stateless? Will it take payments, and how? Who manages content — you, or the developer each time? Expected volume? Any integrations (CRM, Sheets, your API)?

What makes a bot worth the price

A cheap bot that loses orders, double-charges, or silently breaks when Telegram changes something isn't cheap — it's expensive in trust. The value is in the boring parts: retries, error handling, transaction records, clean logs, and code you own and can extend. That's the difference between a weekend script and something you can run a business on.

Thinking about a Telegram bot — for bookings, payments, support or an AI assistant? I build production bots with clean, owned code and an honest scope up front — vengstudio.online.

Do You Need a Website or a Web App? A Simple Decision Guide

pante5ter — Tue, 02 Jun 2026 17:47:22 +0000

"I need a website" and "I need a web app" sound similar and cost very differently. Picking the wrong one means either overpaying for complexity you don't need, or building a brochure when you needed a tool. Here's a clear way to tell them apart.

The core difference: do users read or do?

A website is mostly read. Visitors come to learn — what you offer, your prices, your story — and then contact you or buy. Think a clinic site, a restaurant, a portfolio, a landing page. The content changes occasionally; the visitor mostly consumes it.

A web app is mostly do. Users log in and accomplish tasks — booking, managing data, tracking orders, collaborating. State changes constantly because users are creating and changing things. Think a dashboard, a booking system, a SaaS product, an internal tool.

If your visitors primarily read and contact, you need a website. If they log in and act, you need a web app.

How it changes cost and timeline

A website is largely pages, content, SEO, and a contact path. It can look premium and load fast without heavy backend work. Faster and cheaper to build.

A web app needs accounts, a database, business logic, security, and ongoing state — effectively a small software product. More design, more engineering, more testing. Longer and more expensive, justified by the work it does for users.

Confusing the two is the most common budgeting mistake. People ask for "just a website" but describe user logins and dashboards (that's an app), or they over-spec an app when a sharp marketing site would convert better.

A simple test

Ask: "What's the most important thing a user does here?" Reads about us and books a call or buys a product → website. Logs in and manages something → web app. Both → a website front with an app behind a login. Common and totally fine — just price it as two pieces.

The middle ground most businesses want

In practice, many small businesses want a great-looking marketing site plus one interactive piece — a booking flow, a quote calculator, a client portal. That's a website with a focused app feature, not a full SaaS. Recognising this keeps the budget sane: build the polished site, and add only the interactive piece you genuinely need.

What to bring to a developer

Describe it in user terms, not tech terms: who visits and the one thing they're here to do; whether users need accounts; whether anything must be saved or tracked by users; whether you'll update content or it rarely changes. Answer those four and any good developer can tell you instantly whether you're looking at a website, a web app, or the practical middle ground — and roughly what that means for time and cost.

Not sure whether you need a website, a web app, or a site with one smart feature? Tell me what your users need to do and I'll give you a straight answer — then build it clean on Next.js. vengstudio.online.

From Spreadsheet Chaos to Automation: A Practical Guide for Small Businesses

pante5ter — Tue, 02 Jun 2026 17:45:31 +0000

Most small businesses don't need "AI" or a big software project. They need to stop copying data between a form, a spreadsheet, an email and an invoice by hand. That's automation — and done right, it pays for itself in saved hours within weeks. Here's how to approach it without overcomplicating things.

Step 1: Find the tasks actually worth automating

Good candidates share three traits: repetitive (done the same way, often), rule-based ("if this, then that," little judgement), and annoying (the work that drains energy and invites copy-paste mistakes). A quick exercise: for one week, jot down every task that made you think "a robot should do this." Tasks that move the same information from one place to another are almost always worth automating first.

Step 2: Map the flow before touching any tool

Write the task as a sentence: "When a customer submits the contact form, add them to the CRM, ping sales on Slack, and email them a confirmation." That sentence is your spec. Mapping it on paper first stops you from automating a broken process — and reveals the edge cases (what if the email is missing? what if they submit twice?).

Step 3: Pick the right level of tooling

There are three tiers, and most businesses start too high or too low.

No-code (Make, Zapier, n8n): perfect for connecting apps you already use — form to CRM to email. Fast to build, easy to change. Start here for standard integrations.
No-code with a developer's help: when the logic gets branchy or hits API limits, a developer building inside Make/n8n keeps it maintainable instead of a fragile spaghetti of steps.
Custom code: when the workflow is core to your business, high-volume, or needs logic the no-code tools can't express cleanly. More upfront work, but you own it and it won't break when a tool changes its pricing.

The honest rule: start no-code, graduate to custom only when the no-code version starts fighting you.

Step 4: Automate one thing, prove it, then expand

The mistake is trying to automate everything at once. Pick the single most annoying repetitive task, automate just that, run it for a week, and confirm it actually saves time and doesn't drop data. One reliable automation builds trust — and frees the time you'll use to build the next one.

Step 5: Build in safety nets

Automation that fails silently is worse than no automation. Whatever you build should log what it did, notify a human on failure (a Slack alert beats discovering a week of lost leads), and be idempotent where money or records are involved (running twice shouldn't create two invoices). These are the parts people skip and regret — and what separates a hack that works until it doesn't from a system you can rely on.

What good automation feels like

You stop being the integration layer between your tools. Data arrives where it needs to be, the right people get pinged, and you find out immediately when something needs a human. The goal isn't to remove people — it's to remove the copy-paste so people can do the work only they can do.

Drowning in repetitive tasks and not sure whether to go no-code or custom? I help small businesses build automations that are reliable, not fragile — vengstudio.online.

5 Signs Your Business Is Ready for an AI Assistant (and 3 Signs It Isn't)

pante5ter — Tue, 02 Jun 2026 17:43:39 +0000

A custom AI assistant — one that answers from your documents, products and policies — can quietly save a team hours a week. It can also be an expensive toy that nobody uses. The difference isn't the technology; it's whether your situation actually calls for it. Here's how to tell.

5 signs you're ready

1. You answer the same questions over and over

If your team retypes the same answers about pricing, hours, policies, or "how do I...", that repetition is exactly what an assistant absorbs. The more repetitive the questions, the higher the payoff.

2. The answers live in documents you trust

An assistant is only as good as its source material. If you have a knowledge base, product docs, FAQs or past tickets that are reasonably accurate, you have fuel. Good sources in, good answers out.

3. A wrong answer is annoying, not dangerous

The best first use cases are forgiving — support triage, internal "where's the doc on X", drafting first replies. If a rare mistake means a follow-up message rather than a lawsuit, you're in safe territory.

4. You have volume

Ten questions a week doesn't justify a build. Hundreds of repetitive interactions a week does — that's where automation pays for itself instead of being a novelty.

5. Someone will own it

An assistant needs a human who keeps its sources current. If one person owns "is the knowledge up to date," it stays useful. If nobody owns it, it rots.

3 signs it isn't time yet

1. Your information is scattered and contradictory

If the "source of truth" is three Google Docs, a Slack thread and someone's memory — and they disagree — an assistant will confidently repeat the contradictions. Fix the knowledge base first; that's valuable on its own.

2. Every answer needs human judgement

If the real work is nuanced negotiation or high-stakes decisions, an assistant can draft but shouldn't decide. If there's no safe "draft and a human reviews" mode, it's early.

3. You're doing it because it's trendy

"We should have AI" is not a use case. If you can't name the specific questions it will answer or the hours it will save, the honest move is to wait until you can.

What to do if it's too early

You're rarely "not ready" — you're usually one step away. Scattered info? Consolidate your FAQs and docs into one trusted place — that helps your team today and becomes the assistant's fuel tomorrow. Low volume? Start with a simpler automation and revisit when volume grows. Just curious? Pilot one narrow, forgiving use case before committing to anything broad.

The honest bottom line

A good AI assistant is grounded in your real content, says "I don't know" instead of inventing answers, and earns its keep on repetitive, high-volume, low-risk work. Built that way, it's one of the highest-ROI things a small team can add. Built on hype, it's shelfware.

Want a straight answer on whether an AI assistant fits your business — and one built to cite your real content instead of hallucinating? That's exactly what I do — vengstudio.online.

Supabase vs Firebase for Your MVP: A Practical Pick Guide

pante5ter — Tue, 02 Jun 2026 17:36:02 +0000

Both Supabase and Firebase let you ship a working product without building a backend from scratch. Both have generous free tiers. So the question isn't "which is better" — it's "which fits this MVP." Here's how I decide.

The one difference that drives everything: the data model

Firebase (Firestore) is a NoSQL document store — you think in collections and documents. Great for fast writes, real-time updates, and naturally nested data. Supabase is Postgres — a real relational database. You think in tables, rows, and relationships, and you can write SQL.

Everything else flows from this. If your data has clear relationships (users have orders, orders have items), Postgres keeps your data honest with constraints and joins. If your data is loose and document-shaped, Firestore fits comfortably.

Auth, storage, and the "batteries included" parts

Both give you authentication, file storage, and serverless functions out of the box, so neither blocks you on day one. Firebase auth is extremely mature and plugs into the Google ecosystem. Supabase auth is built on Postgres with Row Level Security, so your access rules live next to your data as policies. For an MVP both are more than enough — auth is rarely the deciding factor.

Pricing shape (not exact numbers — those change)

Don't compare sticker prices; compare the shape of how you pay. Firestore bills heavily by reads, writes, and deletes — apps that read the same data a lot can see costs climb in surprising ways at scale. Supabase bills more like traditional hosting (compute, storage, bandwidth), which is easier to predict. For an early MVP both are cheap or free; the shape matters most as you grow.

Vendor lock-in

This is where I lean Supabase for most clients. Because it's Postgres underneath, you can take your database and leave — export it, self-host it, or move to any Postgres provider. Firestore's data model is proprietary; migrating off it later is real work. If owning your data matters, that's a strong point for Supabase.

Real-time and offline

Firebase has best-in-class offline support and real-time sync — if you're building a mobile app that must work on a subway, that's a genuine edge. Supabase has real-time subscriptions too, and they're good, but Firebase's offline story for mobile is still ahead.

My rule of thumb

Pick Supabase if: your data is relational, you value SQL and predictable pricing, you want to avoid lock-in, or your team knows Postgres. This covers most web SaaS MVPs. Pick Firebase if: you're building mobile-first with heavy offline needs, your data is document-shaped, or you're already deep in Google's ecosystem.

Either way, the worst choice is agonising over it. Both will get your MVP in front of users this month — the only thing that matters at the MVP stage.

Deciding on a stack, or want your MVP built fast and clean on Next.js + Supabase? I help founders ship a real product instead of a prototype — vengstudio.online.

"It Works on My Machine" — Why Deploys Break and How to Stop It

pante5ter — Tue, 02 Jun 2026 16:58:42 +0000

The app runs perfectly on your laptop. You push to production and it white-screens, 500s, or won't even build. This is one of the most common — and most fixable — categories of bug. The cause is almost always a difference between your machine and the server.

1. Missing environment variables

Number one by a wide margin. Your local .env has the API keys and database URLs; production doesn't, because .env isn't committed (correctly). Locally the app finds its config; in production it gets undefined and crashes.

Fix: keep a committed .env.example listing every variable (names only, no secrets). Before deploying, confirm every variable in it is set in your host's dashboard. Most "works locally, breaks in prod" tickets end here.

2. Build-time vs runtime confusion

In frameworks like Next.js, some code runs at build time and some per request. A value that exists at runtime locally might be needed at build time in production — or a variable not exposed to the browser is read in client code and comes back empty.

Fix: know which code runs where. Public values the browser needs must be prefixed correctly (e.g. NEXT_PUBLIC_). Secrets must never be read in client components.

3. Case sensitivity

Your laptop (macOS, Windows) is usually case-insensitive: import Button from './button' finds Button.tsx. Production runs Linux, which is case-sensitive — and that import fails the build.

Fix: match the exact case of filenames in every import. A green local build and a red production build with "module not found" is almost always a case mismatch.

4. Dependency drift

Locally a package is cached at the version that worked. Production installs fresh from your lockfile — or without one, gets a newer, slightly different version.

Fix: commit your lockfile and make sure CI installs from it. "It built last week and not today, with no code change" is the signature of dependency drift.

5. Node version mismatch

You're on Node 20 locally; the host defaults to Node 18. A feature you rely on isn't there, and the build fails on something that looks unrelated.

Fix: pin the Node version in package.json (engines) and in your host's settings. Make the two match.

A deploy checklist that makes this boring

Every variable in .env.example is set in production.
The project builds from a clean clone, not just incrementally.
Import paths match filenames exactly (case included).
The lockfile is committed and used.
Node versions match locally and in the host.

Fix the root cause once — usually env vars and case sensitivity — and "works on my machine" stops being a phrase you dread.

Got a build that runs locally but won't deploy? That's a same-day fix — I find the exact mismatch, get it green, and tell you what went wrong so it stays fixed. vengstudio.online.

Your React App Feels Slow? 7 Real Causes (and How to Fix Each)

pante5ter — Tue, 02 Jun 2026 16:56:41 +0000

"It works, but it feels sluggish." That's one of the most common things clients say about a React or Next.js app — and almost always, the slowness comes down to a handful of fixable causes. Here are the seven I run into most, with the concrete fix for each.

1. Unnecessary re-renders

The single most common culprit. A parent re-renders, and every child re-renders with it — even the ones whose props never changed.

How to spot it: open React DevTools, enable "Highlight updates when components render," and click around. If half the screen flashes when you type into one input, you have a re-render problem.

Fix: wrap pure children in React.memo, stabilise callbacks with useCallback, memoise derived values with useMemo. Don't sprinkle these everywhere — measure first, then memoise the components that actually re-render hot.

2. State that lives too high

When you keep form state at the top of a large tree, every keystroke re-renders everything below it.

Fix: push state down to the smallest component that needs it. For genuinely global state (auth, theme, cart), use a focused store like Zustand and subscribe to one slice, so only the components using that slice re-render.

3. Oversized JavaScript bundles

If your app ships 1.5 MB of JS before anything is interactive, no micro-optimisation saves the first impression.

Fix: code-split by route and lazy-load heavy components with next/dynamic or React.lazy. Audit the bundle and look for accidental imports — pulling one helper from a giant library often drags the whole library in.

4. Images shipped at full size

A hero "image" that's a 4000px, 3 MB PNG tanks your Largest Contentful Paint on mobile every time.

Fix: use next/image so images are resized, served in modern formats (WebP/AVIF), and lazy-loaded below the fold. Set explicit width/height to avoid layout shift.

5. Blocking data fetching

If a page waits for one slow API call before rendering anything, users stare at a blank screen.

Fix: render the shell immediately and stream or progressively load data. Fetch on the server where it makes sense, cache aggressively, and use Suspense or skeletons so the page feels alive.

6. Effects that fire too often

A useEffect with the wrong dependency array can run on every render — re-fetching, re-subscribing, or looping.

Fix: get the dependency array right, debounce expensive effects (like search-as-you-type), and clean up subscriptions in the return function.

7. Doing too much on the main thread

Heavy synchronous work — parsing big JSON, sorting thousands of rows — blocks the thread that also handles clicks and scrolls. The result is jank.

Fix: move heavy work to a Web Worker, virtualise long lists so you only render what's on screen, and memoise expensive computations. Often the real win is not doing the work at all — paginate or filter on the server.

Approach it in order

Measure first — Lighthouse for the page-level picture, React DevTools Profiler for re-renders.
Fix the biggest lever first — usually bundle size or images for first load, re-renders for interaction speed.
Re-measure — confirm the number moved before moving on.

Most "slow app" complaints are solved by two or three of these — often a single focused afternoon.

Stuck on a React or Next.js app that feels slow and not sure which cause it is? I profile it, fix the highest-impact issues, and hand you the before/after numbers — vengstudio.online.

Hydration Errors in Next.js: What They Mean and How to Fix Them for Good

pante5ter — Tue, 02 Jun 2026 13:24:27 +0000

Few errors waste more time than a hydration mismatch. The app mostly works, the console screams "Text content does not match server-rendered HTML," and the cause is rarely where you're looking. Here's what's actually happening and how to fix it permanently.

What hydration is (in one paragraph)

Next.js renders your page to HTML on the server and sends it down so the user sees content fast. Then React "hydrates" that HTML in the browser — it re-runs your components and attaches event handlers, expecting the output to match the HTML the server already produced. A hydration error means the browser render and the server render disagreed. React notices, throws away the mismatched part, and re-renders on the client — which is slow and can cause flicker.

The usual culprits

1. Time, dates, and random values

The classic. The server renders the date at one moment; the browser renders it a few hundred milliseconds later — different text, instant mismatch. Math.random() does the same.

Fix: don't render time-sensitive or random values during SSR. Render a stable placeholder on the server and fill in the live value after mount (in useEffect), or compute the value once on the server and pass it down as a fixed prop.

2. window, localStorage, navigator

These don't exist on the server. If a component reads localStorage to decide what to render, the server (which has no localStorage) renders one thing and the browser renders another.

Fix: read browser-only APIs inside useEffect, which only runs client-side. Render the same neutral output on both server and first client paint, then update after mount.

3. Invalid HTML nesting

A div inside a p, or a p inside a p, gets "corrected" by the browser's HTML parser — so the DOM the browser builds differs from what React expected. This one is sneaky because the code looks fine.

Fix: keep your markup valid. Don't nest block elements inside a paragraph; don't put a div inside a button. If a third-party component does this, that's often the real source.

4. Browser extensions

Some extensions inject attributes or elements into the DOM before React hydrates (Grammarly is a frequent offender). The page is fine; the extension changed the HTML.

Fix: this one isn't your bug. Confirm by reproducing in an incognito window with extensions off. For inputs, suppressHydrationWarning on the specific element is an acceptable, targeted escape hatch.

5. Conditionals based on client-only state

Rendering a component only when isLoggedIn is true, where isLoggedIn comes from localStorage, is the same problem dressed up — the server can't know the value, so it renders the wrong branch.

Fix: gate client-only UI behind a "mounted" flag, or load that state through something the server can read too (a cookie, for example).

The reliable pattern: the "mounted" gate

For anything that legitimately differs between server and client, this small hook removes the whole class of errors:

const [mounted, setMounted] = useState(false);
useEffect(() => setMounted(true), []);
if (!mounted) return <Placeholder />; // same on server + first paint
return <LiveThing />;                  // only after hydration

Use it sparingly — overusing it means giving up SSR benefits — but for genuinely client-only widgets it's the clean fix.

How to debug efficiently

Read the diff. React's error usually shows expected vs received text. That points straight at the offending value.
Check incognito. If it vanishes with extensions off, it's an extension, not you.
Binary-search the tree. Comment out halves of the page until the warning disappears.

Hydration errors feel mysterious, but they almost always reduce to one rule: the server and the first client render must produce identical HTML. Once you internalise that, the fix for each case is obvious.

Fighting a hydration error or another Next.js bug that's eaten your afternoon? I fix React/Next.js bugs same-day, with a plain note on the root cause so it doesn't come back — vengstudio.online.

3 Reasons Your Web Scraper Breaks in Production (and How to Fix Each)

pante5ter — Mon, 01 Jun 2026 16:29:39 +0000

Most scrapers work great on your laptop and then quietly fall apart the moment they run unattended. The script that pulled 10,000 rows in a demo returns 12 rows at 3 a.m. and nobody notices for a week. After shipping a fair number of these for clients, the failure modes are almost always the same three. Here's how to make a scraper that survives real sites.

1. No retries

The single most common reason a scraper dies: one network timeout kills the entire run.

Real sites are flaky. A request that succeeds 99% of the time will still fail several times across a 10,000-page job — and if a single failure throws an uncaught exception, you lose the whole run, not one row.

The fix is retries with exponential backoff. Wrap each request, retry a few times with growing delays, and log what failed so you can inspect it later. You want to lose a row, not the job.

import time

def fetch(url, retries=3, backoff=2):
    for attempt in range(retries):
        try:
            return get(url)
        except TransientError as e:
            if attempt == retries - 1:
                log.warning("giving up on %s: %s", url, e)
                return None
            time.sleep(backoff ** attempt)

2. Hard-coded selectors with no fallback

Sites change their markup constantly. A scraper built around div.price-box > span.amount will silently return empty strings the day the site ships a redesign — and silent failure is the worst kind, because your pipeline keeps running on garbage data.

Two things make this survivable: use resilient selectors (prefer stable attributes like data-* or itemprops over deeply nested class chains), and validate what you extract. If a field that should always be present comes back empty, raise a clear error instead of writing a blank. A loud failure is a 5-minute fix; a silent one is a corrupted dataset.

3. No rate-limit or proxy handling

Hit a site too fast and you get blocked — IP ban, CAPTCHA wall, or throttling that quietly drops your success rate. A scraper with no pacing isn't faster, it's just banned sooner.

Add human-like delays between requests, respect robots.txt and any documented limits, and rotate proxies/user-agents for larger jobs. The goal is to keep collecting data steadily rather than burning your access in the first ten minutes.

The pattern underneath all three

Each fix is the same idea: assume the outside world is hostile and design for failure. Retries handle flaky networks, validation handles changing markup, and pacing handles defensive servers. A scraper that does these three things runs unattended for months; one that skips them needs a babysitter.

I build scrapers, automation and Telegram bots that hold up in production — clean, typed code you own. If you've got a scraping or automation job (or a scraper that keeps breaking), see my work here: https://vengstudio-portfolio.vercel.app

VENG STUDIO — code that comes alive.

How to stop your RAG assistant from hallucinating (a practical guide)

pante5ter — Sat, 30 May 2026 18:32:23 +0000

A RAG (retrieval-augmented generation) assistant is supposed to answer from your documents, not from the model's imagination. But teams keep shipping bots that confidently invent prices, policies, and features that don't exist. The hallucination usually isn't the model "being creative" — it's a retrieval and prompting problem you can fix. Here's the checklist I actually use.

Hallucination is usually a retrieval failure, not a model failure

If the right chunk never makes it into the context, the model fills the gap by guessing. So before blaming the LLM, ask: did retrieval even return the correct passage? Most "the AI lied" bugs are really "we fed it the wrong context" bugs. Fix retrieval first; it's where the biggest wins are.

Chunk for meaning, not for byte count

Splitting documents every N characters cuts sentences in half and scatters one answer across chunks.

Split on semantic boundaries — headings, sections, list items — not arbitrary lengths.
Keep chunks focused: one idea per chunk retrieves far more accurately than a wall of mixed topics.
Add a little overlap so context isn't lost at the seams.
Attach metadata (source, title, date) to every chunk — you'll need it for filtering and citations.

Retrieve better than plain vector search

Pure embedding search misses exact terms (product codes, names, numbers).

Use hybrid search: combine semantic (vector) with keyword (BM25) so both meaning and exact matches are covered.
Add a reranker to reorder the top candidates before they hit the prompt — it consistently lifts answer quality.
Tune how many chunks you pass. Too few starves the model; too many buries the answer in noise.

Make "I don't know" a first-class answer

This single instruction prevents most embarrassing hallucinations: tell the model to answer only from the provided context, and to say it doesn't know when the context doesn't contain the answer.

If the answer is not in the provided context, say you don't have that information — do not guess.

A bot that admits a gap is trustworthy. A bot that confidently makes something up costs you a customer.

Demand citations and ground every claim

Have the model cite the source chunk for each statement. Two benefits: users can verify, and you can automatically flag answers where the cited text doesn't actually support the claim. If it can't cite, it shouldn't assert.

Evaluate, don't vibe-check

You can't improve what you don't measure.

Build a small test set of real questions with known correct answers.
Track groundedness (is the answer supported by retrieved context?) and retrieval hit rate (did the right chunk show up?).
Re-run it on every change to chunking, embeddings, or prompts so you catch regressions before users do.

A reliable default stack

Clean, semantically chunked docs with metadata → hybrid retrieval + reranker → a strict "answer only from context, cite sources, admit unknowns" prompt → an eval set guarding the whole thing. Boring, measurable, and it stops the confident nonsense.

Done right, a RAG assistant becomes the thing customers trust for accurate answers 24/7 instead of a liability. I build RAG assistants and AI automation that stay grounded in real data as a freelancer — you can see examples at vengstudio.online. Questions about retrieval or grounding? Drop them in the comments.

Building a Telegram bot that takes payments: what actually matters

pante5ter — Sat, 30 May 2026 18:31:04 +0000

"Just add payments to the bot" sounds like a one-liner. In practice, the happy path is the easy 20% — the other 80% is the edge cases that decide whether you actually get paid and keep customers. Here's what actually matters when a Telegram bot handles money, learned from shipping a few of them.

Two very different ways to charge

There are two models, and picking the wrong one causes most of the pain:

Telegram's native payments (sendInvoice + a provider token like Stripe). The whole flow stays inside Telegram, the UX is excellent, and you get a clean successful_payment update. Great for digital goods and simple checkouts.
External payment link / your own gateway. You generate a link, the user pays on a web page, and your backend gets a webhook. More flexible (subscriptions, local providers, complex carts) but you own more of the plumbing.

For most "sell a product or a subscription" bots, native payments are the right default. Reach for external only when the provider or business model forces it.

The pre-checkout step is not optional

With native payments, Telegram sends a pre_checkout_query and you have ~10 seconds to answer it. If you don't answerPreCheckoutQuery(ok=true) in time, the payment fails — even though the user did nothing wrong.

This is where you do final validation: is the item still in stock, is the price still valid, is the user allowed to buy. Approve only if everything checks out. Skipping real validation here is how people sell things they can't deliver.

Treat money events as untrusted until verified

Two rules that save you from fraud and angry customers:

Verify webhook signatures. Anyone can POST to your webhook URL. If you act on an unsigned "payment succeeded" call, you'll ship goods for payments that never happened. Always verify the provider's signature before trusting the event.
Make payment handling idempotent. Networks retry. You will receive the same successful_payment / webhook twice. Store a unique payment ID and ignore duplicates, or you'll deliver (or refund) twice.

The database is the source of truth, not the chat

A Telegram message can be missed, edited, or arrive out of order. Don't drive business logic off the conversation state alone. Persist every order with an explicit status — pending → paid → fulfilled → refunded — and let the bot read from that. When a user writes "where's my order?", you answer from the database, not from memory.

Plan for refunds and failures from day one

The unglamorous parts customers judge you on:

A clear message when a payment fails (and an easy retry), not silence.
A defined refund path — Telegram supports refunds for native payments; wire it up before you need it.
An admin view: who paid, what's unfulfilled, what errored. A bot that takes money but gives the owner no visibility is a support nightmare.

A sane minimum architecture

Bot (webhook mode, not long polling for production) → a small backend that validates and writes to a database → payment provider webhooks landing on a separate, signature-verified endpoint. Keep secrets in env vars, log every money event, and alert on failed payments. That's it — boring on purpose, because boring is what you want around money.

None of this is hard individually; the value is doing all of it so nothing silently breaks once real money flows. I build Telegram bots with payments, databases and admin panels as a freelancer — you can see examples at vengstudio.online. Happy to answer implementation questions in the comments.

How I get Next.js sites to load almost instantly — a practical checklist

pante5ter — Sat, 30 May 2026 16:40:15 +0000

Speed isn't a vanity metric. On real projects, shaving load time directly moves conversion and Google rankings — Core Web Vitals are a ranking signal, and users bounce before a slow page even paints. Here's the checklist I actually run through on Next.js builds, in the order that gives the biggest wins first.

1. Ship less JavaScript to the client

The single biggest lever. Most "slow React site" problems are really "we hydrated 400KB of JS the user never needed" problems.

Keep components as Server Components by default (App Router). Only add 'use client' where you genuinely need state or browser APIs.
Push 'use client' down the tree, not up. A whole page doesn't need to be client just because one button is interactive.
next/dynamic for anything heavy and below-the-fold (charts, editors, 3D, modals):

const GalaxyScene = dynamic(
  () => import('@/components/GalaxyScene').then((m) => m.GalaxyScene),
  { ssr: false, loading: () => null },
);

2. Stop layout shift before it starts

CLS is the easiest Vital to wreck and the easiest to fix.

Always give next/image explicit width/height (or fill + a sized container).
Reserve space for anything async — ads, embeds, banners.
Load fonts with next/font so the swap doesn't reflow text:

import { Inter } from 'next/font/google';
const inter = Inter({ subsets: ['latin'], display: 'swap' });

3. Treat images like the heaviest thing on the page (they are)

Use next/image — it gives you AVIF/WebP, correct sizing, and lazy loading for free.
Mark the hero image priority so it isn't lazy-loaded; lazy-load everything else.
Serve dimensions that match the rendered size. A 4000px photo in a 400px slot is wasted bytes.

4. Render on the server, cache aggressively

Prefer static rendering / ISR for anything that isn't per-request personalized. A pre-rendered page paints almost instantly.
Use fetch caching and revalidate instead of refetching on every hit.
Move third-party scripts to next/script with strategy="lazyOnload" so analytics and chat widgets don't block your main thread.

5. Measure on a throttled mobile, not your laptop

Your machine on fiber lies to you. Run Lighthouse in mobile mode with CPU throttling, and watch the field data in Search Console (CrUX) — that's what Google actually ranks on, not your local numbers.

A useful habit: set a performance budget (e.g. < 150KB JS on first load) and let CI fail the build if a PR blows past it. It stops slow creep before it ships.

None of this is exotic. It's just doing the boring things consistently — and the payoff is a site that feels instant, ranks better, and converts more.

I build Next.js sites, Telegram bots and AI automation as a freelancer — if you want a fast, SEO-ready site, you can see my work at vengstudio.online. Happy to answer Next.js performance questions in the comments.