DEV Community: Muhammad Ali Mughal

Laravel Interview Questions With Answers From Real Projects

Muhammad Ali Mughal — Sat, 24 Oct 2026 11:12:36 +0000

By Muhammad Ali Mughal · Last updated 24 October 2026

Most lists of Laravel interview questions test whether you've read the docs: "What is Artisan?", "What is a migration?". Interviewers who've shipped Laravel apps ask something else. They want to hear what broke, how you found it and what you changed. The best way to prepare is to answer each question with a mechanism and a real example, and to be ready to show it in code.

I'm Muhammad Ali Mughal, a principal software engineer with 9+ years of PHP/Laravel and .NET work. At Loop Origin I've built Laravel apps for e-commerce, logistics and SaaS clients,. Below are 15 questions I'd ask a mid-level or senior Laravel developer, with short answers that show real experience, plus a small test I ran to back one of them up.

Laravel interview questions on Eloquent and the database

1. What is the N+1 query problem, and how do you fix it?

Looping over models and touching a relationship runs one query for the list plus one per row. Fix it with eager loading: Order::with('customer')->get(). A strong answer adds how you catch it: Model::preventLazyLoading() in non-production environments, plus a query log or Debugbar during review.

I checked this on PHP 8.4 with illuminate/database v13.38.0 and an in-memory SQLite database seeded with 50 customers and 200 orders, counting queries with DB::listen:

$queries = 0;
DB::connection()->listen(function () use (&$queries) { $queries++; });

foreach (Order::all() as $o) { $o->customer->name; }              // lazy
foreach (Order::with('customer')->get() as $o) { $o->customer->name; } // eager
Customer::withCount('orders')->withSum('orders', 'total')->get();   // aggregates
Order::chunkById(50, fn ($chunk) => $chunk->count());               // batches

The output (with the counter reset before each line):

Lazy loading, 200 orders:      201 queries
Eager loading with('customer'): 2 queries
withCount + withSum, 50 customers: 1 queries (first: 4 orders, sum 6004)
preventLazyLoading: Illuminate\Database\LazyLoadingViolationException
chunkById(50) over 200 orders: 5 queries

201 queries down to 2. That's the kind of evidence I like to hear in an interview.

2. When would you use `chunkById()` instead of `get()`?

When processing thousands of rows in a job or command. get() loads everything into memory. chunkById() pages by primary key, so rows updated during the loop aren't skipped or repeated, which can happen with offset-based chunk(). For read-only exports, lazyById() gives the same safety with a simpler loop.

3. How do you prevent two requests from overselling stock?

Wrap it in DB::transaction() and either lock the row with lockForUpdate() or use an atomic conditional update: Product::whereKey($id)->where('stock', '>', 0)->decrement('stock'), then check the affected row count. Mention that validation alone can't solve a race.

4. `$fillable` or `$guarded`?

Both protect against mass assignment. I prefer $fillable on models that take user input, because new columns stay protected by default. The deeper answer: validate with Form Requests and pass $request->validated(), never $request->all().

5. How do you write a migration that's safe on a large production table?

Avoid long table locks. Add nullable columns first, backfill in batches through a job, then add constraints. Never edit a migration that has already run in production; write a new one. Senior candidates also mention testing down(), or deciding consciously not to support it.

Laravel interview questions on queues and performance

6. A queued job runs twice. Why, and what do you do?

Usually retry_after is shorter than the job's runtime, so the job is released while still running, or a worker crashed after the side effect but before acknowledging it. Fix the timing, then make the job idempotent: check state before acting, or use unique jobs. I covered the full setup in Running Laravel Queues in Production.

7. Why doesn't my deployed fix take effect in queued jobs?

Queue workers are long-running processes holding the old code in memory. Run php artisan queue:restart (or horizon:terminate) on every deploy. It's a small question, but it tells me whether someone has run Laravel in production.

8. How do you rate-limit calls to a third-party API from jobs?

Use job middleware such as RateLimited or ThrottlesExceptions, together with $tries and an increasing $backoff. For SMS gateways and courier APIs I also log every request and response for support.

9. What do you cache, and how do you invalidate it?

Cache expensive, read-heavy data such as settings, menus and report totals with Cache::remember(). Invalidate on write through model events or explicit Cache::forget() calls. Good candidates mention cache tags on Redis, stampede protection with Cache::lock(), and running config:cache and route:cache on deploy.

Laravel interview questions on architecture and security

10. How does the service container help you?

It resolves dependencies through constructor injection and lets you bind interfaces to implementations. A typical example: binding a PaymentGateway interface to a JazzCash or Stripe class per environment, and swapping in a fake in tests.

11. Middleware, policies or gates for authorisation?

Middleware handles request-level checks such as authentication. Policies hold model-level rules ("can this user update this order?"), gates hold ad-hoc abilities. For larger role systems I've used Spatie Permission with policies, so controllers only call $this->authorize().

12. Where should business logic live?

Not in controllers. I use action or service classes with a single public method, called from controllers, jobs and commands alike. That keeps logic testable and reusable. Strong candidates explain the trade-off instead of reciting a pattern name.

13. How do you protect a Laravel app against common attacks?

Eloquent and the query builder use parameter binding against SQL injection, Blade's {{ }} escapes output against XSS, and CSRF tokens are on by default for web forms. The mistakes come from DB::raw() with user input, {!! !!} on user content and missing authorisation checks on IDs.

Testing and debugging questions

14. How do you test code that sends emails or calls APIs?

Use fakes: Mail::fake(), Queue::fake(), Event::fake() and Http::fake() with Http::preventStrayRequests(). Then assert what was sent. Feature tests with RefreshDatabase cover the full request cycle.

15. A page got slow in production. Walk me through it.

Reproduce with real data, check query count and duration (Telescope, Debugbar or slow query log), look for N+1s and missing indexes with EXPLAIN, then cache or queue what's left. The order matters more than the tools.

How to prepare: a quick checklist

Area	What to have ready
Eloquent	One N+1 story with before and after query counts
Queues	A duplicate-job or stuck-worker story and the fix
Data integrity	How you handled a race condition
Architecture	Where you put business logic and why
Testing	Which fakes you use and one bug a test caught
Your CV	Projects you can explain line by line

If your applications aren't reaching the interview stage yet, my guide on why resumes get rejected by ATS covers the step before this one.

FAQ

What Laravel interview questions are asked for experienced developers?

Expect questions on N+1 queries and eager loading, queue reliability and idempotency, race conditions and transactions, caching and invalidation, authorisation with policies, and testing with fakes. Senior rounds add architecture trade-offs and production debugging stories, so prepare concrete examples with numbers rather than definitions alone.

How should I prepare for a Laravel technical interview?

Rebuild two or three features you've shipped as small demos you can explain line by line. Practise answering each question with the problem, the mechanism and what you'd change next time. Read the current Laravel docs for queues, Eloquent relationships and testing, because version details often come up.

What are the most common Laravel performance questions?

The usual ones are N+1 queries, missing database indexes, loading too many rows with get(), caching expensive queries, queueing slow work like emails and PDFs, and production commands such as config:cache, route:cache and OPcache. Be ready to explain how you measured the problem before fixing it.

Do Laravel interviews include live coding?

Many do, usually a small task such as a CRUD endpoint with validation, a relationship query or fixing a failing test. Some companies send a take-home project instead. In both cases, clear structure, validation, tests and a short README tend to matter more than finishing every optional feature.

Should I learn Livewire or Inertia before a Laravel interview?

Learn the one the job ad mentions. Livewire suits teams that want server-rendered interactivity in Blade, while Inertia suits teams using Vue or React. Knowing the core framework well matters more than either, but being able to discuss why a team might choose one is a plus.

Hiring a Laravel team instead?

If you'd rather hire a team that has already answered these questions in production, see our Laravel development services, or visit Loop Origin.

Which Laravel interview question caught you off guard? Share it in the comments.

laravel #php #interview #career #webdev #backend

How to Prevent Double Booking: Locks, Holds and Expiry

Muhammad Ali Mughal — Sat, 24 Oct 2026 11:12:20 +0000

By Muhammad Ali Mughal · Last updated 24 October 2026

Two customers click "Book" on the last slot at the same moment. Both see a confirmation. One of them shows up to find the truck, room or appointment already taken. If you want to prevent double booking, checking availability in your code before inserting isn't enough. The database has to enforce the rule, using a constraint, a row lock or both, and short-lived holds need an expiry so abandoned checkouts don't block real customers.

I'm Muhammad Ali Mughal, and at Loop Origin we build booking and operations software, including a Car Carrier Management System for a vehicle transport business in Pakistan, built on Laravel and PostgreSQL. In this guide I'll show you a race condition I reproduced on PostgreSQL 17, then three fixes and the test results for each.

Why "check, then insert" double-books

The usual first version looks like this:

SELECT count(*) FROM bookings
WHERE carrier_id = 1 AND during && '[2026-10-25 09:00+05, 2026-10-25 17:00+05)';
-- if 0, then:
INSERT INTO bookings (carrier_id, customer, during) VALUES (1, 'c1', '[...]');

Under load, two requests can both run the SELECT, both see zero, and both INSERT. Nothing in the database says those rows conflict, so both commits succeed. This is a classic time-of-check to time-of-use race.

The test: 20 concurrent requests for one slot

I wrote a Python script using psycopg and 20 threads. Each thread opens its own connection, waits on a barrier so they all fire together, then tries to book carrier 1 for the same 8-hour window. Here's the naive version:

def naive(c, i):
    n = c.execute(f"SELECT count(*) FROM bookings WHERE carrier_id=1 AND during && {SLOT}").fetchone()[0]
    if n == 0:
        c.execute(f"INSERT INTO bookings (carrier_id, customer, during) VALUES (1, %s, {SLOT})", (f"c{i}",))

Result on my box:

Test 1: naive check-then-insert, one slot, 20 concurrent requests
  active bookings: 14 {'ok': 20}

Fourteen bookings for a slot that should hold one, and every request reported success. The exact number changes from run to run, which is what makes this bug so hard to catch in manual testing.

Fix 1: Prevent double booking with an exclusion constraint

For "one booking per resource per time range", PostgreSQL has a direct answer: an exclusion constraint over a range type. It rejects any row whose range overlaps an existing row for the same carrier. The btree_gist extension lets you mix plain equality on carrier_id with the range overlap operator.

CREATE EXTENSION IF NOT EXISTS btree_gist;

ALTER TABLE bookings ADD CONSTRAINT no_overlap
  EXCLUDE USING gist (carrier_id WITH =, during WITH &&)
  WHERE (status IN ('held', 'confirmed'));

The WHERE clause makes it a partial constraint, so cancelled or expired bookings don't block the slot. Same 20 threads, now just inserting:

