Forem: Sharjeel Zubair

I Pushed Our Backend Repo to a Public GitHub by Accident. Here's What Happened in 47 Minutes

Sharjeel Zubair — Sun, 26 Apr 2026 06:01:36 +0000

TL;DR: Leaking real source code (not just .env files) exposes your business logic, internal APIs, hardcoded secrets buried deep in commits, and your auth flow. Bots will find it within minutes. Here's a timeline of what actually happens and how to respond.

The Mistake

I was helping a friend split their monolith into two repos. One was meant to be open-sourced (a CLI tool), the other was their actual backend — payment processing, user data, the works.

I ran:

gh repo create their-org/backend --public --source=. --push

Notice the --public. I meant --private. The CLI didn't ask for confirmation. The repo went live at 14:03.

We caught it at 14:50. Forty-seven minutes. Here's what happened in that window.

Minute 0–2: GitHub's Indexers Wake Up

Within seconds, GitHub's search index picked it up. The repo was indexed and searchable by keyword. This matters because a lot of secret-scanning bots don't crawl GitHub directly — they query the search API for patterns like AWS_SECRET_ACCESS_KEY or Bearer eyJ.

GitHub's own secret scanning ran almost immediately. We later got two automated emails from AWS and Stripe saying our keys had been auto-revoked because GitHub notified them. That's the only reason this story isn't worse.

Minute 2–10: The Bots Arrive

We checked the repo's traffic graph after the fact. In the first 10 minutes there were clones from 14 unique IPs. None of them were us.

These are scrapers. They don't read your code — they git clone --mirror, then run tools like trufflehog and gitleaks against the entire history. Not just the current commit.

That's the part most people miss. You can git rm a secret and push, but if it was ever committed, it's in the pack files. A scanner will find it:

trufflehog git file://./backend --only-verified

In our case, an old commit from 2022 had a hardcoded Postgres connection string for a now-defunct staging DB. The bot found it. The DB was offline so nothing happened, but the credential is now in someone's database forever.

Minute 10–30: Business Logic Exposure

This is the part nobody talks about. Even if you have zero secrets in your code, leaking the source itself is bad.

What we exposed:

Webhook signature verification logic. Anyone could now see exactly how we validated Stripe webhooks and look for bugs in our implementation.
Rate limiting rules. The exact thresholds and the redis keys we used.
Internal API routes that weren't documented anywhere public, including admin endpoints behind a "secret" path.
The promo code generation algorithm. It was deterministic based on user ID. Oops.

Here's a sanitized version of what was sitting in utils/promo.js:

function generatePromoCode(userId, campaign) {
  const hash = crypto
    .createHmac('sha256', PROMO_SECRET)
    .update(`${userId}:${campaign}`)
    .digest('hex');
  return hash.slice(0, 8).toUpperCase();
}

PROMO_SECRET was in env, fine. But the algorithm being public means an attacker who later gets just the secret (from a different leak, a former employee, anything) can generate unlimited promo codes for every user.

Security through obscurity is not security — but losing obscurity does shift your threat model. You should know it shifted.

Minute 30–47: The Discovery and Panic

A teammate noticed the repo was public when they got a GitHub notification ("Your repo is now visible to..."). The next 17 minutes were chaos. Here's the order we did things in, which in retrospect was mostly right:

Make the repo private immediately. Don't delete it yet — you'll want the audit trail.
Rotate every secret in the codebase, even ones not flagged. Database passwords, API keys, JWT signing keys, webhook secrets, OAuth client secrets.
Invalidate all active sessions. If your JWT signing key changed, this happens automatically. If you use server-side sessions, flush them.
Check audit logs on AWS, Stripe, GitHub, your DB. Look for unusual API calls in the leak window and the next 24 hours.
Then you can delete the repo or scrub history if you want — but assume the code is already cloned.

What I Wish We Had

A pre-push hook that screams when you're about to push to a public remote. Something like:

#!/bin/sh
# .git/hooks/pre-push
remote_url=$(git remote get-url "$1")
visibility=$(gh repo view "$remote_url" --json visibility -q .visibility 2>/dev/null)

if [ "$visibility" = "PUBLIC" ]; then
  echo "⚠️  You are pushing to a PUBLIC repo: $remote_url"
  echo "Type 'yes-public' to continue:"
  read confirmation
  [ "$confirmation" = "yes-public" ] || exit 1
fi

Also worth setting up:

GitHub org policies that require admin approval to create public repos.
Pre-commit secret scanning with gitleaks so secrets never enter history in the first place.
Branch protection even on main, so a force-push can't accidentally publish private branches.

The Takeaway

Leaking source code is not a binary "did you leak secrets or not" event. The real damage is:

Historical secrets in old commits you forgot about.
Business logic that informs future attacks even after you rotate.
Internal endpoints and assumptions about what's "hidden."

Assume any public push, even for 60 seconds, has been mirrored. Rotate everything. Audit everything. And put a hook on your machine before you trust yourself with --public.

Vibe Coding Is Burning You Out Here's What's Actually Happening to Your Brain

Sharjeel Zubair — Thu, 23 Apr 2026 16:56:34 +0000

TL;DR: Vibe coding (riffing with an LLM at high speed) feels productive, but it runs your brain at a sprint pace for marathon hours. The dopamine-fast feedback loop drains glucose, spikes cortisol, and wrecks your sleep. Here's the physiology, plus concrete habits and a few scripts to slow the loop down.

The war story

Last month I shipped a side project in a weekend. Fourteen hours on Saturday, twelve on Sunday, mostly prompting Claude and accepting diffs. Monday morning I couldn't remember variable names in my day job codebase. My resting heart rate was up 8 bpm for a week. I wasn't "tired" — I was cooked.

I thought I was being lazy. I wasn't. I was experiencing the cost of sustained high-velocity cognitive flow with almost zero rest cycles.

Why vibe coding hits different

Traditional coding has natural pauses: you read docs, you think, you type, you debug. Those gaps are micro-recovery windows for your prefrontal cortex.

Vibe coding collapses all of that:

