DEV Community: webdev

Bàn giao website xong, 5 việc tuần đầu để trang thật sự dùng được

Mạnh Digital — Sun, 08 Nov 2026 05:49:15 +0000

Ngày bàn giao website thường được coi là ngày kết thúc dự án. Với chủ doanh nghiệp, đó mới là ngày trang bắt đầu phải làm việc. Một trang đẹp mà Google không biết tới, form gửi đi không ai nhận, tên miền hết hạn giữa chừng thì cũng như chưa có trang.

Dưới đây là 5 việc nên làm trong tuần đầu sau bàn giao, kèm lệnh kiểm nhanh cho người làm web. Khách không biết code vẫn tự kiểm được phần lớn bằng trình duyệt.

Kiểm HTTPS và bản www chuyển về cùng một địa chỉ
Trình duyệt trên điện thoại không được báo cảnh báo bảo mật, và bản có www với bản không có www phải về cùng một địa chỉ.

# http phải chuyển hướng 301 sang https
curl -sI http://example.com | grep -iE "^(HTTP|location)"
# bản www phải chuyển về bản chính (hoặc ngược lại)
curl -sI https://www.example.com | grep -iE "^(HTTP|location)"

Ghi ngày hết hạn tên miền và gói máy chủ vào lịch, đặt nhắc trước một tháng.

Khai báo Search Console, kiểm robots.txt và sitemap
Xác minh quyền sở hữu trong Google Search Console, gửi sitemap. Trước đó nên chắc robots.txt không chặn cả trang và sitemap có đủ URL.

curl -s https://example.com/robots.txt
curl -s https://example.com/sitemap.xml | grep -c "<loc>"

Lỗi hay gặp nhất sau bàn giao là trang còn thẻ noindex từ lúc làm bản thử. Trên WordPress, đó thường là ô chặn công cụ tìm kiếm trong mục Cài đặt, Đọc.

# không được thấy "noindex" ở trang chủ và các trang dịch vụ
curl -s https://example.com/ | grep -io '<meta name="robots"[^>]*>'

Đọc lại từng trang dịch vụ như một khách đang vội
Mỗi trang cần trả lời được 4 câu trong vài giây đầu: làm gì, cho ai, giá khoảng bao nhiêu, liên hệ bằng cách nào. Thẻ title nên chứa đúng tên dịch vụ khách hay gõ, không phải khẩu hiệu. Đây cũng là phần nền của SEO: Google và các trợ lý AI chỉ đưa trang ra khi đọc là hiểu trang đó bán gì.

Thử gửi form và bấm gọi từ chính điện thoại của mình
Gửi một form thử, kiểm email hoặc tin nhắn có tới đúng người không. Bấm nút gọi và nút Zalo xem có mở đúng số không. Lỗi ở bước này tốn tiền nhất, vì khách đã quyết liên hệ mà không tới được.

Gắn sự kiện đo trước khi chạy bất kỳ kênh nào
Cài Google Analytics 4 và bắn sự kiện khi khách thật sự hành động, không chỉ khi xem trang.

// form gửi thành công
gtag('event', 'generate_lead');
// bấm nút gọi
gtag('event', 'click_call');

Đánh dấu generate_lead là sự kiện chính trong GA4 để vài tháng sau so được kênh nào mang khách.

Nói trước với khách rằng trang không tự có khách
Phần lớn khách thất vọng với website không phải vì giao diện, mà vì trang không tự có người vào. Nói trước điều này và đưa danh sách trên cho khách, mối quan hệ sau bàn giao sẽ dễ hơn nhiều.

Vì sao một doanh nghiệp nhỏ cần trang web, 6 việc nó làm được và 3 việc nó không làm thay được: trang web dùng để làm gì trên blog Mạnh Digital. Bản kiểm kỹ thuật dài hơn có trong bài tiêu chí website chuẩn SEO.

webdev #seo

Reserved names: keeping your app's brand out of a user's handle

Frank Milvus — Sun, 08 Nov 2026 05:48:08 +0000

A name in a notification is a claim about who is talking. When the row says Folcadi Support, most people read it as the app speaking, not as a stranger who picked a good title. That is the whole attack: cheap to set up, impossible to explain afterwards.

This is the story of closing that gap in Folcadi, a language-exchange messenger. It covers the three holes that made impersonation possible, the one shared module that now closes them, and the design decision that followed: a reserved name is the official channel, and an official channel behaves differently from a normal group.

Three ways to look official

The app already had a reserved-name list for user handles. Group names had none. That asymmetry was the bug.

Three separate holes, each enough on its own:

Group names were unprotected. Anyone could create a group called "Folcadi" or "Folcadi Support". It would appear in other people's chat lists, and the invite push would read "Added to group: Folcadi". A group title travels further than a handle, because it shows up in someone else's notification.
The handle rule lived only in the client. The app limited nicknames to 2–20 characters of [A-Za-z0-9_]. A direct request to the API was not bound by a form validator, so it could store anything the database accepted.
Matching was exact and untrimmed. "folcadi " with a trailing space renders identically to folcadi but failed an exact-match comparison. The check was correct in the letter and useless in practice.

Any of the three makes the other two look like details. Fixing one at a time would have left the same outcome reachable.

One module, two call sites

The fix starts with a single module that owns the rules: the reserved sets, the brand tokens, the normaliser and the nickname pattern. It has no database access and imports nothing from the feature layer, so both the profile path and the group path can use it without a cycle.

RESERVED_NICKNAMES = frozenset({
    "folcadi", "folcadi-admin", "folcadi_official", "folcad-i",
    "admin", "support", "moderator", "system",
    # retired brands stay reserved so nobody impersonates them either
    "tongue", "tongue-admin", "tongue_official",
    "gwing", "gwing-admin", "gwing_official",
})

RESERVED_GROUP_NAMES = frozenset({
    "folcadi", "admin", "support", "moderator", "system",
})

BRAND_TOKENS = ("folcadi",)
NICKNAME_PATTERN = re.compile(r"^[a-zA-Z0-9_]{2,20}$")

The important part is not the list. It is that there is exactly one list. Two copies of a security rule drift on schedule: someone adds a variant to one path during a review and forgets the other, and the hole reopens silently. A shared module turns "did we update both?" into a compiler question.

Normalise before you compare

Comparing user-supplied names is a normalisation problem first and a lookup problem second. The helper is deliberately boring:

def normalize_name(value: str | None) -> str:
    """Lowercase + collapse whitespace, closing the `"folcadi "` bypass."""
    return " ".join((value or "").split()).lower()

Lowercasing handles Folcadi. Collapsing whitespace handles both " folcadi" and "folcadi ", plus the internal-tab variant that looks like a space. .split() with no argument also drops the empty strings, so the join is the normalised form.

Two matching strategies sit on top of it, and the difference is intentional:

Exact match against RESERVED_NICKNAMES and RESERVED_GROUP_NAMES.
Substring match against BRAND_TOKENS — currently just the live brand name.

The substring rule is the strict one: it also blocks "Folcadi fans" and "Folcadi Official". That is deliberate while there is no in-app badge that distinguishes a real official account from a convincing one. Over-blocking a few creative group names is cheaper than under-blocking one impersonation.

Retired brands are exact-match only. This is easy to get wrong. A messenger for language learners needs to let someone name a group "Tongue twisters"; only the retired brand as a name is off-limits. The interesting rule lives in the comment next to the list, not in the code, because that is where the next person will change it.

The server is the boundary, not the form

The nickname rule moved into a validation function used by every path that can write a nickname: the user's own profile edit, the admin edit, and the availability check behind the sign-up form.

