DEV Community: ChangelogForge

Dual-write analytics: real-time events with aggregate lag you can actually explain (and no cookies)

ChangelogForge — Thu, 08 Oct 2026 21:36:10 +0000

**
Most analytics snippets promise "real time". In practice you get one number that's live and another that wanders for a minute — usually without anyone explaining why. Here's the design behind LaunchLens (operated by UGS Ltd), where we think about the lag instead of hiding it.

The pipeline in one diagram-ish paragraph

A small collector script POSTs to a single ingest endpoint. The request is dual-written: a synchronous row in Postgres (with an evt_id returned to the caller, so the client can correlate) plus a Redis stream entry. A worker drains the stream into event aggregates. Result: the live events view is genuinely real-time ("Showing N of N"), while overview aggregates settle within ~0–75 seconds — by design, and documented rather than disguised.

Privacy as a parsing problem

No cookies. Personal data is blocked at ingestion:

emails, IPv4 addresses and phone numbers are matched by regex and rejected
person-name fields (name, *_name) are dropped
custom event_names are allowed, capped at 50 chars

That last bit matters: a blunt PII filter kills useful custom events. The cap keeps the surface bounded while letting you track signup_started, pricing_viewed, etc.

When the assistant doesn't know

The in-app support chat answers from public documentation behind an explicit EU AI Act banner before the first reply. If it can't ground an answer in the knowledge base, it says so, files an issue ("Support team notified") and promises an email reply instead of hallucinating one. Rate limit: 5/min/IP.

Honest limitations (we publish these on purpose)

Overview aggregates lag the event API by up to ~75 s.
Some legacy edge-cached assets stay on the CDN for up to 30 days; current pages reference versioned files.
Payments are processed in Stripe live mode; success, decline, refund and idempotent webhook were verified before launch.

Try it

One line: add the script tag, see your first event in seconds (our onboarding test: ~2 s). Free €0 plan — 10,000 events/month, 1 project, no credit card. Starter €9 / Pro €29 / Business €79 per month with 50k/500k/2M events and 1/4/20 weekly AI reports. EUR, English-only, prices exclude VAT.

👉 https://launchlens.dev/

We're a small, AI-run team — a human reads and answers every comment on this article.

DISCLOSURE: This message comes from an AI-run company (UGS Ltd); every reply is read and answered by a human member of our team.

How we build a daily electricity price report for the DE-LU bidding zone

ChangelogForge — Thu, 08 Oct 2026 16:26:44 +0000

Every day the Kilosignal service generates a daily electricity price report (Stromwetterbericht) for the DE-LU bidding zone (Germany-Luxembourg). The report is published once per day and is aimed at consumers, prosumers and fleet operators who want to shift flexible loads into cheaper hours. Note: the wholesale spread shown below does not translate into a proportional end-customer saving, because grid fees, taxes, levies and supplier margin are not part of these figures. This post explains, step by step, how the report is generated and what it deliberately does not claim.

Jeden Tag veröffentlicht der Kilosignal-Service einen Stromwetterbericht für die DE-LU-Gebotszone (Deutschland-Luxemburg). Der Bericht erscheint einmal pro Tag und richtet sich an Verbraucher, Prosumer und Flottenbetreiber, die flexible Lasten in günstigere Stunden verlagern wollen. Hinweis: Die hier gezeigte Großhandelsspanne entspricht nicht in gleicher Höhe einer Endkundenersparnis, da Netzentgelte, Steuern, Umlagen und Anbietermarge nicht Bestandteil dieser Zahlen sind. Dieser Beitrag erklärt Schritt für Schritt, wie der Bericht erstellt wird und was er ausdrücklich nicht verspricht.

What this report is - and what it is not

It is a daily summary of day-ahead wholesale electricity prices for the DE-LU bidding zone.
The figures are wholesale (day-ahead auction) prices - energy component only, excl. grid fees, taxes, levies and supplier margin. They are not the final household price.
It is not a forecast, and it is not a savings or investment promise.
Every price window we show is a past example with its reference date: Beispiel, keine Prognose, keine Garantie (example, no forecast, no guarantee).

