DEV Community: Mohammed Arshad Ansari

The most dangerous API response is HTTP 200 with an empty body

Mohammed Arshad Ansari — Tue, 15 Sep 2026 10:30:00 +0000

Every pipeline eventually inherits a source that moves. Ours did: dataservices.imf.org
stopped resolving in DNS entirely — not a 500, not a timeout, the hostname itself was gone.
The IMF had migrated its data platform and the old host was on its way out. No villain in
this story; following a publisher to its new home is the consumer's job.

The interesting part is the failure mode the migration exposed, which has nothing to do with
the IMF and everything to do with how most of us write ingestion code.

The symptom

Monthly CPI for a set of non-OECD countries went quietly stale, frozen at December 2025, while
every other source kept ticking. Nothing screamed. The daily job ran green. Downstream scoring
kept computing on last-known values, because CPI resolves through a fallback chain — if the
freshest monthly print is unavailable, the model reaches for the next-best source rather than
failing outright.

That fallback is a feature: one dead source should not take scoring down for a whole tier of
countries. It also has a cost. Graceful degradation and silent staleness are the same
mechanism viewed from two angles. A freshness dashboard is what keeps the second angle
visible; without one, the design that saves you also hides the problem from you.

The migration itself

The new home is api.imf.org, on SDMX 2.1, and it still speaks the same StructureSpecific XML
dialect — so the parser barely changed. All the pain was in the keys:

CPI now lives on the IMF.STA,CPI dataflow, and the all-items series is keyed with COICOP _T (the SDMX "total" convention), not the CP00 the old platform used.
Balance-of-payments moved to IMF.STA,BOP, where the legacy indicator codes do not port one-to-one. No find-and-replace; each series had to be re-derived against the new structure definition and re-tested.

Tedious rather than clever — and easy to get subtly wrong, because of what a wrong key does.

The gotcha worth stealing

A bad key returns HTTP 200 with an empty DataSet.

Not a 404. Not a 400. A cheerful 200 OK, a well-formed SDMX document, zero observations
inside it. If your ingestion trusts the status line:

resp = await client.get(url)
if resp.status_code == 200:          # &lt;- the bug
    rows = parse(resp.text)
    await store(rows)                # stores nothing, reports success

…then a typo in a dimension code, or an un-migrated series key, sails through as success and
writes nothing. Job green. Data frozen. You find out weeks later from a freshness alert, if
you have one, or from a customer, if you do not.

Our fix is a canary: the request always carries a segment we know must return data — United
States all-items CPI — and a parse that yields zero series therefore cannot mean "no data".

series = parse_sdmx21_data(xml_bytes)
if not series:
    raise IMFIFSUnavailableError(
        "IMF.STA,CPI returned an empty DataSet incl. the USA canary — "
        "key schema change or platform fault"
    )

The USA rows are then filtered out before storage — its index base differs from our other
US source and double-sourcing would corrupt the derived series. The canary lives in the
request, not in the warehouse.

Three lines, and it is the difference between finding a structural break in one run versus one
month. Having built it for CPI, it generalises to every SDMX-style source that can return a
well-formed empty response: pick a segment that must exist, assert it came back populated, let
a broken key contract throw. Note what it is not for: a genuine upstream outage is a
different event, and that one deliberately does not raise — it materialises with an
imf_ifs_outage flag, because failing hard there would skip every downstream scoring asset in
the same run.

The same bug one layer up: a fetch that succeeds is not a document

The identical mistake, in a different shape, was sitting in our central-bank statement
scrapers. They fetched a listing page, followed a link, extracted text, and handed it to an
LLM for a hawkish/dovish read. Every step returned 200. Every step "worked".

What was actually being scored, once we read the stored text back:

a bank's login form, because its statement listing redirects to /login
a press-release index whose top headline was Treasury-bill auction results
a SharePoint "you may be trying to access this site from a secured browser" notice
115 characters of "this page depends on JavaScript"
a rates statistics nav link, because the link pattern interest.*rate matched it and it sorted first in the DOM

The parallel to the empty DataSet is exact: nothing failed, so nothing raised, so a
plausible-looking value went downstream. The fixes were the same shape as the canary —
assert the content, not the transport:

