Moïse Kenge

Single-tenant Flask API fronting a job queue that scans repos asynchronously. The RAG-powered chatbot ingests scanned code into vector embeddings, then retrieves relevant chunks per query and feeds them to Claude for OWASP-grounded responses. PostgreSQL stores scan results, embeddings, JWT issuance, and rate-limit counters. Served by gunicorn on AWS EC2, fronted by an ELB with Route53 DNS and least-privilege IAM roles per service.

• Python / Flask — AI libs are Python-first; Flask's small surface kept the security audit minimal.
• Claude API — better structured-code reasoning than alternatives; lower false-positive rate on security claims.
• RAG over vector embeddings — instead of stuffing the full repo into context, the chatbot retrieves only relevant code chunks per question. Cheaper, more accurate.
• PostgreSQL + pgvector — one database for transactional state AND vector search. Fewer moving parts than a dedicated vector DB.
• AWS EC2 over ECS — cost-efficient at low scale; Ansible playbooks already covered config drift.
• JWT + rate limiting — opted out of OAuth complexity for v1; revisiting in v0.5.

• flask isn't async-native — streaming claude responses required custom workarounds. v0.5 migrates to fastapi for sse.
• ansible served well for 1-3 instances; past 10+ i'd switch to terraform + k8s.
• jwt-only auth means manual revocation list maintenance — fine at this scale, painful past 10k users.

• p95 < 200ms on scan requests under realistic load.
• zero-downtime deploys via blue/green on ec2.
• maps 100+ owasp top 10 patterns to severity ratings with claude-generated rationale.
• ansible-provisioned infra reproducible from scratch in < 15 min.

classic 3-tier: express api + sqlite + static site. minimal surface — every endpoint locked behind rate limits and parameterized queries. designed to pass an audit, not to scale to millions.

• node.js / express — fastest path to a small, auditable api surface.
• sqlite over postgres — single-file db, zero ops, perfect for a low-traffic consulting site.
• no frontend framework — fewer dependencies = smaller attack surface, faster ttfb.
• parameterized queries only — no orm, no string concatenation, no surprises.

• sqlite caps near 100k concurrent reads — acceptable here, would migrate to postgres past that.
• no orm meant more hand-written sql but tighter control over query plans and exposure.
• vanilla js frontend means no spa-style navigation — fine for a 5-page site, painful at 50.

• sub-200ms p95 response time under realistic load.
• zero sql injection vectors — verified by manual review + automated owasp scan.
• shipped solo in 4 weeks with full ci/cd.

Dual-client mobile architecture (patient + nurse apps) on a shared NestJS backend. Real-time dispatch via websockets. Stripe Connect handles split payments, platform fees, and tax remittance. Clerk provides auth across both apps. PostgreSQL stores profiles, service requests, transactions, and audit trails for compliance.

• React Native + Expo — one codebase, two apps, fast OTA updates across both clients.
• NestJS — module + DI patterns kept the medium-large API codebase organized from day one.
• PostgreSQL — relational integrity for transactional payments; row-level controls for PHI.
• Stripe Connect — split payments, KYC, and tax handling out of the box. Days vs weeks of custom work.
• Clerk — pre-built phone/email auth flows saved roughly a month of dev time.

• React Native means occasional custom native modules (e.g., background location for the nurse app).
• Stripe Connect platform fees eat margin — accepted for speed-to-market; revisit at scale.
• Law 25 compliance added ~2 weeks for PHI encryption, audit trails, and consent flows — mandatory, not optional.

• Patient + nurse apps shipped to private beta.
• Law 25 / PIPEDA compliant from day one.
• Stripe Connect split-payments + tax handling live.
• CI/CD on every push via GitHub Actions; rigorous unit + integration coverage.