DEV Community: Abid Ali

What I Wish I Knew Before Freelancing as a Developer from Pakistan

Abid Ali — Wed, 14 Oct 2026 15:08:35 +0000

I'm a full-stack developer in Karachi, mostly working with TypeScript, React and Next.js. When I started freelancing, I assumed the hard part would be the code. It wasn't. The code was the part I'd already practised.

The hard parts were getting money into my account, writing proposals that someone actually reads, and figuring out what to charge without either scaring clients off or working for almost nothing. Here's what I wish someone had told me up front.

1. Sort out payments before your first client

This sounds boring, so most people put it off until they've finished their first job and then panic. Don't. PayPal isn't available for receiving payments in Pakistan, and that rules out a lot of the advice you'll read online.

What works for many developers here:

Platform withdrawals. Upwork and Fiverr both let you withdraw to a local bank account, and options like Payoneer act as a middle layer. Check the current withdrawal fees and exchange rate for your setup, since they change.
Payoneer for direct clients. You can share receiving account details, and the client pays like a normal bank transfer.
Wise and similar services, where your client can send from their side.
Direct bank transfer (SWIFT) for larger contracts. It's slower and banks charge fees on both ends, so it makes sense for bigger amounts.

A few practical things:

Open a freelancer-friendly bank account. Several Pakistani banks have accounts aimed at freelancers and exporters of IT services. Ask your bank specifically about receiving remittances for IT services.
Keep records. Save invoices and transaction receipts. IT export income has its own tax treatment, and you'll be glad you kept things organised when you file. Talk to a tax consultant once rather than guessing.
Compare the real rate. Platform fees + withdrawal fee + exchange spread can easily take a noticeable chunk. Run the numbers for a $500 payment before you choose your setup.

I keep a tiny spreadsheet: invoice amount, platform fee, what actually landed in PKR. That one sheet changed how I priced everything (more on that below).

2. Your profile is a landing page, not a CV

My first profile listed every technology I had ever touched: React, Vue, Angular, Laravel, Django, Flutter, WordPress. I got zero replies. It read like I was good at nothing in particular.

What worked better was writing it like a landing page for one type of client:

I build fast, SEO-friendly Next.js sites for startups and small businesses. I've shipped marketing sites, dashboards and tools that people use daily. If your current site is slow or hard to update, I can help.

Then I backed it up with two or three real projects with live links. Side projects count. A small, polished tool beats a list of tutorial clones. Clients click links. If they can see something working, you've already done half the convincing.

3. Proposals: short, specific, and about their problem

I used to write proposals that started with "Dear Sir/Madam, I am a highly skilled developer with 5+ years of experience..." Every client has read that sentence a thousand times.

Here's the structure I use now:

1. One line showing I read their post (mention a specific detail)
2. How I'd approach it, in 2-4 bullet points
3. One relevant link (a project similar to theirs)
4. A question that moves the conversation forward

A real-ish example for a "fix our slow Next.js site" job:

Hi Sarah, you mentioned the product pages take 6+ seconds on mobile,
and that you're using Next.js with a headless Shopify backend.

How I'd start:
- Run Lighthouse + check bundle size to find the biggest offenders
- Move product data fetching to the server and cache it
- Fix image sizing with next/image (usually the quickest win)

Here's a similar store I sped up: <link>

Is the slowdown on every product page, or mostly the ones with many variants?

It's under 100 words. It shows I understand the problem, gives them a reason to reply, and doesn't waste their time.

Other things that made a big difference:

Apply early. Jobs posted in US or UK mornings get lots of replies within the first few hours. Turning on notifications and applying in that window helped me more than better wording did.
Skip vague jobs. "Need website, budget $50, urgent" is rarely worth the connects.
Ask one good question. It turns a proposal into a conversation.

I wrote up more of these lessons for beginners, with platform comparisons and fee breakdowns, on my blog, Digital Dialogue, where I share practical freelancing tips for developers.

4. Pricing: stop converting to PKR in your head

