Forem: OLIVIER VANHESTE

Hack, Reflect, Look Forward: Building JH Link with Google Gemini

OLIVIER VANHESTE — Mon, 02 Mar 2026 21:07:00 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini

For the DEV Weekend Challenge: Community, I built JH Link — a Progressive Web App with the tagline "Your youth centre, in your pocket."

The app serves my local youth center, which runs activities for members aged 10–19 (and welcomes the wider community). Communication was fragmented: events were word-of-mouth, check-ins were manual, and members had no persistent sense of engagement when they weren't physically present.

JH Link solves that with:

Activity Feed — filterable, searchable event list with real-time capacity indicators and one-tap registration or waitlist joining
Digital Member Card — a QR code (built with qrcode.react) that encodes <appUrl>/admin/checkin?uid=<userId>, scannable by staff directly in the app
Gamification — an XP and badge system: attendance earns points, milestones at 50 / 100 / 250 / 500 / 1000 XP, and four automatic badges (First Timer → Regular → Veteran → Legend) plus a bonus for completing your profile
Dashboard — personalized home screen with an XP progress bar, badge shelf, and next 3 upcoming events
Admin Dashboard — four panels: Members (activate/reject), Points (manual award/deduct), Activities (create/edit/cancel), and Check-In (QR scanner that marks attendance and triggers the XP award)

The stack: Next.js (App Router), Supabase (auth + PostgreSQL with RLS + Storage), Tailwind CSS, Vercel. Built entirely inside a VS Code Dev Container using bun.

Before writing a single line of code, I ran a series of sparring sessions with Gemini on the web to settle the architecture. I described the problem space, the target audience, and the constraints (offline-capable PWA, minimal ops overhead, fast solo build), and we worked through the tradeoffs together — why Supabase over a custom backend, why Next.js App Router over Pages, how to structure RLS for a mixed member/admin user model, and what the gamification layer should look like at a schema level. Those early conversations produced the architecture document and the database schema before I opened VS Code.

Google Gemini was my co-developer throughout the entire weekend build. Every feature started as a conversation. I'd describe what I needed, Gemini would produce a draft, I'd review it, challenge it, and we'd iterate. The result was a feature-complete application shipped in roughly two days.

Demo

Live demo: https://jh-link.vercel.app/login

What I Learned

Technical skills

Supabase RLS is subtle and unforgiving. I came into the weekend thinking Row Level Security would be straightforward. In practice, a misconfigured policy fails silently — the query just returns zero rows instead of an error. The trickiest part was the gamification layer: awarding points and badges needs to happen whether triggered by a member action or an admin check-in. The solution was a service-role client that bypasses RLS for those writes, but that meant I had to be very deliberate about where that client is used, since a service-role key in the wrong place would be a serious security leak. Gemini helped me think through the permission model, but I still had to manually review every RLS policy and service-role call.

Next.js App Router has sharp async edges. The mix of Server Components, Client Components, and Server Actions creates subtle boundaries. Several bugs came from mis-placed awaits or from a Server Action not having access to cookies the way I expected. One concrete example: the three Supabase client factories (client.ts, server.ts, middleware.ts) each exist for a specific context, and using the wrong one causes silent auth failures. These are the kinds of bugs where the error message points you nowhere near the root cause.

PWA edge cases are platform-specific and fiddly. The service worker cache invalidation strategy that works on Android often behaves differently on iOS Safari — especially around the install prompt and offline fallback pages. The generated sw.js was a solid starting point but needed manual tuning for iOS.

Parallel data fetching matters. The activities page fetches registration counts, the user's own registrations, and their waitlist entries for the rendered activity IDs. Doing those three queries in sequence would be noticeably slow. Gemini suggested wrapping them in Promise.all() immediately, which I kept — and it made a real difference in perceived load time.

Soft skills & unexpected lessons

