DEV Community: Fahad Azhar

I'm one engineer with an AI team. Here's how I ship agency-sized work alone

Fahad Azhar — Thu, 05 Nov 2026 15:38:09 +0000

On 5 November I started the day without a list of article topics. By the end of it, four researched articles were live on my site, each with its own interactive tool, social image, sitemap entry and a Google indexing request.

I didn't write them faster. I ran them the way an agency runs a project: research, writing, review and release, with several people working at once. The difference is that most of those people are AI agents, and I'm the one who decides, checks and signs off.

This is how that actually works, including the parts that went wrong.

The day, in numbers

Research: 3 agents in parallel, one each for payment gateways, ERP/courier integrations and headless/dashboards. Each made 40–46 searches and page reads in about 3.5 minutes. Between them they came back with 26 ranked problems, with sources for the claims.

Writing: 4 agents in parallel, one per article. Each had to read my existing posts first, match their components and tone, verify every fact against primary sources, and list what it dropped as unverifiable.

Shipping: I integrated the four posts, built, checked every page at 390px and 1440px, fixed what I found and deployed. The same day I submitted 4 URLs to Google.

Earlier that week I used the same setup to build a 16-page store-and-admin template: one agent laid the foundation (design tokens, layout, data), then 3–4 agents built page groups in parallel, and I compared every page against the reference in a browser.

What I actually do

People assume the AI does the work and I watch. It's closer to the opposite. The agents are fast and tireless. The judgement is mine:

Choosing the problem. The first list of topics the agents gave me was the everyday stuff I already fix, so I threw it out. The second round came from a brief I rewrote around one question: what is the market failing at that I've actually built?
Writing the brief. An agent only knows what I tell it. A good brief names the files to read, the scope, what's off-limits and what "done" means. A vague brief gives you confident, generic work.
Checking everything. I treat every agent report as a draft from a smart new hire. It's often right, and it's always confident, even when it isn't.
Saying no. Publishing, passwords and anything that goes out under someone's name stay with a human.

Where it went wrong

This is the part that matters most, because it's where an AI team differs from a real one:

A calculator that looked right but wasn't honest. One agent built a COD calculator with an input nobody could actually fill in (a guessed "error %"), then turned it into a scary yearly loss figure. Each step looked fine on its own. I spotted it on review, and we rebuilt it to use only numbers from a real courier statement: what you should have been paid, against what you were paid.
A word nobody could back up. One draft called an app "well-known". No source said so, and the agent flagged it itself. I cut it. Small words like that are how trust goes.
An agent that stopped halfway. The template's foundation agent ended early with work unfinished. Nothing errored. I only knew because I checked what it had actually written to disk.
A test environment lying to me. My local server kept reloading mid-check because of file syncing. The audit wasn't failing because of the pages. I had to change how I tested before I could trust the result.

None of these showed up as an error. Every one was caught by a check someone decided to run.

The rules that make it work

Parallelise the independent work, keep the decisions in one head. Research and drafting fan out. Choosing and merging don't.
Give every agent its own files. Two agents never edit the same file. I do the integration.
No unsourced numbers. If an agent can't point to where a number came from, it doesn't ship.
Verify like an outsider. Open it on a phone width, click the tool, read the page as the customer would.
Security runs on a schedule, not on memory. A check runs every day at 10:00 across my projects: leaked keys, open database policies, unguarded functions, secrets in live JavaScript.

Why this matters if you hire developers

A solo developer used to mean small scope. That's no longer true. What you're really buying now is judgement: knowing which problem to solve, writing a precise brief, and refusing to ship what hasn't been checked. The typing is the cheap part.

I'm Fahad, a Shopify and full-stack developer. I work this way every day, and I write up what I build at fahadazhar.site. If you're running AI agents in real projects, I'd like to compare notes. What's broken for you so far?

Shopify can't tell you who changed your stock, so I built a ledger for 4 stores

Fahad Azhar — Thu, 05 Nov 2026 13:37:51 +0000

A product shows 12 in stock. Last week it showed 40. Was that 28 sales, a recount, a refund or an app? Shopify gives you the number, but not a usable history, and there's no Admin API for past adjustments. I run four Shopify stores (UK, Pakistan, Saudi Arabia, UAE), so I built the history myself.

The audit came first

Before building anything, I exported every stock level across the four stores:

108 SKUs at negative stock
19 SKUs above 2,000 units, one at 73,688
81% "out of stock" on the UK store, inflated by 5,309 levels on draft products

A ledger that starts from wrong numbers just records wrong numbers. We cleaned up first.

Shopify keeps the number, Postgres keeps the reason

Staff still edit stock in Shopify, and POS and apps still read from it. On top of that, every change is also written to Postgres (Supabase): store, location, variant, before → after, reason, and who changed it. The starting point was an opening balance of 11,544 levels.

Webhooks tell you a level changed. They don't tell you why. So a job runs every 5 minutes and labels each change in this order:

Dashboard intent: written before our own change is sent to Shopify
Sale: an order for that variant within −20/+10 minutes
Cancellation: a cancelled order in the same window
Shopify admin: still unexplained after 60 minutes

That last group, the changes nobody made through the dashboard, is the one the owner checks most. A nightly job compares the ledger with Shopify, and the result has to be 0 mismatches across all four stores. It is.

Dashboard changes are atomic

Receipts, adjustments, transfers and counts are numbered documents. Posting one:

locks the document
reads the live quantity from Shopify
blocks anything that would go below zero
writes the intents
sends one inventoryAdjustQuantities call, so the whole document applies or none of it does

