Libsac

Positioning

Libsac is an opportunity discovery platform that turns scattered deadline-driven information into a daily actionable feed. Competitions, events, performances, and lectures — categories whose channels are normally disconnected — are unified into a single product model built for quick scanning, timely prioritization, and follow-through.

Market and Problem

The supply of opportunity information keeps growing, yet its channels keep fragmenting. A single competition can be advertised across five or more disjoint boards; performances and lectures spill across newsletters, social channels, institution sites, and community forums. Users pay the discovery cost from scratch every time, and the gap between “I would have applied if I’d known” and “the deadline already passed” is exactly where most opportunities die.

Large portals and unified search solve volume but not priority — they do not tell you “this is the one you have to act on today.” Libsac was built around two values that mainstream search underserves: deadline urgency and a consistent action loop across categories.

Core Audience

• Students and job seekers who want to track competitions, internships, and seminars on a deadline basis
• Active explorers of cultural and learning experiences who want to see performances, lectures, and local events on one calendar
• Community contributors who surface and submit opportunities from their own circles

Value Proposition and Differentiation

• Many categories, one flow — A user who came in to browse performances can pivot into competitions or lectures in the same UI. Mainstream channels force users to relearn a different site for each category.
• Urgency made visible — D-day, “ending soon” badges, and a calendar view are all generated from the same data. Users see “what to act on now” at a glance.
• Share-channel-aware SEO — Static HTML is regenerated daily so that when an event is shared on KakaoTalk, Facebook, or X, the event’s poster shows up correctly as the OG image. This is impossible to solve with a plain SPA — Libsac solves it at the operations layer.

Core User Flow

• Enter via category or “ending soon” badges
• Filter by D-day, tag, or keyword to surface only what matters now
• Act by jumping to the external application page in one tap, while click data accumulates back to operator analytics
• Return because new deadlines surface daily, forming a daily/weekly habit

Business Model Hypotheses

Monetization will be validated in stages. Today the focus is on data-asset accumulation.

1. Sponsored placement — Within a category, sponsored events are surfaced first via a sponsored_tier mechanism (already implemented in the schema with auto-expiry on sponsored_until).
2. Paid operator self-serve — A direct channel for institutions and small businesses to enter and promote their own events.
3. Curated dataset licensing — The curated event dataset itself, supplied to peer services such as university communities and job boards.

System Architecture (Translating Plans into Systems)

Two strategic decisions on the product side dictated the architecture.

1. “Deadline urgency cannot be only a UI concern — it has to run all the way through the operations layer.” This translated into a three-stage automation chain: a 03:00 KST cron that crawls external channels and normalizes them via AI; a 04:00 KST prerender cron that PUTs static HTML for every active event onto S3; and a deploy hook that force-regenerates the entire event HTML set whenever the SPA is rebuilt with a new asset hash. The D-day badge a user sees and the unattended daily ingest the operator depends on share the same system spine.

2. “Multiple services should share an operations core.” The backend is a single Hono server that fans out to nine services (Libsac among them) via host-based routing. Each request’s api.<domain> header chooses the router; per-service databases and S3 buckets stay isolated, but the infrastructure, logging, and deploy pipeline are unified. This is what makes the per-service operating cost a fraction of what it would be otherwise.

Daily ingestion → static HTML → CDN delivery pipeline

flowchart TD
    Crawl[Daily scheduler
03:00 KST]
    Prerender[Daily scheduler
04:00 KST]
    API[Hono API
AWS Lightsail · 9 services shared]
    DB[(MySQL
events · sponsored_tier
click·view counters)]
    S3[(S3 libsac.com
web/e/<short>
web/events/<slug>-<short>)]
    CDN[CloudFront]
    User[Users
SPA hydration on prerender]
    Crawler[Social crawlers
static HTML + OG image]

    Crawl -->|fetch external channels
AI enrichment| API
    API --> DB
    Prerender -->|generate active-event HTML| API
    DB --> API
    API -->|PUT static HTML| S3
    S3 --> CDN
    CDN -->|Cache-Control max-age=300| User
    CDN --> Crawler

