OpenSpark

Problem #

Good project ideas die between the “this would be cool” message and the first commit. OpenSpark is a place to post an idea (a spark), shape it into a technical blueprint with other people, and find collaborators before writing any code.

Approach #

There are two parts:

• The app is a Flutter client and a Next.js web front end over a shared Supabase backend. You sign in with email or GitHub, post sparks, vote and comment on them, and join a collaboration space with its own chat.
• spark_bot is a background worker meant to keep the feed full. It scrapes hackathon platforms for project ideas, then cleans, de-duplicates and scores them before posting.

Architecture #

Flutter app ─┐
             ├─> Supabase: Postgres + Auth + Realtime
Next.js web ─┘   tables: sparks, votes, spark_comments,
                         profiles, messages
                 rpc:    toggle_vote

spark_bot
  scrapers ─> clean ─> model ─> store ─> AI judge ─> post
  (Playwright, httpx)

• Real-time: the spark feed and collaboration chat subscribe to Supabase Realtime streams, so new sparks and messages appear without polling.
• Voting: goes through a toggle_vote Postgres function rather than separate insert/delete calls from the client, so a vote flips in a single database call.
• Client structure: Riverpod providers per feature (auth, sparks, collab, profile) and a small terminal-styled design system (JetBrains Mono, terminal cards and inputs) that the screens share.
• Scrapers: each platform implements a BaseScraper interface (fetch_raw_data, parse_data). asyncio.gather runs them all concurrently. Pages that load as you scroll get driven by Playwright.

Trade-offs #

• Supabase instead of a custom backend. Auth, Postgres and Realtime come out of the box, so the first version shipped in a week. The cost is that more logic lives in the database and its policies than in code I control. Elephant went the other way, with a custom Go server.
• Scraping instead of APIs. Most hackathon platforms don’t offer a public API for project listings. Scrapers are brittle when markup changes, which is why each one hides behind the same small interface.

Status and next steps #

• App: v0.1.0 is built, about 4,800 lines of Dart, and Android builds run through GitHub Actions.
• spark_bot: scrapers for Devfolio, DoraHacks, Tianchi, Topcoder and TAIKAI work. The rest of the pipeline (cleaning, modelling, storage, AI judging and posting) is scaffolded but not written yet. That’s the next piece of work, after which the bot can post to the app.