Work · the evidence
Six products.None of themwritten by me.
This page carries the whole argument, so it is the one with the least spin in it. Live links where a live link exists, the stacks in full, and a plain account of the parts I did not do.
- Six products · one company
- Stacks listed in full
- Islamabad, Pakistan
- Building since February 2021
Why this page exists
This is the evidence, not the pitch.
Everything else on this site rests on one claim: that building software became a specification problem, and that specification is an operator skill. This page is where you check it.
A claim like that is worth nothing unless the work behind it is inspectable. So this is all of it, including the one that is private, the one still in development, and the parts that are my word rather than a link.
Read it the way you would read a supplier reference rather than a portfolio. The stacks are listed because a sceptical engineer will want to see whether the pieces fit together the way I say they do, and because a list of technologies is a much harder thing to bluff than an adjective.
- Products shipped
- 6
- Clients advised
- 5
- People trained on AI tools
- 15+
- Following on LinkedIn
- 9K+
The record
Seven entries. Six products and the company they came out of.
Where a product is private, or still in development, the card says so on its own line rather than in a footnote at the bottom of the page.
01
LittleOS
In development · getlittleos.com
A zero-cost AI operating system: 50+ agents, workflow automation, content generation, voice control, installable as a PWA. The most ambitious thing on this list and the place I try ideas too unproven to run on a client engagement.
- Stack: Next.js 15, TypeScript, Supabase, Cloudflare, tRPC, Zod, Zustand, n8n
- Scale: a 45-table database, 20 design documents, 58 recorded architectural decisions
- Repository: [PLACEHOLDER: public repository URL for LittleOS, or delete this line if the repo is private]
02
Triisum
Live · co-founder and CEO since February 2021
A travel eco-marketplace, and the company the whole method came out of. Four years of running something I could not personally build is where I learned to write a specification, because the specification was the only lever I had.
- Team: 8+ across engineering, QA and operations
- Discovery: 50+ customer interviews
- Partnerships: 10+ white-label agreements, 2 OTA partnerships, 2 fintech integrations
- Selection: NIC Islamabad Cohort 12, from 1,110+ applicants
03
Liquid Finance
Live · liquid-finance.pages.dev
A personal-finance PWA with AI receipt scanning, multi-currency budgets and full offline capability. The one I actually use every week, which is the only honest test of a personal-finance app.
- Stack: React, Supabase, PostgreSQL, Vite, Netlify
- Models: Gemini Flash, Groq and Mistral APIs behind the receipt scanner
- Repository: [PLACEHOLDER: public repository URL for Liquid Finance, or delete this line if the repo is private]
04
ThumbSnap AI
Live · private, no public URL
Generative design SaaS for thumbnails. It took a job that ran two hours of designer time and made it thirty seconds: the clearest example on this list of what changes when specification is the only bottleneck left.
- Stack: Next.js, Supabase, Google Vertex AI, credits-based payments
- Access: private, so what you have here is my description of it rather than a link
05
Safar
Live · safar.figma.site
An e-visa eligibility checker, built because the existing answer to "can I actually travel there" was twelve browser tabs and a forum post from 2019. It reads the live requirements rather than a table somebody updated last year.
- Stack: Supabase, with Firecrawl and Context.dev pulling live requirements
- Caching: 48 hours in Supabase, so answers stay current without hammering the sources
- Coverage: Pakistani, Bangladeshi and Nigerian passports, travelling to the UAE, Turkey and Indonesia
06
Autonomous Article Writer
Running · publishing pipeline
A pipeline that ships 15+ articles a day from 20+ sources at zero operational cost, with image generation and HTML formatting, publishing into Notion and WordPress. It is the reference implementation for the automation work, not a demo of it.
- Stack: GitHub Actions orchestrating the run, publishing into Notion and WordPress
- Throughput: 15+ articles a day from 20+ sources, at zero operational cost
- Repository: [PLACEHOLDER: public repository URL for the Autonomous Article Writer, or delete this line if the repo is private]
07
Triisum Eco-Ambassadors
Live · triisum-eco-hackathon.vercel.app
A sustainability app that awards points for eco-actions and holds attention with streaks, levels, team challenges and partner rewards. The smallest thing on this list and the fastest, which is the point of including it.
- Mechanics: points for eco-actions, streaks, levels, team challenges, partner rewards
- Stack: [PLACEHOLDER: stack for Triisum Eco-Ambassadors, the one build on this page I have not written down anywhere]
The honest part
What I did not do.
I did not write the production code in any of these. Not most of it, not the difficult parts, none of it.
What I wrote was the specification. The constraints, the edge cases, the file it goes in, what "done" means, and the list of things it must not touch. Then I read what came back against that brief and rejected whatever did not match it.
That is deliberately not vibe coding as Andrej Karpathy defined it when he coined the term in February 2025: "you fully give in to the vibes, embrace exponentials, and forget that the code even exists." In the original description you accept every diff without reading it and paste errors straight back at the model. That is a fine way to get a demo by Friday. It is not how anything above stayed up.
What the work actually was
- Writing the brief before the build, then rewriting it when the first output exposed a gap I had not seen
- Choosing the architecture and the stack, and refusing the ones that would have cost a rebuild six weeks later
- Reviewing every change against the specification rather than against my own ability to read the language
- Using the thing as a user, in production, on a real device: the only test I am actually qualified to run
- Deciding what to cut when the scope and the time disagreed, which they did every time
What it was not: writing the production code, or reviewing it the way an engineer would. If your problem needs somebody who can read the source and tell you the concurrency model is wrong, that is not me. I would rather say so on the first call than after the invoice.
Before you count it as proof
What this page cannot prove, and where I am asking you to take my word.
Where there is a link, open it. Those are the only claims here that verify themselves, and LittleOS is still in development, so what you find there is a work in progress rather than a finished product.
The rest does not verify itself and I would rather name that than let four links carry seven entries. ThumbSnap AI is private, so what you have is my description of it. Triisum is a company rather than a page: the interviews, the partnerships, the cohort and the team size are mine to state and yours to check, and I will walk you through any of them on a call.
Three of these are ones I would like to point you at the source for, and until a repository URL is actually on this page, do not count that as verified. A repository nobody can open proves nothing, and a portfolio page is the wrong place to ask for the benefit of the doubt.
If a stack here looks wrong to you, say so. Somebody who checks and finds a hole is the most useful person who has read this page.
If it holds up
You have checked the work. The question is whether it transfers.
Thirty minutes, free, and no pitch. You describe what you are trying to ship and where it is stuck, and I tell you what I would do about it. If I am not the right fit I will say so in the first ten minutes; most of these calls end with somebody getting a useful answer and not spending any money, and that is a completely fine outcome for me.
P.S. The most useful thing you can do with this page is open one of the live links and try to break it. If you find something, bring it to the call. I would much rather hear it from you than from a client.