DEV Community: Nazma Akter

From checkout to "seat booked": how free and paid orders turn into event registrations

Nazma Akter — Tue, 20 Oct 2026 05:01:44 +0000

Selling a live event sounds simple until you build it. A payment has to become a seat, the seat has to show up in the buyer's dashboard, and the meeting link should be useful at the right moment and not before. In VeloxonHub events are just another product type, so they go through the same cart and checkout as courses and memberships. The 30-second reel shows the flow. Here's what happens under the hood.

1. An event is a product with settings, not a separate system

The host creates an event in a 6-step drawer: details, type, schedule, registration, pricing and notifications. Under the hood it's a scheduling product with event settings (type, recurrence, capacity, replay) and one or more occurrences (start, end, time zone, meeting provider, join URL). If the host picks the built-in live room, the live session is created from the event's name and date, so there's no link to paste.

Prices are attached after the first save, through the same pricing model every other product uses. That keeps the Product List widget and the cart unaware of what an "event" is.

2. The widget and the cart don't special-case events

The Product List widget the host drops on a page reads the public products endpoint and renders events next to everything else, with their active prices, search, filters and an Add to Cart button. The cart and checkout work the same way for every product type.

3. Fulfilment happens on the paid order item

When an order is paid, an access service walks its items and grants access per product type. For a scheduling item, it creates the buyer's booking for that event. If the event needs approval (the waitlist option), the booking stays pending and the host is notified. The approval notice is sent after the payment is recorded, so a notification problem can never turn a successful payment into an error for the buyer.

4. Join is a time window, not just a link

The buyer's dashboard shows the booking in a calendar. The Join button only unlocks when two things are true:

the booking is confirmed, approved or rescheduled, and
it's no more than 10 minutes before the start. For a recurring event, that means the next upcoming occurrence.

Before that, the card shows the date and time in the buyer's own time zone. Showing the link too early mostly produces people sitting alone in an empty room.

What we'd tell someone building the same thing

Model events as products. Your cart, coupons, checkout and receipts then come for free.
Fulfil per order item, after payment, and make side effects (emails, notifications) unable to fail the purchase.
Treat "join" as a window with a status check, not a URL you hand out at checkout.

Try it with a free trial: https://veloxonhub.com. I'm happy to go into the booking or time-zone logic in the comments.

Five AI media types, three pipelines: how we built AI Studio in Go and the browser

Nazma Akter — Tue, 20 Oct 2026 04:22:53 +0000

VeloxonHub Social has an AI Studio that makes five kinds of media for social posts: images, infographics, carousels, slide decks and short vertical videos. From the outside it's one form with five tabs. Underneath, it's three pipelines, because the five outputs fail, cost and finish in different ways.

Here's how each one works, and the decisions that made them reliable.

Pipeline 1: images and infographics (synchronous)

An image or an infographic is a single HTTP request that returns a finished file.

Model routing comes from a table, not code. Every model a user can pick lives in an ai_models table: its OpenRouter id, a display name and which use it is the default for (image, infographic, post, slides…). The model picker in the UI is just that table. A google/… model runs on our Gemini key; anything else goes through OpenRouter. Changing the default image model is a row update, not a deploy.

Infographics get a stricter prompt than images. Image models invent numbers when given space for a chart. The infographic prompt asks for short, legible text and says, in so many words, do not invent statistics that are not given below. The form says the same thing to the user: "Give the exact facts and numbers to include; the AI won't make any up."

Storage is checked before the model is called. Generated files go into the workspace's media library, which has a quota. We check for room (with some headroom) before calling the model, so nobody pays for an image we then can't save.

Credits are held, then settled or refunded. The flow is:

Hold the credits for the generation.
Create a generation row (prompt, options, model, which key).
Call the model, store the file, add it to the library.
Settle the hold on success. On any failure, refund it and mark the row failed with a message a person can read.

A failed generation never costs the user anything, and the history shows why it failed instead of a spinner that never ends.

Errors are split by whose problem they are. If our own provider account runs out of quota, that's our problem: the user sees "AI is temporarily unavailable", and we get a log line telling us to check billing. If the user's own key runs out, they get the provider's message, because they're the one who can fix it. That brings us to keys.

