I build Smart Resume Analyzer, so I spend a lot of time looking at what extraction actually returns. I wrote this with help from AI tools and checked every command and claim myself. Every output below comes from files I generated and ran on my own machine today.

How do ATS parsers read your contact information?

Direct answer: Parsers extract plain text, find your name near the top, then match email, phone, location and URLs with patterns. Text inside Word headers, text boxes or icon fonts can be skipped or polluted, and phone numbers without a country code may not normalize. Put them in plain body text at the top, with a country code on the phone.

The fields your contact block feeds

Each field feeds something a recruiter or form depends on:

The last row catches many developers. A PDF can keep the link target, but plenty of extractors only keep visible text. If the visible text is just "GitHub", the parser gets the word, not your profile.

What I saw when I ran the extractors

I built three small test files with Python (python-docx and reportlab) and ran them through common open-source extractors. These are not any vendor's parser. They show what a text extraction layer, which every parser starts with, can do to your header.

Test 1: contact details inside the Word header area. The DOCX has the full contact line in the page header and the job content in the body. Reading body paragraphs with python-docx, and exporting to plain text with LibreOffice (soffice --convert-to txt), both returned the same thing:

Senior Backend Engineer
EXPERIENCE
Acme Payments, Backend Engineer, Jan 2021 - Present

The name, email, phone, city and LinkedIn URL are gone. Some commercial parsers do read header areas and some do not, and you cannot tell which one a given employer runs. Moving the block into the body removes the gamble.

Test 2: icons and a two-column banner in a PDF. Name on the left, contact details in a right-hand column with ✉, ☎ and ⌂ symbols. pdftotext -layout returned:

SARA KHAN                                             ✉ sara.khan@example.com
                                                      ☎ +92 300 1234567
Senior Backend Engineer
                                                      ⌂ Karachi
                                                      in/sarakhan

The job title is now wedged between the phone and the city, and every contact token carries a symbol prefix. Here the symbols came from a normal Unicode font, so they at least extract as characters. Icon fonts often map glyphs to Private Use Area code points, which extract as unreadable characters or nothing at all. And "in/sarakhan" is not a URL any pattern will recognize as LinkedIn.

Test 3: phone normalization. I ran the same numbers through Google's phonenumbers library (v9.0.42), the kind of normalization step many systems use to store E.164 numbers:

'0300-1234567'         region=None  -> ERROR (0) Missing or invalid default region.
'0300-1234567'         region=PK    -> +923001234567  valid=True
'+92 300 1234567'      region=None  -> +923001234567  valid=True
'(415) 555-0132'       region=None  -> ERROR (0) Missing or invalid default region.
'+1 415 555 0132'      region=None  -> +14155550132  valid=True

A local number only works when the system guesses your country correctly. With the + country code it parses with no guess at all. If you apply across borders, which many engineers in Pakistan, India and the Gulf do, the country code is not optional.

AI-generated image.

How each ATS uses what it extracts

Vendors do not publish parser internals, so this table sticks to what you can observe as an applicant:

To find out which platform a posting uses before you apply, see my guide on telling which ATS a job uses from the link.

Weak vs ATS-optimized contact headers

Rewrite 1: the designer banner

Weak:

[Header area] SARA KHAN  ✉ sara.khan@example.com | ☎ 0300-1234567 | 📍 Karachi | LinkedIn | GitHub

ATS-optimized (in the body, first lines):

Sara Khan
Senior Backend Engineer
Karachi, Pakistan (open to remote)
+92 300 1234567 | sara.khan@example.com
linkedin.com/in/sarakhan | github.com/sarakhan

Why it works: body text, no glyphs, a country code, a city and country, and visible URLs. The pipes are fine here because each side is a complete, recognizable token.

Rewrite 2: the remote-only location

Weak: Location: Remote

ATS-optimized: Lahore, Pakistan (open to remote, UTC+5)

Location filters need a place. "Remote" is a work arrangement, not a location, and a recruiter filtering on a country or time zone will skip a profile with no city.

Rewrite 3: the hidden links

Weak: Portfolio · GitHub · LinkedIn (each word hyperlinked)

ATS-optimized: sarakhan.dev | github.com/sarakhan | linkedin.com/in/sarakhan

If a human prints the PDF, or a parser keeps only visible text, the URLs survive.

Where the contact block should go

The 7-step contact header diagnostic

1. Extract the text yourself. Run pdftotext -layout resume.pdf - (poppler-utils), or paste the PDF into a plain-text editor. If your name is not on line 1, a parser may not find it either.
2. Check the header area. In Word, open the header. If anything important lives there, move it into the body.
3. Search for odd characters. Look for boxes, question marks or blank gaps where icons were. Delete every icon.
4. Normalize the phone. Write one number with a + country code. Remove second numbers unless the role demands it.
5. Write the location as a filterable place. City, country, plus "open to remote" or "open to relocation" if true.
6. Make every link visible. Use bare domains like github.com/you, and click each one to confirm it is public, not behind a login.
7. Compare against the form. After a Workday or Lever autofill, compare each field with your resume before you click Next.

Then run the file through an ATS parser preview to see the fields as a parser splits them. If other sections also come out scrambled, start with resume formatting mistakes that break ATS parsing, then check how ATS parsers normalize your skills.

Frequently asked questions

Should I put my contact information in the header of my resume?

Not in the Word or Google Docs header area. In my test, body-only extraction dropped it completely. Put the contact block in the first lines of the body. It looks the same to a human and removes the risk.

Do icons for email and phone hurt ATS parsing?

They can. Symbols attach to the token next to them, and icon fonts often extract as unreadable characters. Labels are optional; plain values are usually clear enough on their own.

Should I include my full address on a resume?

No. City and country are enough for location filters and recruiter decisions. A full street address adds privacy risk with no screening benefit.

How should I write my phone number for international applications?

Use one number in international format, such as +92 300 1234567. Without a country code, a normalization library has to guess your region and may reject the number.

Should I list "Remote" as my location?

List a city and country first, then add "open to remote". Location filters and time-zone checks need a real place to match against.

Do I need to write out the full LinkedIn URL?

Yes, a short visible form like linkedin.com/in/yourname. A hyperlinked word may lose its target in plain-text extraction, and a visible URL also works on paper.

Follow & Connect

• YouTube: Resume Boost AI (@resume-boost-ai)
• TikTok: Resume Boost AI (@resumeboostai)
• X: Muhammad Ali Mughal (@AliMughal887)
• GitHub: Muhammad Ali Mughal (@ali111887)
• LinkedIn: Muhammad Ali Mughal

At Loop Origin we build document-heavy B2B portals, from KYC onboarding to dealer ordering, and upload handling is part of every custom web application we design. This is the reference architecture I use, with production configuration for Node and Laravel, the cost trade-offs and the failure modes behind each control.

What is a secure file upload architecture for a SaaS app?

Direct answer: Upload directly to private object storage with short-lived presigned URLs that enforce size and type, land files in a quarantine bucket, scan and validate them asynchronously by content rather than extension, re-encode images, then promote clean files to a private bucket and serve them through short-lived signed URLs from a separate domain with download-safe headers.

The threat model

The metadata row is easy to underestimate; I showed what a single phone photo leaks in image metadata privacy leaks.

The reference flow

Browser ──(1) request upload──► API: authorize, create upload record, presign POST
Browser ──(2) POST file───────► quarantine bucket (private, expires after 7 days)
Storage ──(3) event───────────► queue ──► scan worker (isolated, no inbound network)
Worker:  magic bytes â–º size/structure â–º antivirus â–º re-encode images â–º strip metadata
Worker ──(4) clean────────────► files bucket (private)  + mark record "ready"
Worker ──(4) rejected─────────► delete + mark record "rejected" + alert
Browser ──(5) download────────► API: authorize per request ► 5-minute signed GET
                                 served from usercontent.example.net

Files never touch the app servers, and nothing is downloadable until the worker marks it ready.

Step 1: Presigned uploads that enforce limits

A presigned PUT URL only proves the client may write one key. A presigned POST policy can also enforce size and content type at the storage layer. In Node with AWS SDK v3:

import { S3Client } from '@aws-sdk/client-s3';
import { createPresignedPost } from '@aws-sdk/s3-presigned-post';
import { randomUUID } from 'node:crypto';

const s3 = new S3Client({ region: process.env.AWS_REGION });
const ALLOWED = new Set(['application/pdf', 'image/jpeg', 'image/png']);

export async function presignUpload({ tenantId, userId, contentType, size }) {
  if (!ALLOWED.has(contentType)) throw new Error('type_not_allowed');
  if (size > 15 * 1024 * 1024) throw new Error('too_large');

  const key = `quarantine/${tenantId}/${randomUUID()}`; // never the client filename
  const { url, fields } = await createPresignedPost(s3, {
    Bucket: process.env.UPLOAD_BUCKET,
    Key: key,
    Conditions: [
      ['content-length-range', 1, 15 * 1024 * 1024],
      ['eq', '$Content-Type', contentType],
    ],
    Fields: { 'Content-Type': contentType },
    Expires: 300,
  });
  await db.uploads.insert({ key, tenantId, userId, status: 'pending', declaredType: contentType });
  return { url, fields, key };
}

In Laravel 10 and later, Storage::disk('s3')->temporaryUploadUrl($key, now()->addMinutes(5)) returns a presigned PUT URL and headers. It is simpler, but enforce size with a bucket-side check in the worker because a PUT URL cannot carry a size range. For uploads that go through the app, validate with mimetypes: (content-based) rather than mimes: alone, and set max: in kilobytes.

Step 2: Validate by content, then scan

The scan worker runs on a separate small instance or container with no inbound network access and read access only to the quarantine prefix. Its pipeline, in order of cost:

# 1. Real type from magic bytes, not the extension
type=$(file --mime-type -b "$f")
case "$type" in application/pdf|image/jpeg|image/png) ;; *) reject "type:$type";; esac

# 2. Antivirus with ClamAV's daemon (exit 0 clean, 1 infected, 2 error)
clamdscan --fdpass --no-summary "$f"; rc=$?
[ $rc -eq 1 ] && reject "malware"
[ $rc -eq 2 ] && retry_later "scanner_error"   # fail closed, never mark ready

Treat a scanner error as "not clean". The most common scanning incident I have seen was a worker that marked files ready whenever the scanner timed out.

For images, re-encode instead of trusting the original: decode, resize to a maximum dimension, and write a fresh JPEG or WebP with metadata stripped. This removes EXIF data, appended polyglot payloads and most malformed structures in one step; run it with resource limits.

Antivirus signatures catch known malware, not targeted payloads, which is why content validation, re-encoding and delivery isolation still matter.

Step 3: Serve files so they cannot attack your app

A clean file is still dangerous if the browser renders it on your app's origin. My delivery defaults:

Content-Disposition: attachment; filename="invoice-2026-10.pdf"
Content-Type: application/pdf            (the validated type, not the uploaded one)
X-Content-Type-Options: nosniff
Content-Security-Policy: sandbox; default-src 'none'
Cache-Control: private, max-age=300

Serve from a separate registrable domain, such as example-usercontent.net, so that a file that does execute script has no access to your app's cookies or same-origin APIs. A subdomain of your main domain is weaker, because cookies scoped to the parent domain still travel; I covered that in cookie security flags.

Every download goes through an API endpoint that checks the tenant and the user's permission on that record, then issues a signed URL valid for a few minutes. Signed URLs are bearer tokens: anyone holding one can use it until it expires, so keep the lifetime short and never log full URLs. In shared-schema multi-tenant systems, scope the lookup by tenant in the query itself, as discussed in multi-tenant SaaS database architecture.

Step 4: Lock down the buckets

• Block all public access at the account and bucket level.
• Deny requests that are not over TLS with a bucket policy condition on aws:SecureTransport.
• Enable default encryption; use a customer-managed key for regulated documents so access is auditable.
• Add a lifecycle rule that expires everything under quarantine/ after a few days, so abandoned and rejected uploads do not accumulate.

Cost and trade-offs

ClamAV keeps signatures in memory; do not co-locate it on a small app server.

Failure modes I have seen

• Bucket made public "temporarily" to fix broken image previews, then forgotten.
• Download URLs with year-long expiry pasted into emails and support tickets.
• Extension allowlist only, bypassed with report.pdf.html or a correct extension on the wrong content.
• Scanner fail-open on timeouts, as described above.
• Thumbnails generated before scanning, running untrusted files through the image library first.

Implementation checklist

1. Presigned POST with size and type conditions; random keys under a tenant prefix.
2. Quarantine prefix with lifecycle expiry; nothing downloadable until marked ready.
3. Isolated worker: magic-byte check, structure and size limits, antivirus, fail closed.
4. Re-encode images and strip metadata; reject or tightly cap archives.
5. Private buckets, TLS-only policy, encryption at rest.
6. Separate content domain with attachment, nosniff and CSP sandbox.
7. Per-request authorization and signed GET URLs measured in minutes.
8. Per-tenant quotas, upload rate limits and alerts on rejection spikes.
9. Audit log entries for upload, scan result, download and deletion.

Need this reviewed on an existing platform? We cover it in server setup and maintenance engagements and Laravel development work.

Frequently asked questions

Is checking the file extension enough?

No. Extensions and the browser-supplied MIME type are both controlled by the uploader. Detect the type from the file's magic bytes on the server, compare it with your allowlist, and serve it with the validated type and nosniff.

Is ClamAV good enough for scanning uploads?

It catches known malware signatures and is a reasonable baseline for document uploads. It will not catch targeted or novel payloads, so combine it with content validation, re-encoding and safe delivery headers rather than relying on it alone.

How long should signed download URLs last?

Minutes, not days. Generate a fresh URL on each authorized request; long-lived URLs behave like public links once shared or logged.

Why serve user files from a separate domain?

So a file that executes script runs on an origin with no access to your app's cookies, storage or same-origin APIs.

Are SVG uploads safe to allow?

Not as-is. SVG is XML that can contain script. Either convert SVGs to PNG on upload, sanitize them with a strict allowlist, or serve them only as downloads from the isolated content domain.

Follow & Connect

• Website: Loop Origin
• LinkedIn: Loop Origin
• X: Muhammad Ali Mughal (@AliMughal887)
• GitHub: Loop Origin (@LoopOrigin)

At Loop Origin we build and maintain storefronts and B2B portals, and a tag audit is part of every e-commerce development engagement. This is the playbook I use, and it applies whether you run a custom storefront or one of the platforms I compared in custom e-commerce vs Shopify Plus vs WooCommerce.

How do you stop third-party scripts from hurting Core Web Vitals?

Direct answer: Inventory every tag with an owner and purpose, measure its main-thread cost with Long Animation Frame attribution, then assign a loading tier: defer analytics until after consent and idle time, replace chat and video embeds with facades, scope payment and review SDKs to the routes that need them, and move pixel delivery server-side where possible. Enforce budgets in CI.

How third-party code damages each metric

INP is where third parties hurt most in my experience, because the damage lands exactly when a customer acts.

Step 1: Measure in the field, with attribution

Lighthouse and the DevTools Performance panel are a starting point, but tags behave differently by consent state, campaign and geography, so you need field data that names the script.

The Long Animation Frames API (LoAF), available in Chromium browsers, reports frames longer than 50ms together with the scripts that ran in them. A small observer that ships the worst offenders to your own endpoint:

// loaf-monitor.js - load early, first-party
const seen = new Map();

new PerformanceObserver((list) => {
  for (const frame of list.getEntries()) {
    if (frame.duration < 100) continue;
    for (const s of frame.scripts) {
      const origin = s.sourceURL ? new URL(s.sourceURL).origin : 'inline';
      const key = `${origin}|${s.invokerType}|${s.invoker}`;
      const prev = seen.get(key) || { count: 0, ms: 0 };
      seen.set(key, { count: prev.count + 1, ms: prev.ms + s.duration });
    }
  }
}).observe({ type: 'long-animation-frame', buffered: true });

