Five systems, labelled for what they actually are.
Every item here is my own work, running on my own infrastructure. None of them is client work, and none is presented as client work. Each case states what it cannot do, because a page that only lists strengths is a page you have learned to distrust.
Read them in this order: the first takes side-effecting actions on a database under human approval gates, the second is the retrieval benchmark behind the headline numbers, the third handles documents you already have, the fourth is a support agent with tool calling, and the fifth is an MCP server that lets an agent read this work and file a brief.
AI WhatsApp CRM / ERP
The problem this demonstrates the ability to solve
Order capture by chat message is the classic small-business automation: someone sends a WhatsApp message with a product and a quantity, and a human retypes it into a system. The hard part is not the reply — it is that the agent takes side-effecting actions on real inventory, and a wrong action is worse than no action.
How it is put together
Human approval gates in front of the writes
The agent may read and draft; order creation sits behind an approval queue with a full audit trail. This costs latency on every order. The alternative — trusting the agent with writes unsupervised — is the failure mode that ends the engagement, so the gate stays.
Tool arguments validated before execution, not after
An order that references a SKU that doesn't exist must fail loudly at the boundary. Discovering it from a customer complaint three weeks later is a different and much more expensive class of bug.
Stateless backend function, Postgres as the only state
Every request boots the app, reads Postgres, and returns. No long-lived server and no in-memory queue to lose. Buys deploy simplicity and removes a whole class of production incident.
What I measured, and what it does not measure
- Committed test files
- 2 in the backend — the weakest evidence on this page
- Repository
- 28 commits, public
- Size
- ~7,900 lines of TypeScript
- Live demo
- no signup required — create a real order in the sandbox
- Stack
- Next.js · NestJS · Postgres (Neon) · BullMQ/Redis
What this cannot do
- No paying customer and no conversion. It is a demonstration, not a business.
- No published agent benchmark yet. Two committed test files is the honest current state, and the gap I am closing next.
- It does not measure refusal rate on out-of-scope requests or argument-validation failure rates — the two numbers that matter most for an agent that writes to a database.
No paying customer and no conversion. These are demonstrations, not revenue.
AI Receptionist
The problem this demonstrates the ability to solve
A small business loses enquiries at the exact hour a customer decides to act — 9pm, lunch, a busy line. This is the system that closes that gap: qualify, book, capture, escalate to a human. It is also the system I used to build a measurement practice rather than assert that retrieval works.
How it is put together
Routing as a LangGraph state machine, not one long prompt
Buys bounded loops and a step you can inspect per node. Costs more code and more state to hold. A prompt you cannot take apart is a prompt you cannot debug at 11pm when a customer is waiting.
Retrieval measured before any answer is written
If retrieval misses, the answer is downstream of a known-bad input. The benchmark below exists because I could not otherwise tell the difference between 'the model is weak' and 'we retrieved the wrong chunk'.
One trace span per graph node, per model call, per tool call
Lets me attribute a bad answer to a retrieval miss or a model failure instead of guessing. This is not distributed tracing — there are no database or queue spans — and I would rather say that than let the word imply more coverage than exists.
Token usage and latency recorded from the first milestone
The cost conversation then happens against real numbers rather than an estimate. Costs instrumentation work before the first feature ships, which is exactly why it gets skipped and then regretted.
What I measured, and what it does not measure
- Retrieval goldset
- 232 labelled queries · 45-chunk knowledge base · 177 single-chunk, 29 multi-chunk, 26 distractor
- Vector (production path)
- F1 93.4% · Precision 90.8% · Recall 96.1% · FPR 76.9%
- Keyword (fallback)
- F1 91.2% · Precision 94.3% · Recall 88.3% · FPR 42.3%
- Conversation eval set
- 69 cases · 97 turn assertions · 15 categories · severity tags that gate a deploy
- Committed test files
- 13 in the backend, run in CI on every push
- Repository
- 104 commits · ~24,000 lines of TypeScript
What this cannot do
- Single-tenant and single-language. Multilingual intake is not shipped.
- The benchmark measures the retrieval policy — the similarity floor, the top-k cut, the vector-vs-keyword choice — not the production embedder and not end-to-end answer quality.
- The goldset is synthetic: hand-written paraphrases authored against this corpus, not captured visitor logs. It is still one knowledge base.
- The 76.9% false-positive rate at the F1-optimal threshold is real and is the weakest number on this page.
No paying customer and no conversion. These are demonstrations, not revenue.
Smart PDF Workspace
The problem this demonstrates the ability to solve
Document Q&A is the most requested and most badly-served AI feature: people upload a contract or a report and want an answer with the source attached. The failure modes are specific and measurable — scanned PDFs with no text layer, and tables that get chunked into nonsense.
How it is put together
Scanned and image-only PDFs rejected with a clear OCR message
Silently returning nothing for a scanned document looks identical to 'the model cannot answer this', and the user concludes the product is broken. An explicit refusal is more useful than an empty answer.
Low-text-density warning on table- and image-heavy documents
Indexes them, but tells you the text density is low so a bad answer is diagnosable rather than mysterious.
Every answer reports the retrieval mode that produced it
An answer carries the `retrievalMode` that generated it, so you can tell whether it came from vector search, keyword fallback or a direct summary. A summary reads the whole document and performs no retrieval, so it correctly returns no mode at all.
Multi-tenant auth with token revocation, not just login
JWT access and refresh, revocation, company slugs, agent invites, password reset. Buys nothing visible and prevents the incident that ends a B2B contract.
What I measured, and what it does not measure
- Committed test files
- 10 across the stack
- Repository
- 47 commits · ~12,300 lines of TypeScript
- Stack
- NestJS · Postgres + pgvector (vector(1536)) · Next.js · Expo Android · embeddable widget
- Embeddable widget
- one-line script, config per workspace
What this cannot do
- Text layer only — no OCR. Scanned documents are refused rather than guessed at.
- No published retrieval benchmark. The 232-query goldset belongs to the receptionist, not this project, and implying otherwise would be dishonest.
- No paying customer. The live demo has no real users.
No paying customer and no conversion. These are demonstrations, not revenue.
AI Support Agent
The problem this demonstrates the ability to solve
Tier-one support is a volume problem that keeps setting your headcount. This resolves what the knowledge base can answer, checks orders, creates the ticket as a real side-effecting action, and escalates to a human only when it should.
How it is put together
Tool arguments validated against a schema before execution
A malformed argument must fail loudly instead of quietly doing the wrong thing to a customer's record. The failure mode this prevents is not a crash — it is a confident wrong action nobody notices for a week.
Escalation carries full conversation state, not a summary
A summary loses the thing the human actually needed. When the handoff arrives empty, the customer repeats themselves, which is the exact moment they decide you are not worth staying with.
Routing as a state machine rather than one long prompt
Same reasoning as the receptionist: a routing decision you cannot inspect is a routing decision you cannot debug.
What I measured, and what it does not measure
- Committed test files
- 2 in the backend
- Repository
- 80 commits, public
- Live demo
- runs on my own domain
What this cannot do
- No published retrieval benchmark for this one. The committed goldset and eval suite exist only for the receptionist, and I would rather say that than imply the evidence is uniform when it isn't.
- Two committed test files is the whole evidence base. That is the honest state and it is the weakest project on this page.
- It has not been load-tested against production traffic volumes.
No paying customer and no conversion. These are demonstrations, not revenue.
HireMe MCP Server
The problem this demonstrates the ability to solve
MCP is how agents call tools, and almost nobody ships one. This exposes a real profile, shipped projects and fixed pricing over the Model Context Protocol, so a client or an agent can vet the work and file a structured brief without a human in the loop.
How it is put together
Four read tools and one write tool, deliberately
get_profile, search_projects, get_pricing, get_next_slot are side-effect free. submit_project_brief is the only write — it persists, emails and is rate limited per IP. A tool surface that is all reads is a library; one that can write is an agent, and the blast radius is why there is only one.
Stateless Streamable HTTP, plus the same handlers over REST
MCP clients hit POST /mcp; the widget and mobile app hit /api/tools/:id. One implementation, two transports, so neither drifts from the other.
This is tooling, not a client system
It proves I can build against a protocol, define a typed tool surface and reason about which tools should be permitted to act. It is not evidence of production delivery volume, and I am not presenting it as such.
What I measured, and what it does not measure
- Tools
- 4 read · 1 write (brief submission, persisted + emailed, rate-limited per IP)
- Repository
- 30 commits · ~1,900 lines · Express + @modelcontextprotocol/sdk
- Endpoint
- live and callable by any MCP client
What this cannot do
- No client and no users. It was built to demonstrate protocol competence and to make my own work machine-readable.
- At ~1,900 lines it is the smallest project here. I am not going to inflate it into an enterprise integration.
- It says nothing about delivery volume — the thing a buyer most wants to know and the thing I cannot yet evidence.
No paying customer and no conversion. These are demonstrations, not revenue.
Also built
Retrieval benchmark harness
Clone and re-run with one command
The instrument behind the receptionist's numbers: threshold sweep, precision/recall/F1/FPR, committed goldset, deterministic offline embedder, zero dependencies, exits non-zero below an F1 floor, runs on every push in CI.
Android builds
Published release artifacts
Expo/React Native APKs published as GitHub releases for the receptionist, support agent and PDF workspace, plus an embeddable JS widget on the PDF product.
The client work I don't have yet
Two clients, two countries, and what they actually hired me for:
“Great people, very good service. Made my website within 2 weeks in such a professional manner, very good communication skills — would highly recommend!”
“Huge shout-out to Djaouad! Complete, fully functional full-stack build delivered right on schedule. That's how it's done. Star developer right here.”
Both were website builds, not AI systems. I'm not going to present them as something they weren't.
What they do establish is the thing no screenshot on this page can: someone working remotely from Algeria delivered on schedule, twice, for real businesses in two countries. If that's the question you're actually asking — and for a cross-border hire it usually is — that's the answer.
Happy to arrange a reference call. Ask on the call and I'll connect you directly.
The gap is client case studies, and I'd rather name it than fill it with a logo wall.
Everything above is my own work. What I don't have is a public case study from a paying client with agreed numbers — and two systems here have a benchmark where I'd rather publish the absence. That gap closes the only way it should: by building something for someone and measuring it together. The free five-day audit is the front door: measured on your documents first, and the fee comes off any build that follows.