Prompt quality directly determines output quality. The clearest lesson of the weekend: vague prompts produce vague code. When I started framing requests as "I need a Server Action that registers a user for an activity, enforcing membership, capacity, and deadline constraints, and returning a typed result object", the output was immediately usable. When I said "add registration logic", it was a mess. Treating Gemini like a senior collaborator who needs full context — not a magic code button — changed everything.

Never merge generated security-sensitive code without reading it. The RLS policies and the service-role client usage are the two places where a bug isn't just a broken feature — it's a data exposure or privilege escalation. I learned to treat those sections with the same scrutiny I'd apply to a security audit, regardless of how confident the explanation sounded.

Speed creates scope creep. When you can generate features quickly, the temptation is to keep adding. I had rough implementations of a member messaging system and social reactions on activities before I cut them. Being fast doesn't mean you should keep going — knowing when to stop is a skill the AI can't help you with.

Google Gemini Feedback

What worked well

Context retention within a long session was excellent. I could say "remember that the gamification runs via the service-role client" and Gemini would correctly propagate that constraint into the next feature's implementation without me restating it. This made multi-step features feel like a real dialogue.

Error reasoning saved significant debugging time. When Supabase returned a cryptic error code, Gemini's ability to reason about what the error likely means in this context, rank the possible causes, and suggest targeted fixes was faster than reading documentation cold. This happened several times with RLS policy errors and with the pkce auth flow callback.

Boilerplate for well-known patterns was fast and accurate. The three Supabase client factories, the useTransition-based optimistic UI on the registration button, the next/font/google setup, the PWA metadata in layout.tsx — all of these are patterns that are tedious to type out correctly but well within Gemini's training data. Getting them right on the first pass was a genuine time saving.

Code organisation suggestions. When I dumped a large feature request in one go, Gemini would often propose a sensible file split before writing any code. It suggested separating ActivityCard.tsx from RegistrationButton.tsx so the card could be a server-renderable component while only the button needed to be a Client Component. That's the kind of structural thinking I appreciated.

Where there was friction

Hallucinated API signatures. On a couple of occasions, Gemini generated code using Supabase SDK methods or options that don't exist in the version I was using — most notably around the count query option syntax. The code compiled fine and failed at runtime with an opaque error. This is the most dangerous failure mode: confidently wrong code that looks right. Cross-referencing the actual Supabase docs became a habit.

Over-engineering on the first pass. When I asked for the gamification system, the initial output included an abstraction layer — a GamificationEngine class with a plugin interface for future reward types. I needed a single awardPoints() function that works now. Asking for simplicity became a recurring step; the phrase "write the simplest version that satisfies these requirements" was something I used often.

Debugging loops that don't converge. If a bug had multiple possible causes, Gemini would sometimes propose a fix, I'd report it didn't work, and the next response would be a marginally different version of the same fix — without genuinely reconsidering the root cause. These loops required me to hard-reset: close the conversation, write a fresh prompt that described the symptom from scratch, and reframe the problem. That usually broke the loop, but it cost time.

Occasional confidently wrong explanations. A few times, Gemini explained why something worked in a way that was plausible-sounding but subtly incorrect. I caught these by testing the claim against the actual behavior or the docs. The risk is not catching them — you end up with a mental model of your own codebase that's wrong.

The VS Code extension ignored my project structure. This was a persistent and frustrating friction point with the Gemini extension in VS Code: it consistently created new files under the repository root instead of under src/, regardless of how I phrased the request. Every file it scaffolded — components, actions, route handlers — had to be manually moved or I had to explicitly spell out the full path in the prompt every single time. The web interface never had this problem; it was specific to how the extension interpreted workspace context. It wasn't a showstopper, but it broke flow repeatedly across the entire build.

The honest verdict

Building a feature-complete application in a weekend would not have been possible to the same standard without Gemini. The productivity gain on well-defined, boilerplate-heavy work is real and large. But it's a force multiplier for someone who already understands the domain — not a substitute for understanding it. Every security-sensitive section required me to be fully present and skeptical. Every place I accepted output on trust, I eventually paid for.