A length floor and a bot/JS-notice check, so a page that cannot be a statement is skipped rather than scored.
Feeds and APIs instead of HTML scraping where the bank publishes one (RSS/Atom, or the PDF-minutes API where the web page is a JS shell).
A source is only enabled once its extracted text has been read back and confirmed to be a monetary policy decision — and a source that cannot pass is switched off in config with the reason recorded, not left nominally "covered". Fifteen of twenty configured banks are on; five are off behind commercial bot management, a client-rendered shell, hard 403s on the decision pages, or a listing API that refuses anonymous reads — protections we decline to work around.

Two reusable lessons

Assert data presence, not status codes. 200 OK means the HTTP conversation succeeded. It says nothing about whether the payload contains what you asked for.
Connection outages and silent-empty responses are different failure modes needing different handling. A DNS failure throws — retry with backoff and you will know. A 200-plus-empty never throws, so try/except + retry leaves it completely uncovered. It needs an affirmative presence check. Handle both, separately, on purpose.

The payoff, incidentally, was not just damage control: following the source to its new home
took BOP coverage from roughly 70 to 148 countries and made reserves available quarterly. The
endpoint you are reluctantly forced onto is often the one the publisher is actually investing
in.

Full write-up, with the migration detail:

What the pipeline feeds — a daily 0–100 credibility score for 169 countries on 100% free
public data, with per-indicator provenance:

DuckDB in production: what it's actually good at (and what it isn't)

Mohammed Arshad Ansari — Mon, 14 Sep 2026 14:00:01 +0000

DuckDB is having a moment, and like every tool having a moment, the hype runs ahead of the nuance. "Just use DuckDB" is now a reflex answer to questions it doesn't actually fit. So let me give you the honest version, from someone who ships it.

What DuckDB is

DuckDB is an in-process analytical (OLAP) database — think "SQLite for analytics." It runs a columnar, vectorized query engine inside your application process. No server, no network hop, no cluster. You point it at Parquet, CSV, or its own format and run real SQL — window functions, joins, the works — at speeds that embarrass a round-trip to a cloud warehouse for the same-size data.

Is DuckDB production-ready? Do people actually run it?

Yes — with a shape attached, and the shape is the entire answer.

"Production-ready" doesn't mean "safe to drop in anywhere." It means the engine is stable, the file format is stable, and the failure modes are known and boring. DuckDB clears that bar. It's past 1.0, it's MIT-licensed, and there's a foundation and a company behind it rather than one maintainer with a day job. In the systems I run it has never lost data or quietly returned a wrong answer. The bugs have all been in my SQL.

What people are usually asking is the less polite version: do serious teams run this, or am I the guinea pig? They run it — mostly in a shape you can't see from outside. DuckDB rarely appears on an architecture diagram as "our warehouse." It appears inside a batch job, a service, a CLI, a notebook that runs in CI. It's an engine, not a platform, so it hides inside things, which is why real usage is far more common than the blog posts about it.

The caveat worth internalising: production-readiness here is a property of the system you build around it, not of the database. A warehouse hands you concurrency, access control and a serving layer in the box. DuckDB hands you a query engine and expects you to bring the rest. Bring it, and it's production-ready. Expect it included, and you'll conclude the tool is immature when what's missing is your service layer.

This is the first part. The full post — including the rest of the working details — is on my site: DuckDB in production: what it's actually good at (and what it isn't)

We gave our macro dataset an MCP server (and made every number show its source)

Mohammed Arshad Ansari — Fri, 11 Sep 2026 10:30:00 +0000

"Trust the data" is easy to say and hard to check. Two things we shipped to make it checkable
— by people, and by the agents they increasingly send to read the web for them.

1. Every number prints its source

We publish a daily 0–100 sovereign credibility score for 169 countries, composed of seven
dimensions, built entirely on free public data (World Bank, IMF, BIS, FRED, OECD, ILO, GDELT,
ECB). Each dimension on a country page now expands to show the source that produced the
reading, the as-of date of the underlying data, and the coverage tier behind it.

Turkey's page, right now:

Credibility gap   40.0   IMF / national CPI          as of 2026-06-01   gold
Behind the curve  78.7   BIS policy rates + CPI      as of 2026-08-14   gold
Communication     54.5   Central-bank statements     as of 2026-08-26   gold
Geopolitical      44.5   GDELT                       as of 2026-08-26   gold
Growth            37.3   World Bank WDI / IMF WEO    as of 2026-08-26   gold
Liquidity         43.1   IMF BOP / BIS / FRED        as of 2026-08-26   gold
Governance        37.5   World Bank WGI              as of 2026-08-26   gold

