Abdullah Siddiki Applied AI
Open to work · remote or NYC area (hybrid / in person)
01MaktabSchool administration platform for Islamic schools. Admissions, Stripe tuition payments, academics and FERPA-audited student records.375API operations3,460automated tests23Stripe event types
02Open Deep ResearchMulti-agent research API evaluated on 20 DeepResearch Bench tasks. The eval traced report quality to one reranking stage.0.847FACT accuracyr 0.69recall vs RACE$0.22median cost
03jev-cc-analyzerAnswers 16 analyst questions about an earnings call with a decision model. Evaluated for accuracy, calibration and injection robustness.157 ms16 decisions91%acceptable vs gold0.10calibration error
05candidsQR-code photo galleries for weddings and parties on an all-Cloudflare stack. Image moderation runs on a decision model picked by benchmark.0.866AUROC, Jev 1.1410,146images scored865tests
06KhaldunMulti-agent equity research on Agno. Eight analyst agents feed a synthesizer, and a permission-aware chat answers over reports and team conversations.8analyst agents1typed LLM call each3chat sourcesSchool administration software for Islamic full-time and weekend schools. It covers admissions, tuition payments, academics and student records. I designed and built it, and I run the deployment, billing and on-call myself.
Real Maktab screen with demo school data.
01Product
Registration with capacity and waitlists, sibling pricing, re-enrollment campaigns, tuition by card or ACH with installment plans, timetables, attendance, gradebooks, report cards, year-end rollover, and student records with access auditing.
Schools, years, staff invitations, platform settings.
Admissions, payments, follow-up queue, academics.
Classes, attendance, gradebook, report cards.
Registration wizard, family billing, child records.
02Architecture
One Django image runs as three process roles: API, worker and a one-shot migrate step. The server has no open ports and is reachable only through Cloudflare Tunnel. Postgres holds the data, the job queue, the rate limits and the audit log.
Hover or tap any component to trace its connections, or pick a flow to step through a request end to end.
03Payments
A payment bug costs a family real money. The payment path is designed around lost responses, duplicate and out-of-order webhooks, concurrent requests from one family, and partial failure.
The attempt ID, pricing digest and per-child cent allocations are frozen in the transaction. Stripe is called only after commit, with a reused idempotency key.
Enforced in code. A Stripe call attempted inside an open transaction raises, rolls back, fetches outside the lock and re-runs with a freshness check.
Every registration in a family is locked in primary-key order. A real-Postgres test reproduced the deadlock before the fix landed.
Webhook rows are stored on their Stripe event ID before any handler runs. Duplicates are no-ops, failures stay on disk for replay, and stale events are rejected.
Plans run on Stripe Subscription Schedules that cancel after the last payment. A DST-aware date map keeps a 1st-of-month plan on the 1st.
A worker job replays unprocessed events and recovers lost Checkout sessions every 15 minutes. A daily audit re-checks every subscription.
04Background work
The audit found Celery installed but unused while work ran on request threads, and cron jobs that exited 0 on failure. Both were replaced by a transactional outbox that a worker drains.
A broker to operate, and side effects that could fire for writes that rolled back.
Failed runs still exited 0, so failures were invisible.
Jobs commit with the business change. Failures become FAILED rows and alerts.
A BackgroundJob row is inserted alongside the change it belongs to and keyed for idempotency. If the transaction rolls back, the job does too.
Workers claim jobs under a 15-minute lease and back off exponentially from 30 seconds to an hour. Exhausted jobs stay FAILED for review.
The in-worker scheduler enqueues schedule:<name>:<slot> for 10 recurring jobs. Any number of workers produce exactly one run per slot, missed slots are not replayed, and runs never overlap.
The worker sends a heartbeat every 5 minutes. A gap over 15 minutes, or a schedule overdue by twice its interval, sends an alert.
05Privacy
Student records are regulated under FERPA. Every read path goes through code that records who accessed a record and on what basis.
Every education-record read or write goes through one function. It resolves the access basis, applies restrictions and writes an AccessEvent.
Audit rows are append-only in the ORM and again through a Postgres trigger, so a bug in application code cannot rewrite history.
Each API operation carries exactly one classification decorator. A test fails the build if any operation is unclassified.
Platform-support reads require an X-Access-Reason header. The vendor has no standing login to school data.
Logs are redacted at the shipper and again at ingest. A test fails if any logging call passes an email address.
Uploads land on a quarantine key and are promoted by a conditional copy with the ETag and SHA-256 pinned. A mismatch on download returns 409.
06Delivery
Staging deploys after every green build of main. Production promotion is a separate, gated workflow that ships the image CI scanned.
Whitespace, Black, Ruff, ESLint and Biome on staged files.
Real-Postgres tests, 80% coverage gate, OpenAPI snapshot, Trivy, Snyk.
Re-checks CI at the head SHA, then squash-merges with --match-head-commit.
The deploy key can only deploy a 40-hex SHA on main. Secrets go over stdin.
Migrate once, then fail unless /health/status reports that exact revision.
Release tag, staging evidence, typed SHA confirmation, immutable image digest.
07Observability
Logs, errors, request percentiles and alerts run on a Cloudflare Worker and D1 within the free tier. The events are specific to this product: Stripe webhook lag, job heartbeats and per-deploy error diffs.
| Retention | Window |
|---|---|
| Requests and INFO logs | 7 days |
| WARNING and above, events | 30 days |
| Error groups and deploys | 90 days |
| FERPA access log (Postgres) | 3 years |
08Agents
Maktab is built with AI coding agents working in parallel branches, each merged through its own PR. A session tool gives every agent an isolated stack, and repository rules define what an agent may do.
$ ./maktab session create stripe-refunds ✓ worktree .worktrees/stripe-refunds ✓ slot 2 (ports +200) ✓ stack postgres · redis · mailpit · s3 · stripe-cli ✓ api :8200 vite :5373 $ ./maktab verify --with-stripe ✓ report.json sources hashed · runtime fingerprinted
09Decisions
Each of these is written up in the repo with the alternative that was rejected.
ADR 01
Admissions, identity and payments are tightly coupled. Splitting them would turn every enrollment into a distributed transaction.
Trade-off One blast radius. Scaling is per process role, not per domain.
ADR 02
Side effects commit atomically with the data, failures become rows with alerts, and there is one fewer system to run.
Trade-off At-least-once delivery and head-of-line blocking on a single worker.
ADR 03
The code has about 200 transaction.atomic and select_for_update sites plus an audit trigger. D1 has no interactive transactions.
Trade-off A server to run. D1 is still used for observability and marketing forms.
ADR 04
The Droplet has zero open ports, and TLS, DNS and access control live in one place.
Trade-off Cloudflare is in every request path, and Bot Fight Mode stays off so it cannot challenge Stripe webhooks.
ADR 05
Events specific to the product (Stripe lag, heartbeats, deploy diffs) at no cost.
Trade-off I maintain it, and the D1 write budget forces sampling.
ADR 06
Readable types written on purpose. Contract drift is caught by schema equality and a method and path validator in CI.
Trade-off Manual upkeep when shapes change.
10Failure modes
| What breaks | Guard | How I'd know |
|---|---|---|
| Stripe response lost after a charge | Frozen contract and reused idempotency key. An identical retry resumes the open session. | Checkout events. The 15-minute reconcile recovers the session. |
| Webhook handler crashes mid-way | Inbox row persisted before dispatch and marked processed only on success. | stripe.webhook outcome and lag, alerts on failures, replay by reconcile. |
| Two requests race for one family | Family locks in global key order and one active attempt per parent and batch. | Real-Postgres concurrency regression tests in CI. |
| A scheduled job silently stops | One job per slot and a heartbeat after each success. | Missing-heartbeat and overdue-schedule alerts. |
| The wrong code gets deployed | The deploy key accepts only a SHA on main, and health must report that revision. | CI re-checks the public /health/status revision. |
| Log volume exceeds the free tier | The write budget sheds DEBUG logs and samples requests with weights. | D1 write counter on the dashboard. |
11Quality
| Suite | Tests | Runs against |
|---|---|---|
| Backend (pytest) | 2,098 | Real Postgres 17 with migrations, 80% gate |
| Frontend unit (Vitest) | 1,231 | Components, hooks, services |
| Browser (Playwright) | 60 | 25 real-stack journeys, Stripe test mode |
| Observability Worker | 50 | Workers runtime |
| Tooling | 24 | Launcher, deploy, merge gate |
18 dated audits (production readiness, architecture debt, payments, documents, auth) feed a single open-issues list.
A 36-script staging QA handbook covers 12 areas, and a 991-line deployment runbook covers rollback, restore and incident steps.
129 docs are link-checked in CI, with one canonical guide per topic.
The full verification run went from 29 minutes to about 12 with per-worker databases, sharded Stripe journeys and an ordered lane that runs beside the parallel static checks.
12Stack
Frontend
Backend
Seven apps: accounts, schools, academics, students, registration, ferpa, jobs.
Data
Payments and email
Infra
CI and security
Observability