The two improvements I'd most want to see: better API version awareness (or at least a clear caveat when generating code against a specific SDK version) and a more deliberate root-cause debugging mode that explicitly backtracks rather than proposing incremental variants of a failing approach.

JH Link: A PWA to Connect and Engage Our Local Youth Center

OLIVIER VANHESTE — Sun, 01 Mar 2026 21:43:03 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

This project is for my local youth center. While its main focus is on providing a vibrant hub for young people aged 10-19, the center maintains an open and welcoming atmosphere for the entire community. People of all ages are encouraged to drop in for a chat, grab a drink from the cafe, or even participate in activities. However, communication and engagement are often fragmented, relying on word-of-mouth and scattered social media posts. It can be hard for members to track activities, see who's attending, or feel a persistent sense of belonging when they aren't physically at the center. Administrators also spend significant time on manual tasks like check-ins and tracking participation.

What I Built

To address these challenges, I built JH Link, a Progressive Web App (PWA) designed to be the digital heart of our youth center.

It's a mobile-first application that provides:

Activity Feed: A real-time list of upcoming events and activities that members can register for with a single tap.
Member Profiles: A space for members to express themselves and see their engagement history.
Digital Member Card: A QR-code-based virtual card for easy check-ins, replacing the need for physical cards.
Gamification: A points and leveling system that rewards members for participating in activities, fostering friendly competition and sustained engagement.
Admin Dashboard: A comprehensive backend for staff to manage activities, check in members, and oversee the points system.

The goal is to make participation easier, more rewarding, and to strengthen the community bond, even when members are apart.

Demo

You can try out a live demo of the application here: https://jh-link.vercel.app/login

Here's a video walkthrough of the application:

Code

The full source code is available on GitHub:

https://github.com/polcrosmol/jh-link

How I Built It

I developed JH Link over the weekend, leveraging a modern, full-stack TypeScript approach.

Framework: Next.js (using the App Router)
Backend & Database: Supabase for authentication, a PostgreSQL database with Row Level Security, and storage.
Deployment: Vercel
Styling: Tailwind CSS
UI/UX: The app is a fully Progressive Web App (PWA), installable on mobile devices for a native-like experience. It includes page transition animations and a navigation progress bar.
Tooling: I used bun as the package manager and the entire development was done inside a VS Code Dev Container.

A significant part of the development process involved working with an AI assistant. This co-development model was incredibly efficient. The AI handled much of the initial scaffolding, boilerplate code, and complex server actions, which allowed me to focus on the overall architecture, user experience, and critically reviewing the generated code to ensure its quality and correctness. We collaborated on everything from feature implementation to complex debugging of SQL policies and asynchronous JavaScript, enabling the creation of a feature-rich application in a very short amount of time.

Copilot Jira Planner — Turn Project Ideas into Jira-Ready Plans with AI

OLIVIER VANHESTE — Sat, 14 Feb 2026 16:26:52 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

Copilot Jira Planner (cjp) is a terminal-native project planning tool that uses GitHub Copilot CLI as its AI engine. You describe a project idea in plain English, and it generates a fully structured Jira-compatible plan — complete with Epics, Stories, Tasks, story points, time estimates, and acceptance criteria.

The problem it solves: every new project starts with the same tedious ritual — manually creating dozens of Jira issues, structuring them into epics, writing user stories, estimating effort. This tool automates that entire process in seconds.

Key features:

🤖 AI-Powered Planning — Describe your project in natural language, get a structured plan back
🌲 Beautiful Terminal UI — Tree and table views with color-coded priorities and status icons
📤 Jira Export — CSV and JSON export in Jira-compatible format for bulk import
🔗 Direct Jira Sync — Push plans directly to Jira via REST API (with dry-run preview)
🔄 Iterative Refinement — Refine existing plans with natural language instructions
💾 Local Storage — Plans persist locally for later viewing, editing, and exporting