def validate_nickname(nickname: str) -> str:
    value = (nickname or "").strip()
    if not is_valid_nickname(value):
        raise HTTPException(status_code=400, detail=NICKNAME_RULE)
    if is_reserved_nickname(value):
        raise HTTPException(status_code=400, detail="Nickname already taken")
    return value

Two response details matter more than they look.

Invalid shape is a 400; reserved is "already taken". The first tells the user to fix their input. The second should not confirm that admin exists as a reserved slot — from the outside, "reserved" and "someone has it" are indistinguishable, and that is fine. Different status codes, one message for the outside world.

The stored value is the stripped value. Returning the normalised result instead of validating a copy means the database only ever sees the shape that was checked. A validator that returns the original string is a subtle bug: it verifies " frank " and then stores the spaces.

Signup is the third writer, and it generates handles instead of asking for them. Generated names are truncated to fit the same pattern, so an account created through a provider never starts life with a handle it is not allowed to keep.

Group names got the same treatment one layer earlier. The request schema trims the name before the length validators run:

@field_validator("name", mode="before")
@classmethod
def _trim_name(cls, value: object) -> object:
    return value.strip() if isinstance(value, str) else value

Without that ordering, a whitespace-only name passes min_length=1, and " Folcadi " reaches the reserved check unnormalised. Validator order is part of the rule.

A reserved name is the official group

Once group names could not be taken by users, a product question appeared: what should somebody use the name for?

The app needed an official announcement channel — release notes, downtime notices, the things you want every account to see once. That needs a way to identify it. The tempting answer is a new column: is_official, a migration, an admin toggle, and a permanently new concept in every query that reads a conversation.

The cheaper answer was already in the schema. A reserved name is a marker nobody else can set. Staff can create or rename a group to a reserved name; everyone else gets a 403. So the name itself identifies the channel:

def is_official_group(conv: Conversation | None) -> bool:
    return bool(
        conv is not None
        and conv.type == "group"
        and is_reserved_group_name(conv.name)
    )

No column, no backfill, no second source of truth. The trade-off is honest: renaming the channel requires staff, and the behaviour is coupled to the name. But the invariant is enforced in the same module that protects the brand, so the coupling cannot drift either.

Non-staff members cannot rename the group, transfer ownership, or dissolve it. Those are checked at the service layer, not just hidden in the interface.

A channel you cannot silence

For a normal group, the user's controls are the point. Mute it, block the owner, leave it. For an announcement channel, the same controls mean a user can quietly opt out of the one channel that carries "we are down for maintenance".

So the official group changes three behaviours:

Muting is refused. Setting a mute on a reserved-named group returns 403. Unmuting is still allowed, because a mute that predates the rule should be recoverable. Quiet hours still apply — that is a device-level setting about when you want to be disturbed, not a per-conversation decision, and respecting it is the difference between "cannot be silenced" and "wakes you at 3 a.m.".

Blocking has no effect. Group conversations already skipped block checks, and that stays true: blocking the owner of the channel does not stop announcements.

"Delete chat" only hides it. This is the interesting one. Leaving a normal group deletes the membership row. Leaving the official group clears the member's reads, drafts, scheduled messages, private pins and unread rows, then sets a flag:

if is_official_group(conv):
    member.is_hidden = True
    await db.commit()
    # ...and the row stays in the database
    return

The chat disappears from the list. The next message to the channel brings it back, because the broadcast path clears the flag before fan-out:

update(ConversationMember)
.where(
    ConversationMember.conversation_id == conversation_id,
    ConversationMember.is_hidden.is_(True),
)
.values(is_hidden=False)

Normal groups are untouched: leaving still deletes the membership. The asymmetry is the feature. "Delete chat" is a statement about the list you look at, not about the relationship you have with the team — and for the channel that carries service notices, the relationship has to survive it.

One detail makes this work without new client code. The app already had a "message for an unknown group → reload the list" path. Setting the flag back to false server-side means the client's existing reaction re-renders the row. A server-side restore that needs no new client state is worth designing for.

What this does not solve

Three limits are worth stating plainly, because a post about impersonation defence that claims completeness is the problem it describes.

Homoglyphs are still possible. Names are compared case-insensitively and whitespace-normalised, but not Unicode-normalised. A Cyrillic а in folcаdi looks identical in most fonts and is a different string. Real confusable detection is a separate project with its own data (mixed-script detection, skeleton mapping, a font-aware UI decision). Pretending the current normaliser covers it would be worse than saying it does not.

Substring blocking has a false-positive cost. "Folcadi fans" is a natural group name and it is refused. That is the price of not having an official badge. When a badge exists, the rule can loosen. Until then, the product chooses the impersonation risk over the naming-convenience risk, and that is a judgment call, not a technical one.

A reserved list is not a trust system. It stops the cheap attack — pick the brand as your name and wait for someone to misread it. It does not stop a compromised device, a lookalike outside the app, or a user who believes a screenshot. Reserved names reduce the cost of being fooled for the laziest case.

What the tests pin

Two suites cover the rules, and the interesting assertions are the negatives:

"folcadi", "Folcadi", " Folcadi ", "FOLCADI" are all rejected.
"folcadi " with a trailing space is rejected even though it is a different string than the one on the list.
"Tongue twisters" is accepted; "tongue" is not.
A non-staff member creating or renaming to a reserved group name gets 403.
The official group refuses a mute, but accepts an unmute.
Leaving the official group keeps the membership and sets the hidden flag; the next message clears it.
Leaving a normal group deletes the membership, as before.

That last pair is the one that catches regressions. A refactor that unifies the two leave paths would make all the positive tests pass and quietly break the official channel.

The pattern

Strip away the app-specific parts and the shape is:

One module owns every name rule — reserved sets, normaliser, pattern, helpers. Two call sites, one source.
Normalise before comparing — case and whitespace at minimum, and say out loud what you are not normalising.
Enforce on the server, with the client as a convenience. A form validator is not a boundary; the API is.
Let the reserved name carry the identity when it is already unique and staff-only. Fewer concepts, fewer migrations.
Design the exception to the user's controls deliberately, and document why the channel that carries service notices behaves differently from a chat with a friend.

None of that is novel. The failure mode it prevents is boring too, which is the point: a name is a claim, and the app should decide which claims are available to anyone.

FAQ

Why not just show a verified badge?

A badge is the right long-term answer, and it needs a server-side source of truth first. Reserved names are that source of truth, and the badge renders it. Building the badge first would have meant a visual marker with nothing behind it.

Does this change normal group names?

Only when the name contains the live brand token or matches the reserved list. "Language practice", "Book club", and "Tongue twisters" all pass. If a group name is refused, the reason is the 403 detail, not a silent rename.

What happens to a group that already had a reserved name?

The rule is checked when a group is created or renamed. An existing group keeps its name until someone edits it; editing it then requires staff. The check is at the write boundary, which is where it can be enforced cheaply.

Why is unmuting still allowed?

Because a mute can predate the rule. Refusing both directions would make a legacy mute permanent, and "we cannot notify you and you cannot fix it" is not a policy — it is a stuck state.

Get Folcadi — a language-exchange messenger with live translation.

Official website: folcadi.com
Android: Google Play
Windows: .zip or installer
Linux: .deb or portable tarball
Articles: write-ups and covers
Telegram: @frank_says
Facebook: facebook.com/FrankMilvusSays

What Is AI Code Review?

Jeff — Sun, 08 Nov 2026 05:47:52 +0000

Quick answer: AI code review is a tool that reads the code you changed, along with a bounded amount of related context, and returns prioritized findings with evidence and a recommendation. It works on top of local git differences and parsers that resolve definitions, callers, and imports. It does not run the application, and it does not prove the code is correct. You assess each finding and decide what to act on.