Bring your own key, everywhere

Every workspace can pay with our AI credits or connect its own key. Images run on a Gemini or OpenRouter key, and videos on a Gemini key. The generation row records which key it used, which matters most for the next pipeline.

Pipeline 2: video (asynchronous)

A video takes minutes to render, so the API can't wait for it.

Generate starts the render with the video model and stores the provider's operation id on the generation row, then returns at once. The UI shows "rendering".
A worker polls the operations that are due, a few at a time. When one finishes, it downloads the file, stores it, adds it to the library and settles the credits.
A render that's still running after 30 minutes is marked failed and its credits are refunded automatically.
If the user removes the API key a video was started with, the poll fails cleanly with "the API key this video was made with was removed" rather than retrying forever.

The rule that kept this simple: the generation row is the whole state machine. The request handler and the worker never talk to each other; they both read and write that row.

Pipeline 3: carousels and decks (AI writes, the browser draws)

A carousel or a deck is mostly text, and image models are at their weakest with text: words get misspelled, slides in one set don't match, and fixing one word means generating the whole image again.

So carousels and decks are split in two:

The server asks a text model for JSON. A carousel is {title, caption, slides: [{heading, body}]}; a deck is {title, subtitle, slides: [{heading, bullets, notes}]}. The system prompt sets the shape and the limits: headings of at most 8 words, a hook on the first carousel slide and a call to action on the last, speaker notes for decks, and no invented facts. The parser is deliberately forgiving: it takes the outermost {…} even if the model wrapped it in prose, trims every field to what the templates can show, drops empty slides and cuts the list to the slide count the user asked for.

