DEV Community: Abubakar Ahmed

Tickler: The Lease Agent That Never Forgets A Deadline And Proves Every Answer

Abubakar Ahmed — Mon, 19 Oct 2026 06:58:42 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

A hundred years ago, offices kept a "tickler file": 43 folders, one for each day of the month plus one for each month. You dropped a note into a future folder and it resurfaced right before its date. Nothing got missed, because paper does not forget.

Tickler is that file for lease documents. And like the paper version, it never forgets.

Leases bury their most expensive sentences in normal prose. "The tenant shall give written notice at least sixty (60) days before the end of the term." Miss that window and your property rolls into a new term on someone else's rules, or you eat a penalty that was written in plain English the whole time. Small landlords do not have property managers. Tenants definitely do not. They have a PDF in a downloads folder and their memory.

Most tools treat this as extract and hope: pull the text out, let a model guess the dates, show a table. One invented date is enough to make the tool useless, because the wrong date is exactly the one that costs money.

Tickler runs on a different rule: an answer exists only if it can point to the sentence it came from. Here is the whole flow:

Upload a lease. Tickler reads the PDF page by page and stores the text in a knowledge graph. Open-weight models (gpt-oss-20b and gpt-oss-120b, Apache 2.0, served on Groq) pull out the terms: clauses, fields, deadlines.
Prove it. Every extracted fact must carry a quote and a page. A few lines of TypeScript verify the quote appears word for word on that page. Anything that fails never becomes a fact. It becomes unknown with a review flag, because unknown beats a confident guess.
Approve. You review each field next to its source sentence. One click opens the actual PDF page with that sentence highlighted. Your corrections are kept as history, never silently overwritten. Approving computes the deadlines with a pure TypeScript function and schedules the reminder workflows.
Forget about it. Temporal workflows sleep 90, 30, and 7 days before every deadline. Kill the process, restart the machine, the timer still fires. That sentence is the product.
Agents take the night shift. When a timer fires, the Watcher agent reads the graph and decides: alert, snooze, or escalate. Escalation hands off to the Drafter agent, which writes your notice letter using only the quotes stored in the graph. Letters are born pending. Nothing sends without your click. Alerts also go out by email.

Tickler reads, reminds, and drafts. The human decides.

Demo

Live, deployed, running right now: tickler-web.onrender.com

Three demo leases ship with the deployment in different states: one waiting for review, one with real 90/30/7 day reminders scheduled, one in demo mode where the first alert lands about 24 seconds after you approve. The "Load sample lease" button gives you a fresh one in a single click.

Honest note about email: alert emails currently reach only my own inbox. Sending to arbitrary recipients needs a verified sending domain: add the domain to the SMTP provider (Resend, here), publish its SPF and DKIM records, and wait for DNS to propagate and verify, which took about 24 hours in my testing. That window risked crossing the submission deadline, so I shipped with the owner-scoped sender and left domain verification as a documented next step. The sending code is identical either way; only the verified from-domain is missing. Everything else works for any visitor: upload, extraction, review, chat, reminders, drafts.

Code

abubakar-ahmed-dev / tickler

Tickler: a lease-deadline agent that proves every answer. FalkorDB knowledge graph + Temporal durable timers + open-weight agents. Every fact cites the exact lease sentence it came from.

Tickler

An agent that reads your lease documents, remembers the deadlines hiding in them, and never lets one slip.

Leases bury their important dates in prose: renewal notice windows, rent escalation schedules, deposit return deadlines. Tickler extracts those terms into a knowledge graph, anchors every fact to the exact sentence it came from, schedules durable reminders that survive crashes, and drafts the notice letters you'll eventually need, with the source text cited line-by-line.

How it works

flowchart LR
    A["lease PDF"] --> B["ingestion + grounded extraction"]
    B --> C[("FalkorDB graph")]
    C <--> D["Concierge agent<br/>(chat, cited answers)"]
    C --> E["Temporal<br/>durable reminder timers"]
    E -->|fires| F["Watcher agent"]
    F -->|escalates| G["Drafter agent"]
    G --> H["grounded letter<br/>(pending human approval)"]
    F --> I["email alert"]

FalkorDB is the only datastore: pages, clauses, quotes, deadlines, reminders, agent memory, drafts. The agent's tools are Cypher queries; its context is the graph. Remove FalkorDB and nothing works, by…

View on GitHub

The README has the full graph map and setup. docs/graph-model.md is the schema, docs/cypher.md is every query the product depends on.

How I Built It

The proof rule: no fact without a sentence

After extraction, for every quote, in plain TypeScript:

const norm = (s: string) => s.replace(/\s+/g, " ").trim();
const ok = norm(page.text).includes(norm(quote.text));  // word for word, or it does not ship

If the check fails, the quote is rejected, the field falls back to unknown, and the human sees exactly why. The model is good. The check is better. That two-line loop is the reason I can put a number on accuracy.

The model reads, the code decides

The most important separation in the codebase: the model only extracts normalized values (temperature 0, strict JSON output). Every piece of date arithmetic, like "notice deadline = term end minus 60 days", happens in a pure TypeScript function with no model in the loop. That is what made the eval meaningful: it measures a deterministic function plus verified inputs.

Why the models run on Groq and not on my laptop

I tried local first, because "your lease never leaves your machine" is the best privacy pitch there is. The plan was Ollama. Then the numbers: gpt-oss:20b needs about 14 GB of RAM for its weights, and gpt-oss:120b needs around 65 GB. My laptop has 8 GB, shared with the OS, a browser, and an editor. Ollama loaded a quantized 20b anyway, started swapping to disk, and token generation collapsed to seconds per token while the whole machine crawled. The runs were not slow, they were unusable.

So the same open weights now run on Groq: same Apache 2.0 model files, same OpenAI-compatible API shape, temperature 0. Only the hardware changed. Anyone who wants the fully local path can point the same base URL at their own Ollama host; the code never left that API.

One graph holds the whole product

Pages, clauses, quotes, fields, deadlines, reminders, alerts, drafts, human corrections, and the assistant's memory all live as nodes and edges in one graph. That choice is plumbing rather than the headline, but it pays off in one spot: the chat assistant has no private knowledge. Its six tools (also exposed as an MCP server) are each a parameterized Cypher query, and every answer must carry the quote and page it walked. The query behind every "where did this come from?" moment:

MATCH (l:Lease {id:$id})-[:HAS_CLAUSE]->(c:Clause)-[:YIELDS]->(f:Field {key:$key})
OPTIONAL MATCH (c)-[:GROUNDS]->(q:Quote)
RETURN f.key, f.value, c.type, q.text, q.pageIdx

One query, the whole proof. The agent cannot invent an answer because its only access to the data is that graph. Every other part of the app reads the same nodes, so there is one version of the truth and nothing to keep in sync.

Humans own the decisions

Extraction review happens before any reminders are scheduled, and a notice letter is born pending. There is no code path that approves a letter. The agents recommend; a person confirms. Tickler extracts and drafts; it does not give legal advice, and the product says so.

Measured, not guessed

I generated 12 fully synthetic leases (fictional people, real clause shapes: rent steps, leap-year terms, deposit windows) with the correct answers computed at generation time. Nine were the dev set. Three were locked away and opened exactly once, after every prompt was frozen.

Dev set: 99 of 99 fields, 29 of 29 deadlines correct. Sealed set, run once: 33 of 33 fields, 11 of 11 deadlines, zero ungrounded quotes, about 4 seconds per lease. The honest caveat: that is synthetic prose, which is regular. Real attorney-drafted leases are the next frontier.

What I got wrong (so you do not have to)

I ran a production build while the dev server was running. The build folder corrupted, the app hung, and I spent an hour hunting a bug in my own code. The bug was me. Now I type-check with tsc --noEmit and never build over a live server.
A secret that lives in two places is a bug waiting for a redeploy. The database password sat in one variable on the database and another on the clients. They drifted. FalkorDB answered every query with WRONGPASS. Fix and lesson below in the Render section.
Things I cut on purpose: no OCR (text PDFs only, with a clear error otherwise), no concurrency benchmarks (I did not measure it, so I do not claim it), no agent framework (a plain function-calling loop shipped first and stayed).

How we used Render (and why this stack only works there)

The full product deploys from one render.yaml. One file stands up five resources:

tickler-web: the Next.js app, with a persistent disk at /data/uploads so uploaded leases survive redeploys.
tickler-falkordb: FalkorDB as a private service on its own persistent disk. The graph is the entire database, and it never touches the public internet.
tickler-temporal: Temporal's official auto-setup image, as a private service, persisted to Render Postgres.
tickler-worker: the reminder runner, as a background worker polling Temporal over the private network.
tickler-temporal-db: managed Postgres underneath Temporal.

- type: pserv
  name: tickler-falkordb
  runtime: image
  image:
    url: docker.io/falkordb/falkordb:latest
  disk:
    name: tickler-graph
    mountPath: /data
    sizeGB: 1