The biggest pricing mistake I made was thinking "$15/hour is already a lot of rupees" and stopping there. It's a trap for a few reasons:

Clients aren't comparing you to local salaries. They're comparing you to other freelancers.
Fees take a cut before it reaches you (see your spreadsheet from step 1).
Not every hour is billable. Proposals, calls, revisions and admin are all unpaid.
Very low prices often attract the hardest clients.

A simple way I sanity-check a rate:

// Rough monthly calculator, not financial advice :)
const targetMonthlyPKR = 300_000;
const usdToPkr = 280;          // use the current rate you actually receive
const feeRate = 0.15;          // platform + withdrawal, check your real number
const billableHoursPerMonth = 80; // be honest: not 160

const neededUSD = targetMonthlyPKR / usdToPkr / (1 - feeRate);
const hourlyRate = neededUSD / billableHoursPerMonth;

console.log(`Charge at least $${hourlyRate.toFixed(0)}/hour`);

Plug in your own numbers. The point is to work back from what you need and what you actually keep, not forward from what feels like a lot.

Some other pricing lessons:

Fixed price for well-defined work, hourly for unclear work. If the client can't describe the scope, don't commit to a fixed number.
Split fixed-price jobs into milestones. Something like 30% to start, 40% at a working demo, 30% at handover. It protects both of you.
Write down what's included. "Landing page" means very different things to different people. List pages, revisions, and what counts as a change request.
Raise rates with every few good reviews. Your first rate is just your first rate. Existing clients can stay on their price for a while. New clients get the new one.

5. Communication is the actual product

Clients rarely judge the code. They judge whether they felt informed. A few habits that got me repeat work:

Send a short update every day or two, even if it's "No blockers, on track for Thursday."
Mention time zones clearly: "I'm in Pakistan (PKT, UTC+5), usually online 2pm-11pm your time."
Warn early about delays. A delay announced on day two is an update. A delay announced on the deadline is a problem.
Share a preview link (a Vercel preview deployment is perfect) instead of screenshots.

Load-shedding and internet outages are real here. I keep a UPS for the router, a mobile data backup, and I never promise delivery on the last possible day.

6. Be patient, and keep building

My first paid job took weeks of proposals. That's normal, and it isn't a sign you're bad at this. In the meantime, keep building small, real things. Every project you finish becomes a portfolio link, a talking point in proposals, and sometimes a source of clients on its own.

If you're just starting out, here's the short version:

Set up your payment route before you need it.
Write your profile for one kind of client.
Keep proposals short, specific and question-led.
Price from what you need and what you keep, not from what sounds like a lot.
Over-communicate.

I keep notes like these, plus guides on platforms and fees, over at Digital Dialogue's freelancing guides for beginners. If you're a developer freelancing from Pakistan (or anywhere with similar payment headaches), I'd love to hear what's worked for you in the comments.

Building a Low-Latency Soundboard in Next.js: Audio Preloading, Web Audio and Mobile Autoplay Gotchas

Abid Ali — Wed, 14 Oct 2026 15:02:36 +0000

A soundboard looks like the simplest app ever: a grid of buttons, each one plays a sound. I thought I'd finish one in an evening.

Then I tested it on my phone. Tap a button, wait about 300 ms, then the sound. On iOS, the first tap sometimes did nothing at all. Spam a button quickly and sounds either cut each other off or queued up like a slow printer.

For a meme soundboard, timing is the whole joke. A late "bruh" isn't funny. This post covers what I changed to make playback feel instant, using Next.js on Vercel, React and the Web Audio API.

Why `new Audio()` feels slow

The first version looked like this:

function SoundButton({ src, label }: { src: string; label: string }) {
  return <button onClick={() => new Audio(src).play()}>{label}</button>;
}

It works, but every tap:

Creates a new media element.
Starts a network request (or a cache lookup).
Decodes the audio progressively.
Starts playback once enough data is buffered.

