StartupXO

Positioning

StartupXO bundles startup ideas, founder-perspective news, and immediately connectable talent into a single multilingual discovery experience. It’s not just an archive, it connects “what can be built (Ideas) → what’s happening in the market right now (News) → who can build it together (Humans)” through a single search input.

Market and Problem

Anyone preparing or early in a startup needs three things simultaneously: validated idea seeds, market context, and execution partners. Existing services scatter these across separate platforms. StartupXO integrates all three into one browsing flow.

• Instead of idea lists with low information density, problems, opportunities, and “why now” visible directly on each card
• Instead of link aggregators for news, founder-perspective interpretation and source depth shown upfront, not just headlines
• Instead of profile directories for talent, compare roles and strengths quickly, then connect directly on Telegram

Core Audience and Personas

• Aspiring founders exploring startup ideas, People who want a fresh perspective daily on what problems are worth solving right now
• Early teams needing market context, Teams who want the latest signals in a specific domain with founder-level interpretation
• Builders looking for co-founders or collaborators, People who want to scan relevant talent quickly even before a specific role is defined

Value Proposition and Differentiation

• Daily AI-refreshed idea archive, AI generates new ideas every day, structured so problem, opportunity, and recommended talent are immediately readable
• Founder-perspective news interpretation, After RSS collection, AI rewrites news from a builder’s viewpoint, not just translation, but “what does this mean for someone building something”
• ko / en / ja three languages simultaneously, Languages are generated together at creation time, eliminating separate translation operations
• Natural-language AI search, Ideas, news, and talent are searched simultaneously client-side without server calls. Query intent is interpreted to guide relevant content and follow-up discovery

Content Automation Pipeline

flowchart TD
    RSS["RSS feeds
(startup news sources)"]
    Sonar["sonar-pro
research · fact-check"]
    Sonnet["claude-sonnet
founder-perspective article writing
(ko · en · ja)"]
    Haiku["claude-haiku
translation refinement"]
    Astro["Astro build
static HTML generation"]
    FH["Firebase Hosting
global delivery"]
    Visitor["Visitor"]

    RSS --> Sonar
    Sonar --> Sonnet
    Sonnet --> Haiku
    Haiku --> Astro
    Astro --> FH
    FH --> Visitor

    Ideas["Idea generation script
(Grok API)"] --> Astro

News is collected, generated, and deployed twice a week via a scheduled trigger. Ideas are generated via a separate script and loaded as Astro content.

System Architecture

flowchart LR
    Browser["Visitor browser"]
    FH["Firebase Hosting
(static Astro output)"]
    FS["Firestore
(startupxo DB)"]

    Browser --> FH
    Browser --> FS

• Frontend: Astro static site (ko·en·ja) → Firebase Hosting (deployed via GitHub Actions)
• Data: Firestore (named DB). No separate backend API server, the client queries Firestore directly. News collection is handled by GitHub Actions cron scripts that generate content and write to Firestore/git
• AI search: window.__XO__ embedded data + client JS. Operates without server calls

Technology Choices and Trade-offs

• Astro v5 (static site + React islands): Migrated from Hugo. Tailwind v4, TypeScript, and the React island pattern strike the right balance between the workspace’s Vite+React standard and a content platform’s need for SEO-first, server-free deployment
• Client-side AI search: Embedded data searched in JS at build time, no server calls. Zero latency · zero server cost · offline-capable, the optimal trade-off at this content scale
• OpenAI gpt-4o-mini (single model): Handles news research, idea writing, and translation with one model. The active client is tools/lib/openai.ts. At the current content scale, cost and operational simplicity win over a multi-model split
• What was dropped: Server-side real-time search (client JS is sufficient), custom CMS (Astro content collections are sufficient), user accounts and saved items (anonymous browsing for now)

Current State and Operational Signals

• Status: Live. News auto-collection and deployment stabilized; idea archive accumulating
• Content: Dozens of ideas and news articles accumulated; Mon/Thu automatic updates
• Infrastructure: Firebase Hosting (static Astro), Firestore named DB. No separate API server
• Languages: ko (default) / en / ja, all simultaneously

Retrospective and Next Hypotheses

• What worked: Bundling content generation, translation, and deployment into one pipeline so three languages update automatically with no operational overhead. Client-side AI search delivers discovery UX with no server cost
• What I would redo: Integrating idea generation as an API endpoint the same way news collection is would have made the full automation loop cleaner
• Next hypotheses: (1) Idea generation endpoint + auto-scheduler, (2) Stronger cross-linking between related ideas, news, and talent, (3) Subscription notifications (new ideas/news beyond RSS), (4) Auto-surfacing latest StartupXO content on the mrlatte hub

Comparable Engagements

Core capabilities built while developing StartupXO.

• AI content automation pipelines, External source ingestion → AI rewriting → multilingual → static site auto-deployment
• Client-side AI search, Intent classification + semantic search over embedded data, no server required
• Astro multilingual static sites, Simultaneous ko/en/ja builds, SEO-optimized, Firebase Hosting deployment
• LLM multi-model pipelines, Designing research, writing, and translation stages to leverage each model’s strengths

I prefer engagements where one person carries the work end to end. Reach me via /work-with-me or /contact.