Hello, I'm Malik.
Ten years of software engineering, 210+ projects at 5.0 on Fiverr, the last few years shipping LLM systems into real business software. Karachi, UTC+5.
Read about me →
Karachi, Pakistan · UTC+5
Open to new projects · replies within 24 hours
I build AI agents, web & mobile apps, and the API integrations that make them work in production.
10 years of software engineering: web apps, mobile apps and the back ends behind them. The last few shipping LLM systems into real business software. Not a chatbot that answers and stops.
The 24-hour read
Pick a problem. This is the shape of the read I'd send back within 24 hours.
RE: CRM ↔ accounting sync
Pre-written · the real one follows a call
RE: CRM ↔ accounting sync
- Approach
- Two systems never designed to talk: webhooks, OAuth flows, rate-limited endpoints. Refunds, partial payments, and reconciliation handled automatically.
- What breaks
- Two people edit the same customer on different days, a refund lands after the invoice is closed, and the nightly run is rate-limited halfway through. So: a baseline per field, idempotent writes, and a dry run that is the same decision list the real run executes.
- Not AI
- Reconciliation is arithmetic, not judgement: deterministic rules, tested, with a log you can read record by record. A model only proposes a field map between two unfamiliar shapes, and a person approves it.
- Proof
- Stripe ↔ QuickBooks sync for a logistics company. Has reconciled cleanly since launch without manual fixes.
RE: Invoices & documents
- Approach
- Read the invoice, check it against your own systems, do the work: a bill in QuickBooks, a ticket in the helpdesk, a line in Slack.
- What breaks
- 429s, 5xx, timeouts — so retry with exponential backoff, duplicate and reconciliation checks, an approval threshold, and a replayable event log.
- Not AI
- I tell you when AI is the wrong tool. Sometimes a 40-line script beats an LLM: cheaper, faster, deterministic.
RE: An assistant on your own data
- Approach
- Trained on your own data — Slack, Notion, Google Workspace, or your database — and answering with sources, so output is verifiable instead of confidently wrong.
- What breaks
- Confident answers with nothing behind them, a stale index, and questions the source never covers. So every answer cites the passage it came from, a second pass checks each sentence against the source, and the assistant says so when the answer is not there.
- Not AI
- The model is the smallest part. Retrieval, ranking, permissions and the evals that catch regressions are ordinary engineering — and for a fixed set of questions, a good search box beats a chatbot.
- Tools
- Anthropic API · OpenAI API · open models · LangChain · LlamaIndex · RAG · Pinecone · Supabase pgvector · Chroma · evals
RE: API integrations
- Approach
- Third-party, undocumented, and legacy SOAP APIs: webhooks, OAuth flows, rate-limited endpoints. Half my career. Built to survive production, not just a demo.
- What breaks
- Rate limits at the worst moment, tokens that expire mid-run, webhooks that arrive twice or six hours late, and a SOAP endpoint that returns 200 with the error inside. So: retries with backoff, idempotency keys, replay, and logging from day one.
- Not AI
- An integration is deterministic work. No model decides a type or a mapping; I read the real payloads, and the code you own does the rest — documented, structured, yours.
- Proof
- Instead of a claim: the systems I have actually integrated are named on this page, grouped by what they do.
- Tools
- REST · GraphQL · webhooks · OAuth2 · SOAP · Python (FastAPI, Django) · Node.js (Express, NestJS) · PHP/Laravel · .NET/C#
RE: A web or mobile app
- Approach
- Screens and data first, then the build: React or Next.js on the web, React Native or Flutter for iOS and Android from one codebase, a Python or Node API shared by both. Ten years of shipping this.
- What breaks
- Auth edge cases, slow networks, offline states, app-store review. So milestone one is a working skeleton on a real device, with tests, CI and crash reporting from day one.
- Not AI
- Most of an app is not AI. I tell you which small part benefits from a model and build the rest as plain, fast, maintainable software you own.
- Proof
- GoGstaad: food ordering and taxi booking for Gstaad, Switzerland, with a customer app, a driver app and the backend behind them. Gineerz: a technician app, back office and client portal for a field-services company in Karachi.
- Tools
- React · Next.js · TypeScript · React Native · Flutter · Python (FastAPI) · Node.js · Postgres · Supabase · Stripe · CI/CD
RE: Payments & checkout
- Approach
- Taking money in an app, on a website, or on a screen in front of the customer: cards, wallets and terminals. Refunds, partial captures, split payments, and payouts into other people’s accounts.
- What breaks
- The webhook that arrives twice, out of order, or six hours late. Idempotency keys, reconciliation, and a ledger that still balances when a payment half-fails.
- Not AI
- Payments is the clearest case where AI is the wrong tool: deterministic code, tested, with an audit trail. No model goes anywhere near your money.
- Proof
- Stripe ↔ QuickBooks sync for a logistics company. Has reconciled cleanly since launch without manual fixes.
- Tools
- Stripe · Stripe Connect · PayPal · Square · Braintree · Authorize.Net · eWAY · CommBank · TWINT · Xendit · Apple Pay · Google Pay · Tap to Pay
RE: A self-service kiosk
- Approach
- Touch-first ordering and checkout that runs unattended all day: a locked-down Android tablet, an iPad, or a browser in kiosk mode, wired to a card reader and to the systems behind the counter.
- What breaks
- Nobody is standing next to it. A dropped connection, a tap that does not read, a customer who walks away mid-order — it has to recover to a clean screen on its own and keep taking orders.
- Not AI
- A kiosk has to be fast and predictable, not clever. The menu is a database query, not a prompt.
- Tools
- Android · iPad · kiosk mode · card reader · Apple Pay · Google Pay · Tap to Pay · offline tolerance · remote updates
RE: Email that has to land
- Approach
- Multi-domain sending set up properly: SPF, DKIM and DMARC, custom tracking domains, warmup, and the sending API wired into your product rather than bolted on beside it.
- What breaks
- Deliverability. Mail that quietly goes to spam, a domain that gets burned, and bounces nobody is watching. Monitoring from day one, not after the reputation is gone.
- Not AI
- Writing the copy is not the hard part. The DNS, the reputation and the sending schedule are, and none of them need a model.
- Tools
- SPF · DKIM · DMARC · multi-domain sending · custom tracking domains · warmup · SendGrid · Mailchimp · Klaviyo
- Timeline & cost
- Realistic estimates. Fixed scope, clear milestones, no surprise invoices.
AboutMalik Akhtar
- Based
- Karachi, Pakistan · UTC+5
- Overlap
- US mornings · EU afternoons
- Experience
- 10 years of software engineering
- Track record
- 210+ projects · 5.0 on Fiverr
- Replies
- Within 24 hours
- Language
- English
Hello, I'm Malik.
The engineer you hand the hard part to.
I've spent ten years building software for people who need it to work on Monday morning, not just in the demo. More than two hundred and ten projects with a 5.0 average rating on Fiverr, and enough production incidents to know what actually matters: honest scoping, boring reliability, and code you still own when I'm gone.
For the last few years that has meant putting LLMs to work inside real business systems — agents that read documents and take actions, assistants that answer with sources, integrations between tools that were never meant to talk. I like the unglamorous parts: retries, rate limits, logging, the monitoring that keeps a system running while you sleep.
I work from Karachi with clients in the US, UK, EU, Australia and the Middle East, overlapping US mornings and EU afternoons. You'll get written updates without asking, a realistic estimate, and a straight answer — including "you don't need AI for this" when that's the truth.
- 01
Honest scoping
A short scoping call before any estimate. I would rather tell you the project is simpler than you thought than take a bloated budget.
- 02
Boring reliability
Error handling, logging, and monitoring from day one, not after something breaks. Realistic estimates, fixed scope, clear milestones, no surprise invoices.
- 03
Code you still own
Documented, structured, yours. No lock-in, no black box, and support after delivery — I don't disappear at handover.
- 04
No AI for its own sake
I tell you when AI is the wrong tool. Sometimes a 40-line script beats an LLM: cheaper, faster, deterministic — and I say so even when the AI version would bill more hours.
Work18 projects
Work
Thirteen you can open, in the order I would show them to you. Four more are shown in screenshots, and one I can only describe: that client work stays private, so I show the shape of it instead.
01 Client work · Gstaad, Switzerland live
GoGstaad
A ride or a meal. One app, one account.
This one is not a demo. It is the taxi and food-delivery service for Gstaad and the Saanenland, running as a real business: a customer app on iOS and Android, a separate app the drivers work from, and the backend holding the two together. Order from a local restaurant and watch it come, or book a taxi with the fare agreed before you confirm and the driver moving on the map while you wait.
- 2apps + backend
- 2app stores
- 3languages
- 4airports served
- Role
- Customer app, driver app and the backend behind them.
- The product
-
- Restaurant ordering with live order tracking
- Taxi booking: the fare shown before you confirm, rides scheduled in advance, the driver tracked on the map
- Airport and city transfers to Geneva, Zurich, Bern and Basel
- Card and TWINT payment in the app
- Driver app: jobs, shifts and zones, navigation, earnings and payouts
- German, French and English, across both apps
- Why it is not a small build
-
- Two sides of the same event: what the customer watches on a map and what the driver is told to do have to stay the same thing — when they drift, somebody is left standing outside
- A fare quoted before the work is a promise, and it has to survive the route that actually gets driven
- Money moves both ways: customers pay in, drivers are paid out. Different rules, different failure modes, and neither may be approximate
- Two apps through two review processes on every change, and the driver’s one has to work on a moving phone in an alpine valley
- It runs a real business, so the standard is not “it works”: if it is down at six in the morning, somebody misses the flight to Geneva
02 Client work · Karachi, Pakistan client testing
Gineerz Field Operations
Every technician, every site, every rupee. One system.
Client work, now in the client’s hands for testing. Gineerz installs and maintains CCTV, networks and access control at client sites in Karachi. This platform replaces their registers, WhatsApp groups, Excel salary sheets and paper challans with one connected system: an Android app the technicians work from, a web back office for the owner, admins, accounts, stores and HR, and a portal for their own clients. The back office runs on staging at tech.gineerz.com, where the company is walking it through a real working day before go-live.
- 47office & portal screens
- 39app screens
- 148database tables
- 505end-to-end tests
- Role
- The technician app, the back office and client portal, the API and data model, and the staging deployment.
- Stack
- TypeScript end to end · NestJS · Prisma · PostgreSQL + PostGIS · React + Vite · React Native + Expo · Docker · Supabase
- The product
-
- Check-in with GPS, a selfie and the odometer; tracking that follows the shift; a live map and day playback in the office
- Tasks from dispatch to sign-off: checklists, before and after photos, a customer signature, a hold with a reason
- A ledger of what is fitted where, by serial, scanned on and off the wall with a QR code
- Stock across warehouse, vans and sites: purchase orders, three-way matching, challans, transfers, counts
- Double-entry accounts: supplier bills, cash and floats, expense and fuel claims, invoices, receivables, quotations, project costing
- Leave and payroll from the register; tickets with SLAs; contracts; chat; a panic button; a client portal; English and Urdu
- Roles are permission bundles, enforced in the API; every money and stock document is append-only
- Works offline: every write from the app carries its own id, so a retry can never land twice
- Why it is not a small build
-
- Nine roles in one system — a technician on a site with no signal, a storekeeper counting cable, an accountant closing a month — and each one’s screens have to be right for them
- Money and stock are one story: a bill split across three projects, or cable issued to a van and used on a site, has to add up in the ledger and in the store at the same moment
- GPS is evidence, not decoration: distance drives fuel money, so faked fixes, long gaps and a phone that changes hands are handled, not hoped away
- Multi-company from day one: a tenant is provisioned complete or not at all — roles, branch, financial year, chart of accounts — in one transaction
- Deployed where the client already pays: shared hosting, a managed database in Mumbai, one command to redeploy
03 Own product · Karachi, Pakistan live
VisionAttend
Walk-through attendance from the cameras you already own.
Not a demo either. A camera-based attendance and HR system, sold as a service. A small Site Connector program on a PC the customer already has pulls the CCTV streams, finds faces and uploads the crops; the cloud recognises people, turns sightings into punches, works out each day by the rules (shifts, night shifts, grace, overtime, holidays, leave) and serves the console, the reports and the HR work on top. Employees get a phone-first portal with nothing to install, and there is a platform console to onboard companies on any kind of contract.
- 77screens: console, platform, portal
- 107database tables
- 526API endpoints
- 459backend tests
- Role
- All of it: the recognition service, the Site Connector, the API and attendance engine, the console and portal, the platform console, licensing and billing, and the deployment.
- Stack
- Python · FastAPI · SQLAlchemy · PostgreSQL + pgvector · Redis · OpenCV (YuNet + SFace) · Next.js · TypeScript · Tailwind · Docker · Stripe
- The product
-
- Site Connector for Windows, Linux or Docker: pulls NVR and camera streams, detects faces, keeps the best crops, buffers offline and uploads
- Recognition with a liveness check, so a photo held up to the camera is not a punch
- The attendance engine: shift resolution, night shifts across midnight, grace, rounding, breaks, late and early, half days, overtime with a cap, holidays, week-offs, leave, regularisations, recompute on change
- Console: live feed with crops, enrolment with quality feedback, the daily grid and the monthly muster, connectors and cameras, reports as CSV
- HR on top: leave, documents with compliance, payroll runs and payslips, alerts with a delivery log, onboarding, org chart, letters, loans, expenses, helpdesk
- Employee portal on the phone: geofenced check-in, my month, leave with balances, payslips, documents
- Platform console: onboard a company on a flat, per-employee, one-time or free contract; invoices; licences; impersonation, audited both ways
- Self-hosted edition under a signed licence file; face vectors, camera passwords and media encrypted per tenant
- Why it is not a small build
-
- Cameras lie: a bad angle, a backlit door, one face seen twice in five seconds. The connector keeps the best three crops per track and the cloud debounces, or every doorway becomes forty punches
- The day is computed in the site’s time zone, not the server’s; a night shift belongs to the day it started; every rule is a test, not an opinion
- Face data is the most sensitive thing a company will hand you: encrypted per tenant, consent recorded, purged by plan, employees walled into their own routes by a test that fails the build if any other route would answer them
- Three ways to sell it — cloud, self-hosted, an appliance later — from one codebase and one connector image
- It runs on a shared box next to twenty other sites, where one wrong proxy line takes all of them down
04 Own product · Karachi, Pakistan live
Hunt
Every remote job, project and client worldwide, ranked for one person.
Not a demo. The system I run every day to find work. It reads job boards, freelance marketplaces, community hiring threads and the careers pages of hundreds of companies, then answers the questions a listing never does: can I take it from where I live, how well does it fit, what should I show them, whom do I write to, and what happened next. One SQLite file, the Python standard library and nothing to install, served from a hardened box behind Cloudflare with a scheduled run every fifteen minutes.
- 12job boards & marketplaces
- 364company job boards watched
- 23klines of Python, no packages
- 297tests, all offline
- Role
- All of it: the twenty source readers, the eligibility and scoring rules, the dashboard, the mail and assistant layers, the relay, the deployment.
- Stack
- Python 3.12, standard library only · SQLite · hand-written HTML, CSS and JS · systemd + nginx on AlmaLinux, Cloudflare in front · SMTP through my own mailbox · a language model behind a hard spend cap
- The product
-
- Sources: twelve boards and marketplaces, RSS feeds, company boards on nine hiring platforms (Greenhouse, Lever, Ashby, Workable, Recruitee, SmartRecruiters, Personio, Breezy, Teamtailor), a watchlist that grows itself from links in postings, and a bookmark for sites that forbid automation
- Eligibility from Pakistan on every posting: open, likely, unclear, restricted or on-site, with the sentence that decided it
- A 0–100 score from fixed rules with the breakdown shown; freelance briefs are scored for their odds too, so fifty bids cap the score
- Proof to show: the two or three projects from an evidence library that match the posting, and a first message drafted around them, as a proposal or an e-mail
- Whom to write to: every address, named person and link the posting published, best first; one click sends through my own mailbox and logs the application
- Pipeline from shortlisted to won with follow-ups that come due on Today; Insights computed from the log: funnel, reply rate, time to first reply, which resume version gets replies, where the open roles are
- Companies and agencies: who is hiring now in roles I can take, agencies that could pass on white-label work, confirmed from their own websites; direct clients found city by trade
- An assistant that reads each posting against my profile, drafts, and bids on fresh briefs on its own inside hard rules: a budget floor, a daily cap, a veto window and a spend meter
- Why it is not a small build
-
- Nothing is fetched until the owner allows it. Every request carries a fixed user agent, no cookies, no referrer and never the computer name, and the Sources page shows exactly that
- Sites that forbid automated access are never scraped; the bookmark reads the page’s standard job data instead
- One “too many requests” answer pauses every reader of that site for two hours, so a block never grows into a longer one
- One marketplace shows a bot check to data-centre addresses, so a relay on an ordinary computer reads it and pipes the briefs over SSH, pinned to a single command
- A scheduled run and a dashboard fetch never overlap; a backup is written daily; the whole test suite runs without a network
- Sign-in with scrypt, hashed session tokens and lockouts; the origin answers Cloudflare’s addresses only
05 Client work · Sentinel EPOS, UK delivered
Sentinel ePos for Restaurants
Your restaurant, at a glance. On the web and in your pocket.
Client work for a UK till-system company. Sentinel EPOS sells the tills; this is the owner’s side of them. A web back office reads the live till database, and an owner app for iPhone and Android brings every page of it to the phone, redesigned for it: today’s net sales, orders, refunds and cancellations, sales by hour, how customers paid, who is on shift, and a receipt for every order, across every store the owner has, with one store switcher and one period shared by every screen.
- 7back-office pages
- 21app screens
- 9periods, one picker
- 880app tests
- Role
- The web back office, the owner app, and the sample-data mode both of them can run on for demonstrations.
- Stack
- C# · ASP.NET Core MVC · SQL Server on Azure · Flutter · Dart · iPhone and Android from one codebase
- The product
-
- Dashboard: net sales, orders, average order, refunds and cancellations, sales by hour, the payment mix, order types, best sellers, the latest orders and who is on shift
- Orders: sales, refunds and cancelled orders grouped by day, with search, filters and a receipt for every one
- Sales analysis: trend, time of day, payments, order types, staff, costs and stores, against the previous period or last year
- Staff hours from the clock-in records; expenses paid out of the till, by reason and by person
- One period everywhere: today, yesterday, this week, last 7 days, this month, last month, last 30 days, this year or a custom range
- The app signs in with the website’s own account and reads the website’s own pages; nothing to install on the server
- Why it is not a small build
-
- The figure on the phone and the figure on the web must be the same number: the app uses the website’s data, never a second calculation that could drift
- Till data is messy: refunds, partial payments, unpaid orders and discounts land in the same table, and each has to be counted exactly once
- A demo mode with two years of generated history, shaped on the real database’s own rates, so the product can be shown without touching a customer’s data
- No plugins, no third-party services, no tracking: with demo data the app makes no network request at all
- UK time everywhere, including where one trading day ends and the next begins
06 Client work · Sentinel EPOS, UK delivered
Sentinel ePos Retail
Every till, every VAT rate, every shift. Exported in a tap.
The retail counterpart, for shops rather than restaurants. A web back office with the same owner sign-in, an API built underneath it so a phone app could exist, and the app itself. Daily store summary, VAT by rate, sales by department, refunds, cancellations, staff hours and expenses, each exported as PDF, Excel or CSV from the phone. A dashboard that shows how today compares with a typical day, and a Sales Insight page that writes its own highlights in plain English.
- 9back-office pages
- 13API endpoints
- 7reports
- 3export formats
- Role
- The web back office, its REST API with token sign-in, and the iPhone and Android app on top of it.
- Stack
- C# · ASP.NET Core MVC · REST API with access and refresh tokens · SQL Server · Flutter · PDF, Excel and CSV written on the phone
- The product
-
- Dashboard: the period’s takings with a bar per day and a ring for how today compares with a typical day; cash, card, VAT, cash in till, the payment mix and the latest orders with receipts
- Sales Insight: KPIs against the previous period or last year, highlights in plain English, the month’s outlook, busiest hours, departments, basket sizes, refunds, VAT and cash control, costs, people and stores
- Seven reports, daily store summary to expenses, each as PDF, Excel or CSV through the phone’s share sheet
- Sign-in issues a one-hour access token and a 30-day refresh token, kept in the iPhone Keychain or Android’s encrypted storage
- A slim header pinned on every screen: the store on the left, the period on the right
- A sample-data mode on the website that never opens the database, so the app can be demonstrated and tested against it
- Why it is not a small build
-
- The API reads the same services as the web pages, so a figure on the phone always matches the one on the website
- VAT is the report an accountant checks: every rate, every line and every refund, reconciled to the penny against the till
- The files are made on the phone: the PDF, Excel and CSV writers are the app’s own, with no server round-trip and no third-party service
- Money is held in pence, never as a float; UK time, including the day boundary
- Partial days are said out loud: while today is still trading, the app tells you the comparison is not yet like for like
07 Client work · Sentinel EPOS, UK delivered
MyPoints
A loyalty card that lives on the phone.
The customer’s side of the same tills. The loyalty card for Sentinel EPOS stores, rebuilt as one Flutter app for iPhone and Android to replace two ageing native apps. A customer types the code their store gave them, once. From then on the app opens on their card: a Code 128 barcode for the till, their points, and what the points are worth, with the store’s offers and the latest movements of their points underneath. It ships as an update to the existing listings, not a new app, so it had to keep the old identity and read the card the native apps had saved.
- 2native apps replaced
- 1codebase, both stores
- 2themes: light and dark
- 773tests
- Role
- The whole app: design, the barcode, the migration from the native apps, and the release builds for both stores.
- Stack
- Flutter · Dart · Code 128 drawn in code · native channels for brightness, keep-awake and backup rules · Android + iOS
- The product
-
- Home: the card with a scannable Code 128 barcode, available points and their value, the store’s offers and recent purchases
- History: every movement of the points, by month, with what each purchase earned
- Account: light, dark or follow the phone, and changing the customer code
- The screen stays awake while the barcode is up at the till
- A demo mode with a sample customer for store screenshots, compiled out of ordinary builds
- Why it is not a small build
-
- Same app ids, same launcher activity, same saved-card file as the native apps, so an update keeps every customer’s card; a test pins each of these so a slip fails the build
- The barcode encoding and the pixel layout of the bars are the app’s own, crisp at any size, because a blurred barcode is a card that does not scan
- Built to stay smooth on an ordinary phone: the sky, glass and engraving effects are rendered once and reused, not repainted every frame
- The customer code never leaves the device: backups switched off on Android, the card’s folder excluded from backups on iPhone
- Judged only on release builds on a real phone, never on the debugger
08 Self-service ordering live
Counter
Order on one screen. Watch it land on the others.
A self-service kiosk, a kitchen display and a counter console, all pointed at one store. Tap something on the kiosk and the ticket is on the kitchen display before your finger leaves the glass — on a different device, with no reload. Tickets age from grey to amber to red so a late one is visible across a room, and the console shows the takings, the average time to ready and which surfaces are connected right now.
- Role
- Design, backend and frontend. Solo project.
- Stack
- Cloudflare Workers · one SQLite-backed Durable Object per store holding the menu, the order queue and every socket · WebSocket hibernation · D1 for the registry, the shared import cache and the budgets · Workers AI (a vision model to transcribe, a small open-weight model to structure) · hand-written HTML, CSS and JS
- How it holds up
-
- The kiosk sends item ids and quantities only — every price and total is recomputed server-side
- Quantities clamp and unknown options are ignored, so a tampered client changes nothing
- Mutations go over HTTP; the socket is fan-out only, so opening one changes nothing
- Sockets hibernate: an idle store costs nothing and the queue survives a closed tab
- Menu prices a model returns are checked against the transcription — unread ones are flagged, never guessed
- Bounded items, open orders, orders and neurons a day; visitor stores expire after 7 days
- Not in the demo
- The card terminal is simulated and says so on screen. No card is read and no money moves — a real build wires that to an acquirer.
09 CRM ↔ accounting sync live
Ledger
The CRM says one thing. The books say another.
The job I am asked for most often, with its reasoning showing. Two systems hold the same customer, both edited by people who never speak, and something has to decide overnight. Break the data on purpose with the buttons — edit one side, edit both sides, rename somebody in the accounts — then run the sync and read what it decided, record by record. Run it a second time and it writes nothing at all.
- Role
- Design, backend and frontend. Solo project.
- Stack
- Cloudflare Workers · D1, one JSON document per workspace so a run is atomic without a transaction · Dice coefficient on character bigrams for fuzzy matching, no dependencies · Workers AI only to propose a map between two unfamiliar shapes · hand-written HTML, CSS and JS
- How it holds up
-
- A baseline per field, not per record — so it knows which side moved, not merely that they differ
- A transform that cannot run backwards is reported and held, never guessed: a display name is not split into a first and last name
- A dry run is not an estimate — it is the same decision list the real run executes
- A run repeats its passes until nothing changes, capped at three, so a created record gets its computed fields the same night
- The second run writes zero. Measured, and printed on the page
- An unresolved conflict keeps its old baseline, so it is still outstanding tomorrow rather than quietly forgotten
10 Assistant on your own data live
Docent
Any website. Answers with receipts.
Paste a website and Docent reads it, indexes it, and becomes its support assistant: every answer cites the exact passage it came from, a second pass checks each sentence against the source, and when the answer isn't on the site it says so. Visitors can try it on their own site and take the embed snippet home.
- Role
- Design, backend and frontend. Solo project.
- Stack
- Cloudflare Workers · Workers AI (embeddings, reranker, open-weight LLM) · Vectorize · D1 with FTS5 · hybrid retrieval · SSE · vanilla JS
- Guardrails
-
- Every fact cited to the passage, not the page
- Sentence-level grounding check; unsupported sentences flagged, never cached
- Abstains on weak evidence instead of guessing
- Polite reading: robots.txt, one host, 20 pages, timeouts, no private networks
- Per-visitor and daily budgets; indexes expire after 7 days
11 Undocumented APIs live
Surveyor
Somebody’s API. No documentation.
Half of integration work is finding out what a system actually does. Drop in a browser network capture, an OpenAPI document, a WSDL or a few curl commands, and Surveyor returns the endpoints, the schemas it really observed, a list of what will break, and a typed client in TypeScript and Python you can download and compile. This is the part of my job I have done most, made into a tool.
- Role
- Design, backend and frontend. Solo project.
- Stack
- Cloudflare Workers · D1 · a hand-written XML reader for WSDL, because Workers have no DOMParser · Workers AI for naming only · hand-written HTML, CSS and JS · the inference and parsing modules are pure functions that run under plain node, which is how they were tested
- How it holds up
-
- A model never decides a type — types, optionality, enums and formats are counted from real payloads
- Optional means a field was actually missing, and the client records how often: present in 2/3
- A field seen as two types is the top finding, generated as number | string so the compiler catches it
- Credentials are stripped in your browser before upload; the count removed is shown so you can check it
- Generated TypeScript compiles under tsc --strict; generated Python compiles
- The live call is GET and HEAD only, https only, public addresses only, twelve-second timeout
12 Payments & subscriptions live
Cadence
“They upgraded on the 12th. What do they pay?”
Taking the money is the easy half — a payment provider does that, and you should buy it. The hard half is deciding what to charge, and that is the half that gets written badly. Proration in both directions, trials, coupons that expire, graduated tiers, usage billed in arrears against a subscription billed in advance, a card that fails and the ladder that goes back for it, and tax that is sometimes the customer’s problem. Pick a situation and read the arithmetic.
- Role
- Design, engine and frontend. Solo project.
- Stack
- Cloudflare Workers · D1 for saved scenarios and counters, never for invoices — those are recomputed on every read · integer minor units end to end, no float touches a total · hand-written HTML, CSS and JS · no model anywhere in it, deliberately
- How it holds up
-
- No AI in it, deliberately — what a customer owes has one right answer, and arithmetic that is occasionally creative is not a feature
- Proration is two line items, never one: credit the unused old plan, charge the new one for the days left — the only version a customer can check, and the only one that survives a refund
- The billing anchor survives short months: anchored on the 31st it bills the 28th in February and returns to the 31st in March
- Tax is computed after discounts and after account credit, not before — charging tax on money never taken is a liability
- One engine file: the Worker imports it and your browser runs the same one, and the page prints both fingerprints side by side
- Deterministic, so the whole scenario downloads as a test fixture you can commit and diff
13 AI operations agent live
Relay
Paper in. Actions out.
An AI operations agent that reads supplier invoices and customer emails, checks them against the company's own systems, and does the work: bills in QuickBooks, tickets in the helpdesk, a line in Slack.
- Role
- Design, backend and frontend. Solo project.
- Stack
- Python · FastAPI · LLM tool use · SSE · vanilla JS · pytest · live demo on Cloudflare Workers AI
- Guardrails
-
- Six tools with strict JSON schemas
- Duplicate and reconciliation checks
- Approval threshold
- Retry with exponential backoff for 429 / 5xx / timeouts
- Event log streamed over SSE — replayable, testable without a network
Four more, all open
Each is a working demo with its own limits, its own budget and its own honest account of what it will not do.
14 Email that lands live
Envelope
Everyone sends the email. Far fewer check it arrives.
Live DNS for any domain you type, including the check almost nothing runs: SPF is capped at ten DNS lookups, and past the tenth it fails everywhere while still looking perfect. Then the message itself — what breaks in Outlook, what dark mode does to it, what a third of readers see with images off, rendered five ways at once.
Workers · DNS over HTTPS · a DER reader for DKIM key length · a hand-written MIME parser
envelope.malikakhtar.dev
15 Offline mobile app live
Outpost
The plant room is in the basement.
An installable field app that does not need a network. Every write lands in IndexedDB and returns immediately; the outbox syncs later, or next week. Install it on your phone, turn on aeroplane mode, open it from the icon and keep working. Then watch the queue drain, with idempotency keys so a lost reply cannot write anything twice.
Service worker · web app manifest · IndexedDB · Workers · D1
outpost.malikakhtar.dev
16 Work over a list live
Tabula
A spreadsheet whose columns do the work.
Give it a list and add a column that fetches, extracts, classifies or scores — then watch the cells fill in live, on every device that has the sheet open. Research and enrichment work that is normally a person and a long afternoon.
Durable Objects · Workers AI · D1 · WebSocket hibernation
tabula.malikakhtar.dev
17 Integration plumbing live
Conduit
A webhook endpoint that does not lose anything.
Signed webhooks in, a visual pipeline in the middle, retries with backoff, replay of anything that failed, and a cache so the same lookup is not paid for twice. The unglamorous layer that decides whether an integration is reliable or merely working today.
Workers · D1 · two zone routes so the public endpoint sits outside /api
conduit.malikakhtar.dev18 Client work · Logistics company
Stripe ↔ QuickBooks sync
Refunds, partial payments, and reconciliation handled automatically. Has reconciled cleanly since launch without manual fixes.
No public link — client work
Integrations58 systems
Integrations
Payments, payouts, terminals, dispatch, maps, messaging, ledgers. Systems I have integrated and shipped — the hard part is never the happy path.
Payments
Cards, refunds, partial captures, split payments, payouts. And the webhook that arrives twice, out of order, or six hours late.
- Stripe
- Stripe Connect
- PayPal
- Square
- Braintree
- Authorize.Net
- eWAYAU
- CommBankAU
- TWINTCH
- XenditSEA
Wallets & in-person
Paying with a phone, taking payment on one, and a kiosk that takes it unattended. Device support, certification, and a fallback for every tap that does not read.
- Apple Pay
- Google Pay
- Tap to Pay
Ecommerce, delivery & maps
Catalogues, orders and stock inside the storefront somebody already runs. Then dispatch, and a map that says where the driver actually is.
- Shopify
- WooCommerce
- Magento
- BigCommerce
- WordPress
- DoorDash
- Google Maps
ERP, accounting & CRM
The systems of record. The pipeline, the ledger and the stock count, kept in step with each other and with the payments.
- SAP
- NetSuite
- Dynamics 365
- Odoo
- QuickBooks
- Xero
- Salesforce
- HubSpot
- Zendesk
Messaging & email
Messages that have to arrive, not eventually. Templates, opt-outs, bounces, and deliverability that survives volume.
- Twilio
- WhatsApp Business
- SendGrid
- Mailchimp
- Klaviyo
- Meta Graph API
Workspace, docs & meetings
Where the work actually happens. Read a sheet, drop a file, send it for signature, book the call, post the line that says it is done.
- Slack
- Notion
- Google Sheets
- Google Drive
- Microsoft 365
- DocuSign
- Calendly
- Zoom
Project, data & analytics
Boards, backlogs, and the base somebody is quietly running their whole business from. Then what the numbers say afterwards.
- Jira
- Asana
- Monday.com
- Airtable
- Google Analytics
AI, cloud & automation
Tool calling, streaming, structured output that parses every time. Where it runs, what wakes it up, and glue for the parts that do not deserve custom code.
- Anthropic
- OpenAI
- Pinecone
- Supabase
- AWS
- Cloudflare
- Firebase
- Zapier
- Make
- n8n
These are the names you will recognise. The rest of the list is longer and duller: SOAP endpoints, OAuth flows, rate-limited REST, and webhooks that have to be idempotent.
What I build9 services
What I build
Systems that do the work. Not a chatbot that answers and stops. Pick one and the stage draws it.
-
AI agents & automation
Systems that do the work: process documents, qualify leads, research, draft, classify, and take real actions inside your tools. Not a chatbot that answers and stops.
-
AI inside your existing stack
LLMs wired into your CRM, database, admin panel, Google Workspace, Slack, Notion, HubSpot, Shopify, or a legacy system nobody wants to touch.
-
Complex API integration
Third-party, undocumented, and legacy SOAP APIs. Webhooks, OAuth flows, rate-limited endpoints, data syncs between systems never designed to talk. Half my career.
-
RAG chatbots & assistants
Trained on your own data, answering with sources so output is verifiable instead of confidently wrong.
-
Backend & workflow systems
The APIs, queues, schedulers, and pipelines underneath all of the above. Built to survive production, not just a demo.
-
Email infrastructure & deliverability
Multi-domain sending, SPF/DKIM/DMARC, custom tracking domains, warmup, API-level integration.
-
Web apps & custom software
Full products and internal tools: React and Next.js front ends on Python or Node back ends, admin panels, dashboards, and the APIs underneath. Ten years of shipping software that is documented, structured, and yours.
-
Mobile apps
React Native and Flutter apps that share the API, auth, and data of your web product: iOS and Android from one codebase, with the backend built to match.
-
Self-service kiosks
Touch-first ordering and checkout that has to run unattended all day: a locked-down Android tablet, an iPad, or a browser in kiosk mode, wired to a card reader and to the systems behind the counter.
How I workFrom first message to handover
How I work
I tell you when AI is the wrong tool. Sometimes a 40-line script beats an LLM: cheaper, faster, deterministic. I say so even when the AI version would bill more hours.
01 First reply · within 24 hours
An honest read
Send me the problem, even roughly. Within 24 hours you get an honest read on approach, timeline, and cost. If I am not the right person for it, I will tell you that too.
02 Scoping call · short, first
Simpler than you thought
A short call before any estimate. I would rather tell you the project is simpler than you thought than take a bloated budget. Sometimes a 40-line script beats an LLM.
03 Scope & milestones · fixed, written
No surprise invoices
Fixed scope, clear milestones, realistic estimates. I have been wrong enough times to know how long things take, so the plan is one you can hold me to.
04 Build · with written updates
You never have to ask
Regular written updates, so you always know the status. Error handling, logging, and monitoring from day one, not after something breaks.
05 Handover & after · support included
Code that stays yours
Documented, structured, yours: code you can hand to another developer, no lock-in, no black box. Support after delivery. I do not disappear at handover.
Stack6 layers · 46 tools
Stack
Everything orbits the product. Six layers, in the order a request travels through them, and the older ones I still add AI to.
-
01
Web & mobile apps
the apps people touch · 5
Products and internal tools: React and Next.js front ends, dashboards and admin panels, and React Native or Flutter apps that share the same API and data.
- React
- Next.js
- TypeScript
- React Native
- Flutter
-
02
Backend
the APIs and the logic · 6
FastAPI and Django in Python, Express and NestJS in Node: the APIs, queues, schedulers and pipelines underneath everything, built to survive production.
- Python
- FastAPI
- Django
- Node.js
- Express
- NestJS
-
03
AI / LLM
the reasoning, kept on a leash · 9
Agents with strict tool schemas and approval thresholds, RAG assistants that answer with sources, evals so the output is verifiable instead of confidently wrong.
- Anthropic API
- OpenAI API
- open models
- LangChain
- LlamaIndex
- RAG
- tool use
- MCP servers
- evals
-
04
Data & infra
where it lives and runs · 10
PostgreSQL first. Redis for queues and caching, vector stores for retrieval, Docker and AWS with CI/CD so deploys are boring and repeatable.
- PostgreSQL
- MySQL
- MongoDB
- Redis
- Pinecone
- pgvector
- Chroma
- Docker
- AWS
- CI/CD
-
05
Integration
the systems it has to talk to · 12
Half my career: third-party, undocumented and legacy APIs, webhooks, OAuth flows, rate limits, and syncs between systems that were never designed to talk.
- REST
- GraphQL
- webhooks
- OAuth2
- SOAP
- Stripe
- Twilio
- HubSpot
- Shopify
- n8n
- Make
- Zapier
-
06
Legacy
systems that already exist · 4
For adding AI and modern integrations to PHP/Laravel and .NET/C# systems that already exist and that nobody wants to rewrite.
- PHP
- Laravel
- .NET
- C#
What this stack has shipped9 kinds of work
210+projects delivered with a 5.0 average rating on Fiverr , over ten years, on this stack. Eighteen of them are described in Work; these are the kinds of problems behind the rest.
- 01
AI agents & automation
“Read our documents and do the work in our tools.”
AI / LLMBackendData & infra
- 02
Assistants on your own data
“Answer questions from our docs, with sources.”
AI / LLMData & infra
- 03
Web apps & internal tools
“A product, an admin panel, a dashboard.”
Web & mobileBackendData & infra
- 04
Mobile apps
“iOS and Android, one codebase, same backend.”
Web & mobileBackend
- 05
CRM, accounting & payment syncs
“Make Stripe, HubSpot and QuickBooks agree.”
IntegrationBackendData & infra
- 06
Undocumented & legacy APIs
“Talk to a system nobody wants to touch.”
IntegrationLegacy
- 07
Backends & pipelines
“The queue, the scheduler, the API underneath.”
BackendData & infra
- 08
Email infrastructure
“Our mail lands in spam.”
BackendIntegration
- 09
Legacy upgrades
“Add AI to the PHP or .NET system we already run.”
LegacyAI / LLM
- 01
Boring on purpose
PostgreSQL before a new database, a queue before a framework, a 40-line script before an LLM. Deterministic wins when it can.
- 02
The right tool, not the newest
I tell you when AI is the wrong tool, even when the AI version would bill more hours. The stack serves the problem, not the other way round.
- 03
Yours to keep
Documented, structured, standard tools another developer can pick up. No lock-in, no black box, no framework only I understand.
ContactReplies within 24 hours
Within 24 hours: an honest read on approach, timeline, cost.
Send me the problem. Short scoping call first — I would rather tell you the project is simpler than you thought than take a bloated budget.