Prompt → diff → accept/reject → prompt again. Cycle time: 10–30 seconds.
Every accepted diff = small dopamine hit (variable reward schedule, like a slot machine).
Every rejected diff = micro-frustration + immediate retry.
No natural "I need to go read the docs" break.

Your brain runs on ATP, and the prefrontal cortex is expensive. Sustained decision-making depletes glucose and increases glutamate buildup in the anterior cingulate cortex — which is literally what "mental fatigue" is, per Wiehler et al., 2022 (Current Biology).

Translation: fast decisions × high volume = neurotoxic byproducts faster than your brain can clear them.

The symptoms, ranked

From my own logs and conversations with other devs doing a lot of AI-pair work:

Eye strain + tension headaches (you stopped blinking, you stopped moving)
Decision fatigue leaking into non-coding life ("what do you want for dinner?" → paralysis)
Poor sleep despite exhaustion — elevated cortisol from extended focus
Reduced code comprehension when reading non-AI-generated code
"Shallow mastery" — you shipped it but couldn't re-derive it

What to actually do

1. Enforce a hard cycle timer

The pomodoro is fine but too long for vibe coding. I use 25-on / 5-off minimum, but for heavy LLM sessions I drop to 20/7. Here's a dead-simple terminal timer:

import time, subprocess

def notify(msg):
    # macOS; use notify-send on Linux
    subprocess.run(["osascript", "-e", f'display notification "{msg}"'])

while True:
    notify("Code block: 20 min")
    time.sleep(20 * 60)
    notify("BREAK. Stand up. Look at something 20ft away.")
    time.sleep(7 * 60)

The break rule: leave the chair. If you stay seated you will "just finish this one thing" and the break is gone.

2. The 20-20-20-20 rule (I added one)

Standard: every 20 minutes, look at something 20 feet away for 20 seconds.

My addition: 20 slow breaths before starting a new prompt chain. This resets your sympathetic nervous system from "slot machine" mode.

3. Separate "generate" and "understand" sessions

The mistake I made: accepting code and immediately prompting for the next thing. Instead, batch it:

Session A (30 min): Vibe, generate, accept diffs fast.
Session B (30 min): Read every line. Rename things. Add comments.
                    No AI. No generation.

Session B uses a different cognitive mode (analytic vs. generative) and actually feels restful compared to pure vibe mode. It also catches the bugs you'd ship otherwise.

4. Pre-commit friction

Add a pre-commit hook that makes you summarize what you did. This forces consolidation into long-term memory:

#!/bin/sh
# .git/hooks/prepare-commit-msg
echo "# What did this change actually do? (3 bullets)" >> "$1"
echo "# Why? (1 sentence)" >> "$1"

If you can't fill it out, you didn't understand the code. Back to Session B.

5. Hydrate and fuel for the actual workload

Your brain burns ~20% of your resting calories. When it's sprinting, more. Dehydration of even 2% measurably reduces cognitive performance (Adan, 2012).

My desk rules during vibe sessions:

500ml water within reach, refill every break
Protein + fat snack every 2 hours (nuts, cheese) — not sugar
Caffeine cutoff 8 hours before sleep (not 6, not 4 — 8)

6. Body > mind tricks

The cheapest stress dump I've found: box breathing between prompts.

4s inhale → 4s hold → 4s exhale → 4s hold
Repeat 4 times.

Sounds stupid. Works. Navy SEALs use it, and it directly lowers cortisol via vagal activation. Do it while the LLM is streaming its response — free time.

7. Log your sessions

This one surprised me. I started logging vibe sessions:

date: 2024-11-08
duration: 3h20m
prompts: ~85
subjective_fatigue (1-10): 8
quality_of_output (1-10): 5
sleep_that_night: 6h, fragmented

After two weeks the pattern was obvious: anything over 2.5 hours of continuous vibe coding gave me negative ROI. Quality dropped, fatigue spiked, sleep tanked. I now cap it.

The takeaway

Vibe coding isn't free velocity. You're borrowing focus from tomorrow to ship today. That's fine occasionally — it's a disaster as a default.

Treat high-speed AI coding sessions like sprinting, not jogging: short, intense, with real recovery between. Your 40-year-old self will thank you, and honestly, your code next Tuesday will too.

Vibe Coding Vs New Generation of coders

Sharjeel Zubair — Wed, 22 Apr 2026 08:49:00 +0000

I Watched a 14-Year-Old Ship a Working App Without Reading a Single Line of Docs

TL;DR: The new generation isn't learning to code the way we did — they're learning to direct code. AI and "vibe coding" have flipped the loop from syntax-first to outcome-first, and it's producing wildly different skill profiles: faster shippers, weaker debuggers, and a new class of problems nobody taught in CS 101.

The Moment It Clicked for Me

My nephew wanted a Chrome extension that blurs Instagram Reels after 10 minutes of scrolling. He's 14. He's never written JavaScript.

Two hours later, he had a working extension. He used Cursor, prompted in plain English, accepted most suggestions, ran into a CORS error, pasted the error back in, and got a fix. Shipped.

When I asked him what addEventListener does, he shrugged. "The AI handles that part."

That's vibe coding in a nutshell — and it's how a huge chunk of Gen Z and Gen Alpha are entering the craft.

What "Vibe Coding" Actually Means

The term got popularized by Andrej Karpathy, but the practice is older. You describe what you want. You run it. If it breaks, you paste the error back. You barely look at the code.

Here's the classic loop a self-taught teen runs today:

1. Describe the thing in English
2. Accept the generated code
3. Run it
4. Paste the error (if any) back into the chat
5. Repeat until it works
6. Ship

Compare that to how most of us learned:

1. Read a tutorial for 3 hours
2. Type code character-by-character
3. Hit a bug
4. Read Stack Overflow for 45 minutes
5. Understand why
6. Fix it
7. Ship eventually

Both produce working software. They produce very different programmers.

What They're Getting Good At

1. Systems thinking and product sense, early.

When syntax isn't the bottleneck, kids spend their mental budget on what to build. I see 16-year-olds arguing about auth flows and rate limiting before they know what a for-loop looks like.