That block is the entire database deployment. A stranger can fork the repo, press the Deploy to Render button, answer the secret prompts once, and have the whole product running in about ten minutes. Pushes to main auto-deploy.

Now the honest part. Deploying took an evening. Debugging the deployment taught me more about distributed systems than the previous month. Every one of these was a real outage on the live site:

What we saw	What it looked like	The real cause	The fix
Live dashboard stuck on a loading screen	A frontend bug	The blueprint read the port from Render's service properties, which returns the outside proxy port (10000), not the port inside the private network (6379)	Pinned `FALKORDB_PORT=6379` and stopped asking Render to guess
Every query answered `WRONGPASS invalid username-password pair`	Someone changed the password	The password lived in two variables (one on the database, one on the clients) and had drifted apart after an edit	Reset both in one sitting, database first, then every client, and wrote the order down as a runbook step
Temporal restart-looping: `Unsupported driver specified: 'DB=postgresql12'`	A broken image	Temporal's setup script wants `postgres12`, not `postgresql12`	Renamed the value. One word fixed a crash loop
Worker crash: `Cannot find package '@temporalio/worker'`	A bad deploy	The worker has its own `package.json`, and the root `npm ci` never touched it	Build command: `npm ci && cd worker && npm ci`
A patching script kept writing broken `render.yaml` files	A bug in the script	Windows line endings (`\r`) hiding inside the strings being matched	Normalize line endings before matching

The pattern in all five: the error pointed away from the cause. The loading screen was not the frontend. WRONGPASS was not a changed password. Reading Render's service addresses panel, instead of trusting what the blueprint resolved, is what cracked the port bug.

The whole stack costs about $35 a month, which fits inside the challenge's $50 Render credit with room to spare. Two of those resources are disks, which is the quiet feature that made this a real product: uploaded leases and the graph survive redeploys. Without them, every deploy would eat the user's documents.

How we used Temporal (the part that cannot forget)

A deadline product that can forget is worse than no product at all. A cron job dies with the process. A queue empties on restart. So reminders are Temporal workflows, and this is not an add-on, it is the reason the core promise is true.

The anatomy:

Approving a lease starts one workflow per deadline.
Inside, three durable timers: 90, 30, and 7 days before the date.
When a timer fires, an activity runs the Watcher agent, which reads the graph and decides: alert, snooze, or escalate. Escalation runs the Drafter activity, which writes the letter from stored quotes.
Demo mode: waiting 90 days is not a demo, so the lead times are configurable. Approve a lease and the first alert lands in about 24 seconds.

The proof. This is the demo, and it is the most convincing thing about the product:

Step	What happens
1	Approve a lease. Each deadline's workflow sets three timers: 90, 30, and 7 days out.
2	Kill the worker process mid wait. Not pause. Kill.
3	The workflow keeps waiting. Its history lives in Temporal, not in our process.
4	Restart the worker.
5	Timers fire on schedule. Alerts and letters arrive exactly as if nothing happened.

The mistake worth admitting: Temporal ships two client packages and they are not interchangeable. The worker needs @temporalio/worker (which brings NativeConnection), while anything that just starts workflows, like the web app's review endpoint, needs Connection from @temporalio/client. I imported the wrong one at first and paid for it in bundle size and confusion. Splitting the two fixed it in minutes once I understood the difference.

Temporal itself runs on Render as a private service (the official temporalio/auto-setup image over Render Postgres), so the reminder engine lives on the same private network as the graph and the worker. Nobody outside the deployment can even reach it.

One line sums up the split: the graph holds what matters. Temporal holds when. Neither is allowed to be the other's problem.

Why Does Open Innovation Matter

Privacy is the product. A lease is the most sensitive document a landlord owns: names, addresses, money. Extraction runs on open-weight models (gpt-oss, Apache 2.0) served on Groq. Because the weights are open, anyone can audit the exact model or self-host it later. I tried self-hosting first; that attempt is its own story above.
A paid service, made free. Commercial lease abstraction exists. Vendors charge per lease, so small owners skip it and absorb the misses. An open stack (graph database + Temporal + open weights) makes one lease cost about 4 seconds and a fraction of a cent.
No lock-in, by architecture. Every component is open source or open weight, and each one is replaceable: a graph database holds state, Temporal runs the timers, the open weights do the reading and the writing. Swap any one of them; nothing collapses into one vendor's API.
The honesty is auditable. The quote check, the code-computed deadlines, and the citation trail are all in the open repo. You can check exactly why the tool believes a date.

Prize Categories

