6 Bugs That Broke a Live Community Platform Overnight — And How We Fixed Them in 2 Hours

"Events aren't working. Server error. Can't login to admin. We have members waiting."

The platform was live. Not in staging. Not in testing. Live — with real members, real data, and real expectations.

This is what happened next.

A UK-based community platform had just done a bulk database import. Shortly after, things started breaking. The admin panel threw a server error on every attempt to schedule an event. A recently created test opportunity had no way to be deleted. And the public-facing counters — the numbers visitors see when they land on the site — were showing zero, even though events had actually happened.

One error message. Six different root causes hiding underneath it.

Here's what we found when we got in:

1. Image upload was silently killing the event save. The admin event form accepted an image, uploaded it — then discarded it with unset($data['image']). When GoDaddy's storage threw an error during that process, it killed the entire save operation. No image, no event. No explanation to the user.

2. Date validation was blocking past events. The create form required start_date to be after_or_equal:today. Logical for future scheduling — but it meant a concluded symposium (March 2026) couldn't be recorded as an event at all. The system was enforcing a rule that made historical records impossible.

3. UK datetime format wasn't being normalised before MySQL insert. Mobile and UK-locale browsers format datetimes as 21/08/2026, 18:30. MySQL expects 2026-08-21 18:30:00. Without normalisation, the insert failed silently — another source of intermittent 500 errors.

4. Empty fields were hitting NOT NULL columns. Price, boolean flags, and created_by could all arrive empty from the form and attempt to insert NULL into columns that didn't allow it. Intermittent failures, hard to reproduce, easy to miss in testing.

5. Yes/No selects were using :value instead of :selected. A small mistake with a visible result — form defaults were wrong. The Event Mode field was showing "Yes" when it should have shown "No." Wrong data, presented confidently.

6. The delete button existed — but was invisible on mobile. The opportunity delete control was a tiny icon squeezed into a 5% column. On mobile, it was essentially invisible. Members had no delete option at all in their own dashboard. The client reported "nothing to delete it" — the function existed, it just couldn't be found.

And the counter issue: the public Events counter was pulling from Event::active()->count() only. The symposium lived on a separate /symposium page — not in the events table — so the counter stayed at zero regardless of what had actually happened.

Admin event creation: past dates now allowed, datetime normalised, image save decoupled from event save, NULL fields handled, Yes/No defaults corrected.

Delete functionality: visible, labelled action button on the admin list; member dashboard now includes delete own opportunity.

Public counters: updated to include the symposium in the Events count without double-counting if a matching event row already exists.

All six issues. One deployment. Under 2 Hours.

The client's response the next morning: 👍

None of these were exotic bugs. No clever attack vector, no obscure framework behaviour. They were edge cases — the kind that don't show up in standard happy-path testing because nobody thinks to try them.

Nobody tested scheduling a past event during QA. Nobody tested the delete button on a mobile screen. Nobody tested what happens when image storage fails mid-save.

The bugs weren't written by a bad developer. They were written by a developer who tested the path that was supposed to work — and didn't test the paths that users would actually take.

After this project, we added a mandatory edge-case audit to every build before it goes to a client:

1. Test every form with missing optional fields.

2. Test file uploads with storage failure simulated.

3. Test all date fields with past dates, future dates, and edge-of-day values.

4. Test every list action (edit, delete) on a mobile viewport.

5. Test all counters with zero records, one record, and historical records.

6. Test all datetime inputs from a UK/mobile locale.

It takes two hours. It has saved us from exactly this situation — more than once.

If your platform is live and you suspect there are bugs hiding in the edges — the flows nobody tests — we offer a production audit as a standalone engagement. Get in touch at neticx.com/contact.