Test 2: exclusion constraint on (carrier_id, during)
  active bookings: 1 {'ok': 1, 'ExclusionViolation': 19}

Exactly one booking. The other 19 got error 23P01 (exclusion violation), which your app can catch and turn into "Sorry, that slot was just taken".

If your slots are fixed (for example 30-minute appointments), a plain UNIQUE (resource_id, slot_start) constraint does the same job and works in MySQL too.

Fix 2: Lock the parent row when capacity is more than one

A car carrier has room for several vehicles, so the rule isn't "no overlaps", it's "no more than N". A constraint can't count rows, but a row lock can serialise the check. Lock the carrier row with SELECT ... FOR UPDATE, count, then insert, all in one transaction:

def capacity_lock(c, i):
    cap = c.execute("SELECT capacity FROM carriers WHERE id=1 FOR UPDATE").fetchone()[0]
    used = c.execute(f"SELECT count(*) FROM bookings WHERE carrier_id=1 AND during && {SLOT} "
                     "AND status IN ('held','confirmed')").fetchone()[0]
    if used >= cap:
        raise psycopg.errors.CheckViolation("full")
    c.execute(f"INSERT INTO bookings (carrier_id, customer, during, status, expires_at) "
              f"VALUES (1, %s, {SLOT}, 'held', now() + interval '10 minutes')", (f"c{i}",))

With capacity set to 8:

Test 3: capacity 8 (car slots on one carrier), SELECT ... FOR UPDATE on the carrier row
  active bookings: 8 {'ok': 8, 'CheckViolation': 12}

Eight in, twelve refused. The lock makes each transaction wait for the previous one to commit before counting, as described in the PostgreSQL docs on explicit locking. Keep these transactions short, because everyone booking that carrier queues behind the lock.

In Laravel, the same pattern is DB::transaction() with Carrier::whereKey($id)->lockForUpdate()->first() before the count.

Fix 3: Holds with expiry

Notice that Test 3 inserted rows as held with expires_at = now() + 10 minutes. That's the pattern for checkout flows: reserve the slot while the customer pays, then confirm or release it.

A hold that never expires is just another double-booking bug in slow motion. A scheduled job releases stale holds:

UPDATE bookings SET status = 'expired'
WHERE status = 'held' AND expires_at < now();

To test it, I back-dated three holds, ran the sweeper, confirmed one hold as paid, and fired a second wave of 20 requests:

Test 4: expire stale holds, then capacity frees up
  holds expired: 3
  second wave of 20 requests: 8 {'ok': 3, 'CheckViolation': 17}

Three slots freed, three new holds taken, total still capped at 8. Your availability query should also ignore expired holds directly (expires_at > now()), so a late sweeper never shows a slot as full when it isn't.

In Laravel I run the sweeper from the scheduler every minute, and payment callbacks go through queued jobs that confirm a hold only if it's still held. I wrote about running those workers reliably in Running Laravel Queues in Production.

Which fix to use

Situation	Fix	Works in
One booking per resource per time range	Exclusion constraint on a range	PostgreSQL
Fixed slots (e.g. 30-minute appointments)	Unique constraint on resource + slot start	PostgreSQL, MySQL, SQLite
Capacity greater than one (seats, car slots, stock)	`SELECT ... FOR UPDATE` on the parent row, or a conditional `UPDATE ... SET remaining = remaining - 1 WHERE remaining > 0`	PostgreSQL, MySQL
Checkout or payment step in between	Holds with `expires_at` plus a sweeper	Any

The conditional UPDATE is worth knowing: it checks and decrements in one atomic statement, so there's no gap between check and write. The same idea protects stock counts in online stores, which I touched on in my guide to launching an online store in Pakistan.

Double booking prevention checklist

The database enforces the rule (constraint or lock), not only app code
Time ranges use half-open intervals [start, end) so back-to-back bookings don't clash
Conflicts return a friendly "slot just taken" message, not a 500 error
Holds have an expiry, and a scheduled job releases them
Availability queries ignore expired holds
Payment callbacks confirm a hold only if it's still active
A concurrency test fires parallel requests at the same slot

FAQ

How do you prevent double booking in a database?

Make the database enforce the rule. Use a unique constraint for fixed slots, an exclusion constraint for overlapping time ranges in PostgreSQL, or a row lock with SELECT ... FOR UPDATE when a resource has capacity above one. Checking availability in application code first, without a lock, still allows two requests to slip through.

Is a unique index enough to stop double bookings?

It's enough when bookings map to fixed slots, such as one row per resource per 30-minute start time. It isn't enough for free-form time ranges, because two different start times can still overlap. For ranges, use a PostgreSQL exclusion constraint, or lock the resource row before checking for overlaps.

What is the difference between optimistic and pessimistic locking for bookings?

Pessimistic locking takes a lock first, so other requests wait, as with SELECT ... FOR UPDATE. Optimistic locking lets everyone proceed and rejects the losers at write time, using a version column or a constraint violation. Optimistic suits low-contention bookings; pessimistic suits popular slots where many people compete for the same resource.

How long should a booking hold last?

Long enough for a normal checkout, and no longer. Ten to fifteen minutes is a common choice for card payments, while a phone or bank transfer flow may need more. Store expires_at on the hold, ignore expired holds in availability queries, and run a sweeper that marks them expired.

Can MySQL prevent overlapping bookings?

MySQL has no exclusion constraints, so you need another approach. Use fixed slots with a unique index, or lock the resource row with SELECT ... FOR UPDATE inside a transaction before checking for overlaps. Both work with InnoDB. Test either approach with parallel requests, not just one browser tab.

Need a booking system built?

If you're planning a booking, dispatch or reservation platform, see how we handled bookings, dispatch and accounting in the Car Carrier Management System, or visit Loop Origin.

Have you been bitten by a double-booking bug in production? Tell me how you found it in the comments.

systemdesign #postgresql #database #backend #laravel #architecture

How Long Should a Password Be? Password Entropy Explained

Muhammad Ali Mughal — Sat, 24 Oct 2026 11:12:04 +0000

By Muhammad Ali Mughal · Last updated 24 October 2026

"At least 8 characters, one uppercase, one number, one symbol." Most of us learned password rules from sign-up forms, and most of those rules are out of date. So how long should a password be? For anything that protects an account on its own, use at least 15 random characters, or a passphrase of 5 or more random words, and let a password manager remember it. Length and randomness matter far more than symbols.

I'm Muhammad Ali Mughal, and I build PixelValut, a set of free privacy and developer tools. In this guide I'll show you the maths behind that answer, the actual numbers I got when I ran it on my machine, and what current guidance from NIST says.

What password entropy means

Entropy is a measure of how many guesses an attacker needs. For a password generated at random, it's simple to calculate:

entropy (bits) = length × log2(size of the character pool)

Each extra bit doubles the number of possible passwords. A random 8-character password drawn from all 94 printable ASCII characters has about 52 bits. A random 16-character one has about 105 bits. That isn't twice as strong. It's 2^52 times as many possibilities.

There's one catch: the formula only holds for random passwords. Summer2026! uses uppercase, lowercase, digits and a symbol, but attackers try season-plus-year patterns early. Its real strength is a tiny fraction of what the formula suggests.

How long should a password be? I ran the numbers

I wrote a short Python script that generates a sample password with the secrets module (Python's cryptographically secure random source) and estimates the average time to crack each format. I assumed an offline attack at 10 billion guesses per second, which is a reasonable figure for a fast, unsalted hash on GPU hardware. Real speeds vary a lot with the hash used, so treat this as a comparison, not a promise.

import math, secrets, string

GUESSES = 1e10  # guesses per second, offline, fast hash

def show(label, pool, length):
    bits = length * math.log2(pool)
    years = 2**bits / 2 / GUESSES / (3600 * 24 * 365)
    print(f"{label:<34} bits={bits:6.1f}  avg crack: {years:.3g} years")

full = string.ascii_letters + string.digits + string.punctuation
print("Sample:", "".join(secrets.choice(full) for _ in range(16)))
for n in (8, 12, 15, 16, 20):
    show(f"Random, all 94 printable, {n}", 94, n)
for w in (4, 5, 6):
    show(f"Passphrase, {w} words (7776 list)", 7776, w)

Here's what it printed (I've rounded the times for readability):

Password type	Entropy	Average time to crack at 10^10 guesses/s
8 random characters (94 pool)	52.4 bits	3.5 days
12 random characters	78.7 bits	about 755,000 years
15 random characters	98.3 bits	about 6.3 × 10^11 years
16 random characters	104.9 bits	about 5.9 × 10^13 years
15 random lowercase letters	70.5 bits	about 2,660 years
4-word passphrase (7,776-word list)	51.7 bits	2.1 days
5-word passphrase	64.6 bits	about 45 years
6-word passphrase	77.5 bits	about 351,000 years
6-digit PIN	19.9 bits	0.05 milliseconds

Two things stand out. First, 15 random lowercase letters beat 8 characters that use every symbol on the keyboard. Length wins. Second, a 4-word passphrase is about as weak as an 8-character password, which is why 5 or 6 words is the safer choice.

The 7,776-word list size comes from the EFF dice wordlists, built for picking words at random with dice.

What NIST says about password length

The US National Institute of Standards and Technology updated its digital identity guidelines in SP 800-63B-4. The parts that matter for everyday users and developers:

Passwords used as the only factor must be at least 15 characters
Passwords used as part of multi-factor login may be shorter, but at least 8 characters
Services should allow a maximum length of at least 64 characters
Services shall not force composition rules like "one symbol, one number"
Services shall not force periodic password changes, only a change when there's evidence of compromise
Chosen passwords should be checked against a blocklist of common and breached values

So the "8 characters plus a symbol" rule you see on many sign-up forms falls well short of current guidance.

Password length by use case

Use case	My recommendation
Accounts stored in a password manager	16 to 20 random characters
Password manager master password	6 random words, or more
Wi-Fi (WPA2/WPA3) password	16+ random characters or 5+ random words
Device or laptop login you type daily	5+ random words
Phone or card PIN	6+ digits, only where wrong guesses are rate limited
API keys and app secrets	Generated with 128+ bits of randomness, never typed by hand

A note on PINs: 6 digits is almost nothing offline, but a phone that locks after a few wrong guesses changes the maths. In the same script, a 6-digit PIN limited to 10 guesses per hour takes an average of 5.7 years. Short secrets are only acceptable when guessing is throttled.

How to create a strong password in 3 steps

Don't invent it. Humans pick patterns. Use a generator that draws from a secure random source.
Pick length over complexity. Set the generator to 16 or more characters, or 5 or 6 words for anything you need to remember.
Store it in a password manager, and use a different password for every site so one breach doesn't expose the rest.

If you want a quick generator, the free PixelValut password generator creates random passwords, passphrases and PINs in your browser using crypto.getRandomValues, shows the entropy in bits, and clears your clipboard 30 seconds after copying. Generation happens locally, so the password isn't sent to a server.