2. Prompt decomposition.

The good ones have learned that "build me a todo app" gets slop, but this works:

Build a todo app with:
- SQLite via better-sqlite3
- Express server on port 3001
- Endpoints: GET /todos, POST /todos, DELETE /todos/:id
- Return JSON, no HTML
- Use prepared statements

That's a skill. It's basically writing a spec. The old generation called this "requirements engineering" and charged $200/hr for it.

3. Reading code faster than writing it.

Since the AI dumps 80 lines in front of them constantly, they learn to skim code. They pick out what matters. They recognize patterns without memorizing syntax.

What They're Losing

This is where it gets uncomfortable.

Mental models of execution. When I ask a vibe coder to trace what happens when you type fetch('/api') in the browser, I often get silence. They've never needed to know. Until the day they do.

Debugging without a copilot. Try this test: unplug the AI and give them a bug like:

def get_user(users, user_id):
    for user in users:
        if user['id'] == user_id:
            return user
    return None

# Later...
user = get_user(users, "42")
if user:
    print(user['name'])
# KeyError sometimes, None sometimes. Why?

A traditional learner will check types ("42" vs 42), inspect the data, narrow it down. A pure vibe coder will paste the whole thing into ChatGPT. That works — until the bug is in business logic the AI doesn't know about, and then they're stuck.

The "why" of abstractions. Why is useEffect the way it is? Why do we have async/await instead of just callbacks? That history carries wisdom. Skipping it means repeating mistakes — I've watched new devs reinvent jQuery-era antipatterns in React, confidently.

A Concrete Pedagogy Shift

Good bootcamps and CS programs are adapting. Here's a pattern I've seen work:

Week 1: Build something cool with AI. Ship it. Feel the dopamine.
Week 2: Now rebuild ONE component of it by hand. No AI.
Week 3: Break your own code. Fix it without AI.
Week 4: Read the AI's output and annotate what each line does.

This flips the old "fundamentals first, projects later" model. Motivation comes first, mechanics come second. And honestly? It might work better for a lot of brains.

The New Baseline Skill: Verification

The single most important skill for a vibe-native coder is verifying AI output. Not writing code — checking it.

I now teach juniors this habit:

// The AI gave me this. Before I trust it, I ask:
function sanitizeInput(str) {
  return str.replace(/<script>/gi, '');
}

// 1. What does this NOT catch?
//    <SCRIPT >, <script src=...>, <img onerror=...>, etc.
// 2. Is there a stdlib or battle-tested lib for this?
//    Yes: DOMPurify. Use that.
// 3. Why did the AI suggest the naive version?
//    Because it pattern-matched the shallow intent.

That three-question habit — what does it miss, is there a better tool, why did it pick this — is the new fundamentals.

The Takeaway

Vibe coding isn't "real coding's" lazy cousin. It's a different entry point producing a different shape of engineer. Faster at shipping, better at product, weaker at fundamentals, totally dependent on tools that didn't exist five years ago.

The ones who'll thrive aren't the purists refusing AI, or the vibe-only coders who can't debug. They're the kids who can ship fast and drop into the machine when it matters.

If you're mentoring someone new right now: don't take the AI away. Teach them to interrogate it.

Porting a US Stock Trading App to the Saudi Market -What Actually Broke

Sharjeel Zubair — Wed, 22 Apr 2026 08:32:34 +0000

Last month I forked my US trading platform (Dawul Trader) to build a Saudi equivalent for the Tadawul exchange. I assumed it'd be a branding-and-data-source swap. A weekend, maybe.

It took longer than that. Here's what the "just change the data feed" plan actually looked like in practice, and the five things I didn't see coming.

The stack

Same as the US version, because I wanted the ports to evolve independently without a shared-package dance:

Backend: Python / FastAPI, Anthropic SDK for AI analysis
Frontend: React 19, Vite, Tailwind
Indicators: ta for RSI/MACD/EMA/VWAP
Data: Twelve Data REST + a Laravel MySQL DB (existing Saudi equity data)

Gotcha #1 — Your data vendor probably doesn't cover Saudi

My US version used Alpha Vantage. I was ready to flip an env var and call it done. Alpha Vantage has zero Tadawul coverage. Neither does yfinance in any reliable way.

Twelve Data does, but you have to pass exchange=SAU explicitly — otherwise their symbol resolver happily gives you an unrelated ticker from another market. Stock 2222 is Aramco on Tadawul and something completely different on a dozen other exchanges.

def _td_macd(symbol, interval="1day"):
    d = _td_get("macd", {
        "symbol": symbol,
        "exchange": "SAU",            # <-- critical
        "interval": interval,
        "fast_period": macd_fast,
        "slow_period": macd_slow,
        "signal_period": macd_signal,
        "outputsize": 2,
        "format": "JSON"
    })
    ...

If you're building on Twelve Data for Saudi, bake exchange=SAU into every single endpoint call. I lost an afternoon debugging "correct numbers for the wrong company."

Gotcha #2 — No options market

Tadawul has no equity options. The entire Options Chain page, all the options strategies, the expiration logic — dead code in the Saudi version. I'd built a lot of UI around a feature that simply doesn't exist for these users.

Lesson: when porting, audit your feature list against what the target market actually trades before you migrate the code. I could have skipped two days of ripping out dependencies if I'd mapped this first.

Gotcha #3 — SELL signals in a long-only market

My US screener outputs BUY, SELL, and NO TRADE. Easy call on NYSE — retail users can short with a click.

Tadawul is effectively long-only for retail. Naked shorting is heavily restricted. So when I initially ported the screener, I considered stripping SELL entirely and labeling bearish setups as NO TRADE.

I pushed back on that when a user asked: "why no sells?" The answer is nuance — a SELL signal isn't useless in a long-only market; it just means something different:

On NYSE: "Consider a short entry."
On Tadawul: "Exit longs / don't enter here."

So I kept the detection logic but reframed the UI copy and made sure the signal was visible:

// Strategy2.jsx — SELL badge coexists with BUY
if (signal === "BUY")  return <Badge color="green">BUY</Badge>;
if (signal === "SELL") return <Badge color="red">SELL</Badge>;
return <Badge color="gray">NO TRADE</Badge>;

The backend mirrors bullish filters into bearish ones:

buy_ok = True
sell_ok = True

if use_macd:
    if macd_line > 0:
        sell_ok = False              # bullish -> block SELL
        reasons.append("MACD bullish")
    elif macd_line < 0:
        buy_ok = False               # bearish -> block BUY
        reasons.append("MACD bearish")
    else:
        buy_ok = sell_ok = False     # near-zero -> no trade

# Priority: BUY > SELL > NO TRADE
signal = "BUY" if buy_ok else "SELL" if sell_ok else "NO TRADE"

Same code, different semantics at the UX layer. Worth the extra 30 lines.

Gotcha #4 — Numeric tickers + Arabic names + RTL

US tickers are letters (AAPL, MSFT). Saudi tickers are numbers (2222, 1120, 7010). That sounds trivial — it breaks a surprising amount:

Any regex you wrote assuming [A-Z]{1,5} on ticker input.
URL params that look nothing like tickers (/stock/2222 reads like a product ID).
Users recognizing companies. Nobody in Riyadh thinks "2222," they think "أرامكو السعودية."

I wired Arabic names in alongside the numeric code, and let React handle direction:

<div className="flex flex-col">
  <span>{r.symbol}</span>
  {stockNames[r.symbol]?.name_ar && (
    <span style={{ direction: "rtl", fontWeight: 600 }}>
      {stockNames[r.symbol].name_ar}
    </span>
  )}
</div>

The direction: "rtl" on just the Arabic span — not the whole page — is the move. Full-page RTL breaks every Tailwind utility I had.

Gotcha #5 — The market calendar

Saudi trades Sunday through Thursday, 10:00–15:00 AST. Every "is market open?" helper I'd written assumed weekday = Mon–Fri. Every "next trading day" calculation was wrong. Every cron that ran at US market open fired on Saudi lunch.

Don't hard-code weekends. Read them from the exchange config:

SAUDI_TRADING_DAYS = {6, 0, 1, 2, 3}   # Sun=6, Mon=0, ..., Thu=3 (Python weekday)
SAUDI_HOURS = (time(10, 0), time(15, 0))

One small UX win

After the SELL work shipped, I got asked a second time: "can I just copy all the BUYs to paste into my broker?"

Two-line change. The count pill becomes a button; click it, symbols hit the clipboard comma-separated:

async function copySignalSymbols(sig) {
  const syms = (results || []).filter(r => r.signal === sig).map(r => r.symbol);
  await navigator.clipboard.writeText(syms.join(","));
  setCopied(sig);
  setTimeout(() => setCopied(null), 1500);
}

Takes 30 seconds to write and users immediately noticed. Most satisfying kind of feature.

What I'd tell past me

Pick your vendor before you write any code. Data source constraints cascade everywhere.
Audit the market's feature surface, not your app's. Options, shorting, ETFs, fractional shares — all vary.
Don't strip signals, reframe them. A bearish signal is useful in every market; only the recommended action changes.
Localization is not translation. Numeric tickers, RTL text, calendar, currency, decimal format — each is its own ticket.
Ship the tiny UX requests. Clicking a count to copy symbols is the kind of thing users remember.

If you're thinking about porting a trading tool to a new market, start with the calendar and the vendor. Everything else is downstream.

GDPR Erasure Is Not DELETE FROM users

Sharjeel Zubair — Wed, 22 Apr 2026 08:25:17 +0000

When a parent on our school platform submits a deletion request, an administrator approves it, and our server runs one function — anonymiseContact($contactId). That function took five attempts to get right.

This post is about what makes Article 17 of the GDPR (the "right to erasure") genuinely difficult to implement, the decision tree we eventually settled on, and the specific failure modes we hit along the way. The code is Laravel and Postgres, but the decisions are universal.

The naive implementation

The obvious first draft of "delete a user's personal data" is a single SQL statement:

RosterContact::where('id', $contactId)->delete();

There are three separate reasons this will fail or fail-you-later. Each points at a different design decision.

Problem 1: the NOT NULL foreign key trap

Our students table has this column:

$table->unsignedBigInteger('roster_contact_id'); // NOT NULL

Calling Student::where('roster_contact_id', $contactId)->update(['roster_contact_id' => null]) before deleting the contact produces:

SQLSTATE[23502]: Not null violation: 7 ERROR: null value in column
"roster_contact_id" of relation "students" violates not-null constraint

Every table that references the contact has the same problem: issues, leave_requests, consent_responses, meeting_bookings, students. A naive cascading delete would wipe all of them — which is wrong, because the school owns those records and is legally required to keep them (attendance history, complaint records, consent audit trail).

The fix is to make roster_contact_id nullable on every downstream table:

Schema::table('students', function (Blueprint $table) {
    $table->unsignedBigInteger('roster_contact_id')->nullable()->change();
});
// ... same for leave_requests, consent_responses, meeting_bookings

Only then can you null the link while keeping the row.

Problem 2: the four-way decision

Once the FKs are nullable, every table the user touched needs a deliberate decision. There are four possible outcomes, not two:

Outcome	When to use it	Example
Hard delete	Data has no value after erasure and belongs exclusively to the user	Access codes, push-notification tokens
Anonymise (keep the row, strip PII)	Data has operational or audit value but shouldn't identify the user	The contact record itself, messages authored by the user
Detach (null the FK, keep the row)	Data belongs to a different party (the school, the platform) but was linked to the user	Issues, leave requests, consent responses
Retain (untouched)	Data was never directly identifying	CSAT ratings linked via issue, aggregate metrics

For our platform, the decision matrix looks like this:

Access codes           → hard delete
Push tokens, device ID → null out (PII)
Contact record         → anonymise (name → "Deleted Contact", PII nulled)
Issue messages         → anonymise (null author_id, replace meta.actor_name)
Activity log entries   → anonymise (scrub contact_name in JSON payload)
Issues, leaves,
consents, bookings     → detach (null roster_contact_id, keep row)
Students               → detach (school owns the student record)
CSAT responses         → retain (never carried direct PII)