Best Use of Render. One blueprint file stands up the entire product: web service, background worker, a graph database as a private service with its own disk, Temporal as a private service, managed Postgres, and a second disk so user documents survive redeploys. The database never touches the public internet and the worker talks to Temporal over the private network. We did not just deploy on Render, we debugged on it: proxy ports versus container ports, password pairing across services, driver names, monorepo installs, all documented above with the fixes in the repo. A stranger goes from fork to running product in about ten minutes, and it is live right now for about $35 a month.

Best Use of Temporal. The single thing this product may never do is forget, and forgetting is exactly what ordinary schedulers do on restart. Every deadline gets its own workflow with durable timers at 90, 30, and 7 days. The agents run as activities. We kill the worker mid wait and the timers still fire, on camera. Temporal even runs on Render itself (official auto-setup image), so the reminder engine sits on the same private network as everything else.

For completeness: we are not entering the model or observability categories. Tickler runs open-weight gpt-oss models on Groq rather than locally hosted Gemma or Ollama, and Sentry is not wired in. We would rather enter two categories with a deep, honest story than five with a shallow one.

Tickler reads, reminds, and drafts. The human decides. The graph remembers everything.

Try it: tickler-web.onrender.com · Code: github.com/abubakar-ahmed-dev/tickler

I built Pakistan's missing paddling app - it predicts river flows, speaks Urdu, and refuses to say "safe"

Abubakar Ahmed — Mon, 12 Oct 2026 07:01:05 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

It's Saturday morning in Islamabad. You've got the kayak on the roof, the
weather is perfect, and the group chat is buzzing. The only question that
matters is the one nobody can answer: is the Kunhar running at a good
level right now — and will it still be next weekend?

For most of the world, paddlers answer this with gauge networks, guidebooks,
and community apps. In Pakistan, the answer today is: guess. The hydrology
data actually exists — the European Centre's GloFAS model simulates every
major river on Earth, including ours — but it's published as raw discharge
numbers for flood forecasters. There is no "should I go paddling?" layer.
Not for the Indus. Not for anything.

So for the DEV Hacktoberfest 2026 challenge, I built PaddleSense: a
river-level watcher for Pakistan's paddling waters. It watches river levels
from free public data, predicts next week's flow band, scouts access notes
in English and Urdu, and renders one plain, conservative answer per river —
with the source and date attached to every single number.

And it is built around one rule that shaped every other decision:
it must never lie to you about water.

LIVE_URL: paddle-sense.onrender.com

What it does

1. Watches four rivers daily. The Indus at Besham, the Kunhar at
Balakot, the Swat at Mingora — and Karachi's Malir, which is not a
paddling river. I'll explain why it's in the app, because it's my favorite
feature.

2. Predicts the next 7 days as a band, then proves it. Not "1,632
m³/s next Tuesday" — a band like 1,498–1,849 m³/s, with the model's
uncertainty baked in. And because a forecast you can't check is just a
vibe, the app practices retrodiction: it hides real past weeks,
predicts them blind, and publishes every hit and every miss on a public
page. Coverage metrics live in the repo. The misses stay visible.

3. Scouts the web weekly for the knowledge that isn't in any dataset.
Road closures on the Kaghan valley road. A bridge out near Balakot. An
operator running trips in Swat. The scout runs SerpApi searches in English
and Urdu (کنہار رافٹنگ, سوات کی rafting بند — because Pakistan's river
knowledge lives in Urdu), respects a hard budget of 90 searches a month,
and stores every note with its verbatim quote, source URL, and fetch date.
All of it is embedded and searchable by meaning — ask "where can I put in
near Kaghan?" and get actual sourced notes back.

4. Explains each river in one sentence. A hosted, open-weight Gemma
model turns the day's data into plain language. That sentence passes four
validation gates before a human ever sees it — more on the leash below.

5. Emails you when a river enters its verified runnable range. The
whole pipeline runs itself on a weekly schedule, retries its own failures,
and never sends the same email twice.

The rule that built the product: honesty first

Whitewater has a hard edge: the wrong flow level doesn't ruin your
weekend, it ends your life. PaddleSense is safety-adjacent software, so I
treated every claim the way you'd treat a climbing partner's callout — it
has to be checkable, or it doesn't get said.

That rule produced the five things I'm proudest of:

There is no green "safe" badge anywhere in the product. When a river
is inside its runnable range, the badge is calm water-blue. When it's
high, it says "HIGH WATER — do not go", verbatim, in every state. The
words safe, danger-free, and guaranteed are banned from the UI — and
that's not a style guide, it's an executable test: a Playwright sweep
crawls every page on every change and fails the build if a banned word
renders.

