Security, maintenance and technological risks

GOBEL website — Document for the board

Belgian Go Association
June 2026

1. On code generated with AI assistance

Did the AI write it all? Can we trust it?

The AI (Claude, developed by Anthropic) served as anaccelerated development tool, not a decision-maker. Each feature was:

1. Specified by Yannick Kuy (specifications, architectural choices, design decisions)

2. Generated by Claude under direct supervision

3. Reviewed and validated by Yannick before each commit

4. Tested manually (and for the ELO system, via 47 automated tests)

The AI does not deploy anything autonomously. Every line of code in production has been approved by a human. The code produced is standard TypeScript, readable by any web developer, with no dependency on Claude for future maintenance.

How is code control ensured?

• Git (GitHub): complete history of every change with date, description and author

• Each commit is accompanied by a message explaining why the change was made

• The code is hosted on a private GitHub repository — accessible to any developer appointed at a later date

2. Security

2.1 Protection of member accounts

MeasurementDetailsPasswordsHashed with bcrypt (factor 12) — never stored in plain textFailed attemptsAutomatic lockout after 5 failed attempts, unlock after 15 minutesSessionsServer-signed JWT, automatic expiryResetLink via email, valid for 1 hour onlyComplexity requirementsMinimum 8 characters, must include at least one uppercase letter and one number

2.2 Protection of personal data

• Sensitive data (email, phone number, address, date of birth) stored in Supabase (PostgreSQL on AWS eu-central-1, in Europe)

• Vercel (web server) never stores data — it executes the code and passes requests to Supabase

• Transit: HTTPS enforced on all pages, data is never transmitted in plain text

• Secret keys stored exclusively in Vercel environment variables — never in the source code, never in Git

2.3 Access control (principle of least privilege)

Every action on the server checks the role of the logged-in user. A PRESIDENT can only act on members of their club. A MEMBER can only edit their own profile. It is impossible to elevate one’s own rights.

2.4 GDPR

• Deletion request accessible from each member’s profile

• Complete anonymisation: the name becomes “Anonymous Player-xxx”, the email is replaced by a random address, all personal data is deleted

• Sports history (matches, results) is retained — obligation of sporting integrity

• Privacy policy page available on the website (/privacy)

2.5 What is NOT covered (deliberate scope)

• No two-factor authentication (2FA) — deemed disproportionate for a Go federation, but implementable if required

• No external security audit — recommended prior to general public release

3. Maintenance

3.1 Who can maintain this site?

Any full-stack web developer familiar with:

• Next.js (React) — the world’s most popular framework for web applications, used by thousands of businesses

• PostgreSQL — standard relational database

• TypeScript — statically typed JavaScript

The code contains no exotic or proprietary technologies. A competent developer can take it over within a few days of reading through it.

3.2 Security updates

npm dependencies (libraries) may receive security patches. The procedure is:

npm audit # identify vulnerabilitiesnpm update # update minor dependencies

Recommended: check monthly, especially for NextAuth (authentication) and Prisma (DB access).

3.3 Content changes without a developer

The office can make changes without touching the code:

• ✅ News, events, website pages

• ✅ Navigation menu (sidebar)

• ✅ Photos of clubs and tournaments

• ✅ Membership fees, members’ voting rights

• ✅ Tournament results

Requires a developer:

• New features

• Database schema changes

• Infrastructure changes

3.4 Database

Database migrations are versioned in the code (prisma/migrations/). Every schema change is tracked and reproducible. It is possible to revert to any version.

3.5 Backups

Supabase performs automatic daily backups (7-day point-in-time recovery on the free plan). In the event of a serious issue, data can be restored to any state from the last 7 days.

4. Technological risks

4.1 Vercel (hosting)

4.1 Vercel (hosting)

Legal grey area: Vercel’s Hobby plan is strictly reserved for non-commercial projects. A non-profit organisation collecting membership fees is in a legal grey area. Vercel does not actively check, but upgrading to the Pro plan ($20/month) would eliminate this theoretical risk.

4.2 Supabase (database)

4.3 Next.js (web framework)

Next.js is developed by Vercel and used by companies such as TikTok, Twitch, and hundreds of thousands of projects. The risk of it being discontinued is virtually zero. Major updates (every ~18 months) require a migration, which is usually well documented.

4.4 Dependence on the AI assistant for future maintenance

The code does not depend on Claude to function or be maintained. Claude was a development tool, like an IDE or a linter. A human developer can take over the project without ever using AI.

That said, using an AI assistant for future modifications is perfectly feasible — it is now common practice in the industry, including in critical contexts.

4.5 Continuity if the current developer is unavailable

Short term (< 1 month): the site runs on its own, no intervention required for day-to-day operation.

Medium term: any Next.js developer can take over the project. Commits are commented and critical functions (ELO, anonymisation, contributions) are documented. The rest of the code is sparsely commented — a technical report describing the overall architecture is planned to fill this gap.

Transfer of responsibility requires:

1. Access to the GitHub repository (invitation to be sent within < 5 minutes)

2. Access to the Vercel dashboard (invitation via email)

3. Access to the Supabase project (invitation via email)

4. Environment variables (.env file sent securely)

5. Current costs and projections

For a federation of ~500 members, the free limits will not be reached for the next 2–3 years. The most likely scenario for exceeding these limits is Supabase storage if there are a large number of photo uploads from clubs/tournaments.

Option: migration to a persistent server

The current architecture on Vercel uses serverless functions: the server ‘wakes up’ with every request after a few minutes of inactivity, causing a latency of 500ms to 2 seconds on the first visit. This behaviour is inherent to the serverless model and cannot be corrected without changing hosting providers.

For a smooth user experience (< 100ms on all pages), a migration to a persistent server is an option:

OptionPriceLatencyMigration effortVercel (current)€0/year500ms–2s (cold start)—Railway~$5/month100–200ms (no cold start)1–2 daysRender~$7/month100–200ms (without cold start)1–2 days

Supabase remains unchanged in both cases — only the site’s hosting provider changes. The migration can be reversed at any time.

6. Recommendations for the board

1. Entrust maintenance to the current developer (Yannick Kuy) via an annual maintenance agreement. As the project’s author, he knows the entire codebase and can respond quickly to any bugs or changes. A modest monthly fee (to be negotiated) ensures the project’s continuity without having to rely on an external contractor who would first need to familiarise themselves with the code. This is the most effective and least costly solution for the federation.

2. Document access: who has the Vercel, Supabase, GitHub, Resend credentials — and establish a handover procedure in the event of a change, regardless of who is responsible for maintenance.

3. Carry out a security audit (free OWASP ZAP tool) before opening to the general public.

4. Decide on hosting: stay with Vercel (free, ~1s cold start) or migrate to Railway (~$5/month, smooth navigation). See section 5.

5. Set an annual budget covering infrastructure + maintenance:

Document drafted in June 2026 — gobel-site