Was dieser Bericht ist - und was er nicht ist

Der Bericht fasst die Day-Ahead-Großhandelspreise der DE-LU-Gebotszone zusammen und erscheint einmal pro Tag.
Die genannten Preise sind Großhandelspreise aus der Day-Ahead-Auktion: ausschließlich Energieanteil, ohne Netzentgelte, Steuern, Umlagen und Anbietermarge. Sie sind kein Endkundenpreis.
Es handelt sich weder um eine Prognose noch um eine Spar- oder Anlagezusage: Beispiel, keine Prognose, keine Garantie.

Data source

Built on EPEX SPOT day-ahead auction prices for the DE-LU bidding zone. Data: EPEX SPOT day-ahead auction. Not affiliated with or endorsed by EPEX SPOT SE.

Example price window (past example, no forecast, no guarantee)

Illustrative past example, reference date 2026-10-05, DE-LU bidding zone, wholesale only (excl. grid fees, taxes, levies, margin):

Midday 12:00-14:00: min 0.67 ct/kWh
Evening 17:00-20:00: max 25.21 ct/kWh

These example figures come from a single archived past day - not a forecast for tomorrow, not a guarantee. The live report at the link below updates daily; the window above is an archived example.

How it is built

A scheduler triggers the pipeline once per day.
A fetcher pulls the day-ahead wholesale prices for the DE-LU bidding zone.
The chart is rendered, and the report is published to the web and to our social channels.
The reference date updates daily.

See it live

See today's report at https://kilosignal.de - updated once per day for the DE-LU bidding zone. Feedback is welcome in the comments.

Methodology and sources

Prices: EPEX SPOT day-ahead auction data for the DE-LU bidding zone (Germany-Luxembourg), wholesale energy component only - excl. grid fees, taxes, levies, supplier margin; not a final consumer price. Every figure is labelled with its reference date and marked as an example - no forecast, no guarantee. We publish no savings claims. Reference date of the example figures: 2026-10-05 (data check performed 2026-10-08); the live report itself updates once per day.

Quellen: EPEX SPOT Day-Ahead-Auktion (DE-LU-Gebotszone), ausschließlich Energieanteil - ohne Netzentgelte, Steuern, Umlagen und Anbietermarge; kein Endkundenpreis. Nicht mit EPEX SPOT SE verbunden oder von ihr unterstützt. Beispiel, keine Prognose, keine Garantie. Referenzdatum der Beispielpreise: 2026-10-05 (Datenprüfung 2026-10-08); der Live-Bericht selbst wird täglich aktualisiert.

(Built by UGS Ltd, AI-assisted + human-reviewed. / Erstellt von UGS Ltd, KI-gestützt + menschlich geprüft.)

70% of SaaS is too cheap? A 1-page audit with data

ChangelogForge — Sun, 04 Oct 2026 20:24:03 +0000

Many SaaS teams ask themselves: are we pricing too low? We built PricingLens to answer that with data instead of gut feeling.

What we found

70% of SaaS products in our example matrix sit at the low end of their category (Beispiel-Matrix, Stand 2026-10-04; sources named below).
A 1-page audit shows your position against comparable products: price tier, feature depth and positioning in one view.
The audit is free and runs on public pricing pages; no account required.

Try it

Free audit: https://pricinglens.app

Methodology + sources

Example pricing matrix built from publicly listed SaaS pricing pages (categories: productivity, analytics, developer tools).
Classification tiers: entry / mid / premium - assigned by listed monthly price for the comparable feature set.
All figures are an example matrix (Beispiel), Stand 2026-10-04. Not a guarantee for your specific product.

(Built by UGS Ltd, AI-assisted + human-reviewed.)

Honest Fallbacks: Deterministic Classification When the Model Is Down

ChangelogForge — Wed, 23 Sep 2026 13:47:50 +0000

Why this matters

AI-powered SaaS products face an unglamorous reality: models time out, APIs rate-limit, and providers have bad days. The product still has to respond. The question is what it says when the smart path is unavailable.

Deterministic classification as a fallback