This matrix is worth publishing for your own users. Under Article 15 (right of access) and Article 30 (records of processing), a data subject can ask what happens when they exercise erasure. A vague "we delete your data" is not a satisfactory answer.

The implementation

Here is the core of anonymiseContact(), simplified. Note the order of operations and the transaction boundary:

private function anonymiseContact(int $contactId): void
{
    $tenantId = tenant('id');
    $contact  = RosterContact::where('id', $contactId)->first();
    if (! $contact) {
        return;
    }

    $actor  = auth()->user(); // the admin who approved
    $school = School::where('tenant_id', $tenantId)->first();

    // 1. Collect attachment file references BEFORE deleting rows
    $attachmentFiles = IssueAttachment::whereHas('issue',
        fn ($q) => $q->where('roster_contact_id', $contactId)
    )->get(['disk', 'path'])->all();

    // 2. Auto-close open issues + unassign (housekeeping — see below)
    $this->autoCloseOpenIssues($contactId, $actor);

    // 3. Cancel future meeting bookings
    $this->cancelFutureBookings($contactId, $actor);

    // 4. Core anonymisation inside a transaction
    DB::transaction(function () use ($tenantId, $contactId, $contact) {
        // Hard-delete access codes (no value after erasure)
        AccessCode::where('roster_contact_id', $contactId)->delete();

        // Anonymise messages authored by this contact
        IssueMessage::where('author_type', RosterContact::class)
            ->where('author_id', $contactId)
            ->each(function (IssueMessage $m) {
                $meta = $m->meta ?? [];
                if (isset($meta['actor_name'])) {
                    $meta['actor_name'] = 'Deleted Contact';
                }
                $m->update([
                    'author_id'   => null,
                    'author_type' => null,
                    'meta'        => $meta,
                ]);
            });

        // Scrub contact name from activity log payloads
        IssueActivity::whereIn('issue_id', Issue::where(
            'roster_contact_id', $contactId
        )->pluck('id'))->each(function (IssueActivity $a) {
            $data = $a->data ?? [];
            if (isset($data['contact_name'])) {
                $data['contact_name'] = 'Deleted Contact';
            }
            $a->update(['data' => $data]);
        });

        // Detach — null the FK on downstream records
        Issue::where('roster_contact_id', $contactId)
            ->update(['roster_contact_id' => null]);
        LeaveRequest::where('roster_contact_id', $contactId)
            ->update(['roster_contact_id' => null]);
        ConsentResponse::where('roster_contact_id', $contactId)
            ->update(['roster_contact_id' => null]);
        MeetingBooking::where('roster_contact_id', $contactId)
            ->update(['roster_contact_id' => null]);
        Student::where('roster_contact_id', $contactId)
            ->update(['roster_contact_id' => null]);

        // Finally, anonymise the contact itself
        $contact->update([
            'name'            => 'Deleted Contact',
            'email'           => null,
            'phone'           => null,
            'external_id'     => null,
            'expo_push_token' => null,
            'device_platform' => null,
            'meta'            => null,
            'deactivated_at'  => now(),
            'revoke_reason'   => 'erasure_request',
        ]);
    });

    // 5. Delete attachment files from disk AFTER the DB commits
    foreach ($attachmentFiles as $f) {
        try {
            Storage::disk($f['disk'])->delete($f['path']);
        } catch (\Throwable $e) {
            // Orphaned file is safer than a ghost DB row. Log and move on.
            Log::warning('Attachment delete failed', [...]);
        }
    }
}

There are four non-obvious decisions in this code.

File cleanup happens outside the transaction

Deleting a file from disk is not transactional. If the DB commits and the Storage::delete() call fails, you have an orphaned file — annoying but recoverable. If the DB is still mid-transaction and the file deletion succeeds but the DB then rolls back, you have a ghost DB row pointing at a non-existent file — user-visible errors and harder to clean up.

We favour the first failure mode. Orphaned files can be swept out-of-band; ghost rows break UI.

Attachment paths are collected before the transaction

Inside the transaction we run the DELETE on issue_attachments. That removes the rows we would otherwise query for their disk paths. Collecting paths before the transaction runs means we still have the list when the DB part succeeds.

Auto-housekeeping is separate from anonymisation

When a contact is erased, their open issues should close, their future meeting bookings should cancel, and their staff assignments should release. We do this before the anonymisation transaction, attributed to the approving admin, so each auto-close emits its own activity-log entry with a clear actor and a close_reason: contact_erased flag.

If we did it inside the anonymisation, the actor on those closures would end up as null or "Deleted Contact", which is an audit trail that says "something happened to an issue but no one did it." That's the opposite of what you want in a compliance artefact.

Retry semantics matter

Our first deployment of anonymiseContact() crashed on the NOT NULL FK described earlier. The DB transaction rolled back cleanly, but our DataPrivacyRequest row ended up flagged failed with the error message stored.

We added two flags to the admin UI:

Failed requests show a "Retry & execute" button instead of "Approve & execute"
The approve action accepts both pending and failed statuses

After fixing the schema (making FKs nullable), the admin clicked Retry and the request completed. Without that retry affordance, every fix would have required manual DB editing or asking the parent to submit a fresh request — both are terrible UX for the one operation that must feel exact.

What stays forever

One counterintuitive part of GDPR erasure: the record that an erasure happened must itself be kept.

We keep three types of records indefinitely:

The data_privacy_requests row — with the contact's name and email captured at request time. This is the compliance evidence.
A privacy_erasure activity-log entry — summary of what was erased (issues closed, bookings cancelled) attributed to the approving admin.
Backup snapshots that predate the erasure — these age out on their own 90-day rotation, but until they do, the PII is still in them. That's worth disclosing in your DPA.

Supervisory authorities under Article 33 expect to see records of requests and their handling. A user asking "when did you delete me and who approved it?" is a legitimate question with a legitimate answer: "on this date, by this admin, here's the evidence."

Publishing the decision tree