What it actually reviews

The input is not a vague scan of the whole repository. It starts with your local git diff, the set of added, removed, and modified lines you are about to ship. On top of that, the review pulls in bounded related context: the definitions a change references, the callers of a function, and the imports that tie files together.

Each finding comes back with three parts:

Priority, so you can tell a blocking defect from a minor note.
Evidence, the concrete reason the finding was raised, not just a label.
Recommendation, a suggested next step rather than an automatic edit.

The review starts only when you request it. It does not rewrite the file by itself, and it does not approve or merge anything.

How it fits the desktop workflow

When you choose a code folder, the project structure opens first. You can then open a file and see its full source, with views for source only, full comparison, and changes only. Added and removed lines are marked, inline character highlights show exactly what moved, and navigation plus search help you move through a large diff.

Structure filters add signals that are hard to get by eyeballing a folder:

Filter	What it tells you
Heavily referenced files	Where a change can ripple across many callers
Temporary-name candidates	Files that look like scratch work left in the tree
Identical content	Duplicated blocks that may be copies rather than shared logic
No incoming references	Files nothing resolved points to, worth a closer look

These are cues for review, not verdicts. A file with no incoming reference is not automatically safe to delete, and identical text does not mean two pieces of code behave the same way.

The evidence model behind the findings

Findings are not all the same kind, and treating them that way leads to bad decisions. The review distinguishes evidence classes:

Static signals such as typecheck, lint, build, and references to an API that does not exist.
Dynamic signals from tests, coverage, and smoke runs.
Contract signals from schema and type drift.
AI hypothesis, anything that comes from the model with no deterministic check behind it.

A model-only claim is always a hypothesis, never a confirmed defect. When you run project checks, a missing script is reported as unverified rather than passed. If no evidence comes back, the result is inconclusive, because an empty result is not a pass.

Honest limits

Powerduck can miss defects or raise false suspicions, and it does not run the app. Dynamic loading, framework entry points, and external consumers can be missed by static analysis. A review narrows where you spend attention and gives you a structured way to read a change, but the call on each finding stays with the engineer.

You can also export an agent task package as a Markdown handoff that carries the context and revision anchors. Modification is optional, and the receiving agent assesses every suspicion independently rather than trusting the export.

Frequently asked questions

Does AI code review replace a human reviewer? No. It organizes the diff and surfaces evidence-backed findings, but a person still judges each one and keeps the context that static analysis cannot see, such as product intent and external systems.

Does it run my tests or the application? It can run detected project commands as explicit checks, but it does not run the app itself. A missing script is marked unverified, not passed.

Can a finding be wrong? Yes. The review can raise false suspicions, and model-only claims are hypotheses. Confirm the evidence before you change code.

Does a clean review mean the code is correct? No. A review does not prove correctness, and there are documented blind spots including dynamic loading and external consumers.

The bottom line

AI code review is a focused reading of your diff with bounded context, returning priority, evidence, and a recommendation for each finding. Its value is that it separates static, dynamic, contract, and hypothesis signals so you know how much to trust each note, while keeping the decision in your hands. Treat it as a fast, structured first reviewer that can miss things and can be wrong, not as a correctness certificate. Explore more in the AI code review guide.

Rotate webhook secrets as Stripe

RaccoonDev — Sun, 08 Nov 2026 05:46:39 +0000

When adding a new feature that requires a webhook, you usually think about delivering it, signing it, maybe deduplicating it, and retry logic. But today I want to share one of the best practices for rotating webhook secrets.

The main logic of Stripe's secret rerolling

You can choose your secret expiration either immediately or up to 24 hours later.
If you choose the second option, your OLD secret will stay valid for that period, and all webhook messages will be signed with both secrets.
Maybe you will have lots of questions: is it safe? How can we sign the same message with two secrets? And the reasonable one: what is the purpose of it? Now I will answer all of them.

What if the webhook secret is compromised? Will a hacker have access for 24 hours?

Of course not. It is easy to confuse a webhook secret with an API key. So I will remind you of the difference:

A webhook secret is used by the customer's service to check the author of the message. It is validated on the client side.
An API key is used by our server to check user permissions, credits, etc. It is validated on our side.

If a hacker obtains a user's webhook secret, the user rerolls it in our service as soon as they notice it and changes it in project settings. The old one is still valid on our side, but the user has already replaced it in project settings, so a forged message signed with the old secret fails verification on their side.

Keep in mind that until the user updates their settings, the old secret is still accepted there. So after a confirmed leak, choose immediate expiration. The 24-hour window is for planned rotation, not for incident response.

How can we deliver a webhook with multiple signatures?

We generate one signature per active secret and put all of them into a single header. The timestamp is part of the signed string, which protects from replay attacks:

X-Webhook-Signature: t=1731038940,v1=<hmac_with_new_secret>,v1=<hmac_with_old_secret>

Sender side: sign with every active secret.

import hmac, hashlib, time

def sign(secret, ts, body):
    return hmac.new(secret.encode(), f"{ts}.".encode() + body, hashlib.sha256).hexdigest()

def header(secrets, body):
    ts = int(time.time())
    return f"t={ts}," + ",".join(f"v1={sign(s, ts, body)}" for s in secrets)

header(["whsec_old"], body)
header(["whsec_new", "whsec_old"], body)

Receiver side: it is enough that any signature matches any secret the client knows.

So a client that is still on the old secret and a client that has already switched to the new one both pass verification with the same message. After 24 hours we simply stop signing with the old secret.

What is the purpose of it?

Imagine you are a DevOps engineer who wants to reroll a secret due to basic safety checks, and you create a new secret in the UI, copy it, go to project settings, paste it, and rerun the project. Overall it will take 10-15 minutes, and during this time some messages will fail verification because of mismatched secrets. They will get a 401 and go to the retry queue, but if the retries run out before the new secret is in place, those messages are lost.

This chance is small, but when you are building software for 20+ companies, you should remember that this may happen sooner or later. With two signatures, the client can switch secrets at any moment inside the window, and nothing is lost.

Overall, it is just one of the best practices, and it is not always good for you and your projects, so always think before developing.

Best Amazon SES Alternatives in 2026

Lalit Kumar Jangid — Sun, 08 Nov 2026 05:46:17 +0000

Amazon SES is built for sending at scale from inside AWS, and many teams start there. The best Amazon SES alternatives are for when you want more around the send: no sandbox approval, a dashboard with logs, templates you can edit without a deploy, delivery events without wiring up Amazon SNS, and marketing email in the same place. This guide compares ten Amazon SES (AWS SES) alternatives on price, free tier, SMTP, webhooks, deliverability and campaigns, using each vendor's own pricing and product pages, checked between October 27 and November 8, 2026.

We make Cresca, so it is listed first. Every other entry is described from the vendor's own public pages, without ranking claims about them. Prices and plans change, so confirm on each vendor's site before you switch.

TL;DR

New SES accounts start in a sandbox: verified recipients only, 200 messages per 24 hours, 1 per second, until AWS grants production access.
Cresca: a transactional email API and AI-designed marketing campaigns on one plan, from $29/month, with no sandbox.
Most alternatives include a dashboard, logs and webhooks out of the box; check SMTP, free tiers and how marketing email is billed.
Still moving off Amazon Pinpoint after its October 30, 2026 end of support? See the Pinpoint migration guide.

Quick picks

App email and marketing campaigns on one plan: Cresca, from $29/month, no sandbox.
Largest free monthly allowance in this list: Mailtrap (4,000 emails a month) and Resend (3,000 a month).
Lowest paid entry price: MailerSend at $7/month for 5,000 emails, then Brevo at $9/month from 5,000 emails.
SMTP relay first: SMTP2GO, Mailgun and Postmark all offer SMTP next to their APIs.