Every number carries its provenance. GloFAS values are grid-cell
estimates from a ~5 km model, not gauge readings. Every card shows the
exact cell coordinates, elevation, and fetch time. The About page explains
why a cell "near Skardu" is not a gauge in Skardu. When my first cell
sweep resolved the Indus poorly, the UI didn't hide it — it moved the
monitoring point to the Besham stretch, where the model represents the
river best, and says so.

Ranges are never invented — by the app or by me. A runnable range
only appears after a human verifies a quoted source. During development
the database schema refused my own range entry because I hadn't attached
provenance to it. The guardrail catching its author on day one is exactly
what it's for. (Today the Indus is owner-verified at 55–120 m³/s and the
Kunhar at 35–135 m³/s; the Swat remains honestly "not yet verified".)

The Malir is the honesty check. Karachi's Malir reads 0.1 m³/s most of
the year — a seasonal channel, not a river. It stays in the app on
purpose, labeled not_a_paddling_river. When the app says "not runnable"
and you can look at the dry riverbed yourself, that's the product telling
the truth even when the truth is boring. It's also the fastest way to
trust the rest of the page.

The LLM is on a leash. Gemma writes the sentences, but it never
decides your safety — a deterministic, unit-tested computeStatus()
function owns that. The model's output passes four gates before display:

Schema — is it even the contracted JSON?
Numerals — every number in the sentence must exist in the data we gave it. This gate earned its keep live: the model once relabeled a discharge of "1,632 m³/s" as "1,632 cfs" — same digits, a 16× lie in units. Caught, discarded, recorded as a permanent regression fixture.
Status — the sentence's status word must equal the computed one. A model cannot soften "do not go" into "consider caution".
Banned tokens — safe, danger-free, guaranteed. Absent or discarded.

Any gate failure falls back to a plain deterministic template. The site
never depends on the model — and the model has failed in production
enough times (thinking-token blowouts, </output>-terminated responses
with no answer JSON) that the fallback has real battle scars, all logged
in the runbook.

How it's built

Next.js 16 (App Router, PPR) ──── the app, "Indus Silt" dark theme
        │
Tiger Data (Postgres + pgvector) ──── 17k+ daily readings, HNSW note search
        │
FastAPI + TabPFN ──── 7-day flow bands on CPU, backtested
        │
SerpApi ──── weekly scout, budget-ledgered, EN + UR
        │
Hosted Gemma (Google AI Studio) ──── one validated sentence per river
        │
Temporal (dev) ──── the durable weekly heartbeat
        │
Resend ──── "the Kunhar is in range" email

Why TabPFN for prediction. Constraints first: no GPU, no training
infrastructure, one developer. TabPFN is a pre-trained foundation model for
tabular data — inference on a laptop CPU, calibrated uncertainty out of
the box. Calibrated uncertainty is the whole product: the app renders a
band with published error margins, never a point. The backtest harness
hides real weeks (walk-forward, leak-free), predicts them from history
only, and scores band coverage — 82–96% across rivers against a 70% gate.
Per-horizon decay metrics (day-1 vs day-7 accuracy) are published too,
because "the forecast is better tomorrow than next Sunday" is exactly the
kind of thing a paddler should be told.

Why Temporal for durability. The watcher is the product's spine — it
must survive reboots, crashes, and double-fires. Temporal gives retries
with backoff, missed-schedule catch-up, and kill-mid-run resume for free.
The workflow tests are my favorite in the repo: they literally kill
activities mid-cycle, restart, and assert the run completes with zero
duplicate rows — because every activity is idempotent (upserts,
skip-if-done-today, cache-before-call). The system treats "run it twice"
as a normal Tuesday, not an edge case.

Embeddings that cost $0. The scout's notes are embedded locally with
all-MiniLM-L6-v2 (384 dims, running in-process via transformers.js — no
API, no key, no quota) and searched with pgvector cosine distance on an
HNSW index. Semantic search over river access knowledge, running on a
budget of literally nothing.

An Urdu-aware scout with a relevance gate. On the very first scout
cycle, US rafting guidebooks leaked into the candidate pool — "runnable
between 500 and 2,000 cfs" quotes for the Colorado, attached to nothing
remotely Pakistani. The fix is now a permanent gate: native-script river
names, Pakistan-geo search parameters, and a river-relevance check on every
extracted claim. The failure is kept as a fixture so it can never quietly
come back.

A test culture that matches the stakes. The data dictionary's
invariants are executable: a range claim without a quote cannot exist in
the database; a verified range without a source cannot exist; the scout
budget cannot be blown. The QA phase added an axe-core accessibility audit
(zero violations after it caught real link-contrast issues), five rehearsed
failure drills with recorded evidence, and a cost audit that exits
non-zero if any free-tier ceiling is crossed. npm run verify green is
the definition of done, on every change.