HTMLAudioElement is built for streaming long media, not firing short clips on demand. Even with the file cached, mobile browsers add noticeable startup latency. Reusing one element per sound helps a bit, but then you can't overlap the same sound, and calling currentTime = 0 on a playing element has its own delays.

Switching to the Web Audio API

The Web Audio API lets you download and decode audio ahead of time into an AudioBuffer, which lives in memory as raw PCM. Playing a buffer is just scheduling it on the audio graph, which is close to instant.

Here's the small engine I ended up with:

// lib/audio-engine.ts
let ctx: AudioContext | null = null;
const buffers = new Map<string, AudioBuffer>();
const inflight = new Map<string, Promise<AudioBuffer>>();

export function getContext(): AudioContext {
  if (!ctx) {
    const Ctor = window.AudioContext ?? (window as any).webkitAudioContext;
    ctx = new Ctor({ latencyHint: "interactive" });
  }
  return ctx;
}

export function loadSound(url: string): Promise<AudioBuffer> {
  const cached = buffers.get(url);
  if (cached) return Promise.resolve(cached);

  const existing = inflight.get(url);
  if (existing) return existing;

  const p = fetch(url)
    .then((res) => {
      if (!res.ok) throw new Error(`Failed to load ${url}`);
      return res.arrayBuffer();
    })
    .then((data) => getContext().decodeAudioData(data))
    .then((buffer) => {
      buffers.set(url, buffer);
      inflight.delete(url);
      return buffer;
    });

  inflight.set(url, p);
  return p;
}

export function playSound(url: string, volume = 1) {
  const context = getContext();
  const buffer = buffers.get(url);
  if (!buffer) {
    // Not ready yet: load it, then play. The first tap is slower, the rest are instant.
    loadSound(url).then(() => playSound(url, volume));
    return;
  }

  const source = context.createBufferSource();
  source.buffer = buffer;

  const gain = context.createGain();
  gain.gain.value = volume;

  source.connect(gain).connect(context.destination);
  source.start(0);
  return source;
}

A few things worth pointing out:

latencyHint: "interactive" asks the browser for the smallest output buffer it can manage.
inflight map dedupes requests, so hovering over five buttons quickly doesn't fire five fetches for the same file.
Each play creates a new AudioBufferSourceNode. They're cheap and single-use by design, which is exactly what lets the same sound overlap with itself.

Preloading without killing mobile data

Decoded audio is big. A 3-second stereo clip at 44.1 kHz is roughly 1 MB of PCM in memory, compared to ~50 KB as an MP3. Preloading 200 sounds on page load is a bad idea on a phone.

My compromise:

Preload the first screen of buttons once the page is idle.
Preload others on pointerenter / focus, which on desktop gives you a 100-200 ms head start before the click.
Preload more as the user scrolls, using an IntersectionObserver.

"use client";
import { useEffect, useRef } from "react";
import { loadSound, playSound } from "@/lib/audio-engine";

export function SoundButton({ src, label }: { src: string; label: string }) {
  const ref = useRef<HTMLButtonElement>(null);

  useEffect(() => {
    const el = ref.current;
    if (!el) return;
    const io = new IntersectionObserver(
      ([entry]) => {
        if (entry.isIntersecting) {
          loadSound(src).catch(() => {});
          io.disconnect();
        }
      },
      { rootMargin: "200px" }
    );
    io.observe(el);
    return () => io.disconnect();
  }, [src]);

  return (
    <button
      ref={ref}
      onPointerEnter={() => loadSound(src).catch(() => {})}
      onPointerDown={() => playSound(src)}
    >
      {label}
    </button>
  );
}

Notice onPointerDown instead of onClick. A click fires on release, which adds the whole length of the tap (often 80-150 ms) before anything happens. Playing on press makes it feel like a physical button.

Mobile autoplay: the gotcha that eats your first tap

Browsers don't let pages make sound until the user interacts. With Web Audio, that means your AudioContext starts in the "suspended" state and has to be resumed inside a user gesture handler.