What is Amazon SES?

Amazon Simple Email Service (Amazon SES, often called AWS SES) is the email sending service inside Amazon Web Services. You send through its API or SMTP interface, pay per email, and build the rest yourself: event handling through other AWS services, templates, a log your support team can read, and any campaign tooling. That trade is what makes SES cheap per email, and it is why teams look for an Amazon SES alternative once they want those parts ready-made.

Why teams look for an Amazon SES alternative

The sandbox. AWS places all new accounts in the SES sandbox, where you can only send to verified addresses and domains, up to 200 messages per 24 hours and 1 per second. Leaving it means requesting production access; AWS says its support team gives an initial response within 96 hours.
Plumbing for events. Deliveries, bounces, complaints, opens and clicks are published as events to Amazon SNS, EventBridge, CloudWatch or Data Firehose, which you configure and consume yourself.
Pricing plans. New SES accounts start on the Essentials plan at $0.16 per 1,000 emails; Pro and Enterprise plans add fixed monthly charges per account and region. The full breakdown is below.
No campaign tools. SES sends marketing email, but its pages describe no campaign builder, so newsletters need another tool on top.
Amazon Pinpoint's end of support on October 30, 2026 left teams that used Pinpoint for email campaigns looking for a new home for contacts, templates and campaigns.

Amazon SES pricing: what you actually pay

Amazon SES pricing is per email, with extras for attachments, dedicated IPs and deliverability tools. Figures from the Amazon SES pricing page, checked on November 8, 2026, for the first 10 million emails a month:

Option	Per 1,000 emails	Fixed monthly fee
À la carte	$0.10	None
Essentials plan	$0.16	None
Pro plan	$0.22	$105 per account per region
Enterprise plan	$0.23	$500 per account per region

Which rate applies: AWS says accounts with no metered SES activity since June 1, 2025 start on the Essentials plan from July 21, 2026.
Attachments: $0.12 per GB of attachment data sent.
Dedicated IPs: $24.95 per IP per month (standard), or managed dedicated IPs at $15 per account per month plus $0.08 per 1,000 emails.
Virtual Deliverability Manager: $0.07 per 1,000 emails for SES deliverability insights.
Free tier: new AWS customers get up to $200 in AWS Free Tier credits that can be used on SES.

At 10,000 emails a month, that is about $1.00 à la carte or $1.60 on Essentials, and $26.60 if you add one standard dedicated IP. The per-email price is rarely the reason teams switch. The cost is the work around it: the sandbox request, wiring delivery events through Amazon SNS or EventBridge, a template workflow, and a place where support can see what happened to an email.

How we compared these Amazon SES alternatives

Each service is described from its own pricing pages and documentation, not from third-party reviews. We looked at:

Setup: whether you can send to real recipients on day one, or wait for an approval step like the SES sandbox.
Price: the free option and the cheapest paid plan, in US dollars per month.
Sending options: HTTP API, SMTP relay and delivery webhooks.
Deliverability: domain authentication (SPF, DKIM, DMARC) and how bounces and complaints are handled.
Marketing email: whether campaigns live in the same account and plan, or in a separate product.

Best Amazon SES alternatives compared (2026)

Service	Best for	Free option	Paid from	SMTP relay	Webhooks	Marketing email
Cresca	App email and AI-designed marketing campaigns in one account	30 days free, 1,000 emails, no credit card	$29/month: 7,500 emails and 5,000 contacts, campaigns included	On the roadmap	On the roadmap	Yes, on the same plan
Resend	Developers; sends emails built with React Email	Free plan: 3,000 emails/month, 100 per day	$20/month for 50,000 emails	Yes	Yes	Separate marketing plans priced by contacts
Postmark	Transactional email with separate message streams	100 emails/month developer plan	$15/month for 10,000 emails	Yes	Yes	Broadcast message streams
SendGrid	Email API at scale, part of Twilio	60-day free trial, 100 emails/day	Essentials from $19.95/month	Yes	Yes	Marketing Campaigns, sold as a separate plan
Mailgun	Developers; email API, SMTP and email validation	Free plan: 100 emails/day	$15/month for 10,000 emails	Yes	Yes	Not stated on its pricing page
MailerSend	Email, SMS and WhatsApp for apps	Free plan: 500 emails/month	$7/month for 5,000 emails	Yes	Yes	Not stated; bulk emailing on paid plans
Mailtrap	Developer and product teams; sending plus a testing sandbox	Free plan: 4,000 emails/month, 150 per day	$15/month for 10,000 emails	Yes	Yes	Email Marketing, sold separately
Mailchimp Transactional	Mailchimp customers adding app email	Up to 500 free sends to a verified domain	$20 per block of 25,000 emails, plus a Mailchimp Standard or Premium plan	Yes	Yes	Yes, through the Mailchimp plan it is added to
Brevo	Marketing campaigns, automation and transactional email in one account	Free plan	Starter $9/month from 5,000 emails	Yes	Yes	Yes, in the same account
SMTP2GO	SMTP relay and email API, with SMS	Free plan: 1,000 emails/month	$10/month for 10,000 emails	Yes	Yes	Not stated on its pricing page

Based on each vendor's public pricing and product pages, checked on October 27, 2026 (Brevo and SMTP2GO on November 8, 2026). Prices in US dollars, billed monthly where both options are shown.

1. Cresca: SES-level sending without the setup, plus campaigns

Cresca is a transactional email service and an AI email marketing platform in one account. Verify your domain, create an API key and send: there is no sandbox to leave, and the dashboard shows a timeline for every email. See Cresca transactional email.

API: POST /emails for one email to up to 50 recipients, batches of up to 100, scheduling up to 30 days ahead, attachments, tags and Idempotency-Key headers for safe retries.
Templates: Design in a template editor, publish, and send by alias with variables. Every published version is kept.
Marketing: AI-designed campaigns, contact lists, scheduling and campaign reports on the same plan and the same verified domain.
Pricing: 30 days free with 1,000 emails and no credit card. Professional is $29/month for 7,500 emails and 5,000 contacts, covering API email and campaigns.
On the roadmap: Outbound webhooks and an SMTP relay. Today you read each email's status from the API or the dashboard.

2. Resend

Resend presents itself as an email API for developers and highlights emails built with React Email.

Free option: 3,000 emails per month, up to 100 per day.
Paid: Pro is $20/month for 50,000 emails.
Sending: REST API, SMTP relay, SDKs and webhooks on all plans.
Marketing: Separate marketing plans priced by contacts.

3. Postmark

Postmark describes itself as a transactional email service, with transactional and broadcast email kept in separate message streams.

Free option: A developer plan with 100 emails per month.
Paid: Basic is $15/month for 10,000 emails.
Sending: Email API, SMTP, event webhooks and inbound processing.
Marketing: Broadcast message streams in the same account.

4. SendGrid

SendGrid, part of Twilio, sells its Email API and Marketing Campaigns as separate products.

Free option: A 60-day free trial with 100 emails per day.
Paid: Email API Essentials starts at $19.95/month.
Sending: API and SMTP, with event webhooks on paid plans.
Marketing: Marketing Campaigns, purchased as a separate plan.

5. Mailgun

Mailgun calls itself a transactional email delivery service and API for developers.

Free option: 100 emails per day.
Paid: Basic starts at $15/month for 10,000 emails.
Sending: RESTful APIs and SMTP relay, with webhooks.
Marketing: Not stated on its pricing page.

6. MailerSend

MailerSend presents itself as a team-friendly email API for apps, with SMS and WhatsApp alongside email.

