A multi-service hub that exposes several small internet products as color tiles on one page — acting as both brand gateway and discovery channel.

Positioning

oos is a brand gateway and discovery channel that lists small internet services on a single screen. Users land, scan, and jump into the service they want with one click. Operators expose many services under one identity without building a heavy landing page per product.

Market and Problem

A solo operator running multiple small services hits two frictions at once:

Standalone domains hide each service from the others’ visitors — no cross-discovery
Building a polished landing page per service is too expensive — yet a service that fails to convey value on arrival loses the visitor

oos fills the gap with a deliberately light hub. Each service is reduced to its identity (color, wordmark, one-line description) and a tile click takes the user straight there. No signup, no login, no onboarding — zero-friction entry.

Target Users

Solo / small teams running several products — owners who want to consolidate discovery instead of running discovery per service
Product owners who need a brand gateway — “what tools does our team build?” answered on one page
Visitors browsing curated small tools — people who prefer a hand-picked list of small internet products to platform search results

Value Proposition and Differentiators

Color-tile discovery — Each service is identified by brand color, wordmark, and a single line. Visual catalog, not a text list
Automatic tone matching — Tile background luminance decides text tone (light / dark) automatically — readability is guaranteed when new services are added, with no design work
Adaptive grid — Desktop / tablet / mobile columns are picked based on service count. The layout looks intentional whether there are 1 or 9 services
Zero-friction entry — No signup, login, or search. Tile equals link. Interaction cost is zero

Core User Flow

Arrive at www.oos.kr — headline plus the color-tile grid
Scan by color, wordmark, and one-line description
Click a tile and land on the service domain
Return later via bookmark or search to explore other services — the cross-discovery loop

Business Model Hypothesis

oos itself is not directly monetized — it acts as the discovery channel for downstream services, where revenue happens.

Higher entry conversion across the portfolio — when a visitor learns about multiple services, the average services-used-per-visitor goes up
Brand consistency — every small tool sits under one identity, so external recognition compounds
Selective sponsor slots (hypothesis) — curated third-party small tools could be exposed as a future surface

System Architecture (planning decisions encoded in the system)

Two planning decisions kept the system maximally simple.

1. “A hub should not need a backend.” → 100% static site. The service list is baked into TypeScript at build time; S3 + CloudFront serves it. Availability and cost both bottom out.

2. “Design consistency must be enforced by the system.” → Tile text tone is computed from luminance; the grid is composed from service count. Adding a service is a one-line data change — no design review, no inconsistency.

flowchart LR
    Data["apps.ts
(service data)"] --> Build["Astro build
(static)"]
    Build --> S3["S3
web/"]
    S3 --> CF["CloudFront"]
    CF --> User["Browser"]
    User --> Service1["weple.oos.kr"]
    User --> Service2["…"]

Technical Decisions and Tradeoffs

Frontend: Astro 5 (static output) + TypeScript. No SPA, no React — one tile-grid page is the entire interface, so SSG is the most honest fit
Backend: None. All data is static at build time
Hosting: Workspace standard — S3 (oos.kr/web/) + CloudFront. trailingSlash always
Operational signals: GA4 (page views, tile clicks) + Channel Talk (feedback channel)
What we gave up: dynamic service lists (CMS / DB), search and filters (faster to scan when the count is small), user accounts (no reason for a hub to have them)

Operational Automation

Auto tile tone — background hex → relative luminance (WCAG) → automatic white / dark text choice
Auto grid — desktop / tablet / mobile columns and aspect ratio derived from the service count
Auto OG — build-time composition of headline + brand into og-image
Auto JSON-LD — service list emitted at build time as ItemList(WebApplication) structured data

Current Status and Operational Signals

Status: Live. Started with weple as the first listed service; more to follow
Started: 2026-04
Infrastructure: AWS S3 (oos.kr/web/) + CloudFront, GA4 (G-0N2TV2NS1G), Channel Talk
Validation signals: tile click-through rate, multi-service visits per session (the cross-discovery signal)

Retrospective and Next Hypotheses

What worked: the “tile equals link” zero-friction decision. Nothing for the user to hesitate over
What I’d redo: shipping without OG / Channel Talk / GA / sitemap on day one delayed indexing. SEO infrastructure should land at launch, not later (corrected this round)
Next hypotheses: (1) category grouping when the service count exceeds five, (2) live status / last update on each tile, (3) curated external slots, (4) en locale split

Similar Engagements

The capabilities built while planning, implementing, and running oos transfer to other domains.

Multi-service brand hub / directory pages — gateway pages for teams running several products
Zero-friction discovery UX — interfaces where a single scan replaces signup or search
Data-driven design enforcement — systems where color / grid / typography stay consistent through data changes alone
Static-site SEO automation — patterns for baking sitemap / robots / JSON-LD / OG / GA / help-channel at build time
Low-cost static hosting (S3 + CloudFront) for many sites — shipping small services quickly and operating them on a shared infra pattern

I prefer engagements where one person carries the work end to end — planning, implementation, automation, operation. Reach out via /work-with-me or /contact.

oos

Included services