Every word of the matrix above is now in our user-facing Privacy Policy, under a subsection titled "What happens when your erasure request is approved." Publishing it serves three purposes:

Users exercising the right get a realistic expectation
Auditors reading the policy see the engineering has substance
It forces internal clarity — you cannot publish what you haven't decided

If you are about to implement Article 17, do not start with the code. Start with the decision matrix, write it in user-facing language first, and let the code follow. The five attempts we took were largely about failing to do this in the right order.

Summary

GDPR erasure is an engineering decision with four outcomes per data type, not a binary one. The implementation needs nullable foreign keys, a deliberate order of operations, transaction boundaries that correctly separate DB and storage, separate housekeeping for operational side-effects, retry semantics for failure recovery, and an indefinite audit trail of the erasure itself. The naive DELETE FROM users produces the wrong legal outcome, the wrong operational outcome, and the wrong audit outcome at the same time.

Write the matrix first. Then write the code.

A Dashboard for developers! https://spiffy-palmier-f0c5af.netlify.app/ #health #focus

Sharjeel Zubair — Tue, 14 Apr 2026 11:09:04 +0000

spiffy-palmier-f0c5af.netlify.app

I Built a Multi-Tenant School Helpdesk in Laravel — Here's the Full Stack

Sharjeel Zubair — Tue, 14 Apr 2026 10:28:12 +0000

I open-sourced a production-grade, multi-tenant SaaS last week. Here's a tour of what's inside — and every non-obvious architecture decision along the way.

Meet Schoolytics

Schoolytics is an open-source helpdesk for schools. One platform runs an entire district — each school is isolated by subdomain, runs its own branded portal, and has its own users, issues, and CSAT data.

Think Zendesk meets Linear meets a parent-teacher app — MIT-licensed, self-hostable, and free forever.

🏫 Multi-tenant — one deploy, unlimited schools, subdomain-isolated
🔑 Passwordless parent portal — one-time access codes, no app, no account
🤖 AI triage — Python sentiment microservice scores every issue on submission
🧑‍💼 Three-tier RBAC — admin / branch manager / staff, enforced in queries AND policies
📧 Full email stack — transactional mails, in-app notifications, CSAT surveys
🎛 Nova super-admin — provision a new school (tenant + domain + admin + 10 categories + demo data) with ONE click

The stack

Layer	Choice	Why
Framework	Laravel 12 / PHP 8.2	Fastest iteration, Nova, first-party queue/mail/auth
DB	PostgreSQL 16	Row-level multi-tenancy, case-insensitive `ilike`, check constraints
Multi-tenancy	stancl/tenancy v3	Battle-tested, subdomain-based, row-level scoping
RBAC	Spatie Permission (teams mode)	Team-scoped permissions = tenant-scoped for free
Super-admin	Laravel Nova	Built-in resource CRUD, custom actions for provisioning
Frontend	Blade + Alpine + Tailwind + ECharts	No SPA overhead, ships fast, renders on the server
Queue	Database driver (dev), Redis/SQS (prod)	One less moving piece locally
AI	FastAPI (Python)	Isolated, swappable, doesn't bloat Laravel

The interesting decisions

1. Two auth guards, zero overlap

Most multi-tenant apps put super-admins in the same users table with a is_superadmin flag. That's a mistake the first time a bug lets a tenant query return a central user.

Schoolytics has two completely separate models:

// Guard: central → entry: /nova
class CentralUser extends Authenticatable { /* table: central_users */ }

// Guard: web → entry: /admin/login (tenant subdomain)
class User extends Authenticatable {
    use BelongsToTenant, HasRoles;
    // table: users (row-level tenant_id)
}

CentralUser can't have Spatie roles (teams mode requires a tenant context), so the IssuePolicy has a before() hook:

public function before(?Authenticatable $user): ?bool
{
    if ($user instanceof CentralUser) return true; // full access
    return null; // fall through to normal policy methods
}

Two guards. Zero cross-contamination. Superadmin can debug anything without ever needing a tenant role.

2. Row-level multi-tenancy, enforced twice

Every tenant-scoped model uses a BelongsToTenant trait that:

Adds a global scope filtering WHERE tenant_id = tenant('id')
Auto-fills tenant_id on creating

But I don't trust global scopes alone. For sensitive actions I also do an explicit check:

abort_unless($issue->tenant_id === tenant('id'), 404);

Defense in depth. If someone ever calls withoutGlobalScopes() by accident, the explicit check still catches it.

3. Passwordless parent flow

Parents aren't technical. They don't want accounts. They lose passwords. So:

Admin imports roster contacts (CSV/Excel)
System generates an AccessCode, emails/SMSes it
Parent visits schoola.domain.com, enters code, submits their issue
Only one open issue per contact at a time (enforced by a non-closed-issue lookup)
On issue close, access_code.used_at is reset — parent can submit again with the same code

The UX is identical to a "magic link" but synchronous and auditable.

4. Role-scoped queries in ONE place

Three roles see three different slices:

admin — every issue in the tenant
branch_manager — issues in branches they manage
staff — only issues assigned to them

One query scope handles all of it:

public function scopeVisibleTo(Builder $q, User $user): Builder
{
    if ($user->hasRole('admin')) return $q;

    if ($user->hasRole('branch_manager')) {
        return $q->whereIn('branch_id', $user->branches->pluck('id'));
    }

    return $q->where('assigned_user_id', $user->id);
}

Every Issue::query() in every controller calls ->visibleTo(auth()->user()). Forget it once, and the policy still blocks the action. Two layers.

5. AI triage via a separate microservice

When a parent submits an issue, a queued listener POSTs to a FastAPI service:

Laravel  ──event──► PerformAiAnalysis (queued)  ──HTTP──►  Python FastAPI
                                                               │
                                                               ▼
                                                  {sentiment, category, confidence}
                                                               │
                                                               ▼
                                                  IssueAiAnalysis row

Why separate? Because:

Python's ML libraries are in Python, not PHP
I can swap the model (fine-tune later) without touching Laravel
The HTTP boundary forces me to think about failure modes (timeouts, retries, circuit breakers)
The sentiment service is stateless — horizontally scalable on its own