Free option: 500 emails per month.
Paid: Hobby is $7/month for 5,000 emails.
Sending: Email API, SMTP relay and webhooks.
Marketing: No separate marketing product described; bulk emailing on paid plans.

7. Mailtrap

Mailtrap offers email sending for developer and product teams, with email marketing and a testing sandbox as separate products.

Free option: 4,000 emails per month, up to 150 per day.
Paid: Basic is $15/month for 10,000 emails.
Sending: API, SMTP relay and webhooks.
Marketing: Email Marketing, sold separately.

8. Mailchimp Transactional (formerly Mandrill)

Mailchimp Transactional is sold as an add-on to a Mailchimp plan.

Free option: Up to 500 free emails to a verified domain for new users.
Paid: $20 per block of 25,000 emails, plus a Mailchimp Standard or Premium plan.
Sending: API, SMTP integration and webhooks.
Marketing: Through the Mailchimp plan it is added to.

9. Brevo

Brevo sells email marketing, automation and transactional email in one account, alongside SMS and other channels.

Free option: A free plan, with no credit card needed.
Paid: Starter is $9/month from 5,000 emails a month.
Sending: SMTP relay and API keys for transactional email, with transactional webhooks.
Marketing: Campaigns, templates and segmentation on the same plans; automation from the Standard plan.

10. SMTP2GO

SMTP2GO describes itself as an email and SMS delivery service that you connect through SMTP or its API.

Free option: Up to 1,000 emails a month.
Paid: Starter is $10/month for 10,000 emails, with extra emails at $1 per thousand.
Sending: SMTP relay and HTTP API, with webhooks and reporting.
Marketing: Not stated on its pricing page.

Deliverability: what changes when you leave Amazon SES

Switching providers does not reset your domain's reputation, but it does change who signs and sends your mail. Plan for these:

Authentication records. Add the new provider's DKIM records and, where it uses a custom MAIL FROM domain, its SPF record. Keep your DMARC record; a domain can only have one.
Shared or dedicated IPs. Most plans in this list send from shared IPs. A dedicated IP needs steady volume and a warm-up period before it helps.
Bounces and complaints. Carry your SES suppression list over, so addresses that bounced or complained are not mailed again from the new provider.
Gradual moves. Switch one email type at a time and watch bounce and complaint rates before moving the next.

In Cresca, domain setup shows the DKIM and SPF records to publish and checks whether your domain has a DMARC record. Hard bounces, repeated soft bounces, complaints and unsubscribes are suppressed automatically, for API email and campaigns alike. See the email deliverability guide for the full checklist.

Moving from Amazon SES to Cresca

Verify your sending domain in Cresca by publishing the DNS records it shows, and keep SES sending while you switch. See the quickstart.
Create a sending-access API key and store it as CRESCA_API_KEY.
Move templates. Paste your SES template HTML into Cresca's template editor with Import HTML, mark variables with triple braces and publish.
Swap the send call, one email type at a time, starting with a low-risk one such as a welcome email.
Keep a list of addresses that bounced or complained on SES and leave them out of your Cresca sends, so your new domain setup starts with a clean reputation.
Switch the rest once the dashboard timeline looks right, then retire the SES configuration.

Here is the same email with the AWS SDK for JavaScript (SESv2) and with Cresca:

// Before: Amazon SES with the AWS SDK for JavaScript v3
import { SESv2Client, SendEmailCommand } from '@aws-sdk/client-sesv2';

const ses = new SESv2Client({ region: 'us-east-1' });

await ses.send(
  new SendEmailCommand({
    FromEmailAddress: 'Acme <hello@acme.com>',
    Destination: { ToAddresses: ['ana@example.com'] },
    Content: {
      Simple: {
        Subject: { Data: 'Welcome to Acme' },
        Body: { Html: { Data: '<p>Hi Ana, your account is ready.</p>' } },
      },
    },
  }),
);

