July 2026
Activation email drip (5-email Postmark sequence)
Self-serve signups get 5 timed nudges across their first 14 days. Skip-condition aware.
Read more
What shipped: 5 emails (Day 0 / 3 / 7 / 10 / 14) per tenant, each tied to a specific conversion blocker — first shipment, carrier setup, team invite, billing, expansion frame.
Hard guardrail: HTG and god-mode tenants are skipped automatically. No internal seat gets dripped.
Measurement: Each tenant's conversion-by-step view in admin funnel.
Startup diagnostics: /__healthz, /__startup-log
On-call now has a no-auth probe that tells them why the boot failed, not just that it failed.
Read more
What shipped: GET /__healthz returns 200 + {started_at, port_bound, db: ok|down, csrf_secret_present, csrf_secret_state}. GET /__startup-log returns the boot log tail with sentinels on each step.
Use: Your monitoring stack hits /__healthz every 60s. If it returns anything other than 200, the boot log points at which step regressed.
Security: No secrets in either endpoint. No data. Pure liveness.
April 2026
HTG case study: live metrics, customer story, JSON-LD
The /customers/htg page pulls live shipment and seat counts from the HTG tenant and renders them as a case study — no manually updated numbers.
Read more
Why live data: Case studies with static numbers go stale within a quarter. Pulling from the production tenant means every pageload reflects the actual current state.
What shipped: Server-rendered case study page with live seat count, total loads, and 30-day load velocity. JSON-LD Article + Organization schema. Source-tagged conversion tracking.
Deep-link: /customers/htg.
/ai-employees: public showcase page for AI employee capabilities
Prospects can now see what each AI employee does before they sign up. Capability cards, example outputs, and a "See it in action" demo CTA.
Read more
The page lives at /ai-employees and is indexed by search engines. Each employee card shows their domain, what triggers them, and sample output. JSON-LD markup for rich results.
CTA: Book a demo → /book-demo?source=ai-employees.
Migration playbooks: step-by-step guides for switching from Turvo, MercuryGate, AscendTMS
Switching freight TMS is painful. These playbooks make it less so — covering data export, parallel-run strategy, and common failure modes for each competitor.
Read more
The switching problem: Carriers have your number in their old TMS. Loads in-transit can't be migrated mid-stream. Finance needs a clean cutover date. Most platforms give you zero guidance.
What shipped: Three migration playbooks (Turvo, MercuryGate, AscendTMS), available at /vs/turvo, /vs/mercurygate, /vs/ascendtms. Each covers: what data migrates automatically, what needs manual work, parallel-run checklist, and go-live criteria.
HatchOS rebrand: from HatwayOS to HatchOS
Cleaner name, tighter identity. The platform is now HatchOS. All public URLs, email footers, and UI strings updated. Existing sessions and bookmarks redirect automatically.
Read more
Why it matters: The old name (HatwayOS) was a placeholder that stuck. HatchOS is shorter, easier to say, and survives domain availability. The rebrand touches every customer-facing surface.
Domain redirect from hatchwayos.polsia.app → hatchos.polsia.app is a 301 — existing links continue to work.
Want to see it live?
HatchOS is built for freight operations that want to move faster than their competitors.
See it live → Book a Demo