Case Study · No. 04
BAGSIK
A Batangueño art collective that now runs its own membership, marketplace, auctions, community boards and books, without a developer in the loop and without ever opening wp-admin.
The situation
BAGSIK is a community of Batangueño artists. Before this site existed, the group ran the way most local collectives do: membership through a Google Form, announcements through chat threads, and selling work by posting a photo and negotiating in the comments. There was no roster the officers could actually look at, no record of who had paid their dues for the year, and no place to sell a piece where the money and the record of the sale both ended up somewhere accountable.
There was nothing to improve, because there was nothing there. The group needed a platform built for how it already works.
What I built
Around thirty feature modules on a custom loader, each one a self-contained file. Membership is the spine: the group's real application questionnaire rebuilt as a native form, officer review, three roles (member, officer, buyer), public member profiles, and yearly renewals with an officer-configurable fee and grace period.
On top of that sits a marketplace where members list their own artwork and buyers check out with GCash, an auction system started from any existing listing, phpBB-style community boards with topics, replies, polls and upvotes, a document and announcement library, and branded HTML email notifications for every one of those events.
Officers get their own panel: the members roster, and an income and expense ledger that records marketplace income automatically when an order is confirmed. Login and password reset are the site's own, so nobody ever lands on an unbranded WordPress screen. Every uploaded image converts to WebP on the way in.
A real decision
GCash payment is manual, which means there is a window between a buyer saying "I want this" and anyone being able to confirm money arrived. The easy build reserves the artwork the moment the order is placed. I deliberately did not.
Nothing is actually paid during that window, and these are one-of-a-kind pieces. Locking a painting the instant someone clicks checkout lets an abandoned order hold it hostage for as long as the window lasts. So the order lifecycle is two separate steps: place the order, then prove payment. The listing stays available the whole time an order sits awaiting proof, and the real reservation point is proof submission, not checkout.
That tradeoff has two consequences for the buyer, and both are stated plainly on the awaiting-proof page and in their dashboard rather than buried: someone else can still buy the piece out from under an unpaid order, and an order left without proof expires on its own. When proof does arrive, availability is re-checked for every item in the group, and if even one piece sold in the meantime the whole group is cancelled rather than quietly completing a different order than the one the buyer thinks they paid for.
Where to reuse, and where not to
Two choices in the same codebase went opposite ways on purpose. Community replies use WordPress's own comment system, which hands over threading, moderation and edit or delete for free instead of reinventing a reply table. Auctions got their own tables instead, because auction winners can be genuine guests with nothing but a name and an email, and bolting a guest payment path onto the already-tested checkout order table would have risked regressing working money-flow code for no real gain.
The loader underneath all of it is defensive by design. A missing feature file is skipped rather than required, because requiring a path that is not there is an uncatchable fatal in PHP, and a file that breaks while registering its hooks is caught. One typo in one feature cannot take the collective's whole site down.
The outcome
Live at bagsik.art. The officers run membership applications, the roster, renewals, the ledger, the marketplace and the boards themselves, entirely outside wp-admin. Elections are the next phase and already scaffolded in the loader, commented out until the group is ready for them.
It is early for the collective: the roster and the marketplace are both small on purpose while the group onboards its own members. What is finished is the machinery they will grow into.
Tech stack
Need something like this built?
Tell me what your operation actually does all day, and I'll tell you honestly what's worth building. No jargon, no "let's circle back."