Crawl, normalization, prerender, and caching live in a single operations layer — that’s what makes solo operation tractable.

Technical Decisions and Trade-offs

• Frontend: Vite + React 19 + SPA + S3 + CloudFront, migrated from Next.js + Vercel. SSR was only really needed for the OG metadata of share URLs, and that’s solvable with a daily prerender cron. Migrating away removed SSR hosting cost, cold-start tail latency, and platform lock-in, dropping the site to static-hosting economics.
• Backend: Hono on Node + PM2 on AWS Lightsail (instead of serverless). Nine services share the same core, so a single warm process beats serverless on both cost and operational complexity — splitting into nine functions would have multiplied the deploy/log/observability burden.
• DB: MySQL 8.0 (instead of Postgres). Operational familiarity. JSON columns and advanced features are not used — the workload is composite indexes and DATETIME comparisons, where engine choice doesn’t move the needle.
• AI: OpenRouter / GPT-mini for enrichment (instead of self-hosted models). Enrichment is a batch job that’s latency-insensitive, and the accuracy/cost ratio of mini-class models is good enough for the data shape.
• What was deliberately deferred: real-time sync, user accounts, login. They would have inflated operations cost without testing the core curation hypothesis.

Operational Automation

The layers that make a one-person operation viable:

• Crawling + AI normalization — External channels are crawled daily and AI-normalized into consistent categories, tags, summaries, and image metadata. Daily ingest runs hands-free.
• Poster mirroring — Posters from external sites are mirrored into S3 with time-bucketed prefixes (files/public/posters/<yyyy>/<mm>/), eliminating broken-link and rate-limit risk.
• SEO automation — The 04:00 cron PUTs static HTML for every active event onto S3, baking the event poster into the OG meta so that KakaoTalk, Facebook, and X show it correctly when the event is shared. A deploy hook force-regenerates the set whenever the SPA bundle hash changes, closing the stale-prerender window.
• Expiry cleanup — Events past their end date by 90 days have their static HTML auto-deleted and sponsored_tier reset. The operator never has to track event lifecycle by hand.

Current Status and Operational Signals

• Status: Live, with continuous automated ingest
• Started: 2025-10 (initial release on Next.js); 2026-04 rebuilt on Vite + S3 architecture
• Infrastructure: Single AWS Lightsail instance + per-service S3 buckets + CloudFront, shared across 9 services
• Automation: Three daily schedulers (crawl / prerender / mobile build) + AI enrichment, refreshing content daily without human touch
• Verified signals: 30+ active events surfaced at any given time; prerender cron failure rate at 0%; KakaoTalk / Facebook / X share previews verified to display per-event poster as OG image

Retrospective and Next Hypotheses

• What worked: The “user-facing urgency = system-level urgency” framing. Carrying the planning value all the way through cron, static HTML, and CDN cache produced a structure a single operator can sustain.
• What I would do differently: Picking Next.js + Vercel up front looked like the fastest way to ship SEO, but at the operations stage the hosting cost, cold starts, and platform lock-in turned into liabilities. Going SPA + prerender cron from day one would have saved the migration cost.
• Next hypotheses: (1) user accounts + keyword alerts to test retention; (2) operator self-serve listing to reduce curation cost; (3) exploring licensing of the curated dataset itself.

Similar Engagements I Take On

The capabilities developed by planning, building, and operating Libsac single-handedly transfer cleanly to other domains.

• Deadline-driven discovery services — Job postings, real-estate listings, limited-edition drops, competitions — anything where “miss it and it’s gone” is the operative dynamic.
• Multi-channel crawling + AI normalization pipelines — Pulling fragmented data into a unified schema and turning it into a hands-free ingest channel.
• SEO / static prerender automation — Solving OG-image breakage, search-indexing gaps, and KakaoTalk-style preview issues in SPA stacks via on-schedule static HTML generation.
• Multi-service backend architecture — Designing and implementing systems where multiple services share an operations core, infrastructure, and CI/CD pipeline.

I prefer engagements where one person carries the work end-to-end — from planning through system construction to operational automation. To enquire, visit /work-with-me or /contact.