// After: Cresca, with fetch (Node.js 18+)
const res = await fetch('https://api.cresca.xyz/api/v1/emails', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.CRESCA_API_KEY}`,
    'Content-Type': 'application/json',
    'Idempotency-Key': 'welcome/user-123',
  },
  body: JSON.stringify({
    from: 'Acme <hello@acme.com>',
    to: 'ana@example.com',
    subject: 'Welcome to Acme',
    html: '<p>Hi Ana, your account is ready.</p>',
  }),
});
const body = await res.json();
if (!res.ok) throw new Error(`${body.name}: ${body.message}`);

Full guides for your stack: Node.js, Python, Java, Go, PHP and more. Comparing transactional providers more broadly? See the best transactional email services.

Frequently asked questions

What is the best Amazon SES alternative?

It depends on what you need around sending. If you also send newsletters and campaigns, Cresca puts a transactional email API and AI-designed marketing email on one plan, with no sandbox and a dashboard for every email. Resend, Postmark, SendGrid, Mailgun, MailerSend, Mailtrap, Mailchimp Transactional and SMTP2GO focus on sending, and Brevo combines marketing with transactional email.

Is there a cheaper alternative to Amazon SES?

Per email, rarely. Amazon SES costs $0.10 per 1,000 emails à la carte or $0.16 on the Essentials plan, which is less per email than the paid plans in this list. Alternatives charge more per email but include the dashboard, logs, templates, delivery events and support that you would otherwise build or buy around SES. Several also have free plans, from 1,000 emails a month on SMTP2GO to 4,000 on Mailtrap.

How long does it take to get out of the Amazon SES sandbox?

You request production access from the SES console or the AWS CLI, giving your use case and website. AWS says its support team provides an initial response within 96 hours. Until then you can only send to verified addresses, up to 200 messages per 24 hours.

Is Amazon SES affected by the Amazon Pinpoint end of support?

No. Amazon Pinpoint's engagement features ended on October 30, 2026, but Amazon SES continues. Teams that used Pinpoint for email campaigns, segments and journeys need another place for them, which is what the Pinpoint migration guide covers.

Can I keep my domain authentication when I leave SES?

You keep your domain, but each provider signs mail with its own DKIM keys, so you add the new provider's DNS records. DKIM records for different providers can sit side by side, which lets you move one email type at a time and keep SES running until the switch is complete.

Do SES alternatives support SMTP?

Most of the services in this comparison offer an SMTP relay as well as an HTTP API. Cresca sends through its HTTP API today, and an SMTP relay is on its roadmap.

Try Cresca

Send your app's email and your campaigns from one account, with no sandbox. Try Cresca free for 30 days, no credit card required, then follow the quickstart.

What Is Agent2Agent (A2A)?

Jeff — Sun, 08 Nov 2026 05:46:08 +0000

Quick answer: Agent2Agent (A2A) is an open protocol that lets one agent communicate with another over JSON-RPC. It defines an agent card that describes the remote service, a set of task methods for sending work and reading or cancelling it, and optional streaming over SSE. The desktop can verify a card, exercise the methods, and generate a local A2A server, but A2A is a supporting capability rather than the core of the product.

The problem A2A addresses

Without a shared protocol, every agent integration is bespoke. One agent calls another through a custom shape, parses a private response, and has to be rebuilt the moment the other side changes. There is no standard way to describe what the agent can do, track a task that takes time, or cancel work already in flight.

A2A fixes those points with a small, task-based contract so agents from different systems can interoperate without a point-to-point design.

The core pieces

Piece	Role
Agent card	Describes the agent's skills, endpoints, and security
JSON-RPC methods	Carry the task requests and responses
Task	The unit of work sent to the remote agent
SSE streaming	Optional channel for progress and status updates
Cancel	A method to stop a task that is still running

The card is the entry point. A caller fetches it first, reads what the agent offers and how it is secured, then uses the task methods rather than guessing at the shape.

How a task moves

A2A is built around a task that can take time rather than a single immediate response.

The caller fetches and verifies the agent card.
It sends a task using the declared method.
The remote agent returns a task reference and status.
The caller polls the status or subscribes over SSE.
It can cancel the task before it reaches a terminal state.

Because the work is long-running, the status is a first-class part of the protocol rather than something the caller invents. A task moves through defined states, and the final result is read separately from the initial acceptance.

Where security sits

The agent card carries the security information, and the protocol supports signed requests. A JWS signature lets the caller verify the message, but signature checks have limits, and a valid signature does not make the payload correct or safe. Treat the signature as an authentication and integrity check, not as proof the task behavior is right.

The desktop can check a card locally, including its structure and security fields, before you trust the remote agent. It also handles the case where a JSON-RPC error arrives inside an HTTP 200, which a status-only check would miss.

Honest scope

A2A is a supporting capability behind the two core workflows. It matters because agents increasingly call one another, and those calls need the same kind of verification as any other API, but it is not a reason to position the product as a general client. A generated A2A server is a local scaffold for testing, not a production deployment, and it does not replace the real remote agent.

Powerduck treats A2A as another surface to verify, with the same evidence and idempotency discipline used across the rest of the desktop.

Frequently asked questions

Is A2A a transport or a full protocol? It is a protocol over JSON-RPC, with an agent card, task methods, status, and optional SSE streaming, rather than just a wire format.

Why is the agent card fetched first? It describes the skills, endpoints, and security so the caller knows how to interact before sending a task.

Does a valid signature mean the task is safe? No. A JWS signature checks integrity and origin, not the correctness of the payload or the behavior.

The bottom line

A2A is an open, task-based protocol for agents to communicate over JSON-RPC, built around an agent card, task methods with status, and optional SSE streaming and cancellation. It removes the need for bespoke point-to-point integrations while still requiring real verification, because a signed or accepted task is not a verified behavior. Keep it in its lane as a supporting capability, and verify the card and the responses the same way you would any API. Read more in the A2A guide.

Is Shopify Down? How to Check Shopify Status and What to Do Next

Lavkush Kumar — Sun, 08 Nov 2026 05:45:35 +0000

Originally published on CodingCush.

If your Shopify store suddenly will not load, the fastest way to know whether Shopify itself is down is to open the official Shopify Status page at shopifystatus.com: if it says "All Systems Operational" with green ticks, Shopify is up and the problem is almost certainly in your store, your internet connection or your browser; if it shows a partial or major outage for Admin, Checkout or Storefront, the problem is on Shopify's side and the only real fix is to wait while Shopify repairs it. Checking this first takes twenty seconds and saves hours of changing settings that were never broken.

Step 1: Check the Official Shopify Status Page

Open the official Shopify Status page at shopifystatus.com in your browser. You will see a simple dashboard that reports each part of Shopify separately: Admin, Checkout, Storefront, API and Mobile, Reports and Dashboards, Support, Point of Sale and third-party services. A green tick means that part is working normally. A yellow or orange mark means degraded performance or a partial outage, and a red cross means a major outage.

Read the page like a weather report for your store. If Checkout shows a major outage but Storefront is green, visitors can browse your products but cannot pay, which is urgent for sales but not something you can repair yourself. If everything is green and your store still fails for you, the fault is local, and the rest of this guide is your checklist. Shopify also offers a personalised "My Shopify Status" view once you log in, which shows incidents that affect your specific store, because a problem can touch a small group of stores without appearing as a global outage.

The official Shopify Status page at shopifystatus.com, showing "All Systems Operational" with green ticks for Admin, Checkout, Storefront, Reports and more.

Step 2: Rule Out Your Own Connection and Browser

Before blaming any platform, test the boring local causes, because they are the most common ones. Open your store in a private or incognito window, which ignores your saved cookies and extensions. Try a different browser, and then a different network, for example your phone on mobile data instead of your home Wi-Fi. Ask a friend in another city to open the store, or check it on your phone with Wi-Fi switched off.

If the store opens everywhere except on your laptop, Shopify was never down: your browser cache, an aggressive ad blocker, a VPN or your internet provider's DNS is the culprit. Clear the cache, disable the VPN for a minute and try again. If the store fails on every device and every network, move to the next step, because now a store-level or platform-level problem is likely.

Step 3: Check Whether It Is Your Whole Store or One Part

"Shopify is down" can mean four different problems, and each has a different owner. Your storefront may fail while the admin works, which points at your theme, a newly installed app or a domain problem. Your admin may fail while the storefront sells happily, which points at a login, browser or account issue. Checkout may fail while everything else works, which is the pattern in our guide to Shopify checkout not working and how to fix it, with payment and settings checks in order. Or everything may fail at once, which is either a real platform outage or your domain expiring, and the status page plus a quick domain check will separate those two quickly.

What fails?	Most likely cause	First move
Everything, for everyone	Platform outage or expired domain	Status page, then domain expiry check
Storefront only	Theme change, app conflict, DNS	Preview a fresh theme, undo recent changes
Admin only	Browser, cache, login session	Incognito window, different browser
Checkout only	Payments paused, test mode, outage	Check Shopify Payments and test mode
Only for you	Your network, VPN or DNS	Mobile data test, clear cache

Step 4: If It Is a Real Outage, Do These Things While You Wait

A genuine Shopify outage feels helpless, but there is still useful work to do. First, do not start editing your theme, deleting apps or changing DNS settings in a panic: when the platform recovers, those hurried changes become brand-new problems of your own making. Second, note the time the problem started and take a screenshot of the status page; if you later talk to support or to customers, exact times beat vague memories. Third, tell your customers quickly and calmly on social media or by email that checkout is temporarily unavailable and that you will announce when it is back. Shoppers forgive outages; they do not forgive silence.

Fourth, keep refreshing the status page rather than your store, because Shopify updates incident notes there as engineers work. Most platform incidents are resolved within a few hours. When the status returns to green, place a small test order on your own store to confirm that browsing, checkout and payment all work end to end before you tell customers the good news.

Step 5: If the Status Is Green but Your Store Is Still Broken

A green status page with a broken store means the problem lives in your account. Work backwards through your most recent changes, because new problems usually follow new actions. Did you install an app today? Disable it temporarily. Did you edit theme code? Roll back to the previous version from the theme editor's version history. Did you connect or transfer a domain? Check that the DNS records still point to Shopify and that the domain has not expired at your registrar. Did payments stop? Open Settings, then Payments, and look for a paused or restricted Shopify Payments banner, which can follow an identity review.

The official Shopify Help Center is the right next stop after these checks, with guided diagnostics and 24/7 support chat for account-specific faults that a public status page cannot see. And if several unrelated things in your store feel broken at once, our checklist of common Shopify problems and how to fix them walks through the usual suspects one by one, from slow pages to missing products.

How to Get Warned Earlier Next Time

Once this scare is over, make the next one shorter. Bookmark the status page on your phone, not just your laptop, because outages rarely wait for office hours. Turn on notifications in any community or status-alert service you already use, and keep a simple "store down" draft message ready for your social channels so you are writing calmly in advance instead of typing in a panic. Finally, keep a short note of who controls what: domain registrar login, Shopify login and your backup admin's email. In a real emergency, hunting for passwords wastes the very minutes you are trying to save.

Frequently Asked Questions

How can I check if Shopify is down right now?

Open shopifystatus.com. Green ticks and "All Systems Operational" mean Shopify is up. Orange or red marks next to Admin, Checkout or Storefront mean Shopify has a live incident affecting that part.

Why is my Shopify store not loading but the status page is green?

Then the fault is local to your store or your connection: a theme or app change, a domain or DNS problem, a paused payment account, or simply your browser cache or network. Test in an incognito window and on mobile data to narrow it down.

How long do Shopify outages usually last?

Most incidents are resolved within a few hours, and many within the hour. The status page posts progress updates during an incident, so check there instead of repeatedly refreshing your store.

Can I fix a Shopify outage myself?

No. A platform outage is repaired by Shopify's engineers. Your job during an outage is to avoid making risky changes, inform your customers, and test a full order once the status returns to green.

What should I do if only checkout is down?

Check the status page's Checkout row first. If it is green, inspect your own payment settings: confirm Shopify Payments is active, test mode is off, and no verification banner is waiting in Settings, then Payments.

Conclusion

When your store fails, do not guess and do not panic-edit. Spend twenty seconds on the official status page, test on another device and network, work out which part is actually failing, and only then fix the thing that is yours to fix. That calm order of checks turns a frightening "Shopify is down" moment into a short, clear diagnosis almost every time.

What AI Code Review Cannot Catch

Jeff — Sun, 08 Nov 2026 05:44:34 +0000

Quick answer: AI code review cannot see code that is reached through dynamic loading or framework entry points, external consumers outside the repository, or the runtime behavior of the application, because it does not run the app. It can also miss defects or raise false suspicions, and it does not prove correctness. Knowing these blind spots tells you which parts still need a test, a smoke run, or a person's judgment.

The structural blind spots

The review is built on local git differences plus parsers that resolve definitions, callers, and imports. Anything outside that resolved graph can be missed.

Blind spot	Why it is missed	How to verify
Dynamic loading	Code is reached at runtime, not by static resolution	Tests or smoke runs that exercise the path
Framework entry points	The framework wires the call outside the parsed code	Run the app and trace the entry
External consumers	Callers live outside the repository	Integration checks and service knowledge
Runtime behavior	The review never executes the app	Dynamic tests and smoke calls

A file with no incoming reference is a cue, not a verdict. It is not automatically safe to delete, because an external consumer or dynamic loader may be the real caller. Identical text does not prove interchangeable behavior either, since two matching blocks can sit in different runtime contexts.

What static analysis cannot determine

Some questions only have answers once code runs. Static reading cannot tell you whether a branch behaves correctly under real data, whether a side effect fires in the right order, or how a change interacts with a live service. That is why dynamic evidence from tests, coverage, and smoke runs is a separate class rather than an assumption.

A dynamic run still only covers the paths it reaches, so an unexercised branch carries no evidence. When a project script is missing, the check is unverified rather than passed, and an empty result is inconclusive, not a green check.

The reasoning limits

Model-only notes are AI hypotheses, and they can be wrong. The model does not know product intent it has not been given, and it can raise a false suspicion that reads as confident. A model-only claim is always a hypothesis until you reproduce it or trace it to a real definition.

The deterministic verdict protects you in one direction: failing evidence fails, and no verified evidence is inconclusive. It cannot, however, invent evidence for paths the tooling cannot see. A clean review means the checks that ran did not fail, not that every possible path is sound.

How to cover the blind spots

Use the review for what it does well, then close the gaps deliberately.

Run dynamic tests and smoke calls to cover behavior static analysis cannot reach.
Exercise framework entry points and dynamic loading paths explicitly.
Map external consumers so unused-looking files are not removed by mistake.
Keep a person on design and product-intent decisions.
Re-run the review after adding checks so the verdict updates.

Powerduck states these limits rather than hiding them, and it keeps each finding tied to reproducible evidence so you can tell what was verified and what remains unknown.

Frequently asked questions

Does a clean review mean the code is safe to ship? No. It means the checks that ran did not fail. Dynamic loading, external consumers, and runtime behavior can still hide defects, and the review does not prove correctness.

Can I delete a file with no incoming references? Not on that evidence alone. Dynamic loading or an external consumer may call it. Confirm there is no runtime or outside caller first.

Does the tool run the app to catch runtime defects? No. It does not run the app. Use tests and smoke runs for runtime behavior, and treat missing scripts as unverified.

The bottom line

AI code review is a strong structural reader, but it has fixed blind spots: dynamic loading, framework entry points, external consumers, and runtime behavior are all outside its static view, and model-only notes can be wrong. Cover those with dynamic tests, smoke runs, and human judgment, and never read a clean review as a correctness certificate. The tool narrows your attention; it does not remove the need to verify what it cannot see. More in the AI code review guide.

23 of 56 Pages Ship No JavaScript: The Guide Fleet Is Static, the App Fleet Is Not

OnePassApps — Sun, 08 Nov 2026 05:41:56 +0000

I work on OnePassApps, so this is our own site, and every number below was measured on today's build over plain HTTPS from outside the browser - no session, no cookies, no JavaScript.

Half of our own sitemap ships our application code and half does not, and the line falls in an odd place. Of the 56 URLs in our sitemap, 33 load the app bundle and 23 do not - and the 23 are the guides index plus all 22 individual guide pages. Those are the only routes on the site where a reader gets the whole document with nothing of ours running on top of it.

This is a measurement of the layer between the server and the browser: what each route asks the browser to fetch, and what it leaves out.

How the sitemap splits

Our sitemap answers HTTP 200 with 4,046 bytes and 56 URLs. Reading every one of them and counting the script tags in the served HTML gives two clean groups.

	URLs	script tags	of them ours	modulepreload links	link tags	root div
App bundle	33	6	4	3	10	yes
No app bundle	23	3	1	0	7	no

The 23 routes with no bundle are /guides, /guides/newsflow, /guides/movie-tracker and the 19 other guide pages. Every one of the 33 routes with a bundle is an app page, a Studio page, or one of the four other routes - the home page, the vote board, the plans page and the terms page.

What the 23 routes actually ship

Three script tags each, and only one of them is ours:

the JSON-LD block, the single script of ours, carrying the structured data
Cloudflare's email-obfuscation helper
the Cloudflare analytics beacon

There is no app entry, no fallback script and no preload hint. The modulepreload links are the clearest marker of the difference: the 33 routes that boot the app carry 3 of them, pointing at the runtime, the shared shell and the React vendor chunk, and the 23 routes that do not boot the app carry none. The string modulepreload does not appear anywhere in the 23 served pages.

They also drop the empty mount point: the 0 of 23 that carry a root div element are the app routes, and the guide pages carry the static copy instead. The SEO fallback block that the app routes carry is missing from all 23 of them.

Two things they still take

Dropping the JavaScript does not make the guide pages cheap, because they keep both stylesheets - every one of the 56 pages links the same two: shell-fallback.css and index-B_evf03w.css. The second one is 242,648 bytes raw and 40,833 bytes under brotli, so a reader who opens one guide page still downloads the whole application stylesheet.

The theme is not lost either. All 56 pages arrive with the html element already carrying data-theme="dark" and data-theme-preset="graphite", so the guide pages are dark before the first paint without any script to do it. The app routes additionally run a 1,316-byte inline script that forces that theme and drops a stored light preference; the guide pages have no such script, because they do not need one. The startup-shell marker is on all 56 pages either way.

What the app routes pull instead

The 33 routes that boot the app point at five hashed files:

/assets/app-shell-shared-DCrZF6q_.js - 369,609 bytes raw, 116,569 bytes under brotli
/assets/index-B_evf03w.css - 242,648 bytes raw, 40,833 bytes under brotli
/assets/index-LNYK_bk0.js - 324,591 bytes raw, 90,675 bytes under brotli
/assets/react-vendor-DY6N_LXH.js - 178,924 bytes raw, 56,171 bytes under brotli
/assets/rolldown-runtime-QTnfLwEv.js - 694 bytes raw, 403 bytes under brotli

That is 873,818 bytes of JavaScript raw and 263,818 bytes under brotli, plus 242,648 bytes of stylesheet. All five come back with cf-cache-status: HIT, so the edge serves them rather than the origin.

The two fleets do not weigh the same

Group	URLs	bytes, uncompressed	bytes, brotli
App pages	22	19,132 to 19,576	5,434 to 5,574
Guide pages	22	26,600 to 32,451	6,768 to 7,613
Studio pages	7	17,285 to 17,538	5,022 to 5,126
Other routes	5	16,380 to 75,113	4,689 to 18,221

The five other routes are the home page, the vote board, the plans page, the terms page and the guides index, and the guides index is the one of them without a bundle.

Across all 56 pages that is 1,386,556 bytes uncompressed, 369,515 bytes under gzip and 362,691 bytes under brotli. Brotli buys 6,824 bytes over gzip on our HTML, which is 1.8 percent - nowhere near the 70 percent it saves on the hashed JavaScript. The HTML is mostly one repeated shell, and compressors already do well on repetition.

Read the other way round, the text the pages actually show is bigger in the static fleet. Stripping the tags out of the served HTML leaves 2,781 to 3,395 characters of readable text on a guide page and 1,778 to 2,088 on an app page. The app pages are the interactive ones, and the guide pages are the ones that say more before anything runs.

Three smaller facts

All 56 pages answer with transfer-encoding: chunked and none of them sends a content-length, so a client cannot know the size of the body before it finishes.
Gzip and brotli are both honoured on every page. Zstandard is not: no page came back with a zstd Content-Encoding when asked.
The two fallback files are served with a four-hour window rather than the pages' max-age=0: shell-fallback.css is 3,054 bytes and shell-fallback.js is 4,104 bytes, both public, max-age=14400, must-revalidate. The validators on this host are uneven: none of the 56 pages carries an ETag, all 5 hashed assets carry a strong one, the three text files a crawler reads - robots.txt, llms.txt and sitemap.xml - carry strong ETags too, and the two fallback files carry weak ones.

What I did not do

One build, one day, 8 November 2026, plain HTTPS from one network with no signed-in session. Each URL was fetched four times - once plain, then once each asking for gzip, brotli and zstd - so the byte totals are what the server sent in that window, not a fixed property of the build. Nothing here says what a page looks like once the app code runs, or how any crawler uses what it found; both need a browser and a reader, and this was neither. The zstd result is one request per URL, not a sweep of the encodings the origin supports. The guide pages are static documents and I did not open one in a browser to confirm what a reader sees.

Try it yourself: the app guides, and the site home.

Disclosure: I work on OnePassApps.

Stop Guessing: How to Build an LLM Recommender for Agentic AI into Any Web App

Neweraofcoding — Sun, 08 Nov 2026 05:41:12 +0000

When building agentic AI features into a web app, one of the most common pitfalls is hardcoding a single heavyweight LLM for every single operation.

Using a frontier reasoning model just to classify user intent or format JSON wastes both latency and budget—while using a lightweight model for complex multi-step planning leads to brittle agent loops.

What This Guide Covers:

Task Classification: Scoring incoming agent steps by reasoning depth, context size, and tool-use complexity
Scoring Matrices: Balancing latency budgets, per-token costs, and benchmark accuracy
Recommender Architecture: Building a clean model-selection layer that plugs into any frontend or backend stack
Fallback & Telemetry Loops: Handling rate limits gracefully and adjusting recommendations using real-world execution metrics

Read the complete implementation guide on SunnyWriteUps.

0x Loom is out: a full dev environment in one browser tab

Vasuki iTech International — Sun, 08 Nov 2026 05:38:06 +0000

The 0x Gazette: Release Edition

An editor, an AI pair, GitHub, notebooks and an extension store, with nothing to install and no project to set up before you write the first line.

Try it now: 0x.vasuki.cloud

Most developer tools ask for an afternoon before they give you anything back. 0x Loom asks for a tab.

Open it, drag a folder onto the page, and you are editing with syntax highlighting, auto-closing tags and autocomplete. Your files stay in your browser, and a reload brings back your tabs, your unsaved edits and your open folders.

The goal of this first public release is simple: make the loop from idea to running code short enough that it works on a laptop, a borrowed machine or a phone. Python and Node run on a backend, HTML and SVG preview live beside the code, and a terminal handles npm when a project needs packages.

By the numbers


3	project templates: Node.js, React (Vite) and Angular
15	extensions pre-installed on first run
11	colour themes in the marketplace
600	files loaded when you clone a repository
0	installs required

An assistant that edits, not just chats

The built-in Gemini assistant reads your open file, your selection and anything you mention with @path/to/file. When it wants to change something, it doesn't paste a wall of code. It proposes a precise search-and-replace block, and you press Accept or Reject.

If the text it wants to replace is missing or ambiguous, the edit is refused, so nothing changes by accident.

Every suggestion arrives as a diff you can accept or reject. Nothing is applied behind your back.

Several API keys can sit behind the assistant. When one hits a rate limit, Loom moves to the next. An AI Billing screen shows requests and tokens per key, so you can see a quota running out before it does.

From first commit to a live site

Connect GitHub once, then clone a repository or create a new one from a Node.js, React (Vite) or Angular template. Loom scaffolds the files and pushes the first commit.

Changes are listed file by file before you push, and build output and node_modules are never sent.

When you are ready to share, one button publishes to GitHub Pages. For projects with a build script, Loom adds the deploy workflow, watches the build and hands you the live URL.

Notebooks and a vault

The Shell opens a Jupyter-style notebook with Python and Markdown cells. It reads and writes standard .ipynb files, shares variables between cells, and saves to your browser, to disk or to a private GitHub repo.

Secrets live in your Tijori vault and can be dropped into a file at the cursor, so keys stay out of your source.

Make it yours

Extensions are plain JavaScript with a documented API for commands, panels, status items, key handlers and the AI:

Loom.ui.command('Hello', 'Say hello', () => Loom.ui.toast('Hi from ' + ext.name));

Extension Studio gives you a code editor, a live README preview, version history and a safety scan that flags vault, network and file access before anyone installs your work. Publishing is tied to a key only you hold, and anyone else can fork instead of overwrite.

Also in this edition

Command palette on Ctrl/⌘ K with text, JSON, Base64 and npm tools
Code Map: every function and variable, with all references across files
Light and dark themes, built for phones as well as desktops
Docs for Vasuki Traffic and Tijori in one place

Open a tab. Start building.

👉 Launch 0x Loom at 0x.vasuki.cloud

I'd love feedback: what broke, what's missing, and which extension you'd build first. Drop it in the comments.

Struggling to Understand Someone Else's Code? Try an AI Code Explainer

Monika Pareek — Sun, 08 Nov 2026 05:37:20 +0000

Struggling to Understand Someone Else's Code? Try an AI Code Explainer

Every developer has faced this situation: you open a code file, see dozens of unfamiliar lines, and spend time trying to understand what everything does.

This can be especially challenging for beginners, students, and developers working with unfamiliar codebases.

AI can make this process easier.

Introducing XoneAI Code Explainer

I built a free AI-powered Code Explainer to help developers understand code more easily.

With this tool, you can:

Get explanations of code.
Understand unfamiliar programming logic.
Learn how different parts of code work.
Save time when exploring code.

No Signup Required

You don't need to create an account or log in to try it.

Try it here: https://www.xoneai.in/tools/code-explainer

I'm building XoneAI to make useful AI tools accessible to developers and students.

I'd love to hear your feedback!

What feature would make a code explainer more useful for your daily development work?