The 18 products EarthLink Network builds in-house

Here is what this article gives you first (about a 7-minute read):

• The full picture of the 18 products we run in-house, grouped into six areas — foundation, growth, execution, monitoring, support, and verification — with what each one solves.
• A lineage, not a catalog. They are ordered the way the needs appeared: build it → monitor it → repair it → manage it. This was never a product line designed up front.
• The always-current details live on the official page. Each product's screens and localized versions are collected at eln.ne.jp/products, kept up to date.

We are trying to run the entire company (EarthLink Network) on AI. It was never going to be one tool and done. Build it → monitor it → repair it → manage it → manage the managing — each need surfaced the next, and each one became the next product. So what you see here was not designed up front as a product line. It came out of working through one question: in the age of AI, how do you do team development?

People focus on judgment; the routine work goes to AI. The next generation of productivity will be measured not by how fast you ship, but by the correctness and the number of judgments you make. That is the premise on which these 18 products are running today.

This page is an index — a list of what EarthLink Network is currently building, a description of each product, and an overview of what I am making and how I am trying to automate it.

Some of these are still in development. Heading toward launch, I keep adding screenshots, descriptions, and links to each product's landing page, and I update it as I go.

The details, screens, and localized versions (English, Korean, Chinese, Thai) of each product are collected on the company's official products page, which is always kept up to date.

→ EarthLink Network's products page

Building the foundation (shared components and infrastructure)

• platform — A monorepo that gathers the shared parts of multiple products into one place (multiple packages managed in a single repository). We moved block editors, common DynamoDB handling, rate limiting, notifications and more out of each repository, switched the callers over based on real measurements, and only then retired the originals. In the middle of that cleanup, we retired eight shared-library repositories after confirming zero usage; one more (the old lime) is still having its consumers migrated and will be retired once that's done.
• onion — An SSO foundation that unifies login across all products (one login for many services). It handles authentication for promptflow, sage, alive365, plovant and others, and operations such as client issuance and token revocation are exposed as an API, so other repositories' CI and Claude can drive it directly. Localization passes 10 languages × 16 areas = 13,080 messages with zero validation errors.
• notify — A shared notification foundation that handles email, Slack, LINE, and Webhooks in one place, carved out so that each product doesn't have to build notifications itself. It supports prioritized destinations with automatic failover (if the first fails, it moves to the next) and an idempotency-key API that won't double-send (a resend with the same key is safely ignored).
• dotvault — A homegrown secret-distribution SaaS that delivers secrets such as .env, .npmrc, kubeconfig, and certificates to each person's PC or CI with a single dotvault pull command. Users don't need an AWS account; think of it as an in-house take on Doppler or Infisical. I started from the spec at the end of May and built the organization, permissions, audit log, and billing in one month in June, across 127 commits.

• billing — A foundation that consolidates billing for several in-house SaaS products in one place. It wraps Stripe (the payment service), handles contracts, coupons, and one-off charges through a single API, and when a payment or cancellation occurs it notifies each service via a signed Webhook (a server-to-server automatic notification). Notifications that fail with a 5xx are retried automatically at 1s → 5s → 15s, up to three times.

Building the site and audience

• web-platform (plovant) — A multi-tenant CMS that runs 10–20 sites from a single admin screen (content management for many sites on one foundation). Previously, just pushing to main redeployed seven sites at once; we resolved that by consolidating into a single app that routes sites by hostname. It includes block editing for landing pages, AI page and image generation, and block-level multilingual translation.
• aio-helper — An operations SaaS that automatically ingests Google Search Console data, proposes SEO improvements via RAG (searching internal data to compose answers), and measures the effect. It was carved out of the SEO features that used to live inside web-platform. Implementation has reached 14 front-end pages, 28 APIs, and 12 DB tables, with a roadmap to move from internal use to an external offering.
• curation — A tool that automatically collects news on topics such as AI and security, then summarizes and translates it with Gemini and delivers it to each person individually. The key move was adding a triage stage that selects articles before they hit AI analysis. That lets it handle an inflow of 2,516 articles a day while cutting analysis cost from $1.0–3.7 per day to $0.13 — about 94% lower.

