An opportunity discovery platform that reorganizes 'miss-it-and-it's-gone' information, competitions, events, performances, lectures, into a single curated, automated stream prioritized by D-day.

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.

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).
Paid operator self-serve, A direct channel for institutions and small businesses to enter and promote their own events.
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 daily automation chain: a 03:00 KST GitHub Actions cron that crawls external channels and normalizes them via AI into Firestore; and a 04:00 KST scheduler that rebuilds the site (Astro static SSG) and redeploys to Firebase Hosting, so every active event is frozen back into static HTML with its OG image. The D-day badge a user sees and the unattended daily ingest the operator depends on share the same system spine.

2. “The product should not carry a standalone backend it doesn’t need.” There is no separate API server. Firebase Firestore (named DB libsac) is the single data source, accessed only through the query wrappers in web/src/api/*.ts. Removing the SSR/API tier dropped operating cost, cold-start latency, and platform lock-in to plain static-hosting economics, while Firestore + Firebase Storage + Firebase Hosting (shared project mrlatte) keep infrastructure, logging, and the deploy pipeline unified across the family.

Daily ingestion → static HTML → Firebase Hosting pipeline

flowchart TD
    Crawl[Daily scheduler
03:00 KST · GitHub Actions]
    Enrich[OpenAI gpt-4o-mini
normalize: category · tag · date]
    DB[(Firestore, named DB 'libsac'
events · sponsored_until)]
    Rebuild[Daily scheduler
04:00 KST · rebuild + deploy]
    Build[Astro static SSG
per-event HTML + OG meta]
    Host[Firebase Hosting
project mrlatte · site libsac]
    User[Users
React island hydration]
    Crawler[Social crawlers
static HTML + OG image]

    Crawl -->|fetch external channels| Enrich
    Enrich --> DB
    Rebuild -->|read active events| DB
    Rebuild --> Build
    Build -->|deploy| Host
    Host --> User
    Host --> Crawler

Crawl, normalization, static build, and CDN caching live in a single serverless operations layer, that’s what makes solo operation tractable.

Technical Decisions and Trade-offs

Frontend: Astro 5 static SSG + React islands + TypeScript + Tailwind (web/), migrated from Next.js + Vercel. The page skeleton and OG metadata are frozen into static HTML at build time; only the dynamic parts (event list, counters, calendar) hydrate client-side as React islands. SSR was only really needed for the OG metadata of share URLs, and that’s solvable by regenerating static HTML on a daily build. Migrating away removed SSR hosting cost, cold-start tail latency, and platform lock-in, dropping the site to static-hosting economics.
Backend: No standalone API server. Firebase Firestore (named DB libsac) is the single data source, accessed only through the Firestore query wrappers in web/src/api/*.ts (events.ts · articles.ts). Active events are read in one shot and sorted/filtered in JS to avoid composite-index requirements.
AI: OpenAI gpt-4o-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.
Posters: external posters are mirrored into Firebase Storage (libsac/posters/…) to defeat hotlink blocks, rate limits, and broken external links.
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, A GitHub Actions crawl scheduler (daily 03:00 KST) sweeps external channels and gpt-4o-mini normalizes them into consistent categories, tags, summaries, and dates in Firestore events. Daily ingest runs hands-free.
Poster mirroring, Posters from external sites are mirrored into Firebase Storage (libsac/posters/…), eliminating broken-link, hotlink, and rate-limit risk.
SEO automation, The 04:00 KST scheduler rebuilds the site and redeploys to Firebase Hosting, so every active event becomes static HTML again; Astro bakes the event poster into the OG meta at build time so KakaoTalk, Facebook, and X show it correctly when shared. Unlike a SPA, the build artifact itself is static HTML, no separate prerender step.
Sponsored-tier expiry, Sponsored placement auto-downgrades to normal exposure once Firestore sponsored_until lapses. The operator never has to track exposure lifecycle by hand.

Current Status and Operational Signals

Status: Live, with continuous automated ingest
Started: 2025-10 (initial release on Next.js); later rebuilt on Astro static SSG + Firebase
Infrastructure: Serverless, no standalone server, Firebase Firestore (named DB libsac) + Firebase Storage + Firebase Hosting (project mrlatte, site libsac); deploys via GitHub Actions
Automation: Two daily schedulers (crawl 03:00 KST / rebuild + deploy 04:00 KST) + AI enrichment, refreshing content daily without human touch
Verified signals: active events surfaced continuously; daily crawl and rebuild/deploy pipeline healthy; 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 straight to Astro static SSG + Firestore serverless from day one would have saved the migration cost.
Next hypotheses: (1) user accounts + keyword alerts to test retention; (2) credit-unlock monetization on curated/premium menus; (3) operator self-serve listing + 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-SSG automation, Solving OG-image breakage, search-indexing gaps, and KakaoTalk-style preview issues in SPA stacks via on-schedule static HTML generation (Astro static SSG + daily rebuild).
Serverless data pipelines, Designing crawl → normalize → deploy systems with no standalone API server, using Firestore + Firebase Hosting + GitHub Actions cron, low operating cost, unified logging and CI/CD.

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.