iOS Safari is the strictest. If you create the context during page load, it stays suspended, and the first tap that just calls source.start() plays nothing.

The fix is to resume (or create) the context on the first interaction:

// lib/unlock-audio.ts
import { getContext } from "./audio-engine";

export function installAudioUnlock() {
  const unlock = () => {
    const ctx = getContext();
    if (ctx.state === "suspended") ctx.resume();

    // Old iOS trick: play a 1-sample silent buffer to fully "warm up" output
    const buffer = ctx.createBuffer(1, 1, 22050);
    const src = ctx.createBufferSource();
    src.buffer = buffer;
    src.connect(ctx.destination);
    src.start(0);

    window.removeEventListener("pointerdown", unlock);
    window.removeEventListener("keydown", unlock);
  };

  window.addEventListener("pointerdown", unlock, { once: false });
  window.addEventListener("keydown", unlock, { once: false });
}

Call it once from a client component in your layout. Two more iOS things that cost me time:

The ring/silent switch. On iPhones, Web Audio is muted by the hardware silent switch, while a <video> with audio isn't. Users will report "no sound" and it's their switch. I added a small "no sound? check silent mode" hint.
Context gets interrupted. Taking a phone call or switching apps can put the context into "interrupted" or "suspended". Check ctx.state before each play and call resume() if needed.

Encoding and hosting on Vercel

Some practical notes on the files themselves:

Trim the silence. Many meme clips have 200-400 ms of silence at the start. No amount of code fixes that. I batch-trim with ffmpeg:

ffmpeg -i input.mp3 -af "silenceremove=start_periods=1:start_threshold=-50dB" \
  -ac 1 -b:a 96k output.mp3

Mono, 96 kbps MP3 or AAC is plenty for phone speakers and halves the download size. Every browser supports MP3, so you don't need fallbacks.
Long cache headers. Put files in /public/sounds with hashed or versioned names, and set immutable caching in next.config.ts:

// next.config.ts
import type { NextConfig } from "next";

const config: NextConfig = {
  async headers() {
    return [
      {
        source: "/sounds/:path*",
        headers: [
          { key: "Cache-Control", value: "public, max-age=31536000, immutable" },
        ],
      },
    ];
  },
};

export default config;

Vercel's CDN serves these from the edge, so after the first visit they come from the browser cache and the only cost left is decoding.

Handling spam-tapping

People will hammer the airhorn button 30 times a second. Overlapping 30 copies distorts badly and can make cheap phones stutter. I cap concurrent voices per sound:

const active = new Map<string, AudioBufferSourceNode[]>();
const MAX_VOICES = 4;

export function playLimited(url: string) {
  const list = active.get(url) ?? [];
  if (list.length >= MAX_VOICES) list.shift()?.stop();

  const src = playSound(url);
  if (!src) return;
  list.push(src);
  active.set(url, list);
  src.onended = () => active.set(url, (active.get(url) ?? []).filter((s) => s !== src));
}

Adding a "stop all" button that disconnects everything is also a kindness to everyone else in the room.

The result

After these changes, a tap on a preloaded button on my mid-range Android phone plays in what feels like zero delay. On iOS, the first tap now works reliably. This is the setup running behind MemeTap, the meme soundboard I built with Next.js, and it's held up well on real devices.

To recap:

Use the Web Audio API with decoded AudioBuffers instead of new Audio().
Preload smartly: what's visible, what's hovered, what's about to scroll into view.
Play on pointerdown, not click.
Resume the AudioContext inside a user gesture, and expect iOS to be special.
Trim, compress and cache the files themselves.

If you've found other tricks for low-latency audio on the web, especially on older Android devices, I'd love to hear them in the comments.

Debugging Open Graph Previews in Next.js: Why Your Links Look Broken on WhatsApp, LinkedIn and X

Abid Ali — Wed, 14 Oct 2026 15:01:38 +0000

A few months ago I shipped a Next.js side project, proudly pasted the link into a WhatsApp group, and got... a grey box with the domain name. No image, no title. On LinkedIn it showed a cropped favicon. On X it showed nothing at all.