Getting work done (tasks → knowledge → orchestration → AI infrastructure)

• sage (usesources) — A workspace that brings wiki, task board, dedicated chat, cross-search, and AI agents together around the project. Create a project and its pages, board, and chat are created at once; remove a member and their permissions below it are revoked in bulk. It began as a RAG search across multiple SaaS tools, but we steered it toward integrated task management and chat.
• promptflow (Prompt Flow Studio) — A SaaS that handles multiple AIs from OpenAI, Anthropic, and Google on one screen, in four modes: chat, compare, debate, and workflow. It runs the same question across several models side by side to compare and debate, and it version-controls the outputs. It is one of the largest in-house products by development scale, and an iOS version is being built in parallel.

• local-commander — An AI development orchestrator that puts a local LLM on your own machine, rather than the cloud, in the role of judge. Throw it a task and the local LLM sorts it into buckets like "handle locally," "needs the cloud," or "requires approval"; it inserts a human approval only when needed, routes implementation to Codex or Claude Code, and automates push, PR, review, merge, and task updates. Even buying the dedicated machine (DGX Spark) was decided not on a hunch but on measured benchmarks across 16 cases.
• claude-plugins (ELN workflow) — A private in-house plugin foundation that distributes the same spec process, quality standards, and operating discipline to every project via Claude Code. The key is that it is implemented not as a "please follow this" document but as skills you can't get past without following — and it won't let anyone say "done" without real observation (logs, DB, test output). It is also how this very blog is made.

Monitoring and managing

• alive365 — An uptime-monitoring SaaS that combines multi-location liveness checks, incident management, a status page, and browser-operation checks into one. Starting from the idea that "it's the monitoring side that carries the fixed cost," we made HTTP checks run without a resident process and browser checks start on demand, aiming for zero fixed cost — and we actually eliminated always-on line equipment that had been costing $58–66 a month.

• eln-infra-ops — An internal infrastructure foundation that ends hand-typed SSH operations and makes our home CI server fleet (several machines plus a dedicated one) reproducible from code, at any count. Its distinctive point is that the pass/fail bar sits not in a design document but in a real-hardware kill-test (actually take one machine down and see whether every service survives without interruption on the remaining machines). We actually caused an incident where two machines became primary at the same time, and put in a fix the same day, tightening failover to 18 seconds.

• kale — A multi-cloud cost-management foundation that shows AWS, GCP, Azure, and OpenAI costs on one screen and alerts to Slack / Teams on budget overruns or anomalies. Adding a provider takes only a config entry; we added GCP and OpenAI in a day. Using kale itself, a Claude Code agent watches every product's cost with hourly anomaly detection and daily reports.

Supporting customers

• desk — A foundation that switches FAQ, appearance, and initial message per site identifier, running RAG chatbots (answering based on referenced documents) for many sites on a single base. It has a test mode that works with canned responses even without an OpenAI key, so you can automatically verify production-equivalent acceptance conditions even during development.
• community-v2 — A SaaS for a community that supports AI adoption. It brings a template library, posts, prompt review, short AI lessons, notifications, and search onto one base, with separate apps for users and administrators. It keeps cost down by not auto-building on every push — build charges occur only on an explicit action.

Building verification and teaching material

• tessvia — A foundation that derives four things — tutorial playback, operation-manual generation, E2E tests, and liveness monitoring — from a single canonical scenario. It was originally two separate projects ("a tool to build E2E tests from natural language" and "a tool to deliver internal tutorials"), but we found we had independently built the same design twice — matching down to the color choices — and merged them into one. Manual generation is wired to a local claude -p rather than the cloud.

How to read this list, and what's next

These 18 products are not a standalone catalog. They came out of a single goal — running the whole company on AI — where building, monitoring, repairing, and managing each nested into the next need. Pick the one that interests you as an entry point, trace what came before and after it (what it was built for, and what it needed next), and the intent of the whole becomes clear.

The latest screens, details, and localized versions (English, Korean, Chinese, Thai) of each product are collected on the company's official products page and kept up to date. Start there for an overview of what is running right now.

→ EarthLink Network's products page