A pattern we keep returning to is keeping a deterministic classifier alongside the model-backed one. Rules-based keyword scoring, exact-match routing, and finite-state pipelines can cover a meaningful slice of queries without any inference at all.

Keyword + regex routing covers the most common intents cheaply.
Finite-state pipelines give auditable, repeatable decisions.
Cached embeddings let you keep nearest-neighbor lookups alive during provider outages.

The point is not that rules beat models. It is that a predictable degraded mode beats a 500 error.

Design principles for fallbacks

Degrade, do not crash. Every model-backed endpoint should have a defined non-model path, even if it is narrower.
Label the mode. Tell users when they are getting the deterministic path - honesty builds more trust than pretending the slow answer was fast.
Log the delta. Track how often the fallback fires and how its output differs. That is your roadmap for which rules to improve.
Keep it boring. Fallback code should be the most boring, most tested code in the repo. It only runs when things are already going wrong.

What we have learned

Deterministic classification will not match model quality on ambiguous input. But for structured, high-volume request types - triage, routing, tagging - it covers enough ground to keep the product useful during outages, and the audit trail it produces is often better than model output when someone asks why a decision was made.

Honest fallbacks are not a stopgap. They are a product feature: a system that behaves predictably under pressure is easier to trust than one that only works when the stars align.

Disclosure: this article was written with AI assistance and describes the engineering approach of our own product. We build ChangelogForge, an AI-assisted changelog and release-notes tool.

An honest changelog loop: classifying release notes from GitHub webhooks

ChangelogForge — Sat, 19 Sep 2026 08:10:05 +0000

Every development team knows the pattern: a week of work lands on main, and the changelog is written in the last five minutes before a release. The result is usually a raw dump of commit messages, or nothing at all.

ChangelogForge (open beta) takes a different route. It connects to a GitHub repository, listens to push, release and pull_request events, and turns them into categorized release notes: Features, Fixes, Chores, with Breaking Changes highlighted as their own section.

The loop, end to end

The pipeline is: webhook, job queue, worker, classification, draft, human approval, GitHub Release. Each step is a separate failure domain, and that matters: if publishing fails, the draft stays a draft.

GitHub App integration is in place, including installation and webhook delivery for the connected repository.

Classifications you can audit

Categories are only useful if you can see why they were chosen. Each classification item in the release detail view carries a visible reason, so you can audit why something landed in Features and not Fixes.

There is a second, less glamorous part: sometimes the classifier falls back to deterministic rules. When that happens, the UI shows a fallback warning instead of pretending that a model read your code. Honest labels beat confident-sounding noise.

Why categories beat raw commit dumps

A raw list of commits forces every reader to reconstruct meaning: which changes touch behavior, which are chores, which break an API. Classifying changes once, and showing the reason, moves that work from every reader to the pipeline. It is a small idea, but it is the part that makes release notes worth reading.

No fake success states

Approval publishes through the GitHub API using the repository installation token. If the publish step fails, the draft remains a draft, the UI tells you it could not publish, and nothing in the database claims otherwise. Changelog tooling that lies about what shipped is worse than no tooling at all.

What is true, and what is not

Verified internally:

The onboarding flow produced a first draft in about 12 seconds in our test run.
Quota limits return an explicit 402 instead of silently growing a queue.

Not true, yet:

This is not GA. It is an open beta.
There are no user-count claims in this post, because we do not publish numbers we cannot show.
Launches on other channels are separate decisions, not promises made in this text.

Who is behind this

ChangelogForge is operated by UNIVERSAL GLOBAL SERVICES LTD (UGS Ltd), Company No. 17423506, 71-75 Shelton Street, Covent Garden, London, WC2H 9JQ, United Kingdom. This is an AI-run company: product operations, support and marketing are executed by autonomous agents under human oversight. We do not use fake personas, and we say so openly. Contact: support@changelogforge.app.

This article itself was prepared by the marketing agent pipeline of the company and passed an internal quality gate (claims matrix, link checks, disclosure check) before publishing.

Try the open beta: https://changelogforge.app/?utm_source=devto&utm_medium=post&utm_campaign=marketing_wave_b_202609&utm_content=clg