For developers: store passwords properly

Length only protects users if your app stores the result well. Hash with a slow, salted algorithm such as Argon2id or bcrypt, as the OWASP Password Storage Cheat Sheet recommends, so the 10-billion-guesses-per-second figure above drops sharply. Accept long passwords and pasted passwords, and check new ones against a breached-password list.

If you look after a domain as well as logins, my guides on checking an SSL certificate and checking SPF, DKIM and DMARC records cover the other two security checks I run on every site.

Strong password checklist

15+ characters for any password that works without 2FA
Randomly generated, not based on words, names or dates
5 to 6 random words if you must memorise it
Unique for every account
Saved in a password manager
Two-factor authentication turned on where available

FAQ

How long should a password be in 2026?

Use at least 15 random characters for any account protected by a password alone, which matches NIST SP 800-63B-4. With two-factor authentication the minimum drops to 8, but I still use 16 or more for anything stored in a password manager, because there's no extra effort once the manager remembers it.

Is a 12-character password long enough?

A truly random 12-character password from the full keyboard has about 79 bits of entropy, which is strong against offline guessing. The problem is that most 12-character passwords people choose aren't random. If you're creating one by hand, go longer, or use a generator and a password manager instead.

Are passphrases better than passwords?

A passphrase of 5 or 6 random words is easier to type and remember than a random string of similar strength. The words must be picked at random from a large list, not chosen by you. A 4-word passphrase is too weak by my numbers, so treat 5 words as the minimum.

Do special characters make a password stronger?

They help a little by enlarging the character pool, but length helps far more. In my test, 15 random lowercase letters had more entropy than 8 characters using every symbol. NIST now tells services not to require symbols at all, because forced rules lead to predictable patterns like a capital first letter.

How often should I change my password?

Only when there's a reason, such as a breach notice, a leaked password or a shared account losing a member. NIST SP 800-63B-4 says services shall not force periodic changes. Routine resets push people toward small, predictable edits, which makes passwords weaker rather than stronger.

Generate one now

Pick an account that still uses an old, short password and replace it with a 16-character random one from the password generator. You can also visit PixelValut.

What's the longest password a website has rejected for you? Tell me in the comments.

security #passwords #cybersecurity #privacy #infosec #webdev

How to Track Job Applications: A Simple System That Works

Muhammad Ali Mughal — Sat, 24 Oct 2026 11:11:46 +0000

By Muhammad Ali Mughal · Last updated 24 October 2026

Three weeks into a job search, most people can't answer simple questions about it. Which companies replied? Which resume did I send to that fintech role? Is it time to follow up, or did they already reject me? If you're applying to more than a handful of jobs, you need to know how to track job applications properly, and the fix is smaller than you think: one row per application, a short list of statuses, the exact resume file you sent, and a follow-up date.

I'm Muhammad Ali Mughal. I build Smart Resume Analyzer, and I've run my own searches with nothing more than a spreadsheet and a reminder habit. Below is the system I use, the columns that matter, and a small script I ran on 20 sample applications to show what the data tells you after a few weeks.

Why tracking job applications changes your results

Tracking isn't admin for its own sake. It answers three questions you can't answer from memory:

Where do my applications stall? No replies at all usually points at the resume or the targeting. Replies but no interviews points at fit or timing. Interviews with no offers points at the interview itself.
Which version of my resume works? If you tailor resumes (and you should), you need to know which file went where.
Who needs a follow-up today? A polite nudge one to two weeks after applying is normal. Without dates, it never happens.

Step 1: Choose one place to track job applications

Pick one tool and stick with it. Three options work well:

Option	Good for	Watch out for
A spreadsheet (Excel or Google Sheets)	Full control, filters, charts	You must add dropdowns and reminders yourself
A browser-based tracker	Quick setup, built-in stages	Check where the data is stored and how to back it up
A notes app or email folder	Very small searches	Falls apart past 15 to 20 applications

If you like spreadsheets, I made a free application tracking template you can open in Excel or import into Google Sheets. If you'd rather not build anything, a browser tracker with built-in stages, notes and reminders is quicker. Just check where it stores data and export a backup now and then.

Step 2: Set up the columns that matter

More columns isn't better. These are the ones I actually use:

Date applied
Company and role title (copy the exact title from the posting)
Link to the posting plus the requisition or job ID if there is one
Source: referral, company site, LinkedIn, job board
Resume version: the exact filename you uploaded, for example muhammad-laravel-v2.pdf
Status: a fixed list, not free text
Last contact and next action date
Notes: recruiter name, salary range, anything said on a call

The posting link matters more than people expect. Job ads get taken down, and you'll want the original wording before an interview. Save the text or a PDF of the ad in your notes.

Step 3: Use a fixed list of statuses

Free-text statuses ("waiting?", "maybe", "heard back") make the sheet impossible to filter. Use a short dropdown. In Google Sheets, select the status column and add an in-cell dropdown list. Excel has the same feature under Data Validation.

I use these stages:

Saved: found it, not applied yet
Applied
Replied: any human response, including a screening email
Interview
Offer
Rejected or No reply

Add conditional formatting so a row turns amber when its next action date has passed. That one rule does most of the reminding for you.

Step 4: Log the resume version for every application

This is the column most trackers skip, and it's the one that tells you whether your edits are working. Name files by target role and version, and never overwrite an old file you've already sent.

When you tailor a resume to a posting, it helps to know which ATS the company uses and how it reads your file. I covered that in Which ATS Is This Job Using?, and the keyword side in How to Tailor Your Resume Keywords to a Job Description.

Step 5: Review the numbers every week

Once you have 15 or more rows, the sheet starts to talk. I wrote a short Python script and ran it on a sample CSV of 20 made-up applications (fictional companies, realistic mix of sources and statuses) to show the kind of review I do on Sundays:

import csv
from collections import defaultdict
from datetime import date, timedelta

TODAY = date(2026, 10, 24)
rows = list(csv.DictReader(open("applications_sample.csv")))
responded = {"replied", "interview", "offer", "rejected"}

def rate(group):
    out = defaultdict(lambda: [0, 0])
    for r in rows:
        out[r[group]][0] += 1
        out[r[group]][1] += r["status"] in responded
    return {k: f"{v[1]}/{v[0]} ({v[1]/v[0]:.0%})" for k, v in sorted(out.items())}

print("Response rate by source:", rate("source"))
print("Response rate by resume version:", rate("resume_version"))
due = [r["company"] for r in rows if r["status"] == "no_reply"
       and TODAY - date.fromisoformat(r["last_contact"]) >= timedelta(days=10)]
print("Follow-ups due (10+ days silent):", len(due))

The output on my machine:

Response rate by source: {'Company site': '3/4 (75%)', 'Job board': '1/7 (14%)', 'LinkedIn': '3/5 (60%)', 'Referral': '4/4 (100%)'}
Response rate by resume version: {'backend-v1': '1/4 (25%)', 'backend-v2': '4/5 (80%)', 'dotnet-v1': '2/3 (67%)', 'laravel-v1': '1/5 (20%)', 'laravel-v2': '3/3 (100%)'}
Follow-ups due (10+ days silent): 9

The full script also prints totals: 20 applications, 11 responses and 5 at interview or better. The numbers are from sample data, so don't read them as a benchmark. The point is what the same view shows you on your own data. In this sample, the "v2" resumes did far better than the "v1" files, and job-board applications were mostly silent. That's a signal to retire the old files and spend more time on referrals and company career pages. It also shows nine follow-ups that would have been forgotten.

No Python? A pivot table on Source and Resume version gives the same answer.

Step 6: Follow up on a schedule

When you log an application, set the next action date 7 to 10 days out. When that date arrives:

Send one short, specific follow-up to the recruiter or hiring manager
Update Last contact and push the next action date another week
After two follow-ups with no reply, mark it No reply and move on

Job application tracking checklist

One tool, used for every application
Posting link and job ID saved, plus a copy of the ad text
Exact resume filename logged per row
Status chosen from a fixed list
Next action date on every open row
Weekly review of response rate by source and resume version
Backup or export of your data

FAQ

What is the best way to track job applications?

The best way is the one you'll keep using. For most people that's a spreadsheet or a simple browser tracker with one row per application, a fixed status list, the resume version sent, and a next action date. Tools matter less than logging every application on the same day you apply.

What columns should a job application tracker have?

At minimum: date applied, company, role title, posting link, source, resume version, status, last contact, next action date and notes. Add the job or requisition ID when the posting shows one. Skip columns you won't fill in, because half-empty columns make the sheet harder to read and review.

How many job applications should I track at once?

Track every application, however many there are. The tracker becomes most useful after about 15 rows, because that's when patterns in sources and resume versions start to appear. If you're sending more than 10 a week, review the sheet weekly so follow-ups and stale rows don't pile up.

When should I follow up on a job application?

One to two weeks after applying is a common and polite window. Set the next action date when you log the application, send one short follow-up when it arrives, and try once more a week later. After two attempts with no reply, mark the row as no reply and focus elsewhere.

Is a spreadsheet better than a job tracker app?

A spreadsheet gives you full control, pivot tables and charts, but you build the dropdowns and reminders yourself. A tracker app is faster to start and has stages built in. Whichever you pick, check where your data is stored and keep an export, especially if it only lives in your browser.

Start tracking today

Open the template above or the free Smart Resume job tracker, which needs no account and keeps your data in your browser with an export option. Add every application you've sent this month, and set a next action date on each one. You can visit Smart Resume Analyzer.

How do you track your applications right now? Tell me in the comments.

jobsearch #career #resume #productivity #jobapplication #careeradvice

Running Laravel Queues in Production: Redis, Supervisor, Retries and Failed Jobs

Muhammad Ali Mughal — Sat, 24 Oct 2026 01:37:51 +0000

Laravel queues feel easy in development. You set QUEUE_CONNECTION, run php artisan queue:work in a terminal, and emails send, PDFs generate and webhooks fire in the background. Then you deploy, close the terminal, and a week later a customer asks why their order confirmation never arrived.

I'm Muhammad Ali Mughal, and at Loop Origin, our Karachi team builds and maintains Laravel applications, including e-commerce stores that rely on queues for order emails, courier bookings, SMS and payment callbacks. This is the production setup we use, and the mistakes it's designed to prevent.

1. Pick a real queue driver

The sync driver runs jobs immediately inside the request, which is fine for tests but defeats the point in production. The database driver works and is a reasonable start for small apps. For anything busy, I use Redis: it's fast, it's what Laravel Horizon is built on, and it keeps queue traffic off your main database.

In .env:

QUEUE_CONNECTION=redis
REDIS_HOST=127.0.0.1
REDIS_PORT=6379