The page looked great in the browser, so the problem was obviously somewhere I wasn't looking. This post is everything I learned while debugging it, written so you can skip the afternoon I lost.

How link previews actually work

When you paste a URL into WhatsApp, Slack, LinkedIn or X, their servers send a crawler to fetch your page. That crawler:

Makes a plain HTTP GET request (usually without running JavaScript).
Reads the <head> for Open Graph (og:*) and Twitter card (twitter:*) meta tags.
Downloads the og:image, checks its size and type.
Caches the result, sometimes for days.

Every one of those steps is a place where things can quietly go wrong. The key insight: what the crawler sees is not what your browser sees.

Step 1: Set metadata with the Next.js Metadata API

If you're on the App Router, stop hand-writing <meta> tags in a custom head. Use the Metadata API so tags are rendered on the server and land in the initial HTML.

The most important line is metadataBase. Without it, relative image paths end up relative, and many crawlers simply ignore relative og:image URLs.

// app/layout.tsx
import type { Metadata } from "next";

export const metadata: Metadata = {
  metadataBase: new URL("https://example.com"),
  title: {
    default: "My Project",
    template: "%s | My Project",
  },
  description: "A short, human description of what this site does.",
  openGraph: {
    type: "website",
    siteName: "My Project",
    locale: "en_US",
    images: [
      {
        url: "/og/default.png", // resolved against metadataBase
        width: 1200,
        height: 630,
        alt: "My Project preview",
      },
    ],
  },
  twitter: {
    card: "summary_large_image",
  },
};

For dynamic pages like blog posts, use generateMetadata so each page gets its own title, description and image:

// app/blog/[slug]/page.tsx
import type { Metadata } from "next";
import { getPost } from "@/lib/posts";

type Props = { params: Promise<{ slug: string }> };

export async function generateMetadata({ params }: Props): Promise<Metadata> {
  const { slug } = await params;
  const post = await getPost(slug);

  if (!post) return { title: "Post not found" };

  return {
    title: post.title,
    description: post.excerpt,
    alternates: { canonical: `/blog/${slug}` },
    openGraph: {
      type: "article",
      url: `/blog/${slug}`,
      title: post.title,
      description: post.excerpt,
      publishedTime: post.publishedAt,
      images: [{ url: post.coverImage, width: 1200, height: 630 }],
    },
  };
}

One gotcha that bit me: in Next.js, a nested openGraph object replaces the parent's openGraph instead of deep-merging. If your page defines openGraph.title but no images, the layout's default image disappears. Either repeat the image or spread a shared object:

// lib/seo.ts
export const sharedOpenGraph = {
  siteName: "My Project",
  images: [{ url: "/og/default.png", width: 1200, height: 630 }],
};

openGraph: { ...sharedOpenGraph, title: post.title }

Step 2: Get the image right

Most "broken" previews I've debugged come down to the image. A checklist that works across platforms:

Size: 1200Ã—630 px (1.91:1). This is the safe default for Facebook, LinkedIn, WhatsApp and X's large card.
File size: keep it under ~300 KB. WhatsApp in particular gets flaky with heavy images. 5 MB is the hard limit for X.
Format: PNG or JPEG. WebP is improving, but SVG won't work anywhere.
Absolute HTTPS URL: https://example.com/og.png, not /og.png.
Publicly reachable: no auth, no hotlink protection, no bot-blocking firewall rules on the image path.
Keep text centered: some platforms crop to a square thumbnail on small screens.

Next.js can also generate images on the fly with opengraph-image.tsx. This was a big win for me because every blog post now gets a unique card with zero design work:

// app/blog/[slug]/opengraph-image.tsx
import { ImageResponse } from "next/og";
import { getPost } from "@/lib/posts";

export const size = { width: 1200, height: 630 };
export const contentType = "image/png";