addEventListener('visibilitychange', () => {
  if (document.visibilityState !== 'hidden' || seen.size === 0) return;
  const rows = [...seen].map(([k, v]) => ({ k, ...v }))
    .sort((a, b) => b.ms - a.ms).slice(0, 10);
  navigator.sendBeacon('/rum/loaf', JSON.stringify({ path: location.pathname, rows }));
  seen.clear();
});

Pair it with the web-vitals library's attribution build (onINP from web-vitals/attribution) to connect slow interactions to the element and script involved. A week of data gives you vendors ranked by main-thread time per page type.

Step 2: Assign every tag a loading tier

A minimal loader for tiers 1 and 2 looks like this:

// tag-loader.js
const loaded = new Set();
export function loadScript(src, attrs = {}) {
  if (loaded.has(src)) return Promise.resolve();
  loaded.add(src);
  return new Promise((resolve, reject) => {
    const s = Object.assign(document.createElement('script'), { src, async: true, ...attrs });
    s.onload = resolve; s.onerror = reject;
    document.head.appendChild(s);
  });
}
const idle = (fn) => ('requestIdleCallback' in window ? requestIdleCallback(fn, { timeout: 4000 }) : setTimeout(fn, 2000));

// Tier 1: after consent, then idle
window.addEventListener('consent:analytics-granted', () => idle(() => loadScript('https://analytics.example.com/tag.js')));

// Tier 2: chat facade
document.querySelector('#chat-facade')?.addEventListener('click', async (e) => {
  e.currentTarget.setAttribute('aria-busy', 'true');
  await loadScript('https://chat.example.com/widget.js');
  window.ChatWidget?.open();
}, { once: true });

In Nuxt and Vue apps, tier 3 becomes "load in the page component, not in app.vue or the default layout". I covered how rendering mode interacts with this in Nuxt 3 rendering for B2B SaaS.

Step 3: Choose the architecture patterns deliberately

The highest-return move is usually the last row: every audit I have run found tags for vendors or campaigns nobody used anymore. Server-side tagging needs one caution: it moves consent responsibility onto your backend, so events must carry the consent state.

Step 4: Put the tag layer under governance

Treat the tag manager like a production dependency:

• Tag register. One row per tag: vendor, owner, business purpose, consent category, loading tier, pages, and a review date. Tags without an owner are removed at the next review.
• Publish rights. Marketing can draft containers; publishing requires a second approver who checks the register.
• Content Security Policy. A CSP script-src allowlist makes new vendor origins fail visibly instead of loading silently. Roll it out in report-only mode first; my HTTP security headers audit covers the rollout.
• Budgets in CI. Lighthouse CI accepts a budget file with a third-party resource type:

[{
  "path": "/*",
  "resourceSizes": [{ "resourceType": "third-party", "budget": 150 }],
  "resourceCounts": [{ "resourceType": "third-party", "budget": 8 }]
}]

Sizes are in kilobytes; tighten from your own baseline. Run it on home, category, product and checkout pages with consent pre-granted, the worst case.

Failure modes I see repeatedly

• Anti-flicker snippets. A/B testing tools often hide the page until the experiment loads or a timeout fires. On slow connections that timeout becomes your LCP. Prefer server-side experiments for above-the-fold changes.
• Chat widget on checkout. Support wants it everywhere; checkout is where it costs the most. Scope it, or use a facade.
• Duplicate pixels. The same vendor installed hard-coded in the theme and again in the tag manager, doubling cost and conversions.
• Consent banner as LCP. A large banner rendered by a slow third-party script delays LCP for every first visit. Render the banner first-party and keep it small.

30-day rollout plan

1. Week 1: Export the tag manager container and theme scripts; build the register; deploy the LoAF monitor.
2. Week 2: Remove orphaned tags; move analytics to tier 1; add facades for chat and video.
3. Week 3: Scope payment, review and map SDKs to their routes; fix CLS from injected widgets by reserving space.
4. Week 4: Add the CSP in report-only mode, Lighthouse CI budgets and the publish approval rule; evaluate server-side tagging for conversion events.

If you want this done on an existing storefront or portal, our custom web application development team runs it as a fixed-scope audit; see pricing.

Frequently asked questions

Do async and defer solve third-party performance problems?

They stop scripts blocking HTML parsing, which helps LCP, but do nothing about the main-thread work that hurts INP once the script runs.

Is Google Tag Manager bad for performance?

The container itself is moderate; what it loads is the problem. A container with dozens of tags firing on every page will hurt INP regardless of how the container is loaded. Govern its contents and publish rights.

What is the Long Animation Frames API?

A browser performance API in Chromium that reports animation frames longer than 50ms and lists the scripts that ran during them, with source URLs and durations. It replaced Long Tasks as the better way to attribute slow interactions to specific scripts.

Does server-side tagging remove the need for consent?

No. It changes where the code runs, not what you are allowed to collect. Send the consent state with each event and have the server container drop events the user did not consent to.

Should A/B testing run client-side or server-side?

Server-side or at the edge for anything above the fold, so there is no hidden page or flicker. Client-side testing is acceptable for below-the-fold changes where a late swap is not visible.

Follow & Connect

• Website: Loop Origin
• LinkedIn: Loop Origin
• X: Muhammad Ali Mughal (@AliMughal887)
• GitHub: Loop Origin (@LoopOrigin)

I build PixelValut, a set of browser-side developer and security tools, and verifying downloads is a step I script into every server build and CI pipeline I own. Below is the workflow with real command output from a Node.js release, what each step defends against, and where most teams stop one step too early.

How do you verify a downloaded file is authentic?

Direct answer: Compute the file's SHA-256 hash and compare it with the hash the publisher lists, then verify the publisher's signature on that checksum list with GPG, Sigstore or the platform's own signing, using a key fingerprint you obtained independently. A hash alone detects corruption; only a verified signature ties the file to the publisher.

What each check actually protects against

Two lessons come out of this table. A checksum served from the same place as the file only catches accidents. And no verification step protects you from a legitimate key used maliciously, which is why provenance and short-lived signing identities exist.

Step 1: Compute and compare the hash

I use the Node.js v22.11.0 Linux binary as the example because Node publishes both a checksum list and its signature. Download the file and SHASUMS256.txt, then let sha256sum do the comparison instead of eyeballing 64 hex characters:

$ curl -sO https://nodejs.org/dist/v22.11.0/node-v22.11.0-linux-x64.tar.xz
$ curl -sO https://nodejs.org/dist/v22.11.0/SHASUMS256.txt
$ grep linux-x64.tar.xz SHASUMS256.txt
83bf07dd343002a26211cf1fcd46a9d9534219aad42ee02847816940bf610a72  node-v22.11.0-linux-x64.tar.xz
$ sha256sum node-v22.11.0-linux-x64.tar.xz
83bf07dd343002a26211cf1fcd46a9d9534219aad42ee02847816940bf610a72  node-v22.11.0-linux-x64.tar.xz
$ grep node-v22.11.0-linux-x64.tar.xz SHASUMS256.txt | sha256sum -c -
node-v22.11.0-linux-x64.tar.xz: OK

On macOS the equivalent is shasum -a 256 file, and on Windows certutil -hashfile file SHA256 or PowerShell's Get-FileHash file -Algorithm SHA256.

If you are on a machine without a terminal, the SHA-256 file checksum tool hashes a dropped file in the browser, shows progress on large files and compares the result with the published value. For short strings or smaller files, the hash generator computes MD5, SHA-1, SHA-256 and SHA-512 locally without uploading anything. If someone hands you a hash with no label, the hash identifier ranks the likely algorithm by length and character set.

Step 2: Verify the signature on the checksum list

Node signs SHASUMS256.txt with a release key. On a clean machine, GPG first reports that it does not know the key:

$ curl -sO https://nodejs.org/dist/v22.11.0/SHASUMS256.txt.sig
$ gpg --verify SHASUMS256.txt.sig SHASUMS256.txt
gpg:                using RSA key C82FA3AE1CBEDC6BE46B9360C43CEC45C17AB93C
gpg: Can't check signature: No public key

Import that key from a source that is independent of the download server. For Node, that is the nodejs/release-keys repository on GitHub, and the fingerprints are also listed in the project's README (output trimmed, signer name redacted):

$ curl -sL https://raw.githubusercontent.com/nodejs/release-keys/main/keys/C82FA3AE1CBEDC6BE46B9360C43CEC45C17AB93C.asc | gpg --import
gpg: key C43CEC45C17AB93C: public key imported
$ gpg --verify SHASUMS256.txt.sig SHASUMS256.txt
gpg: Good signature from "<Node.js releaser>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: C82F A3AE 1CBE DC6B E46B  9360 C43C EC45 C17A B93C

"Good signature" is the part that matters. The warning only means you have not personally certified the key in GPG's web of trust; it goes away if you sign the key locally after checking the fingerprint. What you must do is compare that fingerprint against the independently published list. If you skip that comparison, you have only proved the file was signed by someone.

Step 3: Prove the checks fail when they should

A verification step you have never seen fail is a step you have not tested. I append one byte to each file and rerun:

$ printf 'x' >> node-v22.11.0-linux-x64.tar.xz
$ grep node-v22.11.0-linux-x64.tar.xz SHASUMS256.txt | sha256sum -c -
node-v22.11.0-linux-x64.tar.xz: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

$ echo '#' >> SHASUMS256.txt
$ gpg --verify SHASUMS256.txt.sig SHASUMS256.txt
gpg: BAD signature from "<Node.js releaser>" [unknown]

Both commands exit non-zero, which is what lets a Dockerfile or CI job stop the build instead of shipping the file. Always rely on exit codes in scripts, never on someone reading the output.

Step 4: Dependencies are downloads too

Most of what reaches production arrives through a package manager, and the same two layers exist there.

Integrity hashes in lockfiles. npm records a SHA-512 integrity value for every package in package-lock.json, and the install fails if the tarball does not match:

"node_modules/express": {
  "version": "4.21.1",
  "resolved": "https://registry.npmjs.org/express/-/express-4.21.1.tgz",
  "integrity": "sha512-YSFlK1Ee0/GC8QaO91tHcDxJiE/X4FbpAyQWkxAvG6AXCuR65YzK8ua6D9hvi/TzUfZMpc+BwuM1IPw8fmQBiQ=="
}

That pin protects you on every install after the first. It cannot tell you whether the first version you locked was legitimate.

Registry signatures and provenance. npm audit signatures checks the registry's signature on every installed package and any Sigstore-backed provenance attestations. On a fresh project with Express installed:

$ npm audit signatures
audited 69 packages in 0s

69 packages have verified registry signatures

1 package has a verified attestation

A provenance attestation links a package version to the source repository and CI workflow that built it, signed with a short-lived Sigstore certificate rather than a long-lived personal key. GitHub offers the same model for release artifacts through gh attestation verify <file> --repo <owner>/<repo>. For container images, pull by digest (image@sha256:...) rather than by mutable tag, so a re-pushed tag cannot change what you deploy.

I covered what malicious packages actually look like once they are installed in deobfuscating malicious npm and browser payloads.

Threat scenarios worth rehearsing

• The look-alike download page. A search ad leads to a domain one character off the real one, with a matching-looking checksum on the page. The hash matches because the attacker published both. The defense is the signature plus a fingerprint from the real project, and checking the domain itself, which I walk through in how to inspect a suspicious link.
• The compromised mirror. Same story, legitimate domain. Signed checksums catch it; same-server hashes do not.
• The "curl | bash" installer. No checksum at all. Download the script, read it, pin its hash in your provisioning code and verify before executing.
• The MD5-only project. MD5 still detects accidental corruption, but collisions are practical, so it does not stand up to a deliberate attacker. Treat it as an integrity hint, not authentication.

Download verification checklist