The honest deployment story (read this before you copy my architecture)

This is the part most build-in-public posts skip. Here's exactly how
PaddleSense is deployed today, including the part that doesn't work yet.

Deployed and live: the web app (Next.js) and the prediction service
(FastAPI + TabPFN), both on Render's free tier as web services — you can
ping the predict service yourself:
https://paddle-sense-predict.onrender.com/v1/health.
The free tier sleeps idle services, so the first visitor waits ~30–50
seconds — that's disclosed in the UI culture of the project rather than
hidden.

Not deployed yet: the background worker. Render's free tier doesn't
include background workers — that needs the $7/month plan. The DEV
Hacktoberfest promo includes $50 of Render credit, which would cover it
generously, but the credit hasn't applied to my account yet. So the honest
state is:

the watcher runs on my laptop today, fully functional — it has completed real weekly cycles, sent a real range-entry email, and proven the kill-mid-run resume live;
the moment the credit lands, the worker deploys as a third Render service with WORKER_MODE=loop — the code path is already written, decided as an architecture record (ADR D5 in the repo), because a free 512 MB worker can't host a Temporal server alongside itself. Same activities, same idempotency, in-process weekly loop.

I considered not writing this paragraph. But a post about software that
tells the truth about rivers should tell the truth about its own
deployment page. The demo works today; the always-on watcher is one
applied credit away, and the repo documents exactly what happens when it
lands.

