BAMREC Platform

Product: BAMREC
Role: Full Stack Developer, frontend focused
Timeline: 2023 to 2026
Project Type: Super admin panel and public website
Stack: React, Next.js, TypeScript, TanStack Query, Ant Design, Firebase, Stripe

Project Overview

BAMREC is a community platform that brings families and local organizations together. Organizations run events, classes, sports leagues, childcare and academic programs. Families find what suits them, sign their kids up and pay online.

I worked on BAMREC for more than three years as a full stack developer, with most of my time spent on the frontend. I built across both of its web apps: the super admin panel, where the team and organizations manage everything, and the public website, where families browse, register and pay.

I was happy to work on the API whenever a feature needed it, but most of my energy went into the screens people use every day.

Key Features

Payments with Stripe, Google Pay and Apple Pay

• Families pay for tickets and programs through Stripe at checkout, by card, Google Pay or Apple Pay
• One cart that handles paid and free registrations in the same flow
• A payment history with filters and pages, so families can find any past payment

Discount codes

• Organizations create discount codes, edit them and switch them off whenever they like
• Families apply a code at checkout and see the new total straight away
• Removing a code puts the original price back instantly

Event creation

• A guided flow, step by step, covering details, venue, schedule, activities and tickets
• A calendar view for planning activities, including ones that overlap
• Admission tickets, drop in pricing and extra ticket options
• Editing an event opens every step with its saved details already filled in

Also on the platform

• Sports leagues with divisions, teams, rounds and games
• Family profiles with authorized adults, allergies and emergency contacts
• Mentor requests with live price estimates
• A news feed with comments, replies and reactions
• Organization onboarding, approval and publishing

My Approach

Reusable components first

Early on I noticed we kept building the same things over and over: tables with filters, form fields, modals, date pickers and ticket cards. Every new screen started almost from scratch, and small differences crept in between pages.

So I started turning these pieces into shared components with clear, simple props. A filter bar, a ticket form or a confirmation modal was built once and then reused across the admin panel and the website.

This changed how fast we could ship. Building a new screen became mostly a matter of putting existing pieces together. A bug was fixed in one place instead of five, and the whole product started to feel more consistent.

Bringing in TanStack Query

Before, each screen fetched its own data by hand and tracked its own loading and error states. That meant a lot of repeated code just to load a list, and screens often showed old data after an update.

I introduced TanStack Query to look after server data. It handles caching, loading states, refetching and pagination for us. After a change, I update the cache directly, so lists refresh in place without another trip to the server.

With TanStack Query owning everything that comes from the server, the result was less code, fewer duplicate requests and screens that stayed up to date.

Tech Stack

Frontend

• React and TypeScript: The super admin panel
• Next.js: The public website, fast to load and easy for search engines to read
• TanStack Query: Server data, caching and pagination
• Ant Design and SCSS modules: Tables, forms, modals and styles kept close to each component

Services

• Stripe: Card, Google Pay and Apple Pay payments at checkout
• Firebase: Sign in, real time chat and hosting
• Google Maps: Venues, addresses and approved locations

Key Technical Challenges

1. A very long event form

Creating an event touches details, venue, schedule, activities and tickets. As one huge form, it was tiring to fill in and easy to lose work. I split it into steps, and each step checks its own required fields before you move on. When an organizer comes back to edit an event, every step opens with what they saved before. Now even complex events can be built a piece at a time.

2. Checkout edge cases

Free tickets, open tickets with schedules and discount codes all broke the normal cart flow in different ways. I handled each case inside the cart itself. Free orders can check out without a card, schedules are checked before purchase, and the total updates the moment a code is added or removed. Families can now finish any registration, paid or free.

3. Dates and times

Events, activities and drop in sessions sometimes showed the wrong time, and a few week views started on the wrong day. I moved everything to one way of storing and formatting dates, and only converted to local time at the very edges. Organizers and families now see exactly the same schedule.

Key Learnings

• Reusable components pay for themselves very quickly
• Let a proper tool own server data instead of writing that plumbing by hand
• Long forms feel lighter when they are broken into steps
• Real users find every edge case, and handling them well is part of the job

Conclusion

BAMREC is where I grew from someone who builds screens into someone who thinks about how a whole frontend fits together.

Three years on one product taught me to own features from start to finish, and that time spent on good foundations comes back many times over.