Demo

🔗 GitHub Repository: polcrosmol/Copilot-Jira-Planner

Images

Creating a Plan

$ cjp create "Build a simple todo app with user authentication"

  🤖 Invoking GitHub Copilot CLI to generate your plan...
  Project: "Build a simple todo app with user authentication"

  ✔ Plan generated successfully!

  ╔══════════════════════════════════════════════════════════════╗
  ║  🎯 Todo App with Auth                                      ║
  ╚══════════════════════════════════════════════════════════════╝

  Plan ID: 49484ee8  │  Epics: 4  │  Stories: 9  │  Tasks: 25  │  Story Points: 42

├── 🔴 [E-1] User Authentication (2 stories)
│   ├── ⬜ [E-1-S-1] As a new user, I want to register an account... [5sp]
│   │   ├── ⬜ [E-1-S-1-T-1] Create user database model and migration (2h)
│   │   ├── ⬜ [E-1-S-1-T-2] Build registration API endpoint (4h)
│   │   └── ⬜ [E-1-S-1-T-3] Create registration UI form (4h)
│   └── ⬜ [E-1-S-2] As a registered user, I want to log in and out... [5sp]
│       ├── ⬜ [E-1-S-2-T-1] Build login API endpoint (4h)
│       ├── ⬜ [E-1-S-2-T-2] Implement authentication middleware (2h)
│       ├── ⬜ [E-1-S-2-T-3] Create login UI and auth state management (4h)
│       └── ⬜ [E-1-S-2-T-4] Implement protected route guards (2h)
│
├── 🟠 [E-2] Todo CRUD Operations (3 stories)
│   └── ...
├── 🟡 [E-3] UI Polish and App Shell (2 stories)
│   └── ...
└── 🟠 [E-4] Project Setup and Deployment (2 stories)
    └── ...

Table View

$ cjp view --mode table

┌────────────────┬────────┬──────────────────────────────────┬──────────┬─────────┬────┬──────┐
│ ID             │ Type   │ Title                            │ Priority │ Status  │ SP │ Est. │
├────────────────┼────────┼──────────────────────────────────┼──────────┼─────────┼────┼──────┤
│ E-1            │ Epic   │ User Authentication              │ 🔴 high  │ ⬜ todo │    │      │
│ E-1-S-1        │ Story  │ As a new user, I want to...      │ 🔴 high  │ ⬜ todo │ 5  │      │
│ E-1-S-1-T-1    │ Task   │ Create user database model       │ 🟡 med   │ ⬜ todo │    │ 2h   │
│ E-1-S-1-T-2    │ Task   │ Build registration API endpoint  │ 🟡 med   │ ⬜ todo │    │ 4h   │
└────────────────┴────────┴──────────────────────────────────┴──────────┴─────────┴────┴──────┘

Exporting and Jira Sync

# Export to Jira-compatible CSV
$ cjp export --format csv
  ✅ Exported plan to todo-app-with-auth-plan.csv

# Preview what would be created in Jira
$ cjp jira-sync --dry-run
  🔍 Dry Run — Preview of Jira issues to be created:
  📦 Epic: User Authentication
    📖 Story: As a new user, I want to register... (5 SP)
      ✏️  Task: Create user database model (2h)
      ✏️  Task: Build registration API endpoint (4h)
  ...
  Total: 4 epics, 9 stories, 25 tasks

Workflow

cjp create "your idea"      # 1. Generate plan with Copilot
cjp refine "add mobile app"  # 2. Iterate and improve
cjp export --format csv      # 3. Export for Jira import
cjp jira-sync                # 4. Or push directly to Jira

This entire project was built using GitHub Copilot CLI, and it played a dual role: it was both my development companion throughout the build and the runtime AI engine that powers the tool itself.

The Learning Curve: From Confusion to Clarity

I'll be honest — working with GitHub Copilot CLI effectively didn't happen overnight. It took several runs and iterations to thoroughly understand how to harness its full potential.

