GDGoC Admin

Google Developer Groups on Campus chapters run workshops, study jams and hackathons all year, and every event ends the same way: each attendee is owed a certificate.

GDGoC Admin is where chapter leaders do that work. A leader designs the certificate once, drops in the attendee sheet, and the platform renders a personalised certificate for every row, emails it from the chapter's own address, and gives each one a public page anyone can use to check it is genuine. A super admin oversees every chapter, and good templates can be shared so a new chapter starts from a design that already works.

At GDG on Campus NCTU, every event meant hours of copy-pasting names into a design file, exporting one certificate at a time, and sending emails by hand. The work grew in a straight line with attendance, so the bigger the community got, the worse it became.

It was also fragile. A typo meant redoing a certificate, designs drifted between organisers, and once a certificate left the inbox there was no way to prove it was real. Every chapter across Egypt was solving the same problem on its own.

• Visual certificate editor: drag, resize, rotate and layer text, images, vector shapes and QR codes on a canvas, Canva-style. Text layers can be dynamic, bound to a variable such as the recipient's name.
• Bulk issuance: import recipients from CSV or Excel, optionally compute cells with spreadsheet-style formulas, and issue the whole batch in one run.
• Direct mail to recipients: branded HTML emails written in a rich-text editor, with variable placeholders, sent through each chapter's own SMTP (manual, Google or Microsoft OAuth) with the certificate attached.
• Public verification: every certificate carries a QR code that opens a public page confirming it, with a proper link preview when shared.
• Dynamic images: personalised social cards and banners rendered on the fly from a single URL with query parameters, with no batch needed.
• Versioned, shareable templates: every save is an immutable version, and templates and email designs can be published for other chapters to clone.
• PDF and PNG output, including a print-safe colour mode.
• Font library: upload custom fonts, with automatic fallback to Google Fonts.
• Roles and audit log: super admins and chapter leaders, whitelist-only sign-up, and a record of who did what.

A monorepo with a Go + Fiber API and a React 19 + React Router v7 single-page app, on PostgreSQL and Redis, shipped as Docker images to AWS ECS via ECR.

• Domain-driven API. Each area (templates, issuance, mail, verification, dynamic images, chapters, users) is its own package with the same handler → service → repository layering.
• Designs as data. The editor, built on Konva, saves a certificate as a JSON scene. Each save is an immutable version, and a batch snapshots the version it was issued under, so an old certificate always renders exactly as it was issued.
• A pure-Go renderer. Certificates are drawn server-side with tdewolff/canvas, handling text, images, gradients, bezier shapes and QR codes with no C dependencies, which keeps the container a small static binary. The same renderer powers certificates and dynamic images.
• Batches off the request path. Issuing a batch hands its ID to an in-process queue that a pool of goroutines drains, sending each email concurrently. Rendering is lazy: a certificate is rasterised the first time it is fetched, then cached, so a big batch never stalls on image work nobody has asked for yet.
• Layered variables. Emails and certificates resolve placeholders in a fixed order: recipient values, then batch-level overrides, then system values such as the certificate ID and verification link.
• Auth by Kayan, a headless identity platform I built, providing OIDC, multi-provider OAuth and role-based access control.

Frontend: Konva, Tiptap, TanStack Query, React Hook Form + Zod, Radix UI, Tailwind CSS. Backend: Fiber, GORM, go-redis, tdewolff/canvas, go-qrcode, gofpdf.

The platform is live in production, used by 20+ GDG on Campus chapters across Egypt, and has issued more than 1,000 certificates so far.

What used to be hours of manual work per event is now one design, one spreadsheet and one click, and every certificate can be verified by anyone who receives it. It is open source, so any chapter organiser can run it or build on it.