The browser draws the slides on a canvas. Carousel slides are 1080×1350 (Instagram's 4:5) and deck slides are 1920×1080. A small text-fitting routine wraps each block and shrinks the font in steps until it fits its box, so a long heading never overflows. Because the browser draws the text with system fonts, every script those fonts cover works, and a typo fix is just an edit followed by a redraw. There are five colour themes to switch between, plus an optional footer handle.

Exports happen client-side too. Carousel slides are exported as PNGs. Decks are packed into a PDF by about 40 lines of TypeScript that write the PDF objects by hand: one full-page JPEG per page, with no PDF library. The browser then uploads the files to the library, linked to the generation.

The result: the AI does the writing it's good at, and the layout is deterministic and editable.

What we'd tell you if you're building something similar

Keep a generation table from day one. History, refunds, async polling and failure messages all hang off it.
Hold credits, don't charge them. Settle on success and refund on every failure path, including the boring ones like "the file couldn't be saved".
Don't let image models draw text you care about. Ask a text model for structured content and render it yourself.
Put model choice in data. New models ship every month, and a table row is easier to change than a release.

Try it

AI Studio is part of VeloxonHub Social. It's included on the Elite plan and is an add-on on Basic and Pro, and every plan starts with a 7-day free trial.

I'm happy to go deeper on the video polling or the canvas text fitting in the comments.

Keeping an AI lead researcher honest: "word for word" facts and emails that are never guessed

Nazma Akter — Mon, 19 Oct 2026 12:47:44 +0000

Lead discovery is an easy place for AI to make things up. Ask a model for "the founder of Cedar Creative and their email", and it will happily invent a plausible name and alex@cedarcreative.com. A cold email to an invented address bounces and hurts your sender reputation. A wrong name is worse.

When we built lead discovery for VeloxonHub Reach, we set one rule for everything shown on a lead: every fact has to come from a page we actually read, and the user can see that page. The 30-second reel shows the flow. Here's how the rule works in practice.

1. Search returns evidence, not just names

A run takes a plain-language description ("independent social media agencies managing content for 5–20 clients") and searches public websites and indexed LinkedIn, Facebook and X pages through Exa. Each run returns up to 10 results, deduplicated by product and normalized URL, so running the same search again doesn't fill your list with copies.

Every lead keeps the text that made it match, shown as "Why this lead appeared". The fit score next to it is a keyword match, and the UI labels it as a heuristic, not a purchase probability. We'd rather undersell the score than have someone treat it as a prediction.

2. Emails are extracted, never guessed

Deep research reads each website lead's contact, about and team pages. An email is added only if it appears in that text. Addresses on the lead's own domain come first, and no-reply and placeholder addresses are dropped. The lead also stores the page the email was found on, so "where did this address come from?" always has a clickable answer.

We pull phone numbers the same way: from tel: links, or from numbers that start with + or follow a phone label. WhatsApp comes only from wa.me or api.whatsapp.com links. We don't use heuristics that "look like a phone number" anywhere else on the page.

3. AI facts must appear word for word

To find named people and company facts, the model reads the same page text and returns owners, founders and leaders with their titles, plus team size and founding year. Then we check each one against the text:

each fact is kept only if the page text contains it word for word

If the model returns "Alex Rivera, Founder & Creative Director" and that string isn't on the page, it's dropped. No error and no fallback, just an empty field. An empty field is honest, and a made-up one isn't.

This check also makes failures harmless. If the AI call fails or the workspace is out of credits, the people and company fields stay empty, and the rest of the lead is unaffected.

4. Research never sends anything

A run can also write a first message for every new lead. Email goes to leads with an address, and LinkedIn and Facebook leads get a manual DM task with an "Open profile" link. But research never sends anything: every draft waits in review. Private profiles are never accessed.

What we'd tell someone building the same thing

Store the source URL next to every extracted value. It's the cheapest trust feature you can ship.
Check model output against the text you gave it. Matching it word for word is crude, but it catches a whole class of made-up facts.
Name your heuristics in the UI. "Keyword match heuristic, not a purchase probability" saves an argument later.

Try it with a 7-day free trial: https://reach.veloxonhub.com. I'm happy to go into the matching or the Exa setup in the comments.

Why we treat chat as a product, not a channel

Nazma Akter — Mon, 19 Oct 2026 05:30:41 +0000

Most creators who sell a paid community run it on rented tools. The payment goes through Stripe or Gumroad, the conversation happens in WhatsApp or Discord, and someone has to remember to remove people when they stop paying.

While building Group Chat for VeloxonHub, we made one decision that most of the design follows from: a group chat is a product, just like a course or a membership.

What "chat as a product" means in practice

A group chat has:

Prices. Chat prices are the same price objects the rest of the platform uses, so a room can be sold as a subscription, a one-time purchase or any other pricing model the editor supports. We didn't write separate billing code for chat.
Members and entitlement. Who can read and post is decided by entitlement, not by an invite link. When a subscription ends, access ends with it.
A public page. Each room gets SEO metadata and a public sales page, so people can find a paid room through search and buy it, just like a course landing page.
Plan limits. The number of rooms is a plan limit (5, 20 or unlimited), checked the same way as other products.

The realtime part

Messages are delivered over a socket. History is loaded over REST and the socket pushes new messages. On top of that we built what people expect from a modern chat:

reactions, pins, edit and delete
voice notes recorded in the browser, plus file attachments
mute, read marks, unread badges and online status
message reporting that goes into an admin moderation queue

Private 1-to-1 chat and group chat run on one shared chat engine. Creators can sell paid access to themselves as a separate product, and we only maintain one messaging stack.

Two lessons we learned

1. Read state lives in two places. The server stores read marks, and the client keeps local marks so the UI responds instantly. If you update only one of them, the unread badge shows the wrong count. Every path that marks a conversation as read now updates both.

2. Every message write has to go through the live connection. We once added a message action that wrote only through REST. It saved correctly but didn't appear for anyone until they reloaded. Now the socket hook owns the live state, and every write path must go through it.

What it isn't

To be clear about the limits: this is messaging between a creator and their audience, not a Slack replacement. It has no voice or video channels and no nested channels with threads. We left those out on purpose. The goal is a room people pay to join that sits next to the course they bought, not a workplace tool.

Try it

If you sell courses, coaching or a community and you're tired of maintaining a Discord bot just to check who has paid, have a look: https://veloxonhub.com

I'm happy to answer questions in the comments about the entitlement model or the socket setup.

One post, 14 networks: how our composer handles per-network text, limits and timing

Nazma Akter — Mon, 19 Oct 2026 05:01:02 +0000

Write once, post everywhere" is the promise of every social media scheduler. While building the composer for VeloxonHub Social, we found that most of the work is in the exceptions. Bluesky caps a post at 300 characters, and LinkedIn allows 3,000. Some networks need an image, and others can't take the one you attached. Posts are scheduled across time zones. And none of these networks accept formatted text.

Here's how we handle each of these. There's also a 2-minute video of the composer in action.

1. One base text, optional overrides per network

A post has one content and a platform_options map keyed by network. The text a network will actually get is resolved in one place:

const textFor = (p: Platform) => options[p]?.text?.trim() || content;

Clicking "Customize text" copies the current base text into that network's override. From then on, the base text and the override are edited separately until you click "Use main text". Network-specific fields live in the same map: a YouTube title and visibility, a Facebook link, a title, status and tags for Dev.to and WordPress, and tags for Tumblr. Before the post is saved, options for networks that are no longer selected are dropped, so a deselected network doesn't leave stale settings behind.

2. Validate each network, and give each problem a fix

Validation runs separately for each network on the text and media that network would actually receive (textFor(p), mediaFor(p)), not on the base post. Each problem is shown with the network's name, such as "Bluesky allows 300 characters (335 now)". The Schedule button stays disabled until every problem is fixed.

Media problems get a one-click fix. When a network can't take the attached files, the warning shows a "Remove media for LinkedIn" button. It sets a no_media flag in that network's options, and the media resolver then returns nothing for that network. The other networks still get the image.

We count characters with [...text].length, which counts code points, not text.length. An emoji or a "bold" letter is one code point but two UTF-16 units, so text.length would make the counter disagree with the network.

3. "Formatting" is Unicode

Social APIs accept plain text, so the editor's bold, italic and monospace buttons map letters to the Mathematical Alphanumeric Symbols block (sans-serif bold starts at U+1D5D4). Underline and strikethrough add combining marks (U+0332, U+0336). The result survives copy-paste and every network's API exactly as typed. Bullet styles (•, ✅, 👉…), numbered lists, quotes and dividers are line prefixes, so they're plain text too.

One trade-off to be honest about: screen readers may read styled letters one character at a time. We keep formatting for emphasis and don't apply it to whole paragraphs.

4. Time is a wall-clock time plus a zone

The date picker holds a wall-clock time like 2026-10-24T09:00 in your profile's timezone, or in the zone you pick for that post, which is saved with it. It's converted to an instant only when the post is saved. If you change the timezone after picking a time, we keep the wall-clock time, so "9:00" now means 9:00 in the new zone. That's what people expect when they switch from New York to London.

Each account can override the post's time with Post's time, Publish now or Own time. These overrides are sent as separate account_schedules, so one post can go out to LinkedIn at 9:00 in Europe and to Instagram at 18:00 in New York.

5. Retries are part of the record

Every publish attempt is logged with its outcome: published, transient_error, permanent_error or auth_error. Temporary errors (network failures, HTTP 429 and 5xx) are retried automatically with backoff. Validation rejections fail right away, because sending the same request again won't fix them. Authorization errors trigger a token refresh, or ask you to reconnect the account. The post page shows the full history for each network, so "it posted on the second try" is something you can see, not just guess.

See it

The reel shows the full flow: accounts → AI draft → formatting → templates → media → previews → per-network versions → timezone and per-account scheduling → approvals → retries and history → duplicate. 7-day free trial, no card: https://social.veloxonhub.com

Questions about the per-network override model or the Unicode formatter are welcome in the comments.

Installed, but nothing shows": building an install check for a third-party widget

Nazma Akter — Mon, 19 Oct 2026 04:26:14 +0000

Any product that ships a <script> tag for customers to paste into their site gets the same support ticket: "I installed it, but nothing shows." Most of the time the snippet is fine, and something else is in the way.

For VeloxonHub ProofLoom, our social proof widget, we built the setup flow so it ends when the widget is working, not when the code is copied. The 15-second reel shows the whole flow. Here's how it works.

Step 1: Prove you own the domain

A widget that shows "Liam from Austin just purchased…" on any domain that copies the snippet would be a problem, so notifications only run on verified domains. We offer two ways to verify, because different people control different things:

A DNS TXT record, for people who can reach their DNS. The setup screen explains that many providers (Cloudflare, GoDaddy, Namecheap…) add the root domain to the Name field automatically, so you only enter the subdomain part. This is the most common reason verification fails.
A verification file served at /.well-known/proofloom-verification.txt, for people who can upload files but can't change DNS.

Step 2: One script, with platform-specific steps

The snippet is the same everywhere:

<script async src="https://proofloom.veloxonhub.com/widget/v1/widget.js" data-site="site_…"></script>

What changes from platform to platform is where to paste it, so the install panel asks "Where is your site built?" and shows the steps for WordPress, Shopify, Webflow, Wix, Squarespace, Next.js / React, Google Tag Manager or any site. Some no-code builders' code boxes don't accept <script> tags. For those, there's a plain JavaScript version that loads the same widget.

The script is async and never blocks rendering. If our servers are down, the customer's site works as usual. You lose the notifications, not the page.

Step 3: The install check

This is the part that cut down the support tickets. Test installation opens the customer's page from our server and runs a list of checks, each of which passes, fails, warns or is skipped:

Domain verified. Is the host verified for this website?
Snippet on the page. Can we open the page, and is the script tag there? If the page doesn't load, we show the actual error, such as a DNS lookup failure or a timeout, and point out that the page has to be public. Firewalls that block bots are a common cause.
Site ID matches. Is it the snippet for this website, or one copied from another workspace or a staging site?
Not blocked by Content Security Policy. A strict script-src or connect-src blocks the widget silently, with no visible error. We read the CSP header and tell the customer which directive needs our origin.

When we can't open the page, the later checks are marked "Checked once we can open your page" instead of failing. A failure would suggest that those checks found a problem.

The check also runs once on its own if a website has never seen the widget. "Installed, but zero visits" is the most confusing state, so we start explaining it before anyone asks.

Two smaller things that helped

Consent mode. Add data-consent="required" to the script tag, and the widget waits until your banner calls ProofLoom.consent(true).
A preview flag. Add ?proofloom_preview=1 to any page to see the widget with labelled sample data, without counting a visit. This lets customers check the design before they have any real activity.

Try it

14-day free trial, no card needed: https://proofloom.veloxonhub.com

If you've built an install flow for an embeddable widget, I'd like to hear which check caught the most problems for you.

One post, 14 networks: how our composer handles per-network text, limits and timing

Nazma Akter — Mon, 19 Oct 2026 03:01:10 +0000

Here's how we handle each of these. There's also a 2-minute video of the composer in action.

1. One base text, optional overrides per network

A post has one content and a platform_options map keyed by network. The text a network will actually get is resolved in one place:

const textFor = (p: Platform) => options[p]?.text?.trim() || content;

2. Validate each network, and give each problem a fix

3. "Formatting" is Unicode

One trade-off to be honest about: screen readers may read styled letters one character at a time. We keep formatting for emphasis and don't apply it to whole paragraphs.

4. Time is a wall-clock time plus a zone

5. Retries are part of the record

See it

Questions about the per-network override model or the Unicode formatter are welcome in the comments.

Building Customer Trust with VeloxonHub ProofLoom: A Product Tour

Nazma Akter — Sat, 17 Oct 2026 05:40:20 +0000

Visitors are landing on your website. Before they buy, they’re asking one question: “Can I trust this brand?”
Meet VeloxonHub ProofLoom. 🚀
Turn real customer activity and approved testimonials into social proof that helps visitors buy with confidence.
In this product tour, see how you can:
✅ Display social proof notifications powered by real orders and activity
✅ Collect and showcase customer testimonials with permission
✅ Customize campaigns to match your brand
✅ Manage social channels and your content calendar in one place
✅ Track campaign performance with built-in analytics

Built around one simple belief: social proof only works when it’s true.

VeloxonHub #ProofLoom #SocialProof #SaaS #Ecommerce #CustomerTrust #CustomerTestimonials #CustomerReviews #ConversionOptimization #DigitalMarketing #EcommerceMarketing #SocialMediaManagement #ContentMarketing #MarketingTools #OnlineBusiness #BusinessGrowth #ProductDemo #ProductTour #BuildInPublic #SaaSProduct