1. Download from the project's canonical domain, typed or bookmarked, not from an ad.
2. Fetch the checksum list and its signature, not just the file.
3. Get the signing key or identity from an independent channel and record its full fingerprint.
4. Run gpg --verify (or the project's Sigstore or attestation command) and require "Good signature".
5. Run sha256sum -c against the signed list, never a hand comparison.
6. Script both checks so a failure exits non-zero and stops the build.
7. Pin verified hashes in Dockerfiles and provisioning scripts.
8. Commit lockfiles and fail CI on integrity mismatches.
9. Run npm audit signatures (or your ecosystem's equivalent) in CI.
10. Reject MD5 and SHA-1 as the only check for anything security-relevant.

Frequently asked questions

Is a SHA-256 checksum enough to trust a download?

Only against accidental corruption, or when the checksum came from a channel the attacker cannot control. If the checksum sits on the same server as the file, an attacker who replaces one can replace both. Verify a signature over the checksum list for real authenticity.

What does "This key is not certified with a trusted signature" mean?

It means you have not personally certified the key in GPG's web of trust. The signature itself is still valid. Confirm the fingerprint against the project's independently published list; if it matches, the warning is expected and safe to accept.

Is HTTPS not enough to protect a download?

HTTPS protects the connection between you and the server. It does nothing if the server, mirror or CDN node is serving a malicious file, or if you are on a look-alike domain with a valid certificate. Signatures protect the file itself, wherever it was hosted.

Is MD5 or SHA-1 still acceptable for checksums?

For detecting accidental corruption, they work. For security they are broken: practical collision attacks exist for both. Use SHA-256 or SHA-512, and prefer projects that sign their checksum lists.

What is Sigstore, and how is it different from GPG?

Sigstore signs artifacts with short-lived certificates tied to an identity, such as a CI workflow, and records each signature in a public transparency log. There is no long-lived private key to steal or a key server to trust. GPG relies on long-lived keys whose fingerprints you verify yourself.

How do I verify a file on Windows without extra tools?

Run Get-FileHash .\file.zip -Algorithm SHA256 in PowerShell, or certutil -hashfile file.zip SHA256 in Command Prompt, then compare with the signed checksum list. Gpg4win provides the gpg --verify step on Windows.

Follow & Connect

• Website: PixelValut Tools
• YouTube: PixelValut (@pixel-valut)
• TikTok: PixelValut (@pixelvalut007)
• GitHub: Muhammad Ali Mughal (@ali111887)
• LinkedIn: Muhammad Ali Mughal

I build Smart Resume Analyzer, and education blocks fail silently: the resume looks fine to the candidate and the profile looks incomplete to the recruiter. Here is what parsers extract, how each platform behaves, real rewrites and a diagnostic.

How do ATS parsers read education and certifications?

Direct answer: Parsers segment the section by its heading, then split each entry into institution, degree, field of study and dates, and each certification into name, issuer and date. They normalize common degree spellings but miss nonstandard abbreviations, merged lines and missing dates. Use a standard heading, one entry per line group, full degree names and exact certification titles.

What the parser tries to extract

Parsers first find section boundaries by matching headings such as "Education" or "Licenses & Certifications", then extract entities inside each section. A typical target schema:

Degree level and field of study fail most often in my testing. "Bachelor of Science in Computer Science" is in every parser's degree dictionary. "BS(CS) Hons." is in very few.

What you can observe on each platform

Vendors do not publish parser internals, so this covers only what you can observe.

Before applying, run the file through the ATS Parser Online to see how the section is split, then check it with the platform-specific checkers for Workday, Greenhouse, Lever, iCIMS or Taleo.

How tokenization treats degree and certification lines

Here is a simplified view of what happens to a compressed education line versus an explicit one:

Input A:  "BSCS (Hons) - FAST-NUCES KHI '19 | CGPA 3.4"
Tokens:   bscs | hons | fast-nuces | khi | 19 | cgpa | 3.4
Degree:   not matched (unknown abbreviation)
Field:    not found
Date:     "19" rejected as a year
School:   "FAST-NUCES KHI" kept as raw text, not matched to an institution list

Input B:  "Bachelor of Science (BS) in Computer Science
           National University of Computer and Emerging Sciences (FAST-NUCES), Karachi
           Graduated: June 2019 | CGPA: 3.4/4.0"
Degree:   Bachelor of Science -> Bachelor's
Field:    Computer Science
Date:     2019-06
School:   matched, with the acronym also searchable

Two extra lines give every downstream filter something to work with. Likewise, "AWS SAA" is a token no recruiter types, while "AWS Certified Solutions Architect - Associate (SAA-C03)" matches both the full-title search and the exam-code search.

This is the same normalization problem I covered for skills in how ATS parsers extract and normalize resume skills, and for dates in how ATS parsers read work experience dates and gaps.

Weak vs ATS-optimized rewrites

Each rewrite keeps the candidate's facts and changes only structure and wording. The examples are illustrative, not from real clients.

1. The compressed degree line

Weak: BSCS, FAST '19, 3.4

ATS-optimized: Bachelor of Science (BS) in Computer Science, National University of Computer and Emerging Sciences (FAST-NUCES), Karachi. Graduated June 2019. CGPA 3.4/4.0.

2. The degree still in progress

Weak: MBA (ongoing)

ATS-optimized: Master of Business Administration (MBA), Institute of Business Administration (IBA), Karachi. Expected graduation: May 2027. Evening program, completed 30 of 48 credit hours.

"Ongoing" with no date can be read as no end date at all.

3. The certification with no issuer or date

Weak: Certifications: AWS SA, CKA, Scrum

ATS-optimized:

• AWS Certified Solutions Architect - Associate, Amazon Web Services, issued Feb 2025, expires Feb 2028
• Certified Kubernetes Administrator (CKA), The Linux Foundation / CNCF, issued Aug 2024
• Professional Scrum Master I (PSM I), Scrum.org, issued Jan 2023

"Scrum" alone could be a skill, a course or a certificate.

4. Online courses mixed with credentials

Weak: Education: Coursera ML, Udemy Docker, Google Data Analytics, BS Statistics

ATS-optimized: Put the degree under Education and move the rest to a separate "Certifications & Training" section, listing only those with a verifiable certificate and naming the issuer, for example "Google Data Analytics Professional Certificate, Google (via Coursera), 2024".

Mixed lists make parsers treat course titles as degrees. More on which short credentials to list in the micro-credentials and certifications guide.

Where the section should go

Order matters less to the parser than the heading does, but it matters to the human:

• Students and graduates within about two years: Education directly after the summary, with relevant coursework or a final-year project. The fresh graduate resume checker tests that layout specifically.
• Experienced professionals: Education after experience, no GPA unless asked.
• Certification-led roles (cloud, security, nursing, accounting): Certifications near the top, because recruiters filter on it first.

For more on what to include at each career stage, see the education on a resume guide.

The 8-step education and certification diagnostic

1. Heading check. Use "Education" and "Certifications" (or "Licenses & Certifications") as plain headings in the body, not in a header, sidebar or table.
2. Full degree name. Words first, abbreviation in parentheses.
3. Separate field of study. Use "in Computer Science", not "BSCS", so the field becomes its own token.
4. Official institution name. As the school writes it, plus the acronym once.
5. Parseable dates. Month and four-digit year, or "Expected May 2027" for in-progress degrees. No apostrophe years.
6. Exact certification titles. Copy the title as the issuer writes it, add the exam code if one exists, the issuer and the issue or expiry date.
7. Match the job description. If the posting says "PMP certification required", your resume should contain "Project Management Professional (PMP)". Pull those terms with the Job Description Keyword Finder.
8. Parse test, then review the form. Run the file through an ATS resume checker, then check every autofilled education field on the form. What the form stores is what recruiters filter.

If formatting is the deeper problem, start with resume formatting mistakes that break ATS parsing.

Failure modes I see repeatedly

• Two-column education blocks. Dates in a right-hand column get attached to the wrong entry.
• Badge images or links only for certifications. Parsers read text, not badges; the title must be plain text.
• Inconsistent answers. The resume says "BS" and the form says "Master's". Recruiters notice.

Frequently asked questions

Should I list my GPA on my resume?

Only early in your career, for graduate programs, or when the posting asks. Write it with its scale, such as "CGPA 3.4/4.0", so a parser reads it as a number on a known scale. After a few years of experience it adds little.

How do I list a degree I have not finished?

Write the full degree name, institution and an explicit "Expected" month and year. If you have stopped studying, list what you completed instead, such as "Completed 90 credit hours toward a Bachelor of Science in Computer Science", so neither the parser nor the recruiter reads it as a finished degree.

Do ATS systems verify certifications?

Generally no. The ATS stores what you write; verification happens later, by a recruiter or background-check provider using the issuer's directory or credential ID. Exact title, issuer and date make that fast and match what recruiters search for.

Should certifications go in a separate section?

Yes, when you have more than two or the role is certification-led. A separate heading gives the parser a clean boundary. Keep courses without a verifiable certificate under "Training" instead.

How do I list a degree from another country?

Use the official degree and institution names, plus a plain-language equivalent if needed, such as "Bachelor of Engineering (4-year degree)". Mention a credential evaluation if you have one, and avoid local abbreviations a foreign parser will not recognize.

Follow & Connect

• Website: Smart Resume Analyzer
• YouTube: Resume Boost AI (@resume-boost-ai)
• TikTok: Resume Boost AI (@resumeboostai)
• X: Muhammad Ali Mughal (@AliMughal887)
• GitHub: Muhammad Ali Mughal (@ali111887)
• LinkedIn: Muhammad Ali Mughal

At Loop Origin we run Laravel and Node SaaS platforms on VPS infrastructure for clients, and backup design is part of every server setup and maintenance engagement. This is the setup I deploy by default, with the configuration, restore commands and drill schedule.

What is a good backup and disaster recovery setup for a SaaS on a VPS?

Direct answer: Combine continuous database archiving for point-in-time recovery (PostgreSQL WAL with pgBackRest or WAL-G, MySQL binary logs) with periodic full backups pushed to versioned, write-protected object storage in a separate account and region. Define RPO and RTO per tier, encrypt everything, and run a timed restore drill every month.

RPO and RTO tiers: pick one per system, not per company

RPO (recovery point objective) is how much recent data you can lose. RTO (recovery time objective) is how long recovery may take. They drive cost, so set them per system rather than declaring "zero data loss" for everything.

Most clients I work with land on Tier 1 for the primary database and Tier 2 or 3 for everything else. Redis queues and Elasticsearch-style indexes are usually Tier 3: rebuild them from the database instead of backing them up. My guide on running Laravel queues in production covers why failed jobs should live in the database rather than only in Redis.

Why dumps alone are not enough

A logical dump (pg_dump, mysqldump) is a consistent snapshot at one moment. If a bad migration or an accidental DELETE without a WHERE runs at 4:40 PM, a nightly dump takes you back to the previous night and you lose the day. Point-in-time recovery (PITR) closes that gap: restore the last full physical backup, then replay the database's change log up to the second before the mistake.

Dumps are still useful for moving individual tenants, seeding staging and long-term archives. They are just not the recovery mechanism for the primary.

PostgreSQL PITR with pgBackRest

postgresql.conf changes (restart required for archive_mode and wal_level):

wal_level = replica
archive_mode = on
archive_command = 'pgbackrest --stanza=main archive-push %p'
archive_timeout = 60          # force a WAL segment switch at least every 60s

/etc/pgbackrest/pgbackrest.conf:

[global]
repo1-type=s3
repo1-s3-bucket=acme-db-backups
repo1-s3-endpoint=s3.eu-central-1.amazonaws.com
repo1-s3-region=eu-central-1
repo1-path=/pgbackrest
repo1-retention-full=4
repo1-cipher-type=aes-256-cbc
repo1-cipher-pass=<from secrets manager>
compress-type=zst
start-fast=y

[main]
pg1-path=/var/lib/postgresql/16/main

Initialize, verify and schedule:

sudo -u postgres pgbackrest --stanza=main stanza-create
sudo -u postgres pgbackrest --stanza=main check          # confirms WAL archiving works
sudo -u postgres pgbackrest --stanza=main --type=full backup   # weekly via cron/systemd timer
sudo -u postgres pgbackrest --stanza=main --type=diff backup   # daily
sudo -u postgres pgbackrest --stanza=main info

archive_timeout = 60 is what makes the RPO roughly one minute on a quiet database: without it, a low-traffic system may not fill and ship a 16 MB WAL segment for a long time.

The restore you will run when someone drops a table at 16:40:

sudo systemctl stop postgresql
sudo -u postgres pgbackrest --stanza=main --delta \
  --type=time --target="2026-10-31 16:39:00+05" --target-action=promote restore
sudo systemctl start postgresql

In practice I restore to a new server first, verify the data, then cut over or copy the missing rows back. Restoring over the only production copy removes your ability to try again.

WAL-G is the main alternative: archive_command = 'wal-g wal-push %p', wal-g backup-push $PGDATA for base backups, and wal-g backup-fetch $PGDATA LATEST plus restore_command = 'wal-g wal-fetch %f %p' and recovery_target_time for PITR. I prefer pgBackRest for its built-in check, retention and parallel restore, and WAL-G where a team already uses it.

MySQL and MariaDB PITR with binary logs

# my.cnf
[mysqld]
server_id = 1
log_bin = /var/lib/mysql/binlog
binlog_format = ROW
binlog_expire_logs_seconds = 1209600   # 14 days, longer than your full-backup interval
sync_binlog = 1

Take a consistent full backup with Percona XtraBackup for large databases, or mysqldump --single-transaction --source-data=2 for smaller ones (--source-data replaced --master-data in MySQL 8.0.26). Ship binlogs off the server continuously, for example with mysqlbinlog --read-from-remote-server --raw --stop-never running on a backup host.

Recovery: restore the full backup, read the binlog file and position recorded in it, then replay up to just before the incident:

mysqlbinlog --start-position=157 --stop-datetime="2026-10-31 16:39:00" \
  binlog.000412 binlog.000413 | mysql -u root -p

--stop-datetime is interpreted in the local time zone of the machine running mysqlbinlog, a detail that has caught more than one team restoring on a UTC server.

Object storage: where backups survive the incident

The repository must survive the loss of the server and of the credentials on it:

• Separate account or project for the backup bucket, with a write-only key on the server. A stolen server key should not be able to delete backups.
• Versioning plus object lock (S3 Object Lock, or the equivalent on S3-compatible providers that support it) with a retention period longer than your detection window.
• A different region or provider from the primary VPS.
• Client-side encryption (pgBackRest's repo1-cipher-type, or restic for file backups) with the passphrase stored outside the server.
• File uploads (storage/app, user uploads) backed up with restic or rclone, or written directly to object storage in the first place.

Cost drivers, compared

For most Tier 1 SaaS databases the storage bill is small next to the replica and engineering time. My VPS vs managed PaaS cost comparison shows where managed databases with built-in PITR change the calculation.

Failure modes I have seen

• Archiving silently broken. archive_command fails, WAL piles up in pg_wal and the disk fills. Monitor pg_stat_archiver.failed_count and the age of last_archived_time.
• Backups nobody restored. Encryption passphrase lost, wrong PostgreSQL major version, missing extensions. Only a drill finds these.
• Same blast radius. Backups in a bucket the compromised server can delete.
• Binlog retention shorter than the backup interval. A gap makes PITR impossible past the last full backup.
• Forgotten tenants' files. The database restores, but uploaded documents do not.
• Shared-database multi-tenancy surprises. Restoring one tenant from a shared physical backup needs a side restore and a selective copy; plan it. My multi-tenant SaaS database architecture guide covers the trade-offs.

Monthly restore drill runbook

1. Provision a clean VPS from infrastructure code.
2. Restore the latest full backup plus WAL or binlogs to a target time from yesterday.
3. Time it end to end; compare against your RTO.
4. Run integrity checks: row counts on key tables, latest order or invoice timestamp, application smoke test.
5. Restore a sample of uploaded files and open them.
6. Record duration, issues and the backup set used in the runbook.
7. Destroy the drill server and rotate any credentials it used.

Frequently asked questions

What is the difference between RPO and RTO?

RPO is the maximum acceptable data loss, measured as time between the last recoverable point and the incident. RTO is the maximum acceptable time to restore service. A system can have a one-minute RPO and a four-hour RTO, and the two are engineered with different tools.

Is pg_dump enough for a production SaaS database?

Not as the only mechanism. It restores to the moment the dump ran, so anything after that is lost. Use physical backups with WAL archiving for point-in-time recovery, and keep logical dumps for tenant exports, staging data and long-term archives.

pgBackRest or WAL-G?

Both provide base backups, WAL archiving to object storage, compression, encryption and PITR. pgBackRest has a built-in configuration check, retention management and parallel restore. WAL-G is lighter and common in container setups. Choose the one your team will monitor and drill.

How often should I test restoring backups?

At least monthly for production databases, and after any major version upgrade, storage change or backup configuration change. A drill should restore to a fresh server, be timed against your RTO and include an application-level check, not just a successful exit code.

Should backups be stored in the same cloud provider?

A different region at minimum, and ideally a separate account with write-only credentials from the server and object lock enabled. A different provider adds protection against account-level incidents at the cost of egress fees during restores.

Do I need to back up Redis?

Usually not, if Redis holds caches, sessions and queues that can be rebuilt or retried. Keep durable state such as failed jobs and anything business-critical in the main database. Back up Redis only if it is your primary store for data you cannot regenerate.

Follow & Connect

• Website: Loop Origin
• LinkedIn: Loop Origin
• X: Muhammad Ali Mughal (@AliMughal887)
• GitHub: Loop Origin (@LoopOrigin)

At Loop Origin we build customer portals, dealer ordering systems and SaaS dashboards on Nuxt 3 with Laravel or Node backends. This is the decision framework I use, the exact nuxt.config.ts we start from, and the failure modes that have cost real debugging time.

Should a B2B SaaS app use SSR, SPA or hybrid rendering in Nuxt 3?

Direct answer: Use hybrid rendering. Prerender or cache public marketing, pricing and docs pages for SEO and fast first paint, and serve the authenticated app as a client-rendered SPA with ssr: false route rules. Reserve full server rendering for public pages whose content changes per request, and never cache any server-rendered HTML that depends on the user's session cookie.

The four rendering modes, compared

The column people skip is "Server needed". A pure SPA plus prerendered marketing pages can be served from any static host or CDN. One runtime SSR route means running a Node process or edge function.

Map routes to modes, not the whole app

For a typical B2B product, I split routes into four groups:

1. Marketing and pricing (/, /pricing, /features/**): content changes on deploy. Prerender.
2. Docs, blog, changelog (/docs/**, /blog/**): many pages, edited through a CMS. Prerender, or SWR if you publish without redeploying.
3. Public dynamic pages (/integrations/**, public status or listing pages): data from an API, same for every visitor. SWR with a sensible revalidation window.
4. Authenticated app (/app/**, /account/**, /admin/**): per-user data, never indexed. SPA.

Here is the configuration we start from:

// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    '/': { prerender: true },
    '/pricing': { prerender: true },
    '/features/**': { prerender: true },
    '/docs/**': { swr: 3600 },              // cache 1h, revalidate in background
    '/integrations/**': { swr: 600 },
    '/app/**': { ssr: false },                // client-rendered dashboard
    '/account/**': { ssr: false },
    '/admin/**': { ssr: false, headers: { 'X-Robots-Tag': 'noindex' } },
    '/api/**': { headers: { 'Cache-Control': 'no-store' } },
    '/old-pricing': { redirect: { to: '/pricing', statusCode: 301 } },
  },
  nitro: {
    prerender: { crawlLinks: true, routes: ['/sitemap.xml'] },
  },
})

Two production notes. First, swr caching is handled by Nitro's cache layer, which defaults to in-memory storage; on a multi-instance deployment each instance keeps its own cache unless you configure a shared storage driver such as Redis. Second, isr route rules are only meaningful on platforms that implement them (Vercel and Netlify, for example). On a plain VPS, swr is the equivalent you actually get.

SEO and performance: what actually changes

Search engines can render JavaScript, but in my experience pages that ship complete HTML index more reliably and preview correctly on LinkedIn, Slack or X, whose link-preview crawlers generally do not run JavaScript.

For TTFB, the trade-offs are structural, not magic:

• Prerendered pages are static files; TTFB is whatever your CDN delivers.
• SSR TTFB includes every useFetch or useAsyncData call that runs on the server before HTML is sent. One slow backend endpoint makes every page slow. Parallelize and time-box fetches.
• SPA routes return a tiny shell fast, then the browser downloads JavaScript and calls your API. Perceived speed depends on bundle size and API latency, acceptable behind a login.

Measure your own routes:

curl -s -o /dev/null -w 'ttfb=%{time_starttransfer}s total=%{time_total}s\n' https://app.example.test/pricing
curl -s -o /dev/null -w 'ttfb=%{time_starttransfer}s total=%{time_total}s\n' https://app.example.test/docs/getting-started

Run each twice; with swr, the second request should come from cache.

Hosting cost drivers by mode

Exact prices change with provider and traffic, but the cost structure is predictable:

The expensive mistake is full SSR for the authenticated app: you pay server compute to render dashboards for logged-in users, gain nothing in SEO, and add a second place where auth can go wrong. My VPS vs managed PaaS TCO breakdown covers the hosting decision itself, and multi-stage Dockerfiles for PHP and Node shows how we package the Nitro server.

Failure modes I have debugged in production

1. Auth cookies leaking into cached SSR

This is the dangerous one. A page under an swr rule reads the session cookie during SSR (for example, a header that shows "Signed in as ..."), and Nitro caches the rendered HTML keyed by URL. The next anonymous visitor receives the first user's name, or worse, their data.

Rules we enforce:

• Any route that reads cookies, useRequestHeaders(['cookie']) or session state on the server must not have swr, isr or prerender.
• Personalized fragments on public pages render client-side only, inside <ClientOnly>.
• Cached responses must never carry Set-Cookie. Check with curl -sI against a cached route.

2. Hydration mismatches

Vue warns "Hydration completed but contains mismatches" when server HTML differs from the first client render. The usual causes in B2B apps are dates and time zones (server in UTC, browser in the user's zone), Math.random() or Date.now() in templates, and reading localStorage or window during setup. Fixes: format dates on the client or pass the user's time zone explicitly, generate IDs with useId(), and move browser-only logic into onMounted or <ClientOnly>.

3. Forwarding cookies to the API during SSR

On the server, $fetch to your Laravel or Node API does not automatically carry the browser's cookies. If an SSR page needs authenticated data, use useRequestFetch() or pass headers: useRequestHeaders(['cookie']) explicitly, and keep that route out of every cache rule.

4. Middleware that assumes the browser

Route middleware runs on the server for SSR routes and on the client for SPA navigation. Code that reads localStorage for a token breaks on the server. With ssr: false on /app/**, that middleware runs only in the browser.

Rendering decision checklist

1. List every route group and mark it public or authenticated.
2. Authenticated groups: ssr: false, plus noindex for admin areas.
3. Public pages that change only on deploy: prerender: true.
4. Public pages with API data shared by all visitors: swr with a revalidation window you can defend.
5. Confirm no cached route reads cookies or session state on the server.
6. Configure shared Nitro cache storage if you run more than one instance.
7. Measure TTFB per route group with curl -w before and after.
8. Check cached responses for stray Set-Cookie headers.
9. Test the hydration console warnings on the top five public pages.
10. Document the rules in the repo so new routes get a deliberate mode.

If you are planning a portal or SaaS front end, this split is the default in our custom web application development work; the pricing page shows how we scope it.

Frequently asked questions

Is SSR required for SEO in Nuxt 3?

Not for every route. Public content pages should ship full HTML, which prerendering or SWR caching provides without per-request rendering. Authenticated dashboards are not indexed, so client-side rendering is fine there and avoids server cost.

What is the difference between swr and isr route rules?

Both serve cached HTML and revalidate it. swr is implemented by Nitro's own cache and works on a Node server or VPS. isr relies on the hosting platform's incremental static regeneration support, such as Vercel or Netlify, and has no effect where the platform does not implement it.

Can I mix SSR and SPA routes in one Nuxt 3 app?

Yes. Route rules let you set ssr: false on specific path patterns while the rest of the app stays universal or prerendered. It is still one build.

Why does my Nuxt page show another user's data?

Most often because a server-rendered page that reads the session cookie is under a cache rule such as swr, isr or a CDN cache. The first rendered HTML is cached and served to everyone. Remove caching from that route or render personalized parts on the client only.

Do I need a Node server to deploy Nuxt 3?

Only if some routes render at request time. An app made entirely of prerendered pages and ssr: false routes can be generated as static files and served from a CDN. Any SSR or SWR route requires the Nitro server, a serverless function or an edge runtime.

How do I fix hydration mismatch warnings?

Make the first client render match the server HTML. Avoid random values and current time in templates, format dates consistently or on the client, use useId() for generated IDs, and move access to window or localStorage into onMounted or a <ClientOnly> wrapper.

Follow & Connect

• Website: Loop Origin
• LinkedIn: Loop Origin
• X: Muhammad Ali Mughal (@AliMughal887)
• GitHub: Loop Origin (@LoopOrigin)

I build PixelValut, a set of browser-side developer and security tools, and I run this exact audit on every Laravel and Node app I ship. Below is the workflow with real header output, the attack each flag stops, and a checklist you can paste into a pull request template.

Which cookie security flags should a session cookie have?

Direct answer: A session cookie should be set with Secure, HttpOnly, SameSite=Lax (or Strict), Path=/ and no Domain attribute, ideally using the __Host- name prefix, which the browser only accepts when those conditions hold. Add a short Max-Age or session lifetime, and regenerate the session ID on login to prevent fixation.

What each attribute does and what it stops

Without a SameSite attribute, Chromium treats a cookie as Lax, but other browsers have differed; set it explicitly.

Step 1: Read the raw Set-Cookie headers with curl

Start with a header-only request against the login page or home page. These are real responses from this morning, with values redacted:

$ curl -sI https://github.com/ | grep -i '^set-cookie'
set-cookie: _gh_sess=<redacted>; path=/; HttpOnly; secure; SameSite=Lax
set-cookie: _octo=<redacted>; expires=Sun, 31 Oct 2027 05:23:32 GMT; domain=.github.com; path=/; secure; SameSite=Lax
set-cookie: logged_in=no; expires=Sun, 31 Oct 2027 05:23:32 GMT; domain=.github.com; path=/; HttpOnly; secure; SameSite=Lax

$ curl -sI https://pixelvalut.com/ | grep -i '^set-cookie'
Set-Cookie: XSRF-TOKEN=<redacted>; expires=Sat, 31 Oct 2026 07:23:36 GMT; Max-Age=7200; path=/; secure; samesite=lax
Set-Cookie: pixelvalut_session=<redacted>; expires=Sat, 31 Oct 2026 07:23:36 GMT; Max-Age=7200; path=/; secure; httponly; samesite=lax

How I read them:

• _gh_sess is a textbook session cookie: host-only (no Domain), HttpOnly, Secure, Lax, and no Expires, so it dies with the browser session.
• _octo and logged_in are scoped to .github.com on purpose: non-secret state shared across subdomains, fine for a flag, never for a session ID.
• XSRF-TOKEN on PixelValut, a Laravel app, is deliberately not HttpOnly. It is the CSRF token that the JavaScript client reads and echoes back in the X-XSRF-TOKEN header. That is by design; the secret is the session cookie next to it.
• pixelvalut_session has Secure, HttpOnly, Lax and a two-hour Max-Age. What it lacks is the __Host- prefix, which is the next hardening step I cover below.

If you prefer the browser, the Security Headers Checker shows the response headers alongside CSP and HSTS, and my guide on auditing HTTP security headers covers the rest of that response.

Step 2: Confirm what the browser actually stored in DevTools

In Chrome or Edge, open DevTools, go to Application > Storage > Cookies and select the origin. In Firefox it is Storage > Cookies. Check four columns:

1. HttpOnly and Secure ticked for every session or auth cookie.
2. SameSite shows Lax or Strict, not blank or None.
3. Domain shows the exact host (no leading dot) for session cookies.
4. Expires / Max-Age shows "Session" or a short lifetime.

Then open the Network tab, click the login request and look at the response's Cookies sub-tab. A yellow warning icon next to a cookie means the browser blocked or modified it, and hovering shows why, for example "This Set-Cookie was blocked because it had the SameSite=None attribute but did not have the Secure attribute". That message explains most "works in Postman, not in the browser" login tickets.

Step 3: Test the scenarios that actually get exploited

Session fixation

If the session ID stays the same before and after login, an attacker who can plant a known ID in the victim's browser inherits the authenticated session. Test it:

# 1. Get an anonymous session cookie
curl -s -c jar.txt -o /dev/null https://app.example.test/login
grep session jar.txt | awk '{print $7}'   # note the value
# 2. Log in with the same jar
curl -s -b jar.txt -c jar.txt -o /dev/null -X POST https://app.example.test/login \
  -d 'email=test@example.test&password=...&_token=...'
grep session jar.txt | awk '{print $7}'   # must be different

The fix is to regenerate the ID on every privilege change. In Laravel, $request->session()->regenerate() after Auth::attempt() (the starter kits already do this); in Express with express-session, call req.session.regenerate() before setting the user.

CSRF through a permissive SameSite

SameSite=Lax blocks the cookie on cross-site POST form submissions and on cross-site fetches, which neutralizes most classic CSRF. It still sends the cookie on top-level GET navigations, so any state-changing GET endpoint (/logout, /delete?id=, /approve?invoice=) remains exposed. Audit routes for that, and keep a CSRF token on forms anyway; SameSite is a second layer, not a replacement.

If you genuinely need SameSite=None (a cross-site iframe), set it only on that cookie, always with Secure.

Subdomain cookie injection

A cookie set with Domain=.example.com from blog.example.com, or from a compromised marketing subdomain, can shadow or overwrite the session cookie of app.example.com. The __Host- prefix closes this: the browser refuses a __Host- cookie that has a Domain attribute, a path other than /, or no Secure flag, so no subdomain can plant one.

Set-Cookie: __Host-session=<value>; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=7200

In Laravel that is a config change, SESSION_COOKIE=__Host-app_session, SESSION_DOMAIN=null, SESSION_SECURE_COOKIE=true in .env. In Express:

app.use(session({
  name: '__Host-sid',
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
  cookie: { httpOnly: true, secure: true, sameSite: 'lax', path: '/', maxAge: 2 * 60 * 60 * 1000 }
}));
app.set('trust proxy', 1); // behind a TLS-terminating proxy, or secure cookies are never sent

The trust proxy line is the failure I see most in Node deployments: behind Nginx or a load balancer, Express thinks the request is HTTP and silently refuses to set the Secure cookie.

Tokens in readable cookies

If your SPA stores a JWT in a non-HttpOnly cookie or in localStorage, any XSS can exfiltrate it. Decode one with the JWT Decoder and check its lifetime; my article on JWT security pitfalls explains why I prefer an HttpOnly session cookie for first-party apps.

Severity framework for findings

The 10-point cookie audit checklist

1. Run curl -sI on the login page, the post-login redirect and one API route.
2. List every cookie and mark which ones are secret (session, refresh, remember-me).
3. Secret cookies: Secure and HttpOnly present.
4. Secret cookies: SameSite=Lax or Strict, set explicitly.
5. Secret cookies: no Domain attribute; consider the __Host- prefix.
6. Lifetime matches policy; remember-me tokens are separate and rotate.
7. Session ID changes after login and after privilege changes.
8. No state-changing GET routes; CSRF tokens on forms.
9. DevTools Network tab shows no blocked-cookie warnings.
10. Behind a proxy, the app trusts X-Forwarded-Proto so Secure cookies are actually sent.

Frequently asked questions

Does HttpOnly prevent XSS?

No. It prevents JavaScript from reading the cookie, which stops the most common XSS payoff, session theft. An attacker can still act inside the victim's session while the page is open, so you still need output encoding and a Content Security Policy.

Is SameSite=Lax enough to stop CSRF?

It blocks the cookie on cross-site POSTs and subrequests, which covers most CSRF. It still sends the cookie on top-level GET navigations, so state-changing GET routes stay exposed. Keep CSRF tokens on forms and treat SameSite as a second layer.

Why is my Secure cookie not being set in production?

Usually because a reverse proxy terminates TLS and the app sees plain HTTP. Configure the framework to trust the proxy's X-Forwarded-Proto header, such as Express's trust proxy setting or Laravel's TrustProxies middleware, and the cookie will be issued.

What is the difference between __Host- and __Secure- cookies?

A __Secure- cookie must have the Secure flag. A __Host- cookie must also have Path=/ and no Domain attribute, which locks it to one exact host. Neither implies HttpOnly or SameSite.

Should the CSRF token cookie be HttpOnly?

Not when the pattern requires JavaScript to read it, as with Laravel's XSRF-TOKEN cookie that the client echoes in a request header. The token is not a credential on its own; the session cookie it pairs with must be HttpOnly.

Can I audit cookies without logging in?

Partly. Anonymous responses show the session cookie's attributes, since most frameworks issue one on the first visit. For fixation and post-login cookies, use a test account, never a real user's session.

Follow & Connect

• Website: PixelValut Tools
• YouTube: PixelValut (@pixel-valut)
• TikTok: PixelValut (@pixelvalut007)
• GitHub: Muhammad Ali Mughal (@ali111887)
• LinkedIn: Muhammad Ali Mughal

I build Smart Resume Analyzer, and the summary block is where I see the widest gap between what candidates write and what the systems and people downstream can use. This guide covers what parsers do with the section, what recruiters look for in it, real before-and-after rewrites, and a diagnostic you can run in ten minutes.

Should a resume have a summary or an objective?

Direct answer: Use a three-to-four-line professional summary, not an objective. An ATS stores the summary as free text that recruiters keyword-search, so it should repeat your target title, core stack and scope of work in plain words. Keep an objective only for career changes or entry-level roles, and even then state what you offer, not what you want.

Summary vs objective vs profile: what each one is for

The rest of this guide assumes the professional summary.

What ATS parsers actually do with the summary section

Parsers first segment the document by headings. A heading such as "Summary", "Professional Summary", "Profile" or "About" is mapped to a summary or objective field; text before the first recognized heading is often treated as part of the contact block. A summary with no heading, directly under your name, can be merged with your contact details or dropped.

Once segmented, the summary is usually stored as one free-text field. Unlike work experience, it is not split into title, employer and dates. What happens next varies by platform; vendors do not publish parser internals, so this table sticks to what you can observe.

You can check how your own file is segmented with the ATS Parser Online and, if you know the platform, the dedicated checkers for Workday, Greenhouse, Lever, iCIMS and Taleo. Not sure which one a job uses? The Which ATS Is This Job Using tool reads it from the application link.

How tokenization treats summary text

Keyword search over a resume is token-based. A simplified view of what happens to one summary sentence:

Input:   "Senior Backend Engineer (Node.js/TypeScript) | 8 yrs | AWS, PostgreSQL"
Tokens:  senior | backend | engineer | node.js | typescript | 8 | yrs | aws | postgresql
Lost:    "|" and "/" separators, parentheses
Risky:   "Node.js/TypeScript" may become one token "node.js/typescript" in some parsers

Three practical rules follow. Separate skills with commas or spaces, not slashes. Spell out the full term once and the acronym once ("Applicant Tracking System (ATS)", "continuous integration (CI/CD)"), because a recruiter may search either. And write the target title exactly as the job posting does, since title search is usually phrase-based. My guide on how ATS search matches your resume job titles goes deeper on that, and how ATS parsers extract and normalize resume skills covers the skill side.

What recruiters read in the summary

When I review resumes for engineering roles, the summary answers four questions before I scroll:

1. What are you? The title I would put you in, at the level I would hire you for.
2. In what? The two to four technologies or domains that match the role.
3. At what scale or scope? Team size, system size, users, revenue, regulated domain, anything that sets the level.
4. Is there one proof point? A single concrete outcome I can verify in your experience section.

What I skip: soft-skill adjectives ("passionate", "results-driven"), what you hope to learn, and any claim not backed up further down the page.

Weak vs ATS-optimized summary rewrites

Each rewrite keeps the facts of the original candidate and only changes structure and wording. The details are illustrative, not from real clients.

1. The classic objective

Weak: Motivated software developer seeking a challenging position in a growth-oriented company where I can utilize my skills.

ATS-optimized: Full-Stack Developer with 4 years building Laravel and Vue.js applications for e-commerce and logistics clients. Shipped checkout, inventory and courier integrations used daily by operations teams. Comfortable owning features end to end, from MySQL schema to deployment.

2. The adjective stack

Weak: Results-driven, detail-oriented, passionate data analyst and strong team player.

ATS-optimized: Data Analyst with 3 years in retail and FMCG reporting. SQL, Python (pandas) and Power BI for weekly sales, pricing and stock dashboards. Automated a manual Excel reporting process into scheduled SQL jobs.

3. The career changer (objective done right)

Weak: Teacher looking to transition into tech and start a new career in UX.

ATS-optimized: UX Designer transitioning from 6 years in secondary education. Figma, user interviews and usability testing, with three end-to-end portfolio case studies.

4. The senior engineer who undersells

Weak: Experienced engineer with a wide range of skills across many technologies.

ATS-optimized: Principal Software Engineer, 9+ years in PHP/Laravel, Node.js, TypeScript and .NET microservices across fintech and SaaS. Lead architecture for multi-tenant platforms and payment integrations, and mentor teams of 4 to 8 engineers.

The pattern: target title, then years and stack, then domain and scope, then one concrete outcome. That order matches how recruiters scan and what they type into search.

The 7-step summary diagnostic

Run this before every application batch:

1. Heading check. The section has a standard heading ("Summary" or "Professional Summary") and sits below your contact details, not inside a header, text box or table.
2. Title match. The first words are the target title as written in the posting, at a level you can defend.
3. Stack match. Two to four hard skills from the job description appear verbatim. Pull them with the Job Description Keyword Finder.
4. Token hygiene. No slashes or pipes joining skills, acronyms expanded once, no special symbols as bullets.
5. Proof link. Every claim in the summary is backed by a bullet in experience. If it is not, delete it or add the bullet.
6. Length. Three to four lines, roughly 40 to 70 words. Longer summaries get skimmed past.
7. Parse test. Upload the file to an ATS resume checker and confirm the summary lands in its own section, then run a resume-to-job match against the target posting.

If you tailor per application, change the title and stack lines, not the facts. My walkthrough on tailoring resume keywords without keyword stuffing shows how far that can go before it reads as stuffing.

Common failure modes I see

• Summary in a sidebar, header or text box. Some parsers read side panels out of order and ignore document headers entirely.
• Keyword dump. A list of 25 technologies matches searches but fails the human read.
• Objective for senior roles. "Seeking a leadership role" after ten years of experience misses the point of the section.

Frequently asked questions

Is a resume objective outdated?

For most experienced candidates, yes. An objective describes what you want, which neither the ATS nor the recruiter can use. It still has a narrow place for career changers and first-job applicants, provided it is rewritten to state what you bring to one specific target role.

How long should a resume summary be?

Three to four lines, roughly 40 to 70 words. That fits title, years, stack, scope and one proof point; anything longer tends to be skimmed.

Do ATS systems read the summary section?

Most parse it as a free-text block attached to your profile and include it in keyword search. It is not usually mapped to structured fields like job title or dates, so its value is in the plain-language terms it contains, provided it sits under a standard heading in the document body.

Should I write my summary in first person?

Use implied first person: drop the "I" and start with the title or a verb, as in "Backend Engineer with 6 years..." It reads cleanly and is the convention most recruiters expect; full first-person prose belongs in LinkedIn's About section.

Should I change my summary for every job?

Adjust it, do not rewrite it. Swap the title to match the posting and reorder the stack line to lead with the skills that job asks for. Keep the facts identical across versions, because recruiters and background checks compare them.

Can a summary hurt my ATS score?

It can if it lives in a header, text box, table or image, because the parser may misplace or drop it. It can also hurt the human review if it claims skills or scope that the experience section does not support. Plain text under a standard heading avoids both problems.

Follow & Connect

• Website: Smart Resume Analyzer
• YouTube: Resume Boost AI (@resume-boost-ai)
• TikTok: Resume Boost AI (@resumeboostai)
• X: Muhammad Ali Mughal (@AliMughal887)
• GitHub: Muhammad Ali Mughal (@ali111887)
• LinkedIn: Muhammad Ali Mughal

At Loop Origin a large share of our work is connecting custom Laravel and Node applications to ERPs, CRMs, accounting tools and courier platforms. This is the architecture I now use by default: a transactional outbox, rate-limited idempotent workers, a dead-letter table with replay, and a daily reconciliation that catches what everything else missed.

How do you build API integrations that survive outages and rate limits?

Direct answer: Never call a partner API inside the user's request. Write an outbox record in the same database transaction as your business change, deliver it with a queued worker that respects rate limits, retries with backoff and sends an idempotency key, park permanently failing messages in a dead-letter table you can replay, and reconcile both systems daily.

The failure modes you are designing for

The architecture in one picture

[App request] --DB transaction--> orders + integration_outbox
                                         |
                       dispatcher (every few seconds)
                                         v
                   queue: erp-sync (rate limited, retries, backoff)
                        |                         |
                  success: mark sent       final failure: integration_dead_letters
                                                  |
                                     replay command / admin screen
[Partner webhooks] -> verify signature -> integration_inbox (unique event_id) -> handlers
[Nightly] reconciliation job compares both sides and opens tickets for differences

The rest of this article fills in each box.

The transactional outbox

The classic bug: save the order, commit, then call the ERP. If the process dies between the commit and the call, the ERP never hears about the order. Calling the ERP before committing is worse, because a later rollback leaves a phantom order in the ERP. The outbox writes the intent to sync in the same transaction as the business change.

Schema::create('integration_outbox', function (Blueprint $t) {
    $t->id();
    $t->string('target');                 // 'erp', 'crm', 'accounting'
    $t->string('event');                  // 'order.created'
    $t->string('aggregate_id');           // order id
    $t->uuid('idempotency_key')->unique();
    $t->json('payload');
    $t->string('status')->default('pending'); // pending|sent|dead
    $t->unsignedInteger('attempts')->default(0);
    $t->timestamp('available_at')->useCurrent();
    $t->timestamps();
    $t->index(['status', 'available_at']);
});

DB::transaction(function () use ($data) {
    $order = Order::create($data);
    IntegrationOutbox::create([
        'target' => 'erp', 'event' => 'order.created',
        'aggregate_id' => (string) $order->id,
        'idempotency_key' => (string) Str::uuid(),
        'payload' => OrderErpMapper::toPayload($order),
    ]);
});

A scheduled dispatcher picks pending rows and pushes jobs. Delivery is now at-least-once, which is why idempotency is not optional.

The worker: rate limits, backoff and a deadline

Laravel's queue gives you most of what you need out of the box. I covered Supervisor, Redis and failed-job basics in Running Laravel Queues in Production; here is the integration-specific part.

// AppServiceProvider::boot()
RateLimiter::for('erp-api', fn () => Limit::perMinute(50));

class PushOutboxToErp implements ShouldQueue
{
    use Queueable;

    public function __construct(public int $outboxId) {}

    public function middleware(): array
    {
        $row = IntegrationOutbox::find($this->outboxId);
        return [
            new RateLimited('erp-api'),
            (new WithoutOverlapping("erp:{$row?->aggregate_id}"))->releaseAfter(30),
        ];
    }

    public function backoff(): array { return [10, 60, 300, 900]; }
    public function retryUntil(): DateTime { return now()->addHours(6); }

    public function handle(ErpClient $erp): void
    {
        $row = IntegrationOutbox::findOrFail($this->outboxId);
        if ($row->status === 'sent') return;           // already delivered

        $res = $erp->post('/orders', $row->payload, [
            'Idempotency-Key' => $row->idempotency_key,
        ]);

        if ($res->status() === 429) {
            $this->release((int) ($res->header('Retry-After') ?: 60));
            return;
        }
        $res->throw();                                  // 5xx -> retry with backoff
        $row->update(['status' => 'sent', 'attempts' => $row->attempts + 1]);
    }

    public function failed(Throwable $e): void
    {
        IntegrationDeadLetter::fromOutbox($this->outboxId, $e);
    }
}

A few decisions in that code matter more than they look:

• The limit is set below the partner's documented limit, because other systems may share your API key.
• WithoutOverlapping per aggregate keeps two updates for the same order from racing, which handles most out-of-order problems.
• retryUntil instead of a fixed attempt count, so a long outage does not burn every retry in the first ten minutes.
• 4xx validation errors should not be retried. I map 400 and 422 straight to the dead-letter table, since retrying a bad payload only adds noise.

If the partner does not support idempotency keys, look up by your own reference first (for example, an external order number field) before creating. The strategy and factory patterns I use for payment and courier gateways work the same way for multiple ERP or CRM targets.

Inbound webhooks: verify, store, then process

Partners retry webhooks, sometimes many times. Treat every inbound event the same way:

1. Verify the signature (usually an HMAC of the raw body with a shared secret) before parsing.
2. Insert into an integration_inbox table with a unique constraint on the partner's event ID. A duplicate insert means you have already seen it; return 200.
3. Respond quickly, then process from the inbox with a queued job.
4. Re-fetch the current state of the entity from the partner API when ordering matters, instead of trusting the event payload.

The same idempotent-ledger thinking appears in my article on multi-vendor marketplace payments, where duplicate payment webhooks are the expensive version of this problem.

Dead letters and replay

A dead-letter table is only useful if someone looks at it and can fix and resend. Mine stores the outbox ID, target, last HTTP status, the error message and a truncated response body. An Artisan command replays after the cause is fixed:

php artisan integration:replay --target=erp --since="2026-10-27 09:00" --dry-run
php artisan integration:replay --target=erp --ids=812,813,840

Replay resets the outbox row to pending with the same idempotency key, so a message that actually reached the partner is not created twice. I alert when the dead-letter count for any target is above zero for more than an hour, not on every individual failure.

Choosing a sync strategy

Most production integrations I build combine two: push or webhooks for speed, plus cursor polling or reconciliation for correctness.

Field ownership and conflict rules

Two-way sync without rules ends in a loop of each system overwriting the other. Before writing code, I agree a field ownership table with the client: the CRM owns contact details, the ERP owns credit limits and stock, the web app owns orders until they are invoiced. Each mapper only writes the fields its side owns, and every write carries a source marker so an echo of your own change is ignored.

Implementation checklist

1. Never call a partner API inside a user request or a database transaction.
2. Write outbox rows in the same transaction as the business change.
3. Send an idempotency key or check by external reference before creating.
4. Rate-limit below the partner's documented limit and honour Retry-After.
5. Use exponential backoff with an overall deadline, and do not retry 4xx validation errors.
6. Serialize work per entity to avoid out-of-order updates.
7. Verify webhook signatures and deduplicate on event ID.
8. Store dead letters with enough context to fix and replay.
9. Version your field mappers and alert on validation failures.
10. Reconcile key totals daily and review differences.

Our Laravel development and custom web application teams apply this checklist on every integration, and we wrote about common local integration targets in API integration for Pakistani businesses.

Frequently asked questions

What is a dead-letter queue in API integrations?

It is a holding area for messages that failed after all retries. Instead of disappearing into logs, each failed message is stored with its error so a developer can fix the cause and replay it safely, usually with the original idempotency key.

Why use a transactional outbox instead of calling the API after saving?

Because the process can crash between the database commit and the API call, and the partner never hears about the change. Writing an outbox row in the same transaction guarantees the intent to sync is saved whenever the business data is.

How should I handle HTTP 429 responses?

Pause and retry after the time in the Retry-After header if present, otherwise back off exponentially. Also limit your own request rate below the partner's documented limit so you rarely hit 429 in the first place.

What if the partner API does not support idempotency keys?

Store your own reference in a field on the partner record, such as an external order number, and search for it before creating. Combined with per-entity serialization, this prevents most duplicates.

Webhooks or polling: which is more reliable?

Webhooks are faster but can be delayed, duplicated or dropped. Polling with an updated_since cursor is slower but predictable. For business-critical data I use webhooks for speed plus polling or reconciliation as the safety net.

How often should integrations be reconciled?

Daily is a sensible default for orders, invoices and stock. High-volume or financial flows may justify hourly checks of totals and counts, with a full comparison overnight.

Follow & Connect

• Website: Loop Origin
• LinkedIn: Loop Origin
• X: Muhammad Ali Mughal (@AliMughal887)
• GitHub: Loop Origin (@LoopOrigin)

I have estimated and delivered Laravel, Vue, Nuxt, Node and .NET systems for nine years, and at Loop Origin scoping is the step I refuse to rush. My method: a work breakdown that surfaces hidden scope, three-point estimates, a contract model chosen by uncertainty, and change control after kickoff.

How do you estimate a custom software project accurately?

Direct answer: Break the product into features and non-functional work, estimate each item as optimistic, likely and pessimistic hours, and combine them with a three-point (PERT) formula to get a range, not a single number. Price fixed-scope phases only where uncertainty is low, use time-and-materials for discovery and unknowns, and manage every later change through a written change request.

Why single-number estimates fail

A single number hides the uncertainty the client most needs to see. "Payment integration: 40 hours" might mean 24 hours with a well-documented gateway, or 90 with a regional provider whose webhooks are inconsistent. I have seen both.

The other failure is anchoring: once a figure is said in a sales call, everyone remembers it and nobody remembers the assumptions. Writing assumptions next to every line is the cheapest risk control in software.

Step 1: A work breakdown that includes the invisible work

I split every project into four layers before estimating anything:

The second, third and fourth layers are where cheap quotes save money on paper. For a deeper look at how foundations change the build-versus-buy decision, see my DEV article on custom software vs off-the-shelf SaaS and three-year ROI.

Step 2: Three-point estimates per item

For each work item I record three figures in hours: optimistic (O), most likely (M) and pessimistic (P). PERT combines them:

• Expected = (O + 4M + P) / 6
• Standard deviation per item = (P - O) / 6

Here is a small extract from an illustrative B2B ordering portal. The hours are an example to show the method, not a benchmark for your project.

Notice which rows have the widest spread: migration and ERP export. Those are where I spend discovery time before committing to a fixed price.

The summation is simple enough to keep in a script next to the estimate sheet:

import math

items = [  # (name, optimistic, likely, pessimistic)
    ("auth_roles", 16, 24, 40), ("catalogue", 24, 40, 72),
    ("cart_orders", 24, 36, 60), ("erp_export", 12, 20, 48),
    ("admin", 32, 48, 80), ("migration", 16, 32, 80), ("ops", 16, 24, 40),
]
expected = sum((o + 4*m + p) / 6 for _, o, m, p in items)
sigma = math.sqrt(sum(((p - o) / 6) ** 2 for _, o, _, p in items))
print(f"expected {expected:.0f} h, one sigma above: {expected + sigma:.0f} h")
# expected 243 h, one sigma above: 261 h

Summing variances assumes items are independent, which they are not entirely, so I treat the one-sigma figure as a floor for contingency, not a ceiling. I also add project management and QA as explicit lines rather than hiding them in feature hours.

Step 3: Choose the contract model by uncertainty, not by habit

My default for a new business application is short paid discovery under time-and-materials, then fixed-price milestones for well-understood phases. Discovery turns the widest estimates into known work, and the client owns the output. Our pricing page explains how we structure these engagements.

Step 4: Write a scope document a stranger could price

The test I use: could a different competent team produce a similar estimate from this document alone? If not, it is not a scope, it is a wish list. Each feature gets:

• User story and acceptance criteria, written so a tester can say pass or fail.
• Explicit exclusions. "No SSO", "No multi-currency", "No mobile app" save more arguments than any other sentence.
• Non-functional requirements with numbers where possible: expected users, data volume, browsers supported, uptime target, data retention.
• Dependencies on the client: content, API credentials, sample data, a decision-maker available within two working days.

Multi-tenant products need extra care here, because tenancy decisions ripple through every table. I covered those trade-offs in Multi-Tenant SaaS Database Architecture in 2026.

Step 5: Change control that does not poison the relationship

Scope will change; good products learn from users. The goal is that every change is priced before it is built. My change request template:

change_request:
  id: CR-014
  requested_by: Operations lead
  description: Allow customers to save repeat orders as templates
  reason: Top request from pilot customers in UAT
  estimate_hours: { optimistic: 10, likely: 16, pessimistic: 28 }
  impact: "+1 week on Milestone 3; no change to Milestone 2"
  decision: pending   # approved | deferred-to-phase-2 | rejected

Two rules keep this healthy. First, small changes can be swapped against equal-sized items in the backlog instead of adding cost, which keeps goodwill. Second, nothing is built until the decision field says approved, in writing.

Production failure modes I see in estimates

• "Simple" data migration. Legacy exports with duplicate customers, free-text dates and missing foreign keys. Budget a cleanup pass and a dry run. My strangler-fig migration guide covers running old and new systems side by side.
• Third-party APIs estimated from marketing pages. Always check for a sandbox, rate limits and webhook documentation before quoting.
• No UAT window. Clients need time to test with real data; plan one to two weeks per major milestone.
• Reporting added at the end. Reports often need data structures that should have been designed in month one.
• One person holds all the knowledge. Estimate handover and documentation explicitly.

The scoping checklist

1. List features, then add the foundations, data and operations layers.
2. Estimate every item as optimistic, likely and pessimistic hours with written assumptions.
3. Run paid discovery on the items with the widest spread.
4. Choose the contract model per phase based on remaining uncertainty.
5. Write acceptance criteria and explicit exclusions for every feature.
6. Agree client dependencies and decision turnaround times.
7. Adopt a change request template before kickoff, not after the first dispute.
8. Re-estimate at every milestone using actual hours from the previous one.

If you are preparing a brief and want it reviewed against this checklist, our custom web application development team starts every engagement this way.

Frequently asked questions

Why do software quotes for the same brief vary so much?

Because the brief rarely defines foundations, data migration, integrations or operations. One vendor prices them, another assumes they are out of scope or will be handled later. Ask every vendor for a line-item breakdown with assumptions and exclusions, then compare like for like.

Is fixed price safer for the client?

Only when scope is genuinely stable. Fixed price moves risk to the vendor, who prices it in as a buffer or protects margin by cutting quality. For uncertain work, a capped time-and-materials phase is often more transparent.

How much contingency should a software budget include?

There is no universal percentage. Derive it from your estimate spread: the wider the gap between likely and pessimistic hours on key items, the larger the contingency. Items such as migration and third-party integrations usually drive most of it.

What is a paid discovery phase?

A short, fixed or capped engagement to clarify requirements, prototype risky parts and produce a scope document with estimates. It reduces the biggest unknowns before you commit to the full build, and you keep the output.

How do I stop scope creep without blocking good ideas?

Route every change through a written change request with an estimate and impact on milestones. Allow swaps of equal-sized items, defer the rest to a later phase, and build nothing that has not been approved in writing.

Should maintenance be included in the initial quote?

It should be quoted separately but discussed upfront. Hosting, security updates, dependency upgrades and small fixes continue after launch, and knowing that cost early avoids surprises in the first year.

Follow & Connect

• Website: Loop Origin
• LinkedIn: Loop Origin
• X: Muhammad Ali Mughal (@AliMughal887)
• GitHub: Loop Origin (@LoopOrigin)

I build PixelValut, a set of browser-side developer and security tools, and I have been triaging suspicious links for clients and my own inbox for years. This is the exact workflow I use, with real command output so you know what each step should look like.

How do you safely check if a link is malicious?

Direct answer: Do not click it. Copy the URL, parse it to find the real hostname, decode any Punycode or percent-encoding, expand shorteners and redirect chains with header-only requests, then check the final domain's registration age and DNS. A lookalike hostname, a very new domain or a redirect that ends somewhere unrelated is enough to treat it as hostile.

The five places a malicious link hides its destination

The first three are about reading the hostname correctly. The last two are about where the request ends up.

Step 1: Parse the URL instead of eyeballing it

Paste the link into the PixelValut URL Parser or, if you prefer a terminal, Python's standard library. Here is the actual output for the three tricky examples from the table:

$ python3 parse_urls.py   # urllib.parse.urlsplit on each URL
https://www.paypal.com@login-check.example/verify
  scheme=https username=www.paypal.com hostname=login-check.example path=/verify
https://paypal.com.account-verify.example/login?next=%2Fsignin
  scheme=https username=None hostname=paypal.com.account-verify.example path=/login
https://example.com/redirect?url=https%3A%2F%2Fevil.example%2F
  hostname=example.com query=url=https%3A%2F%2Fevil.example%2F

The first line is the clearest lesson: www.paypal.com is parsed as a username. The browser goes to login-check.example. For the second, the registrable domain is the last two labels (or three for suffixes like .co.uk), so account-verify.example owns everything to its left. For the third, the host is legitimate but the encoded url parameter is the real destination; run it through the URL Encoder/Decoder and the target is obvious.

Step 2: Decode Punycode and inspect every character

Internationalized domain names let any Unicode letter appear in a hostname. On the wire, they are encoded as Punycode with an xn-- prefix. That encoding is your friend, because it makes lookalikes visible:

$ python3 -c "print('pаypal.com'.encode('idna'))"
b'xn--pypal-4ve.com'

$ python3 -c "import unicodedata; print(unicodedata.name('аpple.com'[0]))"
CYRILLIC SMALL LETTER A

Two strings that render identically in most fonts are different domains with different owners. Browsers apply mixed-script rules and will often display the xn-- form in the address bar for suspicious combinations, but email clients, chat apps and PDF viewers are less consistent.

In the browser, paste the hostname into the Punycode Converter, which encodes to the xn-- form and warns on mixed-script labels, then into the Unicode Inspector to list each code point, its name and its script. One Cyrillic or Greek letter inside an otherwise Latin brand name is the giveaway.

Step 3: Expand shorteners and follow redirects with headers only

A HEAD or header-only request asks the server where it would send you without rendering the page or running its JavaScript. Two real examples from today:

$ curl -sI https://youtu.be/dQw4w9WgXcQ | grep -iE '^(HTTP|location)'
HTTP/2 303
location: https://www.youtube.com/watch?v=dQw4w9WgXcQ&feature=youtu.be

$ curl -sI https://www.pixelvalut.com | grep -iE '^(HTTP|location)'
HTTP/1.1 301 Moved Permanently
Location: https://pixelvalut.com/

Both are benign: one hop, same organization, HTTPS throughout. A malicious chain usually looks different: a shortener, then a tracking or "cloaking" domain, then a fresh domain, sometimes with an http:// hop in the middle. Repeat the request against each Location until you get a 200 or a loop, or let the URL Unshortener and Redirect Chain Checker do it; both follow headers only and show every hop.

One caveat I learned the hard way: some phishing kits return a harmless redirect to non-browser clients or to IP ranges belonging to cloud providers, and the real one only to a phone on a residential connection. A clean chain lowers risk; it does not prove safety.

Step 4: Check domain age and registration

Brand-new domains are a strong signal. Legitimate login pages almost never live on a domain registered last week. RDAP, the structured successor to WHOIS, gives you the dates directly. Here is the real record for pixelvalut.com:

$ curl -sL https://rdap.org/domain/pixelvalut.com   # relevant fields, queried 27 Oct 2026
registration   2025-07-06T15:25:09Z
expiration     2027-07-06T15:25:09Z
last changed   2026-06-22T17:45:26Z
status         client transfer prohibited
nameservers    DNS1.REGISTRAR-SERVERS.COM, DNS2.REGISTRAR-SERVERS.COM

In the browser, the WHOIS Lookup and Domain Age Checker read the same RDAP data. What I look for:

• Registration within the last few weeks for a domain asking for credentials or payment.
• A one-year registration combined with a brand name in the hostname.
• Nameservers or hosting unrelated to the brand it imitates. A quick DNS Lookup of A and MX records shows where it really lives.

Age alone is not proof. Old domains get compromised, and new startups launch every day. It is one input in the scoring below.

Step 5: Look at TLS and mail authentication, but do not over-trust them

A padlock means the connection is encrypted to whoever controls that hostname. Free certificates are issued automatically to phishing domains as easily as to real ones, so HTTPS is not a trust signal on its own. The SSL Checker is still useful for one thing: the certificate's subject names tell you which hostnames share it, which occasionally exposes a cluster of lookalike domains. My older guide on checking an SSL certificate in 10 minutes covers what each field means.

If the link arrived by email, check whether the message passed SPF, DKIM and DMARC for the domain it claims to come from. My walkthrough on checking SPF, DKIM and DMARC records shows how to read those results in message headers.

A scoring framework you can apply in two minutes

Any single high-risk signal and I treat the link as hostile. Two medium signals and I verify through a separate channel: I type the brand's address myself or call the sender.

The 8-step checklist

1. Copy the link; never click it from the message.
2. Parse it and write down the real hostname.
3. Read the hostname right to left to find the registrable domain.
4. Convert to Punycode and inspect code points for mixed scripts.
5. Decode percent-encoded query parameters that contain URLs.
6. Expand shorteners and follow every redirect with headers only.
7. Check the final domain's registration date, nameservers and A/MX records.
8. If anything is high risk, report it and reach the service through a bookmark or typed address.

If you run a domain yourself, the defensive side matters too: my guide on auditing DNS records before a migration shows how to keep your own records tidy so you are harder to impersonate.

Frequently asked questions

Is it safe to click a link just to see where it goes?

No. Opening a page can run scripts, trigger downloads and confirm to the sender that your address is active. Header-only requests and parsing tools reveal the destination without rendering anything.

Does HTTPS mean a site is legitimate?

No. HTTPS means the connection is encrypted to that hostname. Certificate authorities issue domain-validated certificates automatically, including to phishing domains, so the padlock tells you nothing about who runs the site.

What is an IDN homograph attack?

It is a domain that uses characters from another script, such as Cyrillic "а", to imitate a Latin brand name. Converting the hostname to Punycode exposes it, because the lookalike becomes an xn-- string that no longer resembles the brand.

Can URL shorteners be trusted?

The shortener itself is usually fine; the destination is the unknown. Expand the link with a header-only tool first. Some services also offer preview pages, but checking the redirect chain yourself works for every shortener.

How new is "too new" for a domain?

There is no official threshold. In my own triage, a domain registered within the last few weeks that asks for a login or payment is high risk. Combine age with the other signals rather than relying on a single cutoff.

What should I do after finding a phishing link?

Do not interact with it. Report the message through your email provider's phishing option, tell your IT or security team if it was a work account, and, if you already entered a password, change it immediately and enable multi-factor authentication.

Follow & Connect

• Website: PixelValut Tools
• YouTube: PixelValut (@pixel-valut)
• TikTok: PixelValut (@pixelvalut007)
• GitHub: Muhammad Ali Mughal (@ali111887)
• LinkedIn: Muhammad Ali Mughal

I build the parsing and matching logic behind Smart Resume Analyzer, and I see the same pattern every week: strong candidates whose title line is honest but unsearchable. The fix is not to invent a title. It is to give the parser and the recruiter both the official title and the market title in one defensible line.

How do ATS searches match resume job titles?

Direct answer: An ATS parser splits each role into title, employer, location and dates, and recruiters search that title field and your resume text with keywords like "Backend Engineer". If your official title is internal jargon, add the market title beside it, for example "Member of Technical Staff (Backend Engineer)", and repeat it in your summary.

What the parser does with your title line

Every work entry goes through roughly this pipeline:

1. Block detection. The parser finds the Experience section and splits it into entries, usually by spotting date ranges.
2. Field assignment. It decides which line is the title, employer and location, using position, formatting and dictionaries of known titles and companies.
3. Title normalization. Some systems map the raw string to a standard occupation, using taxonomies like O*NET-SOC (US) or ESCO (EU), which list occupations with alternate titles.
4. Indexing. The raw title, any normalized title and the full resume text become searchable.

Two things fail often. If title and employer share a line with an unusual separator ("Acme // Ninja"), the parser can swap them, leaving a candidate whose most recent title is "Acme". And internal titles rarely exist in any taxonomy, so normalization fails or maps to something odd. You can see the result of step 2 on your own file with the Smart Resume Analyzer ATS Parser: look at which string landed in the title field for each role.

I covered the date half of this pipeline in How ATS Parsers Read Work Experience Dates, Career Gaps & Overlapping Roles. Titles and dates are parsed together, so a broken date often drags the title down with it.

How recruiters actually search by title

Recruiter search is less clever than candidates assume. In most systems I have used or integrated with, it is a keyword or Boolean query over the parsed profile and resume text, sometimes filtered by current or past title:

("backend engineer" OR "backend developer" OR "software engineer")
AND (laravel OR php) AND (postgresql OR mysql)

"Code Ninja", "MTS" and "Associate, Platform" are not in that query. A title that never appears literally only surfaces if normalization maps it correctly, which you cannot verify from the candidate side.

Weak vs ATS-optimized title lines

Real patterns from resumes I have reviewed, names changed. The rule: the official title stays, the market title is added, and nothing claims a level you did not hold.

The parenthetical keeps the whole title on one line in one field. Do not put the market title on a separate line below; some parsers will read that line as the employer.

Side-by-side: one role before and after

Before:

ACME LABS // Code Ninja II
Remote | 03/2021 - now
- Owned the billing stuff and helped with infra

Likely parse: employer "ACME LABS // Code Ninja II" or title "ACME LABS", an odd date token, and a bullet with no searchable skills.

After:

Software Engineer II (internal title: Code Ninja II)
Acme Labs, Remote | Mar 2021 - Present
- Rebuilt the Laravel billing service on PostgreSQL and Redis queues,
  cutting failed invoice runs from weekly to zero over two quarters.

Title on its own line, employer below, standard dates, and a bullet that proves the title with searchable skills.

How Greenhouse, Workday, Lever, iCIMS and Taleo treat titles

I will stick to what you can observe as a candidate or read in recruiter-facing documentation, not guesses about proprietary ranking.

If you are unsure which system a posting uses, the Which ATS Is This Job Using? page shows how to tell from the apply URL. Our system-specific notes for Workday and Greenhouse go deeper on each flow.

Where the target title should appear besides the title line

One occurrence is fragile. I aim for three natural ones:

• Headline or summary. "Backend Engineer with 7 years building Laravel and PostgreSQL billing systems."
• The most recent title line, using the parenthetical pattern when the official title is unusual.
• One bullet that names the function: "Led backend engineering for the payments squad".

Three mentions in three contexts is not stuffing. Twelve in a white-font footer is, and reviewers spot it instantly.

When a market title becomes misrepresentation

I am strict here, because background checks compare your resume with HR records.

• Do not upgrade the level. If you were "Engineer II", "Senior Engineer" is not a market translation, it is a promotion you did not get.
• Do not change the function. A support engineer who wrote scripts is "Technical Support Engineer (Python automation)", not "Software Engineer".
• Keep the official title visible. The parenthetical keeps you consistent with employment verification.
• Match LinkedIn. Recruiters cross-check. Use the same pattern on both, which our LinkedIn Optimizer helps you review.

The 7-step job title diagnostic

Run this before every application batch.

1. Parse your file. Upload it to the ATS Parser and check that each role's title, employer and dates landed in the right fields.
2. List the market titles. Take three postings you want and note the exact titles they use. The Job Description Keyword Finder pulls them out with the rest of the keywords.
3. Compare literally. For each of your recent roles, ask: would a recruiter typing the posting's title find this line? If not, add the market title in parentheses.
4. Separate lines. Title on one line, employer and location on the next, dates in "Mon YYYY - Mon YYYY" form.
5. Split stacked titles. Promotions under one employer get their own sub-entries with dates.
6. Add the title to your summary once, in a sentence that also states scope and stack.
7. Re-check the match. Run the resume and posting through Resume Job Match and confirm the title gap is closed without inflating anything.

For the wider keyword side of step 7, see my DEV guide on tailoring resume keywords without stuffing, and for how the same normalization logic treats skills, How ATS Parsers Extract and Normalize Resume Skills.

Frequently asked questions

Is it lying to put a different job title on my resume?

It is if you replace the official title with a higher or different one. A functional equivalent in parentheses next to the official title is a translation, not a claim, and stays consistent with employment verification.

Should my resume title exactly match the job posting title?

Only if it truthfully describes what you did. Exact matching helps literal search, but a "Senior Data Scientist" headline on an analyst resume will not survive the first interview. Use the posting's wording where it is accurate.

How do I list several titles at one company?

Put the employer once, then each title as a dated sub-entry with its own bullets, most recent first. Every title gets its own parsed field and progression is visible.

Does the ATS rank me lower if my title does not match?

I cannot verify proprietary ranking, and I distrust anyone quoting exact numbers. What is observable: if the recruiter's search does not hit your title or text, you do not appear in the results at all.

What if my official title was more senior than my real work?

Use it, because verification will show it, but make the bullets describe your actual scope. Overstated scope costs more in interviews than a modest title.

Should I put a target title at the top of my resume?

A short headline such as "Backend Engineer, Laravel and PostgreSQL" helps both skimming and literal search. Keep it consistent with your recent roles, or it raises questions instead of answering them.

Follow & Connect

• Website: Smart Resume Analyzer
• YouTube: Resume Boost AI (@resume-boost-ai)
• TikTok: Resume Boost AI (@resumeboostai)
• X: Muhammad Ali Mughal (@AliMughal887)
• GitHub: Muhammad Ali Mughal (@ali111887)
• LinkedIn: Muhammad Ali Mughal

At Loop Origin we run client SaaS products on all three models covered here: a self-managed VPS, a VPS with a management layer and managed data services, and a fully managed PaaS. This is the model I use to choose between them, with prices I checked on the vendors' public pricing pages on 27 October 2026.

Is a self-managed VPS or a managed PaaS cheaper for a Laravel or Node SaaS?

Direct answer: On invoice alone, a self-managed VPS is usually the cheapest option. Once you price the engineering hours for patching, backups, monitoring and incident response, a VPS with managed databases is often the best value for a small team, and a fully managed PaaS wins when ops time is scarce and egress is modest.

What you are actually paying for

Every SaaS needs the same building blocks whatever the host: web processes, queue workers and a scheduler, a relational database, Redis or a compatible store, backups, TLS, deploys, logs and someone on call. The models differ in who owns each block.

If "You" appears in a row, budget hours for it. That is the line item missing from most comparisons.

Verified prices (checked 27 October 2026)

All prices are USD per month from the public pages named here. Pricing changes, so re-check before you decide.

An example TCO model for a small production SaaS

This is an example model, not a benchmark. The workload is a Laravel or Node app with two web processes, one queue worker, PostgreSQL, Redis and 500 GB of monthly egress. The ops hours are my planning assumptions for a stable product, and $40 per hour is a placeholder; plug in your own team's loaded rate.

• A. Self-managed DigitalOcean: 8 GB app Droplet ($48) plus a 4 GB Droplet running PostgreSQL and Redis ($24), weekly backups on both ($14.40). Invoice: $86.40. Ops: 8 hours a month for patching, backup restore tests, monitoring and the occasional incident.
• B. VPS + Forge + managed data: 8 GB Droplet ($48) with backups ($9.60), Forge Growth ($19), Managed PostgreSQL 2 GB ($30.45) and Managed Valkey 1 GB ($15). Invoice: $122.05. Ops: 3 hours.
• C. Render Pro: workspace ($25), two web services ($50), one worker ($25), Postgres 1 CPU / 4 GB ($55), Key Value 1 GB ($20), plus 475 GB overage at $0.15 ($71.25). Invoice: $246.25. Ops: 1 hour.

The compute is not identical: one 8 GB Droplet against three 2 GB services. The model compares what a small team would realistically buy, not equal hardware.

Monthly TCO by egress and ops rate

Three conclusions fall out of the numbers:

1. Self-managed only wins when your time is free. For a solo founder with skills and spare evenings, that can be true. Once you pay for engineering hours, the eight-hour assumption dominates the bill.
2. Egress decides between B and C. At 50 GB Render is cheapest in this model; at 2 TB it costs more than double option B, because DigitalOcean's pooled allowance covers that traffic.
3. Expensive engineers favour PaaS. At $80 an hour, the hours saved outweigh Render's higher invoice at 500 GB.

Move a CDN in front of static assets and user uploads, and egress drops for every option, which shifts the result toward C.

Hidden costs that do not show on any pricing page

• Restore testing. A backup you have never restored is a hope. Budget time to restore into a scratch database monthly, whichever model you choose.
• Security patching. Self-managed means following OS, PHP or Node, and Nginx advisories yourself.
• Single points of failure. Option A puts the database on one Droplet. A managed database plan with a standby node costs more but removes that risk.
• Build minutes and preview environments. Some PaaS plans meter these; check the plan details.
• Migration cost. Containerized apps move between models easily. My multi-stage Dockerfiles for PHP and Node post shows the image setup I use to keep that option open.

Laravel and Node specifics

Queue workers are where the models differ most in practice. On a VPS you run Supervisor or Horizon yourself; on Forge you define daemons; on Render a worker is its own billed service. My production setup is in Running Laravel Queues in Production.

For Node, long-lived WebSocket connections and memory growth matter more than CPU. Size instances by memory headroom and confirm the platform's request timeout and connection limits fit your realtime features.

Multi-tenant products should decide tenancy before hosting, because a database-per-tenant design multiplies managed database costs fast. I compared those designs in Multi-Tenant SaaS Database Architecture in 2026.

Decision checklist

• Estimate monthly egress from real logs or analytics, not guesses
• Put a loaded hourly rate on ops time, even for founders
• List who patches the OS, runtime and database in each option
• Price a standby database or accept the single-point-of-failure risk in writing
• Confirm queue workers, scheduler and WebSockets are supported and priced
• Re-check every price on the vendor's page the week you decide
• Keep the app containerized so you can switch later
• Revisit the model when traffic or team size doubles

Our server setup and maintenance and Laravel development teams handle all three setups. For regional hosting comparisons, see AWS vs DigitalOcean for Pakistani businesses and VPS vs shared hosting, or contact us.

Frequently asked questions

Is a VPS always cheaper than a PaaS?

On the invoice, usually. On total cost, not once you pay for the hours spent operating it. In the example model, self-managed was cheapest only when ops time cost nothing.

When should a startup move off a PaaS?

When egress or compute charges grow faster than revenue and you have someone who can own operations. Re-run the model with your real numbers first.

Is Laravel Forge enough to call a server managed?

No. Forge provisions and deploys, but you still own the server. It reduces ops time; it does not remove it.

Do managed databases make sense for small apps?

Often, yes. Backups, point-in-time recovery and patching are the riskiest jobs to do yourself, and managed plans handle them for a modest premium.

How much egress does a typical SaaS use?

It varies widely with uploads, media and API traffic. Measure it from your logs or CDN reports; it is the variable that most often flips this comparison.

Can I mix models?

Yes. A common pattern is app servers on a VPS with managed PostgreSQL and object storage behind a CDN, which is option B with a CDN in front.

Follow & Connect

• Website: Loop Origin
• LinkedIn: Loop Origin
• X: Muhammad Ali Mughal (@AliMughal887)
• GitHub: Loop Origin (@LoopOrigin)

At Loop Origin we build marketplace and e-commerce platforms on Laravel, Vue and Node, and the payment side is where I spend the most review time. This is the architecture I use: split payments, a double-entry commission ledger, payouts with holds, refunds and chargebacks, idempotency and daily reconciliation.

How should a multi-vendor marketplace handle split payments and payouts?

Direct answer: Charge the buyer once, record every movement as balanced double-entry ledger lines (buyer funds, vendor payable, platform commission, processor fees), and pay vendors from their ledger balance after a hold period. Make every write idempotent, treat refunds and chargebacks as new reversing entries, and reconcile the ledger against processor reports daily.

The money flow, before any code

One order with items from three vendors is one charge but three obligations. The platform keeps a commission, absorbs or passes on processor fees, and owes each vendor the remainder once goods ship and the refund window closes.

On Stripe Connect, row one maps to separate charges and transfers linked by a transfer_group; row two to destination charges, where a refund can pass reverse_transfer and refund_application_fee. The ledger below works with any model because it records what you owe, not what the processor did.

A double-entry ledger schema that survives audits

Every movement is a journal entry with two or more lines that sum to zero. Balances are derived from lines, never stored as the source of truth.

CREATE TABLE ledger_accounts (
    id           BIGSERIAL PRIMARY KEY,
    code         TEXT NOT NULL UNIQUE,      -- e.g. 'vendor:812:payable'
    type         TEXT NOT NULL CHECK (type IN ('asset','liability','revenue','expense')),
    currency     CHAR(3) NOT NULL
);

CREATE TABLE journal_entries (
    id              BIGSERIAL PRIMARY KEY,
    idempotency_key TEXT NOT NULL UNIQUE,   -- e.g. 'order:5521:captured'
    event_type      TEXT NOT NULL,          -- captured, refunded, payout, dispute...
    reference_type  TEXT NOT NULL,
    reference_id    BIGINT NOT NULL,
    occurred_at     TIMESTAMPTZ NOT NULL,
    created_at      TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE journal_lines (
    id          BIGSERIAL PRIMARY KEY,
    entry_id    BIGINT NOT NULL REFERENCES journal_entries(id),
    account_id  BIGINT NOT NULL REFERENCES ledger_accounts(id),
    amount      BIGINT NOT NULL,            -- minor units; debit +, credit -
    currency    CHAR(3) NOT NULL
);
CREATE INDEX ON journal_lines (account_id);

Three rules matter most: integer minor units, never floats; append-only lines, with corrections as new entries; and a unique idempotency_key that makes retries safe.

For a $100.00 order with two vendors, 10% commission and a $3.20 processor fee absorbed by the platform, the capture entry looks like this:

Debits equal credits at 10,320. Vendor 812 sold $60 and is owed $54; vendor 907 sold $40 and is owed $36. The fee reduces what the processor settles, so it also credits clearing.

The posting service: one transaction, balanced or nothing

final class LedgerPoster
{
    /** @param array<array{account:string, amount:int}> $lines */
    public function post(string $key, string $type, Model $ref, array $lines, string $currency): JournalEntry
    {
        if (array_sum(array_column($lines, 'amount')) !== 0) {
            throw new UnbalancedEntry($key);
        }

        return DB::transaction(function () use ($key, $type, $ref, $lines, $currency) {
            $entry = JournalEntry::firstOrCreate(
                ['idempotency_key' => $key],
                ['event_type' => $type, 'reference_type' => $ref->getMorphClass(),
                 'reference_id' => $ref->getKey(), 'occurred_at' => now()]
            );

            if (! $entry->wasRecentlyCreated) {
                return $entry; // replay: already posted, do nothing
            }

            foreach ($lines as $line) {
                $entry->lines()->create([
                    'account_id' => LedgerAccount::idFor($line['account'], $currency),
                    'amount'     => $line['amount'],
                    'currency'   => $currency,
                ]);
            }
            return $entry;
        });
    }
}

Two concurrent replays can both miss on firstOrCreate; the unique index makes one fail, so catch that violation and re-read the entry. The same pattern protects carts, as in How to Prevent Double Booking: Locks, Holds and Expiry.

Webhooks and idempotency in both directions

Idempotency has to work outbound and inbound.

• Outbound: every charge, transfer, refund or payout call sends a key derived from your IDs, such as transfer:order:5521:vendor:812. Stripe accepts an Idempotency-Key header; most processors have an equivalent.
• Inbound: insert each webhook event ID into a uniquely constrained processed_events table before acting. Processors retry on timeouts, so duplicates are normal.
• Order independence: a charge.refunded event can beat your own refund job. Key entries by the processor object ID so the second path is a no-op.

Process webhooks on a queue, return 2xx fast, and let failed jobs retry. My checklist for that setup is in Running Laravel Queues in Production.

Payouts, holds and negative balances

I credit sales to a vendor:{id}:held account and move them to vendor:{id}:payable with a scheduled release entry once the order is delivered and the return window closes. The payout job then:

1. Locks the vendor row (SELECT ... FOR UPDATE) so payout jobs cannot overlap.
2. Computes the payable balance from ledger lines and skips if it is negative or below the minimum.
3. Posts a payout entry (debit payable, credit payout_in_transit) keyed payout:{vendor}:{period}.
4. Calls the processor with the same key, then settles payout_in_transit on the paid event or reverses it on failure.

A refund after payout makes the vendor's payable negative. Do not hide it: net it against future sales, and define in your vendor agreement when you invoice or pause the account.

Refunds and chargebacks are new entries

A partial refund of $20 on vendor 812's item reverses the proportional slice: debit vendor 812 payable 1,800, debit commission 200, credit processor clearing 2,000. Whether the processor fee is returned depends on your processor and its terms, so record what the processor report says, not what you assume.

A chargeback is two events. When the dispute opens, move the amount and any dispute fee into disputes_pending and freeze the vendor's share. Win, and you reverse it; lose, and the loss lands on the vendor or platform per your policy.

Daily reconciliation

Every day, import the processor's balance transactions or settlement report and match totals:

Unmatched rows go to a review queue with object IDs from both sides. A ledger silently off by cents each day becomes an unexplainable gap at month end.

Failure modes I see in reviews

• Floats for money. Rounding drifts across splits. Use integers and assign remainders to one line.
• Commission computed at payout time. A rate change rewrites old orders. Freeze the rate at capture.
• Mutable balance columns as truth. Fine as a cache, fatal as the source.
• Refund handlers that assume no payout happened. Always handle negative balances.
• Multi-currency entries. One currency per entry; post FX as its own movement.

For the processor-abstraction side, I use the strategy pattern from Strategy and Factory Patterns for Payment and Courier Code.

Implementation checklist

• Amounts stored as integer minor units, with currency on every line
• Journal entries balanced before commit and lines append-only
• Unique idempotency key on entries, outbound API calls and inbound webhook IDs
• Commission rate frozen per order line at capture
• Held and payable accounts separated, with scheduled release entries
• Payout job locks per vendor and handles negative balances
• Refunds and disputes posted as reversing entries, never edits
• Daily reconciliation against processor reports, with a review queue

If you are planning a marketplace build, our e-commerce website development and custom web application development teams start with this ledger design. For the business view, read Multi-Vendor Marketplace Development in Pakistan, or contact us.

Frequently asked questions

Do I need double-entry accounting for a small marketplace?

If you pay more than a handful of vendors, yes. It costs three tables and one service, far less than migrating after the first disputed payout.

Should balances be stored or calculated?

Calculate them from ledger lines. Cache them in a column or materialized view for speed, and rebuild the cache from the lines whenever it is in doubt.

How long should the payout hold be?

Long enough to cover delivery plus your return window. Many marketplaces also hold new vendors longer until they build history. Base it on your refund data, not a default.

What happens if a chargeback arrives after the vendor was paid?

Post it as a dispute entry. The vendor's payable goes negative and is recovered from future sales or invoiced according to your agreement.

Can I use the processor's dashboard as my ledger?

No. It records what the processor did, not what you owe each vendor. Reconcile against it instead.

Follow & Connect

• Website: Loop Origin
• LinkedIn: Loop Origin
• X: Muhammad Ali Mughal (@AliMughal887)
• GitHub: Loop Origin (@LoopOrigin)

I build privacy and developer tools at PixelValut, and this is the leak I most often find in otherwise careful people's files. The fix is not complicated, but you have to verify it, because "the platform strips it" is a belief, not a test.

What does image metadata reveal, and how do you remove it?

Direct answer: JPEG, PNG, WebP and HEIC files can embed EXIF, XMP and IPTC metadata: GPS coordinates, camera make, model and serial number, capture time, author names and an embedded thumbnail. Remove it before sharing with a metadata stripper, then verify by re-reading the exported file, not the original.

Where the leak lives: EXIF, XMP, IPTC and the thumbnail

Camera-specific MakerNotes can add more, such as internal serial numbers or lens data, in vendor formats that generic tools do not always display.

Real exiftool output from a tagged test file

To show exactly what a reader can pull out, I tagged a test JPEG with the kind of values a phone writes (the coordinates point at a public landmark in Karachi, not a home) and ran ExifTool 13.25 against it. This is the unedited output:

$ exiftool -G1 -a -s -Make -Model -SerialNumber -Software -DateTimeOriginal \
    -OffsetTimeOriginal -GPSPosition -GPSAltitude -ThumbnailImage -Creator -City IMG_4821.jpg
[IFD0]          Make                            : Apple
[IFD0]          Model                           : iPhone 14 Pro
[ExifIFD]       SerialNumber                    : DNPXK0QYLC
[IFD0]          Software                        : 17.5.1
[ExifIFD]       DateTimeOriginal                : 2026:10:18 21:42:07
[ExifIFD]       OffsetTimeOriginal              : +05:00
[Composite]     GPSPosition                     : 24 deg 50' 51.00" N, 67 deg 1' 58.80" E
[GPS]           GPSAltitude                     : 11.2 m
[Composite]     GPSAltitude                     : 11.2 m Above Sea Level
[IFD1]          ThumbnailImage                  : (Binary data 1741 bytes, use -b option to extract)
[XMP-dc]        Creator                         : Example Seller
[IPTC]          City                            : Karachi

One more command turns that into something you can paste into any map:

$ exiftool -n -p '$GPSLatitude,$GPSLongitude' IMG_4821.jpg
24.8475,67.033

Four decimal places of latitude is roughly ten metres of precision. That is a building, not a neighbourhood.

The cropped-thumbnail problem

Cropping does not necessarily remove the preview. I cropped the same file to a 1600x1200 region and copied the metadata across, which is what many editors and export pipelines do to "preserve" EXIF:

$ exiftool -s -ImageSize -ThumbnailImage -GPSPosition listing_crop.jpg
ImageSize                       : 1600x1200
ThumbnailImage                  : (Binary data 1741 bytes, use -b option to extract)
GPSPosition                     : 24 deg 50' 51.00" N, 67 deg 1' 58.80" E

$ exiftool -b -ThumbnailImage listing_crop.jpg > embedded_thumb.jpg
$ exiftool -s -ImageSize embedded_thumb.jpg
ImageSize                       : 160x120

The visible image is the crop. The embedded 160x120 thumbnail is still the full 4032x3024 frame, including whatever you cropped out: a house number, a car plate, a reflection. Small, but often enough to identify a place.

Threat scenarios that actually happen

• Marketplace listings. Someone sells a sofa and photographs it in their living room. If the marketplace delivers the original file, or the seller emails the "full-size" photos to a buyer, the GPS block can resolve to the flat. The sofa is now an address and a time window when they are home.
• Home location from routine posts. One photo is a data point; ten photos taken in the evening at the same coordinates are a home address. Personal blogs and self-hosted galleries often serve originals untouched.
• Device linking. A pseudonymous account and a real-name account that both publish originals with the same BodySerialNumber can be linked without any GPS at all.
• Document leaks. Screenshots and scans exported from editors can carry XMP with the author's name and the original file path or name.
• Thumbnail recovery. As shown above, "I cropped it out" is not a guarantee.

Which platforms strip metadata? Test it yourself

I am deliberately not publishing a "platform X strips, platform Y keeps" table. Behaviour changes, differs between upload paths (feed post vs direct message vs "send as file"), and differs between the version shown to others and the copy the platform stores. What is safe to state:

The rule: never trust the channel, always test the file the recipient actually receives.

A browser-side verification workflow with PixelValut

Every step below runs in your browser, so the photo is not uploaded to a server for processing.

1. Inspect the original. Open it in the PixelValut EXIF Viewer. Note GPS, make, model, serial, timestamps, thumbnail, IPTC and XMP.
2. Strip it. Run the file through the PixelValut EXIF Remover. JPEG and PNG are rewritten without re-encoding, and batches download as a ZIP.
3. Re-inspect the output. Load the stripped file back into the EXIF Viewer. You want no GPS block, no device fields and no ThumbnailImage.
4. Confirm pixels are untouched. Compare original and stripped versions in the Image Diff Checker. A lossless strip should show no pixel changes.
5. Check orientation. If the stripped photo appears rotated, the original relied on the EXIF Orientation tag. Rotate the pixels first, then strip.
6. Test the delivery channel once. Send the cleaned file through the channel you plan to use and inspect what arrives.

The same "read what the recipient reads" discipline applies to hidden content inside pixels, which I covered in How to Hide a Secret Message Inside an Image.

For developers: strip on upload, and keep orientation

If your application accepts user photos, strip metadata server-side by default. In Node.js with sharp, output does not carry input metadata unless you opt in with withMetadata() or keepMetadata(); call rotate() first so EXIF orientation is baked into pixels:

import sharp from "sharp";

export async function sanitizeUpload(inputBuffer) {
  return sharp(inputBuffer)
    .rotate()              // apply EXIF Orientation to pixels
    .jpeg({ quality: 85 }) // re-encode; metadata is dropped by default
    .toBuffer();
}

In PHP with Imagick:

$img = new Imagick($path);
// Bake EXIF orientation into pixels before stripping it
match ($img->getImageOrientation()) {
    Imagick::ORIENTATION_BOTTOMRIGHT => $img->rotateImage('#000', 180),
    Imagick::ORIENTATION_RIGHTTOP    => $img->rotateImage('#000', 90),
    Imagick::ORIENTATION_LEFTBOTTOM  => $img->rotateImage('#000', -90),
    default => null,
};
$img->setImageOrientation(Imagick::ORIENTATION_TOPLEFT);
$img->stripImage();   // removes EXIF, XMP, IPTC and profiles
$img->writeImage($cleanPath);

For a lossless batch from the command line, keep only orientation:

exiftool -all= -tagsfromfile @ -Orientation -overwrite_original *.jpg

Then add one integration test that uploads a fixture with GPS and asserts the served file has none. Pair it with the response-header checks from How to Audit HTTP Security Headers so served media cannot be sniffed or framed.

Pre-share checklist

• Camera location access off for photos you plan to share
• GPS, device, serial and thumbnail fields removed and re-verified
• XMP and IPTC author fields cleared unless deliberately kept
• Orientation baked into pixels before stripping
• Delivery channel tested once with a known-tagged file

Frequently asked questions

Does taking a screenshot remove EXIF data?

A screenshot is a new image, so it does not carry the original photo's camera or GPS EXIF. It may carry its own metadata, such as the device and creation time, and it captures anything visible on screen. Inspect the screenshot file before sharing it.

Does turning off location in the camera app fix this?

It stops new photos from getting GPS tags, which is the biggest single improvement. It does not remove make, model, timestamps or editor metadata, and it does not clean photos already taken. Strip existing files before sharing them.

Is HEIC metadata different from JPEG metadata?

HEIC stores the same kinds of EXIF and XMP data in a different container. Many sharing flows convert HEIC to JPEG on export and may carry metadata across. Inspect the exported file, whatever its format.

Can metadata be faked?

Yes. EXIF fields are plain values anyone can rewrite with standard tools, which is how I built the test file above. Treat metadata as a leak risk for your own files and as weak evidence when judging someone else's.

Does stripping metadata reduce image quality?

Not if the tool removes metadata segments without re-encoding the pixels. Tools that re-encode, such as canvas exports or some converters, drop metadata as a side effect but recompress the image. Confirm with a pixel diff.

What should I keep?

For most sharing, nothing. Photographers may want copyright and creator fields; add them back deliberately, and keep GPS, serial numbers and thumbnails out.

Follow & Connect

• Website: PixelValut Tools
• YouTube: PixelValut (@pixel-valut)
• TikTok: PixelValut (@pixelvalut007)
• GitHub: Muhammad Ali Mughal (@ali111887)
• LinkedIn: Muhammad Ali Mughal

I have spent nine years building PHP, Laravel, Vue and Node systems, including the parsing pipeline behind Smart Resume Analyzer. The recurring problem is not missing skills. It is skills that never survive extraction, or survive as a string no recruiter query will match.

How do ATS parsers extract and normalize resume skills?

Direct answer: An ATS parser pulls text from your file, finds the Skills block and skill mentions inside bullets, then maps each phrase to a canonical entry in a skill taxonomy, so "JS", "Javascript" and "JavaScript (ES6+)" become one skill. Anything drawn as an image, icon or rating bar carries no text and is never extracted.

That answer hides four separate stages, and each one fails differently:

1. Text extraction. The PDF or DOCX is converted to a reading-order text stream. Two-column layouts, text boxes and tables can scramble the order here.
2. Section segmentation. The parser looks for headings such as "Skills" or "Technical Skills". "My Toolbox", or a heading rendered as an image, may not be recognized.
3. Entity recognition. Phrases are matched against a skills dictionary. Commercial parsing vendors maintain large taxonomies; public ones you can browse include O*NET in the US, ESCO in the EU and the Lightcast Open Skills taxonomy.
4. Normalization. Synonyms, acronyms and spelling variants are collapsed to a canonical ID. "Postgres" and "PostgreSQL" should land on the same node. "React" and "React Native" should not.

You can see the output of stage 1 for your own file with the Smart Resume Analyzer ATS Parser. If a skill is missing from the recovered text, nothing downstream can save it.

Skills list vs skills inferred from bullets

Parsers read skills from two places, and they are not weighted the same way by recruiters.

• The explicit Skills list gives clean, delimiter-separated tokens. This is the easiest place for a parser to extract terms and for a recruiter's keyword search to hit.
• Bullet-inferred skills come from your experience section. "Built a Laravel queue pipeline on Redis that cut invoice generation from 40 minutes to 6" contains three skills plus evidence. Several parsing vendors attach skills found inside a job entry to that position, which is how some systems estimate how recently or how long you used a skill.

A skill only in the list is a claim; a skill also in a dated bullet is a claim with evidence and recency. As I covered in How ATS Resume Parsers Work (and How to Pass Them), parsers reward redundancy between sections, not creativity.

Why skill bars, ratings and icon grids fail

Visual skill elements look professional to the candidate and empty to the parser.

Synonyms, acronyms and the normalization trap

Taxonomies handle common variants and miss niche ones, and recruiter search is often a plain keyword query, not a taxonomy lookup. Write both forms of anything that has two.

Tokenizers that split on punctuation can turn ".NET" into "NET" and "C#" into "C". Pairing them with an unambiguous neighbour ("ASP.NET Core") gives the parser a second chance.

Side-by-side: a weak Skills section vs an ATS-optimized one

Weak version (from a real pattern I see often, details changed):

MY TOOLBOX
[Laravel logo] [Vue logo] [Docker logo] [AWS logo]
JS ●●●●○   PHP ●●●●●   K8s ●●○○○
Team player | Fast learner | Problem solver

What survives extraction: possibly "JS", "PHP", "K8s" with glyph noise, and three soft-skill phrases. Laravel, Vue, Docker and AWS do not exist for the parser. The heading may not be recognized as a Skills section at all.

ATS-optimized version:

TECHNICAL SKILLS
Languages: PHP 8, JavaScript (JS), TypeScript (TS), SQL
Frameworks: Laravel, Vue.js 3, Nuxt 3, Node.js (Express)
Data & Cache: PostgreSQL, MySQL, Redis
Cloud & DevOps: Amazon Web Services (AWS): EC2, S3, RDS; Docker; Kubernetes; GitHub Actions
Practices: REST API design, automated testing (PHPUnit, Pest), code review

And one supporting bullet in the experience section:

Senior Software Engineer, Acme Payments (Jan 2022 - Present)
- Migrated a Laravel monolith's background jobs to Redis-backed queues on AWS,
  containerized with Docker, reducing nightly batch time from 40 to 6 minutes.

Every skill is plain text, grouped under a standard heading, written in canonical form with acronyms in parentheses, and the most important ones are repeated inside a dated role.

How Greenhouse, Workday, Lever, iCIMS and Taleo handle skills

I will keep this to behaviour you can observe from the candidate side or from recruiter-facing documentation, not guesses about proprietary scoring.

Our Workday resume checklist and Greenhouse resume checklist go deeper on each flow. If you are not sure which system a posting uses, my earlier DEV post on formatting mistakes that break ATS parsing covers the layout side of the same problem.

The 8-step Skills section diagnostic

Run this in order.

1. Extract the text. Paste your PDF into the ATS Parser or copy-paste it into a plain text editor. Every skill must appear as readable text.
2. Check the heading. Use "Skills" or "Technical Skills". Rename creative headings.
3. Delete visuals. Remove bars, stars, dots, logos and word clouds. Replace with plain text.
4. Canonicalize names. Use the official product name, then the acronym in parentheses: "Amazon Web Services (AWS)".
5. Protect punctuation-heavy skills. Pair ".NET", "C#", "C++" and "Node.js" with an unambiguous neighbour.
6. Map to the job description. Run the posting through the Job Description Keyword Finder, then compare it with your list in the Skill Gap Analyzer. Add only skills you can defend in an interview.
7. Back the top five with bullets. Each of your five most relevant skills should appear in at least one dated bullet with an outcome.
8. Review the prefilled form. On Workday or Taleo, edit the parsed Skills tags before you submit.

For the keyword-matching side of step 6 without stuffing, see How to Tailor Your Resume Keywords to a Job Description.

Frequently asked questions

Should I put soft skills in the Skills section?

Generally no. Recruiters rarely search for "team player" and it adds no evidence. Show collaboration inside bullets ("led code reviews for a team of five") and keep the Skills section for searchable hard skills.

How many skills should I list?

List what the target role needs and you can discuss confidently, usually 12 to 25 grouped items for a technical role. A list of 60 tools dilutes relevance for the human reader and invites interview questions you cannot answer well.

Do I need both "JavaScript" and "JS"?

Yes, write "JavaScript (JS)" once. Taxonomy-based parsers will map either form, but a recruiter typing a literal keyword search may use only one. Writing both costs four characters and removes the dependency on normalization.

Will an ATS penalize me for skills not in the job description?

Not in any way you can verify. Extra skills mostly cost attention, so order groups with the posting's skills first.

Do skill ratings help if the ATS can read them?

Rarely. Even when the text survives, "4/5" has no shared meaning across candidates. Years of use, scale and outcomes in bullets are a stronger proficiency signal.

Should skills go at the top or bottom of a resume?

For technical roles, a short Skills block near the top helps the human scan; the parser cares about the heading, not the position. Career changers can lead with skills to surface transferable ones first.

Follow & Connect

• Website: Smart Resume Analyzer
• YouTube: Resume Boost AI (@resume-boost-ai)
• TikTok: Resume Boost AI (@resumeboostai)
• X: Muhammad Ali Mughal (@AliMughal887)
• GitHub: Muhammad Ali Mughal (@ali111887)
• LinkedIn: Muhammad Ali Mughal