Introduction

What EasyLink Is

EasyLink is a mobile-first product for discovering job opportunities through a cleaner, more controlled product surface. In the current beta direction, the core experience is centered around:

• account creation and sign-in
• discovery of jobs from approved providers
• search over canonical EasyLink job data
• opening job details in a product experience that EasyLink owns end to end

The important idea is that EasyLink is not just a UI layer over third-party job boards. The product is being designed around its own backend, its own job normalization flow, and its own search experience.

What The First Beta Includes

The first beta is intentionally narrow. The repository planning docs define the beta around a few critical surfaces instead of trying to launch every future idea at once.

Accounts And Access

The beta includes the foundations required for real users to create an account, sign in, and reach a minimal authenticated account surface. The project docs are explicit that EasyLink does not need a rich profile product to make the first beta successful.

Jobs And Search

The current scope is built around the approved beta providers:

• La Bonne Alternance
• France Travail

Those sources are ingested into EasyLink's own canonical data model. That gives the product control over normalization, deduplication, search behavior, and the quality of what users actually browse.

Operational Visibility

The beta is also supposed to be explainable. That means the system is expected to expose ingestion outcomes, quality signals, and debugging visibility for the team operating it.

What EasyLink Is Not Trying To Be Yet

Just as important as the in-scope work is the list of things the repo deliberately excludes from beta.

Some examples that are explicitly out of scope right now:

• additional providers beyond the two approved beta sources
• a standalone profile product with richer editing flows
• posts, comments, follows, and social surfaces
• public platform expansion or multi-app ecosystem work

Why The Architecture Looks Like This

EasyLink is structured as a TypeScript monorepo because the hardest part of the product is not generic CRUD. The hard part is controlled ingestion, normalization, dedupe, indexing, and serving job data through a product surface that stays understandable.

The current repository shape reflects that:

Mobile Owns The User Experience

The mobile app is where users browse jobs, search, and interact with the authenticated product surface.

The API Owns The Product Contract

The API is the boundary that serves EasyLink's own data model to clients. That keeps provider-specific logic out of the product UI.

The Worker Owns Ingestion

The worker is responsible for background ingestion, fetch planning, retries, normalization, and index refresh. This keeps long-running provider workflows out of the request-response lifecycle.

What To Expect From This Blog

This blog should become a place for durable product writing around EasyLink itself. That can include:

• product notes about discovery and search
• architecture and system decisions worth explaining in plain language
• reflections on scope, quality, and how the beta is evolving

The goal is not to turn the blog into filler content. It should help explain what EasyLink is becoming and why the team is making the tradeoffs it is making.