Note the first row. The credibility gap is dated almost three months back, because that is
genuinely the last monthly CPI print we hold for Turkey. Printing the as-of date is the whole
point: a number you cannot date is a number you cannot check. No client-side JS is involved —
it is a plain expandable block, so it works everywhere and loads instantly.

2. A public MCP server

The scores are now readable by agents directly, over the Model Context Protocol, at
https://www.quantamentry.com/api/mcp — JSON-RPC 2.0 over HTTP POST, read-only. GET the
same URL for a plain descriptor; POST to use it. Point an MCP-capable client at it and it
queries the data without scraping a single HTML page.

Three tools are free with no key — list_countries (rank, region, credibility band),
get_country (one country's composite score, band, regional rank, 7-day move and one-line
read) and get_latest_briefing — the same surface as the public pages, at 30 requests/min
per IP. An API key, sent as Authorization: Bearer qm_…, swaps in the full set at 60
requests/min per key:

Tool	Returns
`get_country_score`	current composite + all seven dimensions, with per-dimension provenance and recent deltas
`list_rankings`	countries ranked by composite, optionally filtered by region
`get_score_history`	90-day daily composite history for one country
`get_coverage`	per-source freshness and per-tier country counts
`get_methodology`	current methodology version and what the score is (and isn't)
`compare_countries`	2–6 countries side by side across all seven dimensions

Implementation notes for anyone standing one up next to an existing web app:

It is a route in the same Next.js app, not a separate service. One POST handler doing initialize / tools/list / tools/call, tool schemas in one module, backed by the same API the pages read. Every tool serves only what the same caller could already open on the site — the free tools mirror the public pages, the keyed tools mirror a subscription — which is what makes the tiering defensible rather than a risk. An invalid or lapsed key degrades to the free tier instead of erroring.
Read-only by construction. No tool writes, so there is no consent model to design, no destructive-action confirmation, and the rate limits are the entire abuse surface.
Version the methodology, not just the API. Agents cache; get_methodology returning a version string is how a consumer detects that the formula moved under them. Ours is on v4 and the site carries a dated changelog.

3. The rest of the machine-readable surface

/llms.txt — the whole site summarised for models that ground on it.
/pricing.md — the pricing page as plain Markdown.
/api/product-catalog — the same tiers as JSON.

The last two are generated from one source of truth, so the JSON an agent reads cannot drift
from what a human sees on the page. That is a small thing that turns out to matter: a
machine-readable surface that disagrees with the human one is worse than not having it.

None of this is a roadmap item — the endpoints are live. Try it:
(POST) or start from

Full write-up:

How each dimension is built and sourced:

Your website gets traffic but no sales. The leak is after the click.

Mohammed Arshad Ansari — Fri, 04 Sep 2026 19:50:40 +0000

Traffic with no sales feels like a traffic problem, so the instinct is to get more of it. But a hundred visitors who all leave without buying behave exactly like a thousand visitors who all leave without buying. Volume does not fix a leak — it runs more water past it.

First, be honest about the word "traffic"

If most of your visitors are peers, friends, and people who sell what you sell — which is what a launch post usually produces — you do not have traffic, you have applause. Applause does not convert. If genuine potential buyers are landing and still leaving, the leak is on the page, in one of three places. They fail in a fixed order; check them in that order.

Check 1 — The message

Run the five-second test. Show your homepage to a stranger for five seconds, close it, and ask: What do they sell? Who is it for? What would I get? If they hesitate on any of the three, visitors are hesitating too. The most common failure is not ugliness — it is cleverness. "Unleash your potential" tells a buyer nothing.

Check 2 — The offer

If strangers understand the page but do not buy, look at what you are asking them to buy. An offer that reads like every competitor forces comparison on the only dimension left: price. And on price, someone is always cheaper. You do not fix this with a discount — a discount on an uncompelling offer is a cheaper uncompelling offer.

Check 3 — The next step

The quiet leak almost nobody checks: a visitor is interested but not ready to buy today — which describes most visitors. What do you offer that person? If the answer is "the buy button or nothing", you convert only the tiny fraction who arrived pre-sold and silently lose everyone your message actually persuaded. Interest that has nowhere to go expires.

The false fixes

Redesign the site: a confusing page in a prettier coat is still confusing. Run ads to it: paying to send more strangers past the same leak converts budget into silence, faster. Add more sections: length is not persuasion.

Originally published as a field note at strangertosold.com. The free 3-minute Sales Bottleneck Finder — 18 questions, no email — names the stage of your sales system where strangers are getting lost.

Why is no one signing up for your SaaS? Four leaks, in order

Mohammed Arshad Ansari — Wed, 12 Aug 2026 08:00:00 +0000

You shipped. The product works. The Show HN post got a few upvotes — and the signups chart is a flat line.

The reflex is to conclude the product is not good enough yet and build more of it. That reflex is almost always wrong, and expensive, because building is the one activity that feels like progress while changing nothing. No-signups has four usual causes, and they must be checked in order — a fix downstream is invisible while an upstream leak is open.

Leak 1 — Nobody with the problem is arriving

How many people who plausibly have the problem your product solves saw your page last week? Not peers, not launch-day tourists — potential users. For most SaaS with zero signups the honest answer is "a handful", and no page converts a handful of anybody. If that is you, stop optimising the page and go where the problem is discussed.

Leak 2 — It is built for "anyone"

"A project management tool for teams" selects nobody. When a product is for everyone, no visitor feels it is for them. A product for "developers" loses to a product for "freelance mobile developers who bill hourly" every time the second one shows up — even if yours is technically better. Narrowing is not shrinking your market; it is choosing the smallest market you can actually win.

Leak 3 — No answer to "why you specifically?"

A visitor who has the problem and feels selected still asks one silent question: why this one and not the incumbent I have already heard of? If your page describes you as a member of a category ("a modern CRM"), the visitor fills in the answer themselves — usually "no reason".

Leak 4 — The page talks about the product, not the visitor

Features are evidence, not argument. The visitor is asking "what does my Tuesday look like after I sign up?" and the page is answering "we use vector search". First sentence: their problem. Second: the outcome. Features prove it lower down.

The five-minute test

Write one sentence: "[Product] is for [the narrowest group you would bet on] who [specific situation], so they can [outcome they would pay for]." If you cannot fill it in without "anyone", "teams", or "businesses" — that is your leak, and no amount of traffic fixes it before the sentence does.

Originally published as a field note at strangertosold.com. The free 3-minute Sales Bottleneck Finder — 18 questions, no email — names which of the nine stages of your sales system is actually blocking you.

"I can build, but nobody buys": the technical founder-2019s sales problem

Mohammed Arshad Ansari — Sat, 08 Aug 2026 08:00:00 +0000

"I can build, but nobody buys."

That sentence is the defining problem of the AI era for technical people. Building used to be the moat: if you could ship, you were rare. Now anyone can ship a working product in a weekend — which means the bottleneck has moved, for everyone, to the same place: strangers becoming customers. And most of us never trained for that at all.

It is not a personality flaw

Technical people tell themselves a specific story: I am not a salesperson. Not pushy enough, smooth enough, extroverted enough. The story survives because it is flattering — it frames the gap as character rather than skill, and you cannot be blamed for your character. But watch what it protects: as long as selling is a personality you were not born with, you are excused from learning it, and free to do the thing that feels productive instead. Which is build more.

The reframe that changes everything: the pushy salesperson is not the skilled version of selling — it is the failed version. Pushing is what people do when they have skipped every earlier step and are trying to force a stranger through a wall. Skilled selling is closer to what you already do when you debug: observe, hypothesise, test, fix the actual fault.

"One more feature" is procrastination with a clean conscience

When the product is not selling, building feels like the responsible response. It has visible output, it is within your control, and nobody rejects you while you do it. That last property is the tell. Adding a feature is the only response to "nobody buys" that involves zero contact with the people not buying — which is why it is the most popular and the least effective. The information you are missing is not in your codebase. It is in their heads, and there is no API for that.

What selling actually is

A stranger becomes a customer along a path with fixed stages: they have to want something (market), see why you specifically (position), find the trade obviously worth it (offer), understand you instantly (message), encounter you at all (attention), have a route from curious to committed (journey), and be listened to rather than pitched at (conversation). None of those requires charisma. Every one can be diagnosed.

The trap: the stages fail silently and point the blame downstream. Weak positioning presents as "a marketing problem". A missing journey presents as "bad luck with conversions". So builders fix the visible symptom while the actual fault sits untouched two stages earlier.

Do this today

Write down, as a falsifiable statement, why you believe people are not buying — the way you would write a bug hypothesis. If you cannot finish the sentence with something you have tested against real potential buyers, that is the diagnosis: you are debugging without logs. Your next unit of work is not code — it is five conversations.

Originally published as a field note at strangertosold.com. If you want logs instead of theory: the free 3-minute Sales Bottleneck Finder — 18 questions, no email — names the weakest of the nine stages in your sales system.

I systematised sales like an engineer: 9 stages, one path, and a free 3-minute diagnostic

Mohammed Arshad Ansari — Mon, 03 Aug 2026 05:15:00 +0000

I learned sales the way an engineer would — by refusing to believe it can't be systematised.

The knowledge existed: Godin on permission, Dunford on positioning, Hormozi on offers, Miller on message, Brunson on funnels, Voss on negotiation. Each held one piece. Nobody held the sequence.

So I arranged it: nine stages, one path — the order a buyer actually travels.

Mindset → Market → Position → Offer → Message → Attention → Journey → Conversation → Scale.

The engineering insight that made it click: a sales system is a pipeline, and a pipeline is only as strong as its weakest stage. Most advice fails for a boring reason — it's the right fix for the wrong stage. Upstream problems masquerade as downstream ones: weak positioning looks like a lead problem, a missing journey looks like a closing problem. So people buy ads to fix positioning and sales training to fix funnels, and nothing moves.

The debugging rule applies to revenue too: diagnose before you patch.

I built a free 3-minute test that does the diagnosis — 18 questions, no email, no login. It names the exact stage costing you customers and gives you one concrete action for it today.

→ Take the Sales Bottleneck Finder

(Based on my book, From Stranger to Sold.)

The most dangerous API response is HTTP 200 with an empty body

Mohammed Arshad Ansari — Sun, 02 Aug 2026 19:02:07 +0000

The interesting part is the failure mode the migration exposed, which has nothing to do with
the IMF and everything to do with how most of us write ingestion code.

The symptom

The migration itself

The new home is api.imf.org, on SDMX 2.1, and it still speaks the same StructureSpecific XML
dialect — so the parser barely changed. All the pain was in the keys:

CPI now lives on the IMF.STA,CPI dataflow, and the all-items series is keyed with COICOP _T (the SDMX "total" convention), not the CP00 the old platform used.
Balance-of-payments moved to IMF.STA,BOP, where the legacy indicator codes do not port one-to-one. No find-and-replace; each series had to be re-derived against the new structure definition and re-tested.

Tedious rather than clever — and easy to get subtly wrong, because of what a wrong key does.

The gotcha worth stealing

A bad key returns HTTP 200 with an empty DataSet.

Not a 404. Not a 400. A cheerful 200 OK, a well-formed SDMX document, zero observations
inside it. If your ingestion trusts the status line:

resp = await client.get(url)
if resp.status_code == 200:          # &lt;- the bug
    rows = parse(resp.text)
    await store(rows)                # stores nothing, reports success

Our fix is a canary: the request always carries a segment we know must return data — United
States all-items CPI — and a parse that yields zero series therefore cannot mean "no data".

series = parse_sdmx21_data(xml_bytes)
if not series:
    raise IMFIFSUnavailableError(
        "IMF.STA,CPI returned an empty DataSet incl. the USA canary — "
        "key schema change or platform fault"
    )

The same bug one layer up: a fetch that succeeds is not a document

What was actually being scored, once we read the stored text back:

a bank's login form, because its statement listing redirects to /login
a press-release index whose top headline was Treasury-bill auction results
a SharePoint "you may be trying to access this site from a secured browser" notice
115 characters of "this page depends on JavaScript"
a rates statistics nav link, because the link pattern interest.*rate matched it and it sorted first in the DOM

A length floor and a bot/JS-notice check, so a page that cannot be a statement is skipped rather than scored.
Feeds and APIs instead of HTML scraping where the bank publishes one (RSS/Atom, or the PDF-minutes API where the web page is a JS shell).
A source is only enabled once its extracted text has been read back and confirmed to be a monetary policy decision — and a source that cannot pass is switched off in config with the reason recorded, not left nominally "covered". Ten of seventeen configured banks are on; seven are off behind a login wall, a client-rendered listing, or commercial bot management we decline to work around.

Two reusable lessons

Assert data presence, not status codes. 200 OK means the HTTP conversation succeeded. It says nothing about whether the payload contains what you asked for.
Connection outages and silent-empty responses are different failure modes needing different handling. A DNS failure throws — retry with backoff and you will know. A 200-plus-empty never throws, so try/except + retry leaves it completely uncovered. It needs an affirmative presence check. Handle both, separately, on purpose.

Full write-up, with the migration detail:

What the pipeline feeds — a daily 0–100 credibility score for 169 countries on 100% free
public data, with per-indicator provenance:

I open-sourced AEGIS: a self-hosted, flow-first personal AI orchestration platform

Mohammed Arshad Ansari — Mon, 13 Jul 2026 15:26:15 +0000

For the past year I've run most of my day on a system I built for exactly one user: me. Last week I open-sourced it. It's called AEGIS, it's MIT-licensed, and this is the honest tour.

The bet

Every week there's a new agent framework that promises to do everything. AEGIS is a smaller, stranger bet: that software can learn the shape of one person's life well enough to interrupt less. It watches the boring things — tasks, email, money, a
knowledge base, homelab alerts — and only reaches for me when a decision is genuinely mine to make. It's not a chatbot I log into; it's a fleet of scheduled and event-driven workflows that mostly run without me.

## The shape

Four named agents, each a permission boundary with a personality: Sebas (GTD), Raphael (research), Maou (money), Pandora's Actor (infrastructure). The spine is FastAPI + Postgres (with pgvector) + Temporal, on a small Docker Swarm at home. Models
resolve through a LiteLLM proxy — local-first, reaching for Claude or GPT only when a job needs the horsepower.

A few design decisions did most of the work.

## One primitive for every interruption

The decision I'm proudest of is a table. Every time the system needs a human, it's the same shape: a row in a Postgres interactions table, a card in my chat app, and a Temporal workflow that durably waits — for days if it has to — until I tap a
button.

Approvals, choices, drafts to review, plain acknowledgements — one mechanism, five card kinds, one callback format. No per-feature approval tables; adding a new "ask the human" moment costs nothing. And because interrupting me is now a formal act with a
paper trail, flows get written to do more work before they ask. That one decision turned AEGIS from a notification machine into a queue of interruptions that have to earn their way in.

## Durability instead of cron-and-hope

A card a workflow waits on for three days is miserable to build with cron and a queue — you hand-roll a state machine and reconcile it after every deploy. Temporal's durable execution is exactly this: the workflow awaits a signal, and the wait survives
restarts, redeploys, and the occasional node reboot. Schedules reconcile from DB config, so changing a flow's cadence needs no redeploy.

## Behavior is data, not code

The change that made AEGIS forkable was deleting every line that said if agent == "sebas". Capabilities, tool grants, and routing now live in database metadata, edited from an admin panel. The code asks "who owns GTD?" and gets an answer; it never
names names. Rename the agents, re-scope them, or add your own — no Python.

## Local-LLM-first, for real

Everything routes through a LiteLLM proxy exposing three tiers — fast / balanced / smart. Each agent is assigned a tier, never a model name, so swapping models is proxy config and the app code never changes. One reasoning-model gotcha is handled
explicitly: reasoning models bill hidden reasoning tokens against max_tokens before any visible output, so a tight cap returns finish_reason=length with empty content — the client detects that and raises a typed truncation error instead of handing
an empty string to json.loads.

## What it is not

Not a SaaS — no hosted version, and it does nothing until you point it at your own accounts and models. Not another framework to build on; it's a complete, opinionated application you fork and configure for your own life. If that sounds like more setup
than you want, reading the code is a perfectly good outcome.

## Take it apart

Code: https://github.com/hikmahtech/aegis
The longer tour + design essays: https://hikmahtechnologies.com/aegis

I'd genuinely like to know what breaks — and what you'd reach for on the "smart" tier these days. That's the slot I still escalate most often.