DEV Community: Mohammed Arshad Ansari

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

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.