6. Nova actions that actually save time

Instead of a 5-step manual tenant setup, ProvisionTenant does it all:

Create Tenant row (UUID)
Create Domain row (subdomain)
Switch into tenant context, run tenant migrations
Seed default roles (admin, branch_manager, staff)
Seed 10 default issue categories
Create School + default Branch
Create first admin User with random password
Email the admin their credentials via TenantProvisionedMail

One click. Thirty seconds. A new school is live.

GenerateDemoData is the cooler one — it seeds a tenant with realistic data matched to the 10 default categories (e.g., Transport gets "Bus late", Academics gets "Math homework concern"), creates branch managers, staff assigned to categories, parents and teachers each with an open issue. You can demo the product to a school in 60 seconds.

7. The queue + tenancy trap

This one bit me hard enough that it got its own postmortem post. TL;DR: never put a tenant-scoped Eloquent model in a queued job's constructor. Pass scalars, call tenancy()->initialize() in handle().

What's in the repo

app/
  Http/Controllers/          → tenant + public portal controllers
  Models/                    → User, Issue, RosterContact, AccessCode, ...
  Policies/                  → IssuePolicy, RosterContactPolicy, ...
  Nova/                      → Tenant, Domain, CentralUser resources + actions
  Jobs/                      → AnalyzeIssueSentiment, LogActivityJob
  Listeners/                 → PerformAiAnalysis
  Mail/                      → 6 transactional mailables
database/
  migrations/                → central schema
  migrations/tenant/         → per-tenant schema
  seeders/                   → roles, default categories, demo data
routes/
  web.php                    → /nova + central admin
  tenant.php                 → /admin + public portal (per-tenant)

~30 migrations, ~40 models, ~20 controllers, ~15 policies, full Nova suite.

What I'd do differently next time

Start with Redis for queue — the database driver was fine until demo day, when AI jobs stacked up
Write the tenancy feature test FIRST — the one that actually boots a queue worker with no tenant context. Would have caught the queue trap in minutes instead of hours.
Pick Livewire over Blade+Alpine for the admin — the filter-form dance gets old; Livewire would halve the code
Use Inertia for the parent portal — it's the one place where a SPA-ish feel would help UX

Try it

git clone https://github.com/sharjeelz/eliflammeem-git.git
cd eliflammeem-git
composer install && npm install
cp .env.example .env && php artisan key:generate
php artisan migrate && php artisan db:seed
composer run dev

Then open http://central.lvh.me:8000/nova. Provision a tenant. Watch the whole thing come alive.

Contribute

⭐ the repo if this saved you a weekend. PRs welcome — the roadmap is on the README:

Arabic + RTL UI
WhatsApp Business API for access-code delivery
SSO for staff
Per-tenant custom branding

🔗 github.com/sharjeelz/eliflammeem-git

What would you have done differently? Drop a comment — genuinely want to hear it.

The Laravel Queue + Multi-Tenancy Trap That Cost Me 3 Hours

Sharjeel Zubair — Tue, 14 Apr 2026 10:15:56 +0000

A postmortem on a bug that passed all my unit tests, all my feature tests, and every manual smoke test — then blew up the first time a real user clicked a button in production.

The setup

I'm building Schoolytics, an open-source multi-tenant helpdesk for schools. Multi-tenancy is row-level: one Postgres database, every tenant-scoped table has a tenant_id column, and every tenant model uses a BelongsToTenant trait that adds a global scope:

trait BelongsToTenant
{
    protected static function bootBelongsToTenant(): void
    {
        static::addGlobalScope('tenant', function (Builder $q) {
            if ($tenantId = tenant('id')) {
                $q->where($q->getModel()->getTable().'.tenant_id', $tenantId);
            }
        });

        static::creating(function ($model) {
            $model->tenant_id ??= tenant('id');
        });
    }
}

Simple, effective. Every query a tenant's code makes is automatically scoped. Forget tenant_id? You physically cannot leak another tenant's data.

The feature

When a parent submits an issue through the public portal, we fire an IssueCreated event. A queued listener calls a Python microservice to analyze sentiment, then writes the result to an issue_ai_analysis row. Straightforward event → queued listener → DB write.

class IssueCreated
{
    public function __construct(public Issue $issue) {}
}

class PerformAiAnalysis implements ShouldQueue
{
    use InteractsWithQueue, SerializesModels;

    public function handle(IssueCreated $event): void
    {
        $score = Http::post(config('services.ai.url'), [
            'text' => $event->issue->description,
        ])->json();

        IssueAiAnalysis::updateOrCreate(
            ['issue_id' => $event->issue->id],
            ['sentiment' => $score['label'], 'confidence' => $score['confidence']]
        );
    }
}

Green tests. Works in tinker. Ships.

The crash

First real submission in production:

Illuminate\Database\Eloquent\ModelNotFoundException
No query results for model [App\Models\Issue].

But the issue exists. I can SELECT * FROM issues WHERE id = 189 and see it. The listener is being called with an event whose payload clearly references issue 189 — and then Laravel throws ModelNotFoundException trying to rehydrate it.

The trap

Here's the lifecycle of a queued listener:

Controller fires event(new IssueCreated($issue))
Laravel sees the listener is ShouldQueue, serializes the event via SerializesModels
The event is not serialized as the full Issue object — just App\Models\Issue + the primary key (189). This is the whole point of SerializesModels; it keeps payloads tiny and always fresh.
Worker boots, pulls the job, and calls (new Issue)->newQueryForRestoration(189)->firstOrFail() to rebuild the model.

Step 4 is where it dies. The worker process has no tenant context yet — it just started. Which means tenant('id') returns null. Which means BelongsToTenant's global scope generates:

SELECT * FROM issues
WHERE id = 189
  AND issues.tenant_id IS NULL   -- 💀
LIMIT 1

No rows. ModelNotFoundException.