export default async function Image({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const post = await getPost(slug);

  return new ImageResponse(
    (
      <div
        style={{
          width: "100%",
          height: "100%",
          display: "flex",
          flexDirection: "column",
          justifyContent: "center",
          padding: 80,
          background: "#0f172a",
          color: "white",
        }}
      >
        <div style={{ fontSize: 64, fontWeight: 700 }}>{post?.title}</div>
        <div style={{ fontSize: 28, marginTop: 24, opacity: 0.7 }}>
          example.com/blog
        </div>
      </div>
    ),
    size
  );
}

When this file exists, Next.js adds the og:image, og:image:width and og:image:height tags for you.

Step 3: Check what the crawler actually receives

Don't trust DevTools. The browser runs your JavaScript, the crawler usually doesn't. Fetch the raw HTML the same way a bot would:

curl -sL -A "facebookexternalhit/1.1" https://example.com/blog/my-post \
  | grep -Ei '<meta (property|name)="(og|twitter):'

If that returns nothing, your tags are being injected client-side (common with older react-helmet setups or tags set inside useEffect). Move them to the Metadata API.

Also check the image directly:

curl -sI https://example.com/og/default.png

You want a 200, a content-type: image/png (or jpeg), and a reasonable content-length. A 403 here usually means a WAF or bot protection rule is blocking crawlers.

Doing this for every platform gets tedious, so I ended up building OG Scope, a free Open Graph checker that previews how a link renders on WhatsApp, LinkedIn and X. It fetches the raw HTML the way a crawler does, lists the tags it found, and flags common problems like relative image URLs or missing dimensions. Use it, or curl, or the official debuggers. Just don't rely on what your browser shows you.

Step 4: Deal with caching

So you fixed everything and the preview is still broken. Welcome to caching.

Facebook / WhatsApp: use the Meta Sharing Debugger and hit "Scrape Again". WhatsApp shares Meta's cache, but the app itself also caches previews locally per chat.
LinkedIn: paste the URL into the LinkedIn Post Inspector. This forces a re-fetch.
X: there's no public validator anymore. Re-posting the link usually picks up changes after a while.
Slack / Discord: they cache aggressively. Adding a query string forces a fresh fetch.

The query string trick works almost everywhere, because the cache key is the full URL:

https://example.com/blog/my-post?v=2

To make that safe, set a canonical URL (via alternates.canonical as shown above) so search engines don't treat ?v=2 as a duplicate page.

If you swap the image but keep the same filename, crawlers may serve the old one from their CDN cache. Version the image URL instead:

images: [{ url: `/og/default.png?v=${process.env.NEXT_PUBLIC_BUILD_ID}` }]

Step 5: The usual suspects (quick reference)

Symptom	Likely cause
No preview at all	Tags rendered client-side, or the page returns non-200 to bots
Title shows but no image	Relative `og:image`, image blocked, or too large
Wrong image	Old cache, or nested `openGraph` overrode the layout default
Image cropped badly	Not 1.91:1, or important content near the edges
Works on Facebook, not X	Missing `twitter:card` (X falls back to OG, but needs the card type)
Preview on staging, not production	`metadataBase` still pointing at localhost or a preview URL

That last one is sneakier than it looks. On Vercel, I set metadataBase from an environment variable so preview deployments don't publish production URLs and vice versa:

const baseUrl =
  process.env.NEXT_PUBLIC_SITE_URL ??
  (process.env.VERCEL_URL ? `https://${process.env.VERCEL_URL}` : "http://localhost:3000");

export const metadata: Metadata = { metadataBase: new URL(baseUrl) };

Wrapping up

Broken link previews feel random, but they almost always come from one of a few causes: tags the crawler can't see, an image it can't use, or a cache that hasn't caught up. Render metadata on the server, use absolute 1200Ã—630 images, check the raw HTML, and bust the cache when you change things.

Before I share anything now, I run it through an Open Graph preview checker once. It takes ten seconds and saves the "why does our link look like that?" message in the team chat.

What's the weirdest preview bug you've hit? Let me know in the comments.