Bras Basah Complex
A WordPress website redesign for Bras Basah Complex, built as a final year project at Singapore Polytechnic in collaboration with Bras Basah Complex Merchants' Association and Heartland Enterprise Centre Singapore.
WordPress
PHP
MySQL
AWS
React
Overview
A website redesign for Bras Basah Complex built as a final year project at Singapore Polytechnic, collaborating with a team of five. The project was done in partnership with Bras Basah Complex Merchants' Association and Heartland Enterprise Centre Singapore (HECS).
The goal was to attract youth, modernise the complex's digital presence, and improve the CMS — migrating from Wix to WordPress so merchants could manage their own content more easily.
Features
- Interactive floor map with hover and click interactions (replacing a static image)
- Admin-friendly CMS for merchants and staff to manage stories, events, and units
- Merchant directory with individual shop profiles
- Landing page, events, stories, contact, and an interactive floor map directory
What I worked on
- Set up local development environment (XAMPP) and WordPress, including custom plugin for Gutenberg blocks
- Built the interactive floor map, enabling hover and click on floor units
- Configured AWS deployment (EC2 + CloudFront) and linked the domain to the live site
- Set up a staging environment for UAT demos; deployed to production once after final sign-off
- Various pages, including Events, Stories and Floor Map page.
Challenges
Working directly with external stakeholders meant requirements changed frequently. Balancing feedback from multiple parties — merchants, BBCMA, and HECS — while keeping the project on track required clear communication and careful prioritisation.
Reflection
This was my first project involving real clients and external organisations. It taught me how to present work professionally, manage expectations, and translate non-technical feedback into actionable changes. Working within WordPress also gave me a deeper appreciation of what a well-structured CMS can do for non-technical users.
Screenshots
Under the Hood
Architecture
The production site runs on a self-hosted WordPress instance on AWS EC2, served through CloudFront as a CDN layer for caching and HTTPS while the domain remains on Wix DNS. To showcase the website to the client without risking the live site, we utilized an AWS Academy Learner Lab environment provided by the school for user acceptance testing (UAT). Meanwhile, local development was executed on XAMPP (Apache, MySQL, and PHP) so that the team could work independently on individual devices without clashing or disrupting each other's progress.
Technical Deep Dives
Interactive floor map
Each floor unit was mapped individually by extracting SVG coordinates using a tool we made (There are similiar tools online), then stored in WordPress via Pods as a custom content type — each unit has a unit number, floor number, and coordinate set. Clicking a unit triggers a popup pulling that data from the CMS with no page reload.
Custom Gutenberg plugin
We created our plugin using @wordpress/create-block, a package that scaffolds a custom block with all the necessary files and configuration. Each block includes an edit.js for the editor view, a save.js for the frontend output, and a block.json file that defines the block's properties. The plugin uses wp-scripts, which provides JSX and SCSS compilation, bundling, and linting out of the box.
Our current approach to building blocks is either using render.php on its own for blocks that don't require frontend interactivity, or combining render.php with view.js when features like search, filtering, or dynamic UI updates are needed on the frontend.
There is a third approach introduced in WordPress 6.5, released on April 2, 2024: the Interactivity API. Instead of relying on React, it uses a declarative, store-driven model with a shared store across all blocks — making it a more lightweight alternative to loading a React bundle per block. Unfortunately, we did not get to incorporate this into our project, as it was released just two days before our website went live on April 4, 2024.
Process
Followed Scrum across the full project lifecycle, with each sprint covering the same cycle: design in Figma, present to stakeholders for sign-off, implement, then test before the next sprint began. This kept feedback loops short and meant requirements changes were caught early rather than late.
Maintained a backlog, ran regular standups, and reprioritised between sprints based on client feedback from BBCMA and HECS. The admin user guide was written progressively as features were completed, so merchants could start familiarising themselves before handover.
- Figma wireframes + interactive prototype
- Stakeholder sign-off before each build phase
- Scrum sprints: design → review → implement → test
- Test cases written per feature
- UAT on staging before final production deploy
- Admin user guide delivered alongside features