DEV Community: Mohammed Arshad Ansari

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

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". 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.

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:

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.