If Redis also holds your cache and sessions, consider a separate Redis database or connection for queues, so clearing the cache never wipes pending jobs.

2. Split work into named queues

Not all jobs are equally urgent. A password reset email shouldn't wait behind a 5,000-row export. Dispatch onto named queues:

SendOrderConfirmation::dispatch($order)->onQueue('high');
GenerateMonthlyReport::dispatch($month)->onQueue('low');

Then tell the worker to process them in priority order:

php artisan queue:work redis --queue=high,default,low

The worker always empties high before looking at default, and default before low.

3. Keep workers alive with Supervisor

queue:work is a long-running process. If it crashes, runs out of memory or the server reboots, nothing restarts it unless you have a process monitor. On Ubuntu, Supervisor is the standard choice:

sudo apt install supervisor

Create /etc/supervisor/conf.d/laravel-worker.conf:

[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/app/artisan queue:work redis --queue=high,default,low --sleep=3 --tries=3 --max-time=3600
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true
user=www-data
numprocs=2
redirect_stderr=true
stdout_logfile=/var/www/app/storage/logs/worker.log
stopwaitsecs=3600

Load it:

sudo supervisorctl reread
sudo supervisorctl update
sudo supervisorctl start "laravel-worker:*"

A few notes on those options:

numprocs is how many workers run in parallel. Start with two and increase only if the queue backs up; each worker holds your whole app in memory.
--max-time=3600 makes each worker exit after an hour so Supervisor starts a fresh one. This limits slow memory leaks. --max-jobs does the same by job count, and --memory sets a memory ceiling.
stopwaitsecs should be longer than your longest job, so Supervisor doesn't kill a worker mid-job during a stop.
user should match the user that owns your app files, or you'll get permission errors on logs and storage.

4. Restart workers on every deploy

This one catches almost everyone. A running worker has already loaded your code into memory. Deploy new code and the workers keep running the old version until they restart.

Add this to the end of your deploy script:

php artisan queue:restart

It signals workers to finish their current job and exit gracefully; Supervisor then starts them again with the new code. Clear and rebuild config cache first (php artisan config:cache) so the new workers pick up the right settings.

5. Set timeouts and retries deliberately

Three settings work together, and getting them out of sync causes jobs to run twice:

Job $timeout: the maximum seconds a job may run before the worker kills it.
retry_after in config/queue.php: how long the queue waits before assuming a job died and handing it to another worker.
$tries / $backoff: how many attempts, and how long to wait between them.

Rule: retry_after must be longer than your longest job timeout. If a job legitimately takes 120 seconds and retry_after is 90, a second worker picks it up while the first is still running.

On the job class:

class BookCourierShipment implements ShouldQueue
{
    use Queueable;

    public int $tries = 5;
    public int $timeout = 60;

    public function __construct(public Order $order) {}

    public function backoff(): array
    {
        return [10, 60, 300]; // seconds before retries 1, 2, 3+
    }

    public function handle(CourierClient $courier): void
    {
        $courier->book($this->order);
    }
}

Increasing backoff matters for third-party APIs. If a courier or SMS gateway is down, hammering it every three seconds won't help, and may get you rate-limited.

6. Handle failed jobs instead of losing them

When a job runs out of attempts, Laravel records it in the failed_jobs table (recent Laravel versions include that migration by default). Learn these commands:

php artisan queue:failed            # list failed jobs
php artisan queue:retry <uuid>      # retry one
php artisan queue:retry all         # retry all
php artisan queue:forget <uuid>     # delete one
php artisan queue:prune-failed --hours=168

Add a failed() method to important jobs so someone actually finds out:

public function failed(?Throwable $e): void
{
    Log::error('Courier booking failed', [
        'order' => $this->order->id,
        'error' => $e?->getMessage(),
    ]);
    // notify the ops team by email or Slack
}

Schedule the prune command so the table doesn't grow forever.

7. Make jobs safe to run twice

Even with correct settings, a job can occasionally run more than once: a worker crashes after doing the work but before acknowledging it, or someone retries a failed job that half-succeeded. Design for it:

Check before acting. Before booking a shipment, check whether the order already has a tracking number.
Use unique jobs. Implement ShouldBeUnique to stop duplicate jobs for the same model from being queued at the same time.
Prevent overlap. The WithoutOverlapping job middleware stops two jobs for the same key from running simultaneously.
Dispatch after commit. If you dispatch inside a database transaction, use ->afterCommit() (or set after_commit on the connection) so the worker doesn't look for a record that isn't saved yet.

This matters most for payment callbacks and inventory updates, where a duplicate means a double charge or a wrong stock count.

8. Watch the queue

You can't fix what you can't see. Options, from simplest:

Tail storage/logs/worker.log and check supervisorctl status after deploys.
Schedule php artisan queue:monitor redis:high,redis:default --max=100 so Laravel fires an event when a queue grows past a threshold, and send yourself an alert from it.
Install Laravel Horizon if you're on Redis. It gives you a dashboard of throughput, wait times and failed jobs, and manages worker processes from a config file. With Horizon, Supervisor runs php artisan horizon instead of queue:work, and you restart with php artisan horizon:terminate on deploy.

Production checklist

Redis (or database) driver, never sync
Named queues with priority order
Supervisor running workers with --max-time or --max-jobs
queue:restart (or horizon:terminate) in every deploy
retry_after longer than the longest job $timeout
$tries and increasing backoff on jobs that call external APIs
failed() handlers and a scheduled prune
Idempotent jobs for payments, stock and shipments
Queue-length alerts

If you'd like a team to build or review this for your app, our Laravel development services cover queued jobs, integrations and deployment. You can see our other work at looporigin.com.

What's the worst queue bug you've hit in production? Tell me in the comments.

laravel #php #redis #webdev #backend #devops #queues #supervisor #ubuntu #webdevelopment #pakistan #karachi

How to Check an SSL Certificate in 10 Minutes (and Fix the Most Common HTTPS Errors)

Muhammad Ali Mughal — Sat, 24 Oct 2026 01:37:10 +0000

An expired SSL certificate is one of the most avoidable outages on the web. The site is fine, the server is fine, but every visitor gets a full-page browser warning and most of them leave. Less dramatic certificate problems, like a missing intermediate certificate, are worse in a way: the site works in your desktop browser, so you don't notice, while API clients, mobile apps and curl quietly fail.

I'm Muhammad Ali Mughal, and I build free developer and privacy tools at PixelValut. This is the checklist I run whenever I launch a site, move a server or get a "your connection is not private" report. It takes about ten minutes, and I've included the OpenSSL commands so you can verify everything yourself.

What a certificate check should cover

A useful check answers five questions:

Is the certificate valid right now, and when does it expire?
Does it cover the exact hostname visitors use, including www and any subdomains?
Is the chain complete, so every client can link it to a trusted root?
Is the server configured sensibly: modern TLS versions, HTTP redirecting to HTTPS?
Are the important security headers set, such as HSTS?

The quickest way to get the overview is the free SSL Checker on PixelValut. Enter a domain and it shows the issuer, an expiry countdown and the HTTP security headers the site returns, with fix tips and OpenSSL commands. Then use the commands below to dig into anything that looks wrong.

Step 1: Check expiry and issuer

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

You'll see notBefore and notAfter. If notAfter is in the past, browsers show NET::ERR_CERT_DATE_INVALID.

The -servername flag matters. It sends SNI (Server Name Indication), which tells a server hosting many sites which certificate to present. Without it, you may be looking at the server's default certificate rather than the one your visitors get.

The real fix is automated renewal. Free certificates from Let's Encrypt are short-lived by design, so a manual renewal process will eventually be forgotten. If you use Certbot, test renewal without waiting for it to fail:

sudo certbot renew --dry-run

Common reasons renewal breaks: port 80 is blocked by a firewall (the HTTP-01 challenge needs it), a redirect rule interferes with /.well-known/acme-challenge/, or the DNS now points to a different server. Also confirm the web server reloads after renewal; a renewed file on disk doesn't help if Nginx is still serving the old one from memory.

Step 2: Check the hostname matches

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -ext subjectAltName

Browsers check the Subject Alternative Name (SAN) list, not just the common name. If visitors use www.example.com and the SAN list only has example.com, they get NET::ERR_CERT_COMMON_NAME_INVALID.

Things to remember:

A wildcard like *.example.com covers shop.example.com but not example.com itself, and not a.b.example.com.
When you add a new subdomain, reissue the certificate to include it, or use a wildcard via DNS validation.

Step 3: Check the chain is complete

This is the error that hides from you. Your server should send its own certificate plus the intermediate certificate(s). Desktop browsers can often fill a missing intermediate themselves, so the site looks fine to you. Many other clients can't.

echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null \
  | grep -E "^ *[0-9] s:|Verify return code"

You want to see more than one certificate in the list and Verify return code: 0 (ok). A result like unable to get local issuer certificate or unable to verify the first certificate usually means the intermediate is missing.

Fix: point your server at the full chain file, not just the leaf certificate. With Certbot on Nginx that's:

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Using cert.pem instead of fullchain.pem is one of the most common mistakes I see.

Step 4: Check TLS versions and redirects

Modern clients expect TLS 1.2 or 1.3. You can confirm what the server accepts:

openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null
openssl s_client -connect example.com:443 -servername example.com -tls1_1 </dev/null

The first should connect. The second should fail on a well-configured server (assuming your OpenSSL build still supports TLS 1.1 for testing). In Nginx, ssl_protocols TLSv1.2 TLSv1.3; is a sensible baseline.

Then confirm plain HTTP redirects to HTTPS with a single permanent redirect:

curl -sI http://example.com | grep -iE "^HTTP|^location"

You want a 301 (or 308) pointing to the https:// URL. Long redirect chains (http → https → www → trailing slash) slow down the first visit and are worth flattening.

Step 5: Check security headers

A valid certificate secures the connection. Headers tell the browser how to behave on top of it:

Header	What it does	Example
`Strict-Transport-Security`	Forces HTTPS on future visits	`max-age=31536000; includeSubDomains`
`Content-Security-Policy`	Limits where scripts, styles and frames can load from	Start with a report-only policy
`X-Content-Type-Options`	Stops MIME-type sniffing	`nosniff`
`X-Frame-Options` or CSP `frame-ancestors`	Prevents clickjacking via framing	`DENY` or `SAMEORIGIN`
`Referrer-Policy`	Controls how much URL data leaks to other sites	`strict-origin-when-cross-origin`

curl -sI https://example.com | grep -iE "strict-transport|content-security|x-content-type|x-frame|referrer-policy"

A word of caution on HSTS: once browsers cache it, they refuse plain HTTP for that domain until max-age runs out. Start with a short max-age (a few minutes or a day), confirm everything, including subdomains, works over HTTPS, and only then raise it. Only add includeSubDomains when every subdomain has a valid certificate.

Step 6: Fix mixed content

If the padlock shows a warning even though the certificate is fine, the page is probably loading something over http://, like an image, script or font. Open your browser's developer console; mixed content warnings list the exact URLs. Update them to https:// or relative paths, and check hard-coded URLs in your database or CMS settings after a migration.

Common errors at a glance

ERR_CERT_DATE_INVALID: expired (or the visitor's clock is wrong). Renew and automate.
ERR_CERT_COMMON_NAME_INVALID: hostname missing from SAN. Reissue with every hostname.
unable to get local issuer certificate: incomplete chain. Serve fullchain.pem.
ERR_CERT_AUTHORITY_INVALID: self-signed or untrusted issuer. Use a publicly trusted CA.
Wrong certificate on a shared server: SNI or virtual host misconfiguration. Check server_name blocks.
Padlock warning, valid cert: mixed content. Fix the http:// asset URLs.

Make it routine

My habit: check every domain after any server change, and keep an eye on expiry dates monthly even with auto-renewal, because automation fails silently. If DNS changes are involved, the DNS Lookup tool helps confirm the domain points where you expect before you debug certificates.

Run your own domain through the SSL Checker now and see what comes back. The other free tools are on pixelvalut.com.

What's the strangest SSL issue you've had to debug? Share it in the comments.

ssl #https #security #webdev #devops #tls #cybersecurity #sysadmin #nginx #webdevelopment #privacy #infosec

Which ATS Is This Job Using? How to Tell From the Job Link (and What to Do Differently)

Muhammad Ali Mughal — Sat, 24 Oct 2026 01:36:35 +0000

You found a job you want, clicked Apply, and landed on a form you've never seen before. Maybe it wants you to create an account. Maybe it fills in your work history from your resume and gets half of it wrong. Maybe it's a single page with an upload button and nothing else.

I'm Muhammad Ali Mughal, and I built Smart Resume Analyzer, a free AI resume and ATS checker. One question I see a lot is "which ATS is this company using, and does it change what I should do?" The short answer: you can usually tell from the job link in a few seconds, and while it doesn't change what a good resume looks like, it does change how you should handle the application. Here's how I check, and what I do differently for each type of system.

Why bother knowing the system?

An applicant tracking system (ATS) is the software a company uses to post jobs, collect applications and move candidates through hiring stages. Knowing which one sits behind a posting helps you:

Expect the right process. Some systems ask you to create an account per employer; others take an upload and an email address.
Catch parsing mistakes. Systems that pre-fill a profile from your resume show you exactly what they extracted. That's your chance to fix it before a recruiter sees it.
Plan your time. A long multi-page form with screening questions takes 20 to 40 minutes. A short form takes five. Knowing which you're facing helps you batch applications sensibly.

What it should not do is make you build a different resume for every vendor. The fundamentals work everywhere: one column, standard headings, real text (not images), and wording that matches the role.

Step 1: Read the job link

Most ATS vendors host job pages on their own domains. Look at the address bar on the job page or, better, on the page you reach after clicking Apply. Common patterns:

If the link contains...	It's usually...
`greenhouse.io` (e.g. `boards.greenhouse.io`, `job-boards.greenhouse.io`)	Greenhouse
`jobs.lever.co`	Lever
`myworkdayjobs.com` or `myworkdaysite.com`	Workday
`icims.com`	iCIMS
`taleo.net`	Oracle Taleo
`jobs.ashbyhq.com`	Ashby
`smartrecruiters.com`	SmartRecruiters
`apply.workable.com`	Workable
`bamboohr.com`	BambooHR
`jobvite.com`	Jobvite
`recruitee.com`	Recruitee
`teamtailor.com`	Teamtailor
`successfactors`	SAP SuccessFactors
`oraclecloud.com` with `CandidateExperience` in the path	Oracle Recruiting Cloud

If you don't want to memorise that table, I made a free tool for it: Which ATS Is This Job Using?. You paste the job link and it compares the host name and a few known address patterns against fifteen common systems. The check runs in your browser, nothing is fetched from the job page, and if it can't tell, it says "unknown" instead of guessing.

Step 2: If the link only shows the company, follow the Apply button

Large employers often run their careers site on their own domain (careers.company.com) and load the ATS inside it. The address then shows only the employer. Two quick ways to find the vendor anyway:

Click Apply and look again. The application step frequently moves you to the vendor's domain.
Look at the page footer and privacy links. Many hosted job boards include a small "Powered by" line or link to the vendor's privacy notice.

If you still can't tell, that's fine. Apply with your standard ATS-friendly resume and treat it as an unknown system.

Step 3: Adjust how you apply, not what you are

Here's how I approach the main families of systems. These are patterns I've seen, not promises about any single employer's configuration, because companies customise their setups heavily.

Profile-builder systems (Workday, Taleo, SuccessFactors, Oracle)

These usually ask you to create an account, upload your resume, and then review a long form that has been pre-filled from it.

Check every pre-filled field. Dates, job titles and employers are commonly split or merged incorrectly. Fix them by hand. Recruiters often see the structured fields, not just your file.
Use standard section headings like "Work Experience," "Education" and "Skills" so the parser maps sections correctly.
Write dates consistently, for example "Mar 2022 – Present" throughout. Mixed formats are a common cause of scrambled history.
Keep a password manager entry per employer. Many of these portals create a separate account for each company, and you'll need it to check your status later.
Budget time for screening questions. Answer them carefully; knockout questions (work authorisation, location, required certifications) can filter you out before a human looks.

I wrote a dedicated Workday resume checker page because this is where I see the most parsing frustration.

Upload-and-go systems (Greenhouse, Lever, Ashby, Workable)

These tend to have shorter forms: name, email, resume upload, links, and a few custom questions.

Your resume file does most of the work. There's less structured data to correct, so the file itself needs to read cleanly.
Fill in the optional links. LinkedIn, GitHub or portfolio fields are quick wins for technical roles.
Treat custom questions like a mini cover letter. "Why this role?" answered in three specific sentences beats a pasted generic paragraph.
Mirror the posting's wording for skills and titles, because recruiters often search and filter candidates by keyword later.

Small-business systems (BambooHR, Recruitee, Teamtailor, Breezy)

Often used by smaller companies where the hiring manager reads applications directly.

Lead with relevance. Your summary and first bullets should speak to this exact role.
A short, tailored cover note matters more here, because a person is likely reading it soon.

Step 4: Test how your resume parses before you apply

Whatever the system, the most useful thing you can do is see your resume the way software sees it. Things that commonly break parsing:

Two-column layouts where the reading order gets mixed up
Contact details placed in the document header or footer
Skills shown as icons, progress bars or images
Tables used to lay out the whole page
Unusual section names like "My Journey" instead of "Experience"

Run your file through an ATS parser and read the plain-text output. If your job titles, dates and employers come out in the right order, you're in good shape for nearly every system on the list above.

My quick pre-apply routine

Paste the job link into the ATS detector.
If it's a profile-builder system, set aside extra time to review every pre-filled field.
Check the resume's parsed text.
Compare the resume against the job description for missing keywords.
Apply, then log the company, role, system and date so I can follow up.

Try it on the next job you're about to apply for: paste the link into the ATS detector, then run your resume through the free checker on smartresumeanalyzer.com.

Which application system frustrates you most? Tell me in the comments and I'll cover it in more detail.

resume #jobsearch #ats #careeradvice #resumetips #jobhunting #hiring #careers #workday #techjobs #career #productivity

Planning a VoIP Phone System for a Small Business: An Asterisk and FreePBX Checklist

Muhammad Ali Mughal — Fri, 23 Oct 2026 20:56:52 +0000

When a small business asks me for a "phone system," the first conversation is rarely about phones. It's about missed calls at lunchtime, a sales team that works from home two days a week, and an owner who has no idea how many customers hung up while on hold last month.

I'm Muhammad Ali Mughal, and at Loop Origin, our Karachi-based team builds web applications and also designs and deploys VoIP phone systems on Asterisk and FreePBX. The single biggest lesson from those projects: a phone system succeeds or fails on planning, not on the software. Asterisk can do almost anything. The question is what your business actually needs it to do.

This is the planning checklist I walk through with clients before anyone installs a server. You can use it whether you hire someone, go with a hosted cloud PBX, or build it yourself.

First, a quick map of the options

Asterisk is the open-source telephony engine underneath many PBX systems. It's extremely flexible, configured through text files and dialplan logic.
FreePBX puts a web interface on top of Asterisk, so day-to-day changes (adding an extension, editing business hours) don't need the command line.
Hosted cloud PBX services run the system for you. Less control and customisation, but less to maintain.

For most small offices, FreePBX on Asterisk hits a good balance: a GUI for routine changes and the full power of Asterisk when you need custom behaviour. If you need deep integration with your own software, raw Asterisk dialplan or its APIs become more attractive. We compared the two in more detail in a separate post on Asterisk vs FreePBX.

Step 1: Draw your call flow on paper

Before talking about hardware, answer one question: what should happen when someone calls your main number? Sketch it as a tree:

Call arrives. Is it within business hours?
If yes, play a short greeting and an IVR menu: "Press 1 for sales, 2 for support, 3 for accounts."
Each option goes to a ring group (all phones ring at once) or a queue (callers wait in line for the next free agent).
If nobody answers within a set time, what then? Voicemail? Overflow to a mobile? Back to the main menu?
Outside business hours, play a closed message and offer voicemail, or route urgent calls to an on-call number.

Keep the IVR short. Three or four options is plenty, and the most common reason for calling should be option 1. Every extra menu level loses callers.

Step 2: Count calls, not just people

People size phone systems by headcount ("we have 12 staff"). What actually matters is concurrent calls: how many conversations happen at the same moment, at your busiest time.

A 12-person office where only four people are ever on the phone together needs capacity for roughly four to six simultaneous calls, not twelve. This number drives:

How many channels you need from your SIP trunk provider
Your internet bandwidth requirements
The server size (though a small office PBX needs surprisingly modest hardware)

If you have an existing system or mobile bills, check last month's busiest hour. That's a better guide than any rule of thumb.

Step 3: Choose how calls reach you (SIP trunks)

A PBX handles calls inside your business; a SIP trunk connects it to the outside phone network. When choosing a provider, confirm:

Number availability for the cities or countries you need
How many concurrent channels you get
Calling rates for the destinations you actually call
Whether you can keep (port) your existing numbers
Support hours and how outages are handled

Carrier charges are separate from the cost of setting up the PBX itself, so get those quotes independently. Rules around telecom services, call recording and outbound calling differ by country, so check what applies to you with your provider before you go live.

Step 4: Decide where people will answer

Modern PBX setups don't tie anyone to a desk:

Desk IP phones for reception and anyone on the phone all day
Softphones on laptops (Zoiper and similar apps)
Mobile softphone apps for staff on the move
WebRTC browser phones, where agents answer inside a web page with a headset, with no installation needed

For remote agents, plan for NAT and firewall issues early. Most "one-way audio" complaints come down to network configuration. Using a VPN or properly configured STUN/TURN for WebRTC saves a lot of frustration later.

Step 5: Plan integrations from day one

This is where a custom setup earns its keep. Ask what you'd like the phone system to know about:

Click-to-call from your CRM or admin panel
Screen-pop: when a call comes in, show the customer's record before anyone answers
Automatic call logging against the customer, with duration and outcome
Webhooks so your app can react to events (missed call: create a follow-up task)
Call recordings linked to the customer record, with clear retention rules

Because we build Laravel applications as well as PBX systems, this is the part I enjoy most. A missed call that automatically creates a follow-up task in your CRM is worth more than any fancy IVR.

Step 6: Don't skip reliability and security

A PBX connected to the internet is a target. Toll fraud, where attackers make expensive international calls through your system, is a real risk. Minimum precautions:

Strong, unique SIP passwords; never use extension numbers as passwords
Fail2ban or similar blocking of repeated failed registrations
Firewall rules that allow SIP only from your trunk provider and known locations
International calling restricted to the extensions that need it
Regular updates and configuration backups

For reliability, decide what happens if your internet or server goes down. A common approach is a failover route that forwards your main number to mobiles during an outage. Test it before you need it.

Step 7: Measure after go-live

The point of all this is better customer service, so measure it. Useful numbers from call logs and queue reports:

Missed and abandoned calls by hour of day
Average wait time in each queue
Calls per agent and average call duration
After-hours call volume (often a surprise)

Review these after the first month. You'll almost always tweak something: a ring timeout that's too long, a menu option nobody uses, or a lunchtime gap that needs cover.

A planning checklist you can copy

Call flow drawn for business hours and after hours
IVR limited to 3-4 options, most common first
Peak concurrent calls estimated
SIP trunk provider chosen; numbers, channels and porting confirmed
Answering devices decided: desk phones, softphones, WebRTC
CRM or web app integrations listed
Security basics in place: passwords, firewall, fail2ban, calling restrictions
Outage failover planned and tested
Reporting reviewed after 30 days

Where to go from here

If you're planning a business phone system, start with Step 1 on paper this week. It costs nothing and makes every later conversation easier.

If you'd like help scoping or deploying it, our VoIP & PBX solutions page explains what we set up: IVR and call routing, outbound dialers, Asterisk and FreePBX deployments, WebRTC remote agents, and CRM integration. You can see the rest of our work at looporigin.com.

What's the biggest phone headache in your business right now: missed calls, remote staff, or zero visibility? Let me know in the comments.

voip #asterisk #freepbx #smallbusiness #pbx #callcenter #webrtc #telecom #sip #businessphone #laravel #pakistan #karachi

How to Check SPF, DKIM and DMARC Records in 10 Minutes (and Fix the Common Mistakes)

Muhammad Ali Mughal — Fri, 23 Oct 2026 20:55:57 +0000

Here is a deliverability problem I see a lot: a business says its invoices "just stopped arriving," and nothing changed on their side. When you look at their DNS, you find two SPF records, a DKIM key that was never published, and no DMARC record at all. The mail isn't broken. It just can't prove it's theirs, so receiving servers stop trusting it.

I'm Muhammad Ali Mughal, and I built PixelValut, a set of free developer and network tools that includes DNS, MX, SPF, DKIM and DMARC checkers. I use them for exactly this kind of debugging. This guide walks through how to check a domain's email authentication records yourself in about ten minutes, what each record should look like, and the mistakes I see most often.

The 60-second version

Three DNS records work together to prove an email really came from your domain:

SPF lists which servers are allowed to send mail for your domain.
DKIM adds a cryptographic signature to each message; the public key lives in DNS.
DMARC tells receivers what to do when SPF or DKIM fail, and where to send reports.

All three are TXT records. You don't need special access to check them. Anyone can look them up, which is also why attackers check them before spoofing a domain.

Step 1: Find out who sends mail for you

Before checking records, make a list of everything that sends email as your domain. People usually forget half of it:

Your mailbox provider (Google Workspace, Microsoft 365, Zoho, etc.)
Your website or app (Laravel, WordPress, a contact form plugin)
Transactional email services (password resets, receipts)
Marketing and newsletter tools
Helpdesk, CRM and invoicing software

Every one of these needs to be covered by SPF, DKIM or ideally both. Missing one is the most common reason legitimate mail fails DMARC later.

Step 2: Check your MX and TXT records

Start with a general DNS lookup on your root domain and select MX and TXT. The MX records tell you which provider receives your mail, which is a good hint about who should also be in your SPF record.

In the TXT results, look for a line starting with v=spf1. That's your SPF record. You'll often see other TXT records too (domain verification tokens and so on). Those are fine; only the v=spf1 one matters here.

Step 3: Validate SPF

A healthy SPF record looks something like this:

v=spf1 include:_spf.example-mail.com include:mailer.example.net -all

Run your domain through the SPF record checker. It follows the include: and redirect= chains and counts DNS lookups. Here's what to look for:

Only one SPF record. If you have two TXT records that start with v=spf1, SPF evaluation returns an error. Merge them into a single record.

Ten DNS lookups or fewer. The SPF spec caps evaluation at 10 DNS-querying mechanisms (include, a, mx, exists, redirect, including nested ones). Each third-party service you add can bring several lookups with it. Go over 10 and receivers return a permanent error, which usually means SPF fails. Remove services you no longer use, and avoid ptr entirely.

A sensible ending. -all means "anything not listed should fail." ~all means "soft fail." ?all is neutral and +all lets the whole internet send as you. Never use +all. If you're unsure everything is listed, start with ~all and tighten later.

Every sender covered. Compare the includes against your list from Step 1.

Step 4: Check DKIM

DKIM is trickier to inspect because the record lives at a selector:

selector._domainkey.yourdomain.com

The selector is chosen by whoever signs your mail. To find it, open a message you sent, view the original or full headers, and find the DKIM-Signature header. The s= value is the selector and d= is the signing domain.

Then put the selector and domain into the DKIM record checker. You want to see:

A record that exists and starts with v=DKIM1 (the version tag is optional but common)
A public key in the p= tag. An empty p= means the key has been revoked.
A reasonable key size. 2048-bit RSA is a good baseline; 1024-bit keys are increasingly considered weak.
No leftover t=y testing flag if you've finished setting things up

Each sending service usually has its own selector, so check each one. If a service offers DKIM signing with your domain and you haven't enabled it, that's worth fixing. DKIM survives forwarding better than SPF does.

Step 5: Read your DMARC policy

DMARC lives at a fixed location:

_dmarc.yourdomain.com

A typical starting record:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; adkim=r; aspf=r

Check it with the DMARC checker, which reads the policy tag by tag. The key tags:

p= is the policy: none (monitor only), quarantine (send to spam), or reject (block).
rua= is where aggregate reports go. Without it you're flying blind.
sp= sets a policy for subdomains if it should differ.
adkim= / aspf= control alignment: relaxed (r) or strict (s).
pct= applies the policy to a percentage of failing mail during rollout.

The part people miss: alignment

DMARC doesn't just ask "did SPF or DKIM pass?" It asks whether they passed for the same domain as the visible From address. If your newsletter tool passes SPF for its own bounce domain but doesn't sign with DKIM for your domain, the message can pass SPF and still fail DMARC. That's why enabling custom-domain DKIM on every service matters so much.

Step 6: Roll out DMARC safely

Jumping straight to p=reject is how companies block their own invoices. The rollout I recommend:

p=none with rua reporting for two to four weeks. Read the reports and find every legitimate source that fails.
Fix SPF and DKIM for those sources.
Move to p=quarantine, optionally with pct=25, then raise it.
When reports are clean, move to p=reject.

Aggregate reports are XML files, and a single day can contain dozens of sending IPs. A DMARC report analyser helps a lot, but even skimming the source IPs and pass/fail counts will show you what you missed.

Common mistakes I keep seeing

Two SPF records after adding a new tool. Always edit the existing record.
Too many includes, pushing SPF over 10 lookups.
DKIM published on the wrong host, like selector._domainkey.yourdomain.com.yourdomain.com because the DNS panel already appends the domain.
DMARC at p=none forever. Monitoring is a phase, not a destination.
Forgetting parked domains. Domains that never send mail should publish v=spf1 -all and a p=reject DMARC record so nobody can spoof them.
Not re-checking after DNS changes. TTLs mean old values can linger for a while; check again after the TTL expires.

A quick checklist

One SPF record, starting with v=spf1, under 10 lookups, ending in ~all or -all
DKIM enabled for every sending service, keys published and at least 2048-bit where possible
DMARC record at _dmarc with a rua address
Plan in place to move from none to quarantine to reject
Non-sending domains locked down

Wrapping up

Email authentication looks intimidating because it's three acronyms and a lot of semicolons. In practice it's a short checklist, and you can audit any domain with public lookups. I keep these checks on pixelvalut.com because I needed them myself for client work, and they're free with no signup. Start with the SPF record checker, then follow the DKIM and DMARC steps above.

If you want to find it again later, bookmark PixelValut.

Have you ever tracked down a deliverability problem to a DNS record? I'd love to hear the story in the comments.

emailsecurity #dns #devops #sysadmin #spf #dkim #dmarc #cybersecurity #emaildeliverability #webdev #infosec #devtools

How to Tailor Your Resume Keywords to a Job Description (Without Keyword Stuffing)

Muhammad Ali Mughal — Fri, 23 Oct 2026 20:54:57 +0000

Most job seekers I talk to have one resume. They send that same file to a backend role, a full-stack role and a DevOps-flavoured role in the same afternoon, then wonder why nothing comes back.

I'm Muhammad Ali Mughal, and I built Smart Resume Analyzer, a free AI resume and ATS checker. After looking at a lot of resumes next to the job posts they were sent to, the pattern is hard to miss: the resume often describes the right experience in the wrong words. A recruiter searching the ATS for "PostgreSQL" won't find you if your resume only says "databases."

Tailoring fixes that. It doesn't mean rewriting your life story for every application. It means spending 20 to 30 minutes making sure the words in the posting that genuinely describe you also appear in your resume, in the places that matter. Here's the process I use.

Why exact wording matters

Applicant tracking systems store your resume as text. Recruiters then filter and search that text, often by skills, job titles and tools. Some systems are smarter about synonyms than others, but you can't know which one you're dealing with, so the safest assumption is simple: if the posting says it and you have it, say it the same way.

Humans skim too. A hiring manager gives a resume a few seconds on the first pass. When the first third of the page mirrors the language of their own job description, it reads as a fit before they've thought about it.

Step 1: Pull the keywords out of the posting

Copy the full job description into a plain text file, then sort what you find into four buckets:

Hard skills and tools: languages, frameworks, platforms, certifications (Python, React, AWS, Kubernetes, Tableau, PMP).
Job titles and role terms: "Senior Backend Engineer," "Product Analyst," "Customer Success Manager."
Domain words: "payments," "B2B SaaS," "healthcare compliance," "high-traffic e-commerce."
Soft skills tied to outcomes: "stakeholder management," "mentoring," "cross-functional delivery."

Pay attention to where each term appears. Words under "Requirements," "Must have" or "Minimum qualifications" matter more than words under "Nice to have." Words that repeat across the responsibilities and the requirements are usually the core of the role.

If you'd rather not do this by hand, I built a free job description keyword finder that runs in your browser. Paste the posting, and it groups possible keywords and flags terms tied to requirement cues. You can also paste your resume to see the text overlap. Treat its output as a starting list, not as the employer's secret scoring rules. Always check each term against the original wording.

Step 2: Mark what you genuinely have

Go through your list and mark each keyword:

Have it, already on my resume (same wording)
Have it, but worded differently (you wrote "CI pipelines," they wrote "GitHub Actions")
Partially have it (used it on one project, not in production)
Don't have it

The second group is where most of the easy wins are. The last group is where people get into trouble. Never add a skill you don't have. It might get you past a filter, but it will come apart in the first technical interview, and that's a worse outcome than not getting the call.

Step 3: Put keywords where they carry weight

Dumping 40 terms into a skills section is the most common mistake I see. It looks like a keyword list because it is one. Instead, spread the important terms across three places:

Your headline and summary

The top of the page should use the job title from the posting (if it honestly matches your level) and two or three of its core requirements.

Before:

Software engineer with experience building web applications.

After:

Backend engineer with 4 years building Python and PostgreSQL services for payments products, focused on API reliability and performance.

Same person, same experience. The second version just speaks the posting's language.

Your experience bullets

This is where keywords prove themselves. A skill mentioned inside a real accomplishment is far more convincing than a skill in a list.

Before:

Built reporting tools for the support team.

After:

Built Python reporting scripts and SQL queries used daily by the support team, cutting weekly report prep from 5 hours to 1.

Only include numbers you can back up. If you don't have a metric, describe the scope instead (team size, number of users, frequency).

Your skills section

Use this for exact-match coverage of the tools you really use. Group them so a human can scan it: Languages, Frameworks, Cloud & DevOps, Data. Include both the acronym and the full term once where it's common, for example "Amazon Web Services (AWS)" or "Search Engine Optimization (SEO)."

Step 4: Match the posting's spelling and format

Small differences can matter to a text search:

Spelling and casing: "Node.js" vs "NodeJS," "PostgreSQL" vs "Postgres." Use the version in the posting.
Singular vs plural and verb forms: "data pipeline" vs "data pipelines." Not usually a dealbreaker, but mirroring is free.
Certifications: write the full official name at least once.
Job titles: if your official title was unusual ("Engineer II, Platform Squad"), you can add a clarifying title in brackets, for example "Engineer II (Backend Engineer)," as long as it's accurate.

Step 5: Keep it readable for humans

A tailored resume should read better, not worse. A quick self-check:

Does each bullet still say what you did and why it mattered?
Does any keyword appear so often it sounds robotic? Two or three natural mentions of a core skill are plenty.
Could you talk comfortably for two minutes about every skill on the page?

If a sentence only exists to hold a keyword, rewrite it or delete it.

Step 6: Check the match before you send

Once you've edited, compare the resume against the posting one more time. Look for required terms you have but still haven't mentioned, and for formatting that might trip up parsing (tables, text in headers, multi-column layouts, skills inside images).

This is exactly the loop I built Smart Resume Analyzer for. You upload your resume, paste the job description, and it shows an ATS-style score, missing keywords and suggestions for rewording. I use it as a final check, then I read the resume once more as a human before sending.

Make tailoring fast: the base + variant method

Tailoring every application from scratch is exhausting. What works better:

Keep one master resume with every project, tool and metric you could ever use. It can be three pages; nobody sees it.
Create a base version for each type of role you apply to (for example "backend," "data engineering").
For each application, copy the closest base and spend 20 minutes on Steps 1 to 6.
Save each version with the company and role in the file name so you know what you sent.

After the first few, you'll find that most postings in your field share 70 to 80 percent of their keywords. Tailoring becomes a short edit rather than a rewrite.

A quick checklist

Keywords pulled from the posting and sorted by importance
Job title and two or three core skills in the headline or summary
Key skills proven inside experience bullets
Spelling matches the posting (Node.js, PostgreSQL, etc.)
Acronym and full term used once for common terms
No skills you can't defend in an interview
Simple single-column layout, standard section headings
Final match check against the posting

Try it on your next application

Pick the job you most want right now and run through this once. Start with the keyword finder, make your edits, then run the result through the full checker on smartresumeanalyzer.com. The checker and keyword finder are free to use.

If you want to find it again later, just bookmark Smart Resume Analyzer.

What's the hardest part of tailoring for you: finding the keywords, or fitting them in without sounding forced? Tell me in the comments.

resume #jobsearch #ats #careeradvice #resumetips #jobhunting #hiring #careers #interviewtips #techjobs #career #productivity

Launching an Online Store in Pakistan: A Practical Guide to Platforms, Payments, COD, and Hosting

Muhammad Ali Mughal — Fri, 23 Oct 2026 15:06:36 +0000

Every month I talk to Pakistani business owners who want to sell online. A clothing brand in Karachi that's outgrown Instagram DMs. A wholesaler in Lahore tired of taking orders on WhatsApp. A home-based bakery that wants a proper checkout.

I'm Muhammad Ali Mughal, and I run Loop Origin, a Karachi-based team that builds e-commerce stores, custom web apps, and the servers they run on. The questions I hear are almost always the same: Which platform? Which payment gateway? What about cash on delivery? Where do I host it?

This guide answers those questions plainly, including when you don't need a custom build.

Step 1: Decide what kind of store you actually are

Before picking technology, be honest about where your business is today:

Testing the market (under ~50 products, a few orders a day): you need something live this month, cheaply.
Growing retail brand (hundreds of SKUs, sizes and colors, flash sales): you need solid variant and inventory handling, and a checkout that doesn't leak orders.
B2B or wholesale (buyer-specific pricing, minimum order quantities, order approvals): standard storefronts start fighting you here.

Your answer drives every decision below.

Step 2: Choose a platform: Shopify vs WooCommerce vs custom Laravel

There's no universally "best" platform. Here's how I explain the trade-offs to clients.

Shopify

Good for: getting started quickly with minimal technical work.

Hosted for you, with polished themes and a big app ecosystem.
Monthly subscription in USD, plus app fees that add up. Exchange-rate swings make that bill unpredictable.
Shopify Payments isn't available for Pakistani merchants, so local payments depend on third-party apps or manual methods.
You're limited to what the platform and apps allow, especially at checkout.

WooCommerce (WordPress)

Good for: small to mid-size stores with a budget for a decent developer.

Free core software, huge plugin library, and plenty of local developers.
Performance and security depend heavily on hosting and plugin discipline. Twenty plugins from twenty authors is a maintenance risk.
Fine for a lot of stores, as long as someone keeps it updated.

Custom Laravel store

Good for: businesses whose workflows don't fit a template, or stores scaling past what plugins handle well.

Built around your catalog, checkout, and operations, with no plugin bloat.
You own the code, with full control over pages, checkout steps, and integrations (couriers, ERP, WhatsApp, SMS).
Higher upfront cost and longer timeline. At Loop Origin, a standard custom store starts from PKR 250,000 and usually takes 6 to 10 weeks.

My honest rule of thumb: if you're still testing whether people will buy, start with Shopify or a well-built WooCommerce site. Move to custom when COD returns, variant chaos, wholesale rules, or plugin conflicts start costing you real money. I wrote a deeper comparison here: Laravel vs WordPress for e-commerce in Pakistan.

Step 3: Set up payments that Pakistani customers actually use

Mobile wallets: JazzCash and Easypaisa

Millions of Pakistanis pay with mobile wallets, and both JazzCash and Easypaisa offer merchant payment gateways for websites. Practical notes:

Start the merchant onboarding early. You'll typically need business documents and a bank account, and approval can take a while. Don't leave it for launch week.
Integrate webhooks or payment callbacks properly. A customer closing the browser after paying shouldn't leave the order stuck as "pending." Your server should confirm payment status directly with the gateway.
Test in sandbox first, including failed and cancelled payments, not just the happy path.

Cards

Many Pakistani banks and payment service providers offer card acceptance for merchants. If you sell internationally, Stripe may be an option depending on where your business is registered. Check eligibility before you design around it.

Cash on delivery (COD)

For most Pakistani retail stores, COD is still a huge share of orders. Ignore it and you lose customers. Handle it carelessly and you lose money on returns.

Ways to keep COD healthy:

Confirm orders before dispatch. An automated WhatsApp or SMS confirmation (or a quick call for high-value orders) filters out fake and impulse orders.
Track return rates by city and customer. Repeat refusers should be moved to prepaid-only.
Offer a small discount for prepaid orders to nudge customers toward wallets and cards.
Show delivery charges and timelines clearly on the product page, not as a surprise at checkout.

There's more on this in my guide to COD e-commerce in Pakistan.

Step 4: Connect couriers and inventory early

Couriers like TCS, Leopards, PostEx, and Trax offer APIs or merchant portals for booking and tracking. Integrating early saves hours of copy-pasting addresses. At minimum, your store should:

Generate shipping labels or booking requests from the order screen.
Store tracking numbers and show them to customers.
Update stock automatically when orders are placed, cancelled, or returned.
Alert you when a size or color is running low.

Inventory mistakes, like selling an item you don't have, hurt trust more than slow delivery does.

Step 5: Choose hosting that matches your traffic

Shopify: hosting is included.
WooCommerce: avoid the cheapest shared hosting. A slow checkout loses orders. A small VPS or quality managed WordPress host is worth it.
Laravel: a properly configured VPS or cloud server (Nginx, SSL, Redis for caching and queues, automated backups, uptime monitoring).

Whatever you choose, insist on three things: SSL everywhere, daily off-site backups, and monitoring that alerts someone when the site goes down. For the trade-offs, see VPS vs shared hosting in Pakistan.

Step 6: Get the basics right before launch

A pre-launch checklist I use with clients:

[ ] Mobile-first product pages that load fast on 4G
[ ] Clear size charts, real product photos, and visible prices in PKR
[ ] Delivery charges, timelines, and return policy published
[ ] Wallet payments tested in sandbox and with a small live transaction
[ ] COD confirmation flow working
[ ] Courier booking and tracking tested end to end
[ ] Order confirmation emails and SMS/WhatsApp messages working
[ ] Google Analytics or similar installed; Search Console verified
[ ] Backups and uptime monitoring confirmed

When a custom build makes sense

You probably need a custom store if:

You're paying for a stack of apps or plugins just to make checkout work.
You sell wholesale with buyer-specific pricing or approval workflows.
You need deep integrations with an ERP, POS, or warehouse system.
Your COD returns are high and you need confirmation and blacklisting logic built in.

That's exactly the kind of work we do at Loop Origin. You can see what's included on our e-commerce website development page. Examples include a COD-first clothing storefront and a B2B wholesale platform.

If you want to find us later, bookmark Loop Origin.

Final thought

The platform matters less than people think. What wins in Pakistan is a store that loads fast on mobile, takes the payments people actually use, confirms COD orders, and ships reliably. Get those four right, on whatever platform fits your stage, and you're ahead of most competitors.

What's the biggest hurdle you've hit selling online in Pakistan? Payments, COD returns, or couriers? Tell me in the comments.

ecommerce #Pakistan #onlinestore #Laravel #webdevelopment #JazzCash #Easypaisa #cashondelivery #Shopify #WooCommerce #Karachi #smallbusiness #ecommercePakistan #startup #digitalPakistan

How to Hide a Secret Message Inside an Image: A Practical Guide to Steganography

Muhammad Ali Mughal — Fri, 23 Oct 2026 15:05:50 +0000

Encryption hides what a message says. Steganography hides the fact that there's a message at all.

I'm Muhammad Ali Mughal, and I built PixelValut, a browser-based tool for hiding text inside images. While building it, I learned that most people get two things wrong about steganography. Some think it's magic, and some think it's useless. It's neither. It's a simple technique with real strengths and real limits, and once you see how it works you'll know when to use it.

This guide covers what image steganography is, how to hide a message step by step, where it's actually useful, and the mistakes that quietly destroy hidden data.

What image steganography actually is

Steganography means "covered writing." The digital version tucks data inside an ordinary-looking file, usually an image, so that anyone looking at it sees a normal photo.

The most common method is LSB (least significant bit) embedding. Here's the idea:

Every pixel in a typical image has three color channels: red, green, and blue.
Each channel is a number from 0 to 255, stored as 8 bits.
The last bit of each number (the least significant bit) barely affects the color. Changing a red value from 200 to 201 is invisible to the human eye.

So you take your message, turn it into bits, and write those bits into the last bit of each color channel. The picture looks the same. The data is there for anyone who knows to read it back.

How much can you hide?

With one bit per channel, you get 3 bits per pixel. That adds up quickly:

Image size	Pixels	Approx. capacity
800 × 600	480,000	~175 KB
1920 × 1080	~2.07 million	~750 KB
4000 × 3000	12 million	~4.3 MB

Real tools reserve a little space for a header (message length, format markers), and encryption adds some overhead, but for text you'll almost never run out of room. A full page of text is only a few kilobytes.

Why you should encrypt before you hide

LSB embedding on its own is not security. It's obscurity. Anyone who suspects an image contains data can run a standard extraction script and read raw LSB bits. If your message is plain text, it falls right out.

That's why I designed PixelValut to encrypt the message with AES-256 (using the browser's Web Crypto API) before embedding it. Now there are two layers:

Steganography hides the existence of the message.
Encryption protects the content if someone finds it anyway.

Without the password, extracted bits look like random noise, which is exactly what LSB data in a natural photo should look like.

How to hide a message in an image, step by step

Whether you use PixelValut or another tool, the workflow is the same.

Step 1: Pick the right cover image

This matters more than people think.

Use a photo with lots of natural detail: foliage, gravel, clouds, textured walls. Busy images hide changes better than flat ones.
Avoid big areas of solid color like a plain sky gradient or a logo on white. Statistical tools can spot LSB changes more easily in smooth regions.
Use an original photo you took, not a famous image from the internet. If someone has the original, comparing the two files reveals that something changed.

Step 2: Write your message and choose a strong password

Keep the message plain text. For the password, use a long passphrase (four or five random words) or a generated password. A random password generator helps here. The encryption is only as strong as the password protecting it.

Step 3: Embed the message

Upload the cover image, paste your message, enter the password, and run the encode step. The tool converts your message to bits, encrypts it, and writes it into the pixel data.

Step 4: Download as PNG, and keep it PNG

This is the step that breaks most hidden messages. Save and share the output as PNG. PNG is lossless, so every bit you wrote stays exactly where you put it.

JPG is lossy. When an image is saved or re-saved as JPG, the compression changes pixel values slightly. That's harmless to the eye and fatal to LSB data.

Step 5: Test the round trip before you send it

Before sharing the image, decode it yourself: upload the PNG, enter the password, and confirm the message comes back intact. It takes 30 seconds and saves a lot of confusion.

Step 6: Share the password through a different channel

If you send the image by email, don't put the password in the same email. Share it in person, over a call, or through a separate messaging app.

Where steganography is actually useful

Steganography isn't just for spy movies. Practical uses I've seen:

Watermarking and proof of ownership. Photographers and designers embed an invisible signature or ID in their work. If the image gets reposted, you can prove where it came from.
Tamper detection. If the hidden data no longer decodes correctly, you know the image was edited or re-compressed.
Private notes in plain sight. Some people store an encrypted note (a recovery phrase hint, a private journal entry) inside an ordinary photo in their gallery.
Teaching security concepts. It's a great hands-on way to show students how binary, color channels, and encryption work together.
CTF challenges and puzzles. Capture-the-flag competitions love hidden messages in images.

Limitations you need to know

Being honest about limits is part of using any security tool well.

Social media will destroy your message

Facebook, Instagram, WhatsApp (in normal photo mode), X, and most messaging apps re-compress uploaded images. They resize them, convert them to JPG, and strip metadata. Your hidden data won't survive.

To keep the data intact, send the image as a file or document rather than as a photo, or use cloud storage links and email attachments that keep the original file.

Editing breaks it too

Cropping, resizing, filters, rotation, and screenshots all rewrite pixel values. Treat the output image as read-only.

Detection is possible

Steganalysis tools can detect LSB embedding statistically, especially with large payloads in smooth images. Steganography reduces attention; it doesn't make detection impossible. Keep payloads small relative to image size, and rely on encryption for actual confidentiality.

It's not a replacement for proper secure messaging

If you just need private communication, an end-to-end encrypted messenger is the right tool. Steganography makes sense when you specifically need the message to be invisible, or when you're watermarking, verifying, or learning.

Quick security checklist

Before you hide anything important, run through this:

[ ] Original, detailed photo (not a downloaded image, not flat colors)
[ ] Message encrypted with a strong, unique password
[ ] Output saved as PNG
[ ] Round-trip decode tested
[ ] Sent as a file, not through a photo uploader that re-compresses
[ ] Password shared over a separate channel
[ ] Original cover image deleted if you don't want comparisons possible

Try it yourself

If you want to experiment, PixelValut lets you hide and reveal AES-encrypted text in images, with processing done in your browser. I also wrote a shorter walkthrough on the site: how to hide messages in images. Alongside steganography, the site has free developer utilities like DNS and MX lookups, a JWT decoder, and an SSL checker that I use in my own work.

If you're looking for it later, just bookmark PixelValut.

Have you used steganography for watermarking, CTFs, or something unusual? I'd like to hear about it in the comments.

steganography #cybersecurity #infosec #privacy #encryption #cryptography #datasecurity #AES256 #imagesecurity #hiddenmessage #digitalwatermark #CTF #websecurity #devtools #ethicalhacking

DEV Community: Muhammad Ali Mughal

Laravel Interview Questions With Answers From Real Projects

Laravel interview questions on Eloquent and the database

1. What is the N+1 query problem, and how do you fix it?

2. When would you use chunkById() instead of get()?

3. How do you prevent two requests from overselling stock?

4. $fillable or $guarded?

5. How do you write a migration that's safe on a large production table?

Laravel interview questions on queues and performance

6. A queued job runs twice. Why, and what do you do?

7. Why doesn't my deployed fix take effect in queued jobs?

8. How do you rate-limit calls to a third-party API from jobs?

9. What do you cache, and how do you invalidate it?

Laravel interview questions on architecture and security

10. How does the service container help you?

11. Middleware, policies or gates for authorisation?

12. Where should business logic live?

13. How do you protect a Laravel app against common attacks?

Testing and debugging questions

14. How do you test code that sends emails or calls APIs?

15. A page got slow in production. Walk me through it.

How to prepare: a quick checklist

FAQ

What Laravel interview questions are asked for experienced developers?

How should I prepare for a Laravel technical interview?

What are the most common Laravel performance questions?

Do Laravel interviews include live coding?

Should I learn Livewire or Inertia before a Laravel interview?

Hiring a Laravel team instead?

laravel #php #interview #career #webdev #backend

How to Prevent Double Booking: Locks, Holds and Expiry

Why "check, then insert" double-books

The test: 20 concurrent requests for one slot

Fix 1: Prevent double booking with an exclusion constraint

Fix 2: Lock the parent row when capacity is more than one

Fix 3: Holds with expiry

Which fix to use

Double booking prevention checklist

FAQ

How do you prevent double booking in a database?

Is a unique index enough to stop double bookings?

What is the difference between optimistic and pessimistic locking for bookings?

How long should a booking hold last?

Can MySQL prevent overlapping bookings?

Need a booking system built?

systemdesign #postgresql #database #backend #laravel #architecture

How Long Should a Password Be? Password Entropy Explained

What password entropy means

How long should a password be? I ran the numbers

What NIST says about password length

Password length by use case

How to create a strong password in 3 steps

For developers: store passwords properly

Strong password checklist

FAQ

How long should a password be in 2026?

Is a 12-character password long enough?

Are passphrases better than passwords?

Do special characters make a password stronger?

How often should I change my password?

Generate one now

security #passwords #cybersecurity #privacy #infosec #webdev

How to Track Job Applications: A Simple System That Works

Why tracking job applications changes your results

Step 1: Choose one place to track job applications

Step 2: Set up the columns that matter

Step 3: Use a fixed list of statuses

Step 4: Log the resume version for every application

Step 5: Review the numbers every week

Step 6: Follow up on a schedule

Job application tracking checklist

FAQ

What is the best way to track job applications?

What columns should a job application tracker have?

How many job applications should I track at once?

When should I follow up on a job application?

Is a spreadsheet better than a job tracker app?

Start tracking today

jobsearch #career #resume #productivity #jobapplication #careeradvice

Running Laravel Queues in Production: Redis, Supervisor, Retries and Failed Jobs

2. When would you use `chunkById()` instead of `get()`?

4. `$fillable` or `$guarded`?