The kicker: this never fails in sync mode (there's no serialization round-trip), and tests typically use Queue::fake() or sync drivers. The bug is invisible until you run a real queue worker against a real tenant request.

Laravel's stancl/tenancy does ship a QueueTenancyBootstrapper that restores tenant context on the worker — but it fires after SerializesModels::restoreModel() runs. Too late. The model is already dead.

The fix

Never put a tenant-scoped Eloquent model directly into a queued event or job. Store scalars, and initialize tenancy yourself inside handle():

class IssueCreated
{
    public function __construct(
        public readonly int    $issueId,
        public readonly string $tenantId,
    ) {}
}

class PerformAiAnalysis implements ShouldQueue
{
    public function handle(IssueCreated $event): void
    {
        // Tenant model itself is NOT tenant-scoped — safe to find()
        $tenant = \App\Models\Tenant::find($event->tenantId);
        tenancy()->initialize($tenant);

        try {
            $issue = Issue::findOrFail($event->issueId);

            $score = Http::post(config('services.ai.url'), [
                'text' => $issue->description,
            ])->json();

            IssueAiAnalysis::updateOrCreate(
                ['issue_id' => $issue->id],
                ['sentiment' => $score['label'], 'confidence' => $score['confidence']]
            );
        } finally {
            tenancy()->end();
        }
    }
}

And dispatch it with plain values:

event(new IssueCreated(
    issueId:  $issue->id,
    tenantId: tenant('id'),
));

Three rules I now enforce in code review:

Queued events and jobs store scalars only. No Eloquent models in constructor signatures.
Every handle() method that touches tenant data calls tenancy()->initialize() first and tenancy()->end() in finally.
The Tenant model itself must never use BelongsToTenant (otherwise you can't look it up without already having tenant context — chicken-and-egg).

Why `SerializesModels` is still the right default

The trap is real, but the trait exists for good reasons: tiny payloads, always-fresh data, no stale-attribute bugs. The fix isn't to abandon it — it's to recognize that the trait assumes a single global database context, which breaks the moment you add a tenant dimension.

If you're on single-tenant Laravel, keep passing models. If you're on multi-tenant Laravel with row-level isolation, scalars + manual tenancy()->initialize() are your friend.

How I caught it for good

I added a simple feature test that actually runs the queue:

it('processes queued listeners with correct tenant context', function () {
    $tenant = Tenant::factory()->create();
    tenancy()->initialize($tenant);

    Queue::connection('sync')->... // won't catch it
    // Use actual database queue driver:
    config(['queue.default' => 'database']);

    $issue = Issue::factory()->create();
    event(new IssueCreated(issueId: $issue->id, tenantId: $tenant->id));

    tenancy()->end(); // simulate worker boot with no context
    $this->artisan('queue:work --once --stop-when-empty')->assertExitCode(0);

    expect(IssueAiAnalysis::withoutGlobalScopes()
        ->where('issue_id', $issue->id)->exists())->toBeTrue();
});

Ending tenancy before the worker runs is the critical line — it reproduces what Supervisor does in production.

TL;DR: If you're using stancl/tenancy with row-level isolation and queued events/jobs, never put a tenant-scoped Eloquent model in a queued payload. Pass the ID + tenant ID as scalars, call tenancy()->initialize() in handle(). Your tests won't catch this — only a real queue worker will.

Source code: https://github.com/sharjeelz/eliflammeem-git — the pattern lives in app/Listeners/PerformAiAnalysis.php.

If this saved you 3 hours, drop a ⭐ on the repo. If you've hit it before, I'd love to hear your fix in the comments.

Forem: Sharjeel Zubair

I Pushed Our Backend Repo to a Public GitHub by Accident. Here's What Happened in 47 Minutes

The Mistake

Minute 0–2: GitHub's Indexers Wake Up

Minute 2–10: The Bots Arrive

Minute 10–30: Business Logic Exposure

Minute 30–47: The Discovery and Panic

What I Wish We Had

The Takeaway

Vibe Coding Is Burning You Out Here's What's Actually Happening to Your Brain

The war story

Why vibe coding hits different

The symptoms, ranked

What to actually do

1. Enforce a hard cycle timer

2. The 20-20-20-20 rule (I added one)

3. Separate "generate" and "understand" sessions

4. Pre-commit friction

5. Hydrate and fuel for the actual workload

6. Body > mind tricks

7. Log your sessions

The takeaway

Vibe Coding Vs New Generation of coders

I Watched a 14-Year-Old Ship a Working App Without Reading a Single Line of Docs

The Moment It Clicked for Me

What "Vibe Coding" Actually Means

What They're Getting Good At

What They're Losing

A Concrete Pedagogy Shift

The New Baseline Skill: Verification

The Takeaway

Porting a US Stock Trading App to the Saudi Market -What Actually Broke

The stack

Gotcha #1 — Your data vendor probably doesn't cover Saudi

Gotcha #2 — No options market

Gotcha #3 — SELL signals in a long-only market

Gotcha #4 — Numeric tickers + Arabic names + RTL

Gotcha #5 — The market calendar

One small UX win

What I'd tell past me

GDPR Erasure Is Not DELETE FROM users

The naive implementation

Problem 1: the NOT NULL foreign key trap

Problem 2: the four-way decision

The implementation

File cleanup happens outside the transaction

Attachment paths are collected before the transaction

Auto-housekeeping is separate from anonymisation

Retry semantics matter

What stays forever

Publishing the decision tree

Summary

A Dashboard for developers! https://spiffy-palmier-f0c5af.netlify.app/ #health #focus

I Built a Multi-Tenant School Helpdesk in Laravel — Here's the Full Stack

Meet Schoolytics

The stack

The interesting decisions

1. Two auth guards, zero overlap

2. Row-level multi-tenancy, enforced twice

3. Passwordless parent flow

4. Role-scoped queries in ONE place

5. AI triage via a separate microservice

6. Nova actions that actually save time

7. The queue + tenancy trap

What's in the repo

What I'd do differently next time

Try it

Contribute

The Laravel Queue + Multi-Tenancy Trap That Cost Me 3 Hours

The setup

The feature

The crash

The trap

The fix

Why SerializesModels is still the right default

How I caught it for good

Why `SerializesModels` is still the right default