Case Study · No. 02
BalisongChannel
A newsroom that used to take minutes to load a page, rebuilt to load almost instantly, with a dashboard built for actually running it.
The situation
BalisongChannel was on a slow host, running more than 43 plugins, and it showed: some pages took minutes to load. On top of the performance problem, running a real newsroom from WordPress's default post list gave editors no visibility into how the site was actually doing, no sense of today's traffic, what's sitting in drafts, or whether ad revenue was trending up or down.
What I built
First, the foundation. The site moved off the slow host, and the plugin count came down from over 43 to about 3, with most of what those plugins did rebuilt as purpose-built code instead of general-purpose bloat. Pages that used to take minutes now load almost instantly.
On top of that foundation sits a custom Newsroom dashboard: today's views, the last 7 days, total published articles, drafts and pending review, hosted videos, and new reader inquiries, all in one place. A dedicated Ads panel syncs directly with AdSense, with a daily earnings chart so revenue trends are visible instead of buried in a separate tab.
The site also pulls in live content automatically: a sidebar widget and a dedicated video page auto-fetch the channel's YouTube live broadcasts and latest uploads, checking for a live stream first and falling back to the most recent upload. A weather widget shows each visitor their own local weather, geolocated from their IP, defaulting to Batangas City for anyone visiting from outside the Philippines or if the weather API itself fails.
And every lotto article on the site is generated automatically. BalisongChannel polls LottoNatin's own results feed, and the moment a new draw lands, a full standalone article gets created for it, complete with a generated image of the result, in its own SEO-friendly category.
A real decision
The instinct after a plugin-bloat problem is usually to reach for one more plugin, this time a caching one. Instead, the caching layer was built by hand on top of Cloudflare rather than relying on the host's own LiteSpeed cache: WordPress sends proper cache headers for genuinely static front-end content (and correctly sends none for wp-admin or logged-in requests), Cloudflare edges that HTML for up to two hours, and a targeted auto-purge fires the moment a post publishes or updates, clearing just that post's permalink, the homepage, and its category archive rather than nuking the whole cache. It's the same category of decision as the plugin cleanup: build the few things the site actually needs properly, instead of installing something generic and hoping it behaves.
The Newsroom overview: real traffic, published articles, and drafts, all in one place.
The Ads panel: live AdSense earnings, synced automatically, tracked by day.
The outcome
A real newsroom with over 2,650 published articles and tens of thousands of weekly views, running on a fraction of the plugins it used to carry, loading in a fraction of the time. Editorial, ads, weather, video, and an entire category of auto-generated lotto coverage all run from infrastructure built specifically for this site, not stitched together from other people's plugins.
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."