The early attempts were rough. My first prompts were vague: "help me build a planning tool" or "create a CLI app." Copilot would give generic advice or boilerplate code that didn't quite fit. I quickly learned that Copilot CLI isn't a mind reader — it's a powerful tool that needs precise direction.

The breakthrough came when I started treating Copilot CLI like a senior developer I was pair-programming with. Instead of "build X," I learned to:

Be specific about constraints: "Build a TypeScript CLI using Commander.js that calls copilot -sp and parses JSON responses"
Describe the context in detail: "I need a function that extracts JSON from Copilot's output, but sometimes it wraps JSON in markdown code fences or adds explanatory text before/after"
Break down complex requests: Rather than "build the whole app," I'd ask for architecture first, then scaffolding, then specific implementations

I also leveraged Copilot's agent capabilities extensively. When I needed to understand the Jira API's Atlassian Document Format, I asked Copilot to act as a Jira API expert and explain the structure. When debugging parsing issues, I described the exact error case and asked it to propose robust extraction logic. Creating these focused "expert agents" in my prompts made Copilot's responses dramatically more useful.

The turning point was realizing that the quality of Copilot's output is directly proportional to the detail you provide. Once I started writing prompts that included:

The exact tech stack and versions
Sample input/output formats
Edge cases to handle
Constraints and requirements

...Copilot would generate production-ready code on the first try. What felt like a limitation at first — having to be so explicit — became a strength. It forced me to think through problems clearly before writing code.

The Meta Story: Copilot CLI Building a Copilot CLI Tool

There's something beautifully recursive about using Copilot CLI to build a tool that wraps Copilot CLI. The key discovery was the -sp flags:

-s (script mode) — gives clean output without terminal UI chrome
-p (prompt mode) — non-interactive, single prompt in, response out

Together, copilot -sp "your prompt" turns Copilot CLI into a programmable AI engine you can call from any application. No API keys, no OpenAI account — just an active Copilot subscription.

How Copilot CLI Helped Build This Tool

The meta twist: I used Copilot CLI to build a tool that wraps Copilot CLI. The copilot -sp (script mode, non-interactive prompt) flag was the key discovery — it lets you invoke Copilot programmatically and capture its structured output, making it perfect as an AI engine inside other CLI tools.

During development, Copilot CLI helped me:

Architecture design — I described the project idea to Copilot CLI and it helped me structure the TypeScript project, suggesting the command/lib/ui separation pattern
Jira API integration — Copilot CLI walked me through the Jira REST API v3 document format (ADF), which saved hours of documentation reading
Prompt engineering — I iterated on the planning prompt through Copilot CLI, testing different instructions to get reliable JSON output with proper Agile structure
Debugging — When the JSON parsing broke on edge cases (code fences in responses, extra text), Copilot CLI helped me write the robust extraction logic

The Technical Integration

The core innovation is using copilot -sp as a programmatic AI engine:

// From src/lib/planner.ts
const child = execFile('copilot', ['-sp', prompt], {
  maxBuffer: 1024 * 1024,
  timeout: 120000,
}, (error, stdout, stderr) => {
  resolve(stdout.trim());
});

This approach means:

No API keys needed — just an active Copilot subscription
100% Copilot-native — no OpenAI, no other AI providers
Same AI that powers the coding agent — you get the full power of Copilot's models

What Surprised Me

The quality of the generated plans was consistently impressive. Copilot understood Agile methodology deeply — it wrote proper user stories ("As a... I want... So that..."), assigned realistic story points using the Fibonacci scale, estimated task durations sensibly, and even generated meaningful acceptance criteria. It felt like having a senior PM/scrum master on call.

Tech Stack

TypeScript with Commander.js for CLI framework
GitHub Copilot CLI (copilot -sp) as the AI engine
Chalk + cli-table3 + Ora for terminal UI
Axios for Jira REST API integration