If Shopify already accepted the change and something fails afterwards, the document is marked failed and can never go back to draft. You can't apply the same transfer twice.

229,703 calls a day, and a bug that hid behind HTTP 300

The project runs on Supabase's free plan (5 GB egress a month), and in October it got blocked for about a week. The logs showed 229,703 REST calls in 24 hours from edge functions, against 507 from real users.

There were two causes:

Product sync: it made separate calls for every product, every variant, and two for every tag
Courier tracking: it called a database function once per event, and that function had two overloads. Postgres couldn't pick one, so all 84,818 calls returned HTTP 300. Nothing errored loudly, and no tracking events were saved.

The fix was to batch everything:

create or replace function record_tracking_events(p_events jsonb)
returns int language sql as $$
  with ins as (
    insert into tracking_events (order_id, status, happened_at)
    select (e->>'order_id')::bigint, e->>'status', (e->>'at')::timestamptz
    from jsonb_array_elements(p_events) e
    on conflict do nothing
    returning 1
  )
  select count(*)::int from ins
$$;

Product sync now writes about 7 upserts per page of 25 products instead of hundreds of single calls.

Takeaways

Audit your numbers before you build the ledger.
Let Shopify own the quantity; you own the reason.
Write the reason down before you make your own change.
Make multi-line stock changes atomic, and make "already applied" impossible to undo by accident.
Monitor call volume, not just errors. My worst bug here returned HTTP 300 and stayed quiet.

I'm Fahad, a Shopify and full-stack developer. More write-ups at fahadazhar.site. How do you track stock changes across stores? Tell me in the comments.

Four countries, four currencies, four Shopify orgs, one engineer: how I run the stack

Fahad Azhar — Thu, 05 Nov 2026 13:28:45 +0000

I look after four Shopify stores for the same brand. One in the UK, one in Pakistan, one in Saudi Arabia, one in the UAE. Pounds, rupees, riyals and dirhams. In the UK people pay by card; in Pakistan most people still want cash on delivery. And there's one developer on all of it, which is me.

Nobody sits down and designs a setup like this. You launch one store, then another country asks for its own, and a couple of years later you're maintaining four of everything. This is what I've changed to keep it manageable.

The day I found out they weren't one company (on paper)

I'd built a custom discount Function for the UK store and went to install it on Pakistan. Shopify said no:

app can only be installed on stores in the same organization

Turns out each store had been set up separately, so each one sits in its own Shopify organization. Four stores, four orgs.

So now there are four copies of the app, one per org, all built from the same code. The only things that differ are the shopify.app.toml and the settings, and I keep the settings in a metafield so I'm not editing code per store.

It ended up helping. When Pakistan needed something nobody else did, a small discount for paying online plus hiding Cash on Delivery for those customers, I just added two extensions to the Pakistan app. Both read the same cart attribute, so the storefront sets one flag and checkout handles the rest. No new app, no new install link.

If you're taking over more than one store, find out which org each one is in before you build anything. I learned it after.

Four stores, really one theme

All four run the same theme base with the same custom sections. That's great right up until you fix a bug on the UK store and someone finds the exact same bug on Pakistan a week later. That happened to me more than once.

So my rule now is simple: a fix isn't finished until I've checked every store it could exist on. I think of it as one theme deployed four times.

Two habits make that less scary:

Every morning a small Node script pulls a full copy of all four live themes through the Admin API. If something breaks, yesterday's version is sitting on my disk.
I never push templates/*.json from my local copy. That's where the store team's Theme Editor changes live, and they change them all the time. Liquid, CSS and JS I push freely; the template JSON I leave alone unless I've fetched the live version first.

Same books, four countries, and Google

Four stores selling mostly the same books look like duplicate pages to Google. hreflang is the fix, but if you just print all four regions on every page you end up pointing Google at pages that don't exist.

So I pulled every collection handle from all four stores and compared them. Only 53 out of 152 existed on more than one store. The snippet now only adds a tag for a store that actually has that collection, and x-default goes to the first store that has it instead of one fixed store.

One profit number in four currencies

The owner wanted to see profit for all four stores together. Getting that number to stay the same every time you open the page took two decisions.

First, nobody types revenue in. It comes straight from the orders, and I use current_total_price, not total_price. When I checked recent Pakistan orders, about 8% had been edited after checkout (items added or removed) without a refund. total_price still shows what the order was when it was placed, so every one of those was wrong.

Second, the exchange rate is fixed per month. The combined view converts everything to riyals at that month's average rate. I fetch it once and save it. Otherwise last month's profit would shift a little every day as the rate updates. The riyal and the dirham are pegged to the dollar, so those two are constants. Only the pound and the rupee actually move.

const USD_PEG = { SAR: 3.75, AED: 3.6725 } as const;

async function monthRate(ccy: "GBP" | "PKR", month: string) {
  const saved = await db.fxRates.find({ ccy, month });
  if (saved) return saved.rate;   // fetched once, then never again
  const rate = await fetchAverage(ccy, month);
  await db.fxRates.insert({ ccy, month, rate });
  return rate;
}

Stock is its own story

Each store tracks its own stock, and Shopify won't easily tell you who changed a number, or why. So I built a ledger that records every change across all four stores. That one deserves its own post, so it's next.

If I were starting again

Check the organization of every store on day one.
Treat the stores as one theme, and check every fix everywhere.
Leave the template JSON alone unless you've just fetched it live.
Use current_total_price, and lock your exchange rates.

I'm Fahad. I build and fix Shopify stores, and I write up the problems I run into at fahadazhar.site. If you run more than one store, I'd love to know how you keep them in sync. Tell me in the comments.