The money math, audited. Everything else runs on genuinely free
tiers — and the project proves it instead of claiming it: npm run cost-audit reads the live database and fails if any ceiling is crossed
(SerpApi 12 of 90 searches this month, single-digit LLM calls a day against
AI Studio's daily quota, 16 of 256 MB in Tiger Data, one email sent).
Embeddings: $0 by construction. The app is adoptable by a Karachi rafting
club for nothing, which was the point.

What the app refuses to do

No user accounts, no tracking, no PII (the notification email lives in an env var, nothing else)
No point forecasts, ever — bands with published errors or nothing
No "safe" — not as a word, not as a color
No invented ranges — unverified means the app says so
No deleting history — stored readings and predictions are the evidence the forecast is checked against

What I'll do next

The worker on Render once the credit applies (code ready)
More rivers, validated the same way: sweep cells, check them against a known flood month, ask local paddlers
A public range-candidates review queue, so the community can help verify ranges with quoted sources
Gauge cross-references where Pakistan publishes irrigation data

Try it

Live app: paddle-sense.onrender.com — dashboard, per-river detail with verified bands, retrodiction page, and the semantic note search on the About page
Code: github.com/abubakar-ahmed-dev/paddle-sense — the repo is the second artifact: full PRD, architecture decision records, data dictionary with executable invariants, QA report with the failure-drill evidence, cost audit, and the runbook

If you paddle in Pakistan — or anywhere with rivers and no paddling
tooling — tell me what you'd want it to watch next. And if you know why apromo credit takes its time, I'm listening too.

Built for DEV Hacktoberfest 2026. Free data (Copernicus GloFAS via
Open-Meteo), free tiers (Render, Tiger Data, SerpApi, Resend), an
open-weight model (Gemma), and a durable heartbeat (Temporal). $0 to run and honest about every number it shows you.

I Built WazehTerms: When Your Job Offer Promised One Thing, And Your Contract Says Another, It Shows the Evidence.

Abubakar Ahmed — Mon, 05 Oct 2026 06:59:01 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content.

What I Built

WazehTerms is an evidence-first employment-document review assistant for people in Pakistan considering private-sector employment in the UAE.

It helps a worker understand what their job offer and employment contract actually say before signing.

The system:

extracts important employment terms with page-level evidence;
lets the user review and correct extracted values;
compares offer and contract terms deterministically;
retrieves potentially relevant official sources through Sanity Context;
verifies retrieved evidence against structured Sanity rules before raising a source-backed concern;
separates confirmed mismatches, missing information, questions, and uncertainty instead of producing a generic “safe/legal” verdict.

The key idea is simple:

AI should not make a legal-sounding claim just because it found a relevant sentence. It should first prove that the source, rule, scope, actor, date, and document evidence actually line up.

The public demo uses fictional English PDFs only. No real employment documents should be uploaded.

Demo

Live application: https://wazehterms-957765366699.asia-south1.run.app

No login is required. Start with the fictional sample cases.

The main journey is:

Choose a sample → Extract terms → Verify evidence → Compare documents → Review findings

Code

GitHub: https://github.com/abubakar-ahmed-dev/wazeh-terms

The application uses React/Vite + TypeScript on the frontend and an Express/TypeScript API deployed to Google Cloud Run.

How I Used Sanity

This is where Sanity becomes more than a content store.

I modeled the reference layer as structured records including:

authority
sourceDocument
rule
contractFieldDefinition

The current release contains 44 approved published records: 2 authorities, 6 source versions, 3 rules, and 33 contract-field definitions.

A rule can carry its responsible actor, jurisdiction, worker category, effective period, conditions, source version, and exact official pinpoint.

The runtime flow is:

Document
   ↓
Gemini extraction + evidence
   ↓
Deterministic comparison
   ↓
Sanity Context MCP retrieval
   ↓
Canonical Sanity rule verification
   ↓
Evidence-backed finding

Sanity Context is used for candidate discovery. A retrieved passage does not automatically become a finding.

The application reconciles it with the canonical Sanity record and checks whether the rule actually applies before showing a source-backed concern.

This matters in cases such as recruitment charges. A keyword search might find an official source mentioning recruitment fees, but WazehTerms also needs to establish the relevant jurisdiction, actor, worker category, dates, and exact source support.

If that chain cannot be established, the system withholds or qualifies the claim.

That is the part of WazehTerms that would be difficult to reproduce with a simple search box.

Sanity Project Details

Project ID: 8g0kllu0

Dataset: production

Knowledge Base: kbynAP4r8P6m

Sanity Studio contains the curated structured reference records used by the application, while the Knowledge Base provides the retrieval layer used through Sanity Context MCP.

Worker documents and extracted reports are not stored in Sanity.

What I Learned

The biggest lesson from building WazehTerms was:

“AI with citations” is not necessarily grounded decision-making.

A citation can make an unsupported conclusion look trustworthy.

So I designed the system around a stricter rule:

retrieve → verify → check applicability → inspect evidence → then speak.

And when the evidence chain breaks:

“I don't know yet” is a valid result.

That is what I wanted Sanity's structured content to make possible.

Scaling CrimeLens: From Performance Baseline to Measurable Backend Improvements

Abubakar Ahmed — Tue, 22 Sep 2026 19:34:46 +0000

I recently completed a system design and performance optimization cycle for CrimeLens, my full-stack crime reporting, mapping, and analytics platform.

CrimeLens connects citizens, public users, police officers, and administrators through different workflows. Citizens can submit crime reports, police and administrators can review and manage them, and approved crime data becomes available through maps, statistics, trends, and geospatial searches.

The system is built as a PERN modular monolith using React, TypeScript, Node.js, Express, PostgreSQL, PostGIS, and Supabase.

But building features was only one part of the project. I also wanted to understand how the backend behaved under real load, where its bottlenecks were, and whether system design improvements would produce measurable results.

Establishing the baseline

Before implementing the system design changes, I created k6 tests covering:

Normal API traffic
Gradually increasing stress
Sudden traffic spikes
Authentication flows
Crime-report submission
Statistical and geospatial endpoints
Recovery after heavy traffic

The baseline showed that the application was functionally stable, but response times increased sharply as concurrency grew.

Under normal load, the overall p95 response time was 5.13 seconds. During the stress test, it increased to 36.64 seconds, while p99 reached 41.61 seconds.

The /api/stats/summary endpoint was one of the main bottlenecks, and the results also indicated database connection-pool contention and request queueing.

What I implemented

Based on the baseline findings, I introduced several backend and infrastructure improvements:

Added PostgreSQL indexes and optimized frequently executed queries
Improved PostGIS and geospatial query handling
Added pagination to prevent unnecessarily large API responses
Increased and monitored the database connection pool
Implemented Redis cache-aside caching with TTL and cache invalidation
Added Redis-backed rate limiting
Added request validation and sanitization
Hardened the API using Helmet and stricter CORS configuration
Enabled gzip and Brotli response compression
Added structured Pino logging and request IDs
Added Prometheus metrics and Grafana dashboards
Containerized the application using Docker
Added Nginx as a reverse proxy and tested multi-instance load balancing
Added BullMQ background processing for Cloudinary deletion jobs
Added CI/CD checks using GitHub Actions, CodeQL, npm audit, Docker scanning, and Trivy

After completing these changes, I reran the original k6 baseline scripts so the final results could be compared with the earlier measurements under conditions that were as similar as possible.

Baseline vs final k6 results

Normal-load test

Metric	Before	After	Improvement
Total requests	24,667	53,972	2.19x more
Throughput	25.5 req/s	55.4 req/s	2.17x higher
p50 latency	1,230 ms	25 ms	49.2x faster
p95 latency	5,130 ms	655 ms	7.83x faster
p99 latency	7,690 ms	1,540 ms	4.99x faster
HTTP error rate	0.10%	0.006%	~16.7x lower

The optimized system processed more than twice as many requests while reducing median latency from 1.23 seconds to 25 milliseconds.

Stress test

Metric	Before	After	Improvement
Total requests	33,106	289,121	8.73x more
Throughput	32.3 req/s	282.2 req/s	8.74x higher
p50 latency	8,170 ms	119 ms	68.7x faster
p95 latency	36,640 ms	2,800 ms	13.09x faster
p99 latency	41,610 ms	4,335 ms	9.60x faster
HTTP errors	0	0	No regression

The clearest difference appeared under stress. Throughput increased from 32.3 to 282.2 requests per second, while p95 latency dropped from 36.64 seconds to 2.8 seconds.

The stress test completed without HTTP request failures in both runs. However, the final p95 result was still above the configured two-second threshold, which shows that there is still room for optimization under extreme concurrency.

Spike and recovery test

Metric	Before	After	Improvement
Requests processed	4,997	51,198	10.25x more
Spike-phase p95	45,191 ms	2,964 ms	15.25x faster
Recovery-phase p95	10,370 ms	202 ms	51.34x faster

The recovery result was especially important. After the traffic spike ended, p95 latency returned to 202 milliseconds, compared with more than 10 seconds in the baseline run.

The final spike run did record 31 connection-refused errors against the local Nginx/Docker entry point. This suggests a brief availability problem at the local container or reverse-proxy edge during the sudden burst. It is a useful finding for future investigation rather than something to hide behind the overall performance improvements.

Endpoint-level comparison

Endpoint	Baseline p95	Final p95	Improvement
Statistics summary	8,050 ms	1,104 ms	7.29x faster
Radius search	2,200 ms	583 ms	3.77x faster

The summary endpoint remained one of the heavier operations, but its p95 latency dropped from 8.05 seconds to 1.10 seconds. The geospatial radius endpoint improved from 2.2 seconds to 583 milliseconds.

A note about the test environment

These tests were conducted on my local Windows machine rather than production infrastructure.

The original baseline backend ran locally in Node.js development mode, while the final system ran locally through its current Docker, Nginx, Redis, and application-container setup. Both environments communicated with a remote Supabase PostgreSQL/PostGIS free-tier database.

The same original k6 scripts were used for the final comparison, although the architecture itself changed because those changes were the subject of the test. The database also contained a relatively small dataset.

Therefore, these results should be understood as a controlled before-and-after engineering comparison, not guaranteed production benchmarks. Production performance would also depend on the hosting platform, database tier, deployment region, network latency, available CPU and memory, and the size of the real dataset.

Final outcome

This exercise reinforced an important lesson for me: system design is not simply about adding Redis, Docker, Nginx, or monitoring tools.

The real process was:

Measure the existing system → identify bottlenecks → introduce targeted improvements → observe the system → rerun the same tests → compare the results -> find New Problems -> repeat

The final system handled substantially more traffic, responded much faster under normal and stressful conditions, recovered more quickly after spikes, and now has much better visibility into its runtime behaviour.

There are still areas to improve, particularly the local edge interruption observed during the spike test and the remaining stress-test p95 threshold, but the difference between the baseline and final run is measurable and significant.

Repository: https://github.com/abubakar-ahmed-dev/Crime-Lens

Beyond AI Journaling: Building a Secure Scientific Research Companion with Gemini and Cloud Run

Abubakar Ahmed — Mon, 14 Sep 2026 14:51:36 +0000

Scientific observations often begin as scattered notes, photos, measurements, and unanswered questions. I built AI Scientific Journal to bring them together in one place.

Users can organize observations, explore them on a research map, generate Gemini-powered analyses, continue ideas through AI chat, and ask questions about previous entries to uncover relevant evidence from their own journal.

For me, this project was an opportunity to go beyond simply adding AI to an interface. I gained practical experience building a secure, cloud-deployed AI application with Firebase, Firestore, Gemini, retrieval-based search, Docker, and Google Cloud Run.

🔗 Live App: AI Scientific Journal
💻 GitHub: AI Scientific Journal

Complete App Walkthrough: AI Scientific Journal

I’d be glad if you gave it a try—any questions, suggestions, or feedback would be greatly appreciated