Salman Khan — Full-stack Product Engineer
I am an end-to-end product builder. That means the architecture and the scaling decisions first, then the engineering, then the business around it and the marketing that puts it in front of people — done by one person rather than handed between four. Bizstock is the proof: every line of it, every screen, and every customer, mine.
Products and client platforms delivered end to end. Each links to the full write-up on dragondevs.co, where the architecture and the decisions behind it are written up properly.
A point-of-sale that never waits for the internet.
Inventory and POS tools quietly assume a reliable connection and a browser open all day. On a real shop floor neither holds. Bizstock is built local-first: data lives on the device in SQLite, so billing, stock, ledgers and reports stay instant and fully usable offline, then reconcile across devices when a connection returns.
Outcome
Ships to desktop and Android from one codebase, works offline by design, and serves users in English and Urdu including full right-to-left layouts.
One workspace replacing a studio's spreadsheets and chat threads.
A Saudi design and craft studio had outgrown its tools — projects, clients, designer assignments, contracts and quotations scattered across files and chat, so answering what is the status of this job meant hunting through half a dozen places. I built a single source of truth: bilingual, role-aware, searchable.
Outcome
Setting up a new project takes minutes, quotations follow a consistent template, and management has a live view of the whole pipeline in a language everyone on the team reads comfortably.
Status
Live
My role
Product, data model, bilingual UI and full-stack build
A 25-year cooling brand, brought online end to end.
Al Nada had a deep product range — portable units through central systems — and no modern way to sell or support online. I built a headless commerce and content platform with a bilingual storefront, a guided flow that helps shoppers find the right cooler for their space, secure local checkout, and maintenance and quote requests.
Outcome
An established offline brand now sells and supports online, and the marketing team publishes products, pricing and content without a developer.
File transfer that falls back instead of failing — down to sending data as light.
Every way of moving a file between two devices assumes something: an account, an internet connection, the same app on both ends, or a cable. Quickbeam picks the best channel available and degrades gracefully. On a shared network the sender runs a small web server and the other end collects files in an ordinary browser. With no shared network it hosts its own hotspot. With no radio at all it encodes the file into animated QR frames and the other device's camera reads them back.
Outcome
Verified end to end: a 5 MB file arriving byte-identical over LAN at 38.5 MB/s, with nothing installed on the receiving device. Encrypted transfers and saved pairings are the next milestones.
Stated specifically enough that you can check it. Every claim names the system it came from — the ones above, with the write-ups to match.
The shape of a system is decided in the first week and paid for every week after. I design for the load that is coming rather than the load that is here: data models that do not need rewriting at ten times the volume, boundaries drawn so features slot in instead of tangling, and the expensive decisions taken deliberately and written down.
Bizstock, CraftFlow
Data on the device rather than behind a request. On-device SQLite as the primary store, an interface that never blocks on the network, and reconciliation across devices once a connection returns — scheduled or live over sockets. Designed for the case where the connection is the unreliable part.
Bizstock, Quickbeam
Tenant isolation enforced at the data layer, role-based access that decides what each person can reach, and per-tenant configuration that does not fork the codebase. Built so a second customer costs nothing but a row, and the thousandth costs nothing more.
Bizstock, CraftFlow
Frontend, backend, database and native builds, because splitting them across people is what creates the seams products fail at. TypeScript and Next.js for most of it, Python and Django where the problem is data-shaped, Rust via Tauri when it has to ship as a real desktop and Android application from one codebase.
All four
Arabic, Urdu and English as first-class layouts, not a mirrored stylesheet bolted on at the end. Locale-aware routing, formatting and typography, with the data model designed bilingual from the first sketch rather than retrofitted.
CraftFlow, Al Nada, Bizstock
Pricing, licensing, trials and the unit economics that decide whether a product is a business or a hobby. Bizstock has a licence model, a trial that converts and a support channel because I designed those the same way I designed its database — as parts of the system, not as an afterthought.
Bizstock
Working out who the product is for, what it should say to them, and where they will hear it. That means the landing page, the copy, the search strategy and the launch — the difference between software that exists and software people find. Every site in this list, including this one, is mine.
Bizstock, dragondevs
Finding the real problem, turning it into requirements someone can build against, designing the interface, writing the system, shipping it, and then selling it. Every project on this page went from an empty repository to production with me responsible for that whole line.
All four
Everything here appears in shipped work — either in a case study above or a repository in the archive below. Marked entries are what I reach for by default.
Default choiceUsed in production
Graphic design, then freelance code, then three years of deliberate self-teaching, then products. The early entries are kept because they are where the eye and the habits came from.
dragondevs
Run the studio and do the engineering. Delivered a bilingual operations platform and a full commerce build for clients in Saudi Arabia, while developing Bizstock and Quickbeam as products of our own.
Bizstock — Self-employed
Designed, architected and built Bizstock end to end as a solo product builder: inventory, stock control, purchasing, reporting and multi-tenant isolation. Defined the requirements and the interfaces as well as the system underneath them.
OBS
Built a learning-management system for schools and colleges alongside the owner of OBS, who has twenty years in software. Responsible for interface design and core functionality.
Self-employed
Three years spent deliberately going deeper — personal projects chosen for what they would teach rather than what they would pay. Most of the archive below dates from here.
Jacolink — UAE
Python scripting, Django REST APIs, websites and graphics for a range of clients. First paid work where the code, not the artwork, was the deliverable.
Leader Sign — UAE
Logos, 3D signboards and full brand identities. Where the eye for typography and spacing that runs through everything since was trained.
The self-taught years. Not client systems and not pretending to be — these are the repositories where the habits behind everything above were formed. Most are open source.
Inventory, sales and invoicing for companies selling laboratory tools and medications.
Next.js · TypeScript · PostgreSQL
Full-stack Django app — accounts, profiles, public rooms, presence and private messaging.
Django · Python · SQLite
Football tournament management API: teams, fixtures, scheduling and tournament history.
Django REST Framework · Python · SQLite
The React client for the tournament API, with form handling and a test suite.
React · JavaScript · Jest
Philosophy
Find the real problem.
Build the smallest thing that solves it.
Make it work when conditions do not.
“Simplicity is the key to brilliance” — Bruce Lee
Availability, location, how an engagement starts, and what offline-first actually means. If your question is not here, ask it directly — the form is below.
Systems that a business depends on to operate: inventory and point-of-sale, operations platforms, e-commerce, internal tools, APIs. I am most useful where the problem is not yet well defined and the work runs from requirements through architecture and interface design to a deployed product — that whole line is what I do, rather than one slice of it.
Both, selectively. I run dragondevs, so my time is committed in blocks rather than open-ended — but I take on a small number of engagements a year, and I will consider a full-time role where the work is genuinely hard. The fastest way to find out is to describe the problem and I will tell you honestly whether I am the right person.
Yes. I am based in Islamabad on UTC+5, which overlaps a normal working day across the Gulf, Europe and most of Asia. Delivered work so far spans Pakistan, Saudi Arabia and the United Arab Emirates, and every engagement to date has been remote.
Offline-first means the data lives on the device rather than behind a network request, so the application stays instant and fully usable with no connection, then reconciles across devices when one is available. It matters because most business software quietly assumes a reliable connection, and on a real shop floor or a construction site that assumption is wrong. Bizstock is built this way end to end.
TypeScript and Next.js for most product work, Python and Django where the problem is data or scripting shaped, and Rust via Tauri when something has to ship as a native desktop and Android build from one codebase. PostgreSQL and SQLite for storage, Drizzle for the data layer. The full list is in the stack section above, marked by what I reach for by default versus what I have shipped once.
Yes, and properly. Arabic, Urdu and English as first-class layouts with locale-aware routing, formatting and typography, and the data model designed bilingual from the first sketch. That is a different job from mirroring a finished stylesheet, which is how most retrofitted right-to-left support fails.
With a conversation about the problem, not the technology. I would rather understand what is actually breaking before proposing anything, so the first step is a call or a detailed email. From there I scope the work in phases with something usable at the end of each, so you are never a long way in with nothing to look at.
Serious enquiries only get serious answers, and I read every message myself. Whether it is a product to build, a system to rescue, or a role worth talking about — the fastest route is the one that suits you.
Open to select work
Working UTC+5, which overlaps a normal day across the Gulf, Europe and most of Asia. Every engagement so far has been remote. I read every message myself.