Tahir Rasool builds small-business websites, custom web apps, and practical AI for small businesses, with the person you speak with doing the work.
Two sides of one practice. Neither replaces the other: most projects are a website, an app, or an AI feature inside one of them.
A first business site, a refresh when the old one has outgrown the business, or a custom app for a workflow that keeps getting done by hand.
Question-and-answer over your own documents, or a task-focused agent for one defined job — only where it beats an ordinary form or integration.
Worth saying plainly. No prices, budgets, delivery dates or availability are published here, and no result is promised for a website or an AI feature. Scope and a written quote are discussed per project, before any build starts.
Three studies of how the work is approached: an AI writing draft, a document answer you can check, and a clipboard history you can actually search. They are drawn from this site's own design tokens and labelled as illustrative.
Illustrative interface study. Drawn from the design tokens, not captured from the product. Not a working demo.
Independent product · Topic and voice in, editable draft out. Read the case study
Illustrative interface study. The citation is the point being shown: it points at a page so a reader can check. A citation is not a correctness guarantee.
Independent product · The answer stays beside the source it came from. Read the case study
Illustrative interface study. The URLs shown are this site's own public addresses, used as sample clipboard content.
Open-source project · Retrieval is the part that has to work. Read the case study
Illustrative interface studies, not product screenshots. These panels are drawn from the site's own design tokens to show how the work is approached. They walk through their steps as you scroll. They are not captures of a running product and no result is claimed for any of them.
Every project below is Tahir's own build. Two are independent products, two are open-source. None is a commissioned client engagement, and none is presented as a client result. Where the public description does not verify a technical detail, it is left out rather than guessed.
These are Tahir's independent products and open-source projects. Each writeup separates what the public description or repository documents from what ZUMX cannot verify, because a case study that blends the two is worse than no case study. Direct links to live product pages and repositories are intentionally omitted: the verified public profile is Tahir's GitHub and LinkedIn.
Four published steps in three phases. Nothing here is a delivery promise: timings, cadences and availability are agreed with you per project rather than published in advance.
Brief
Step 1: Understand the job
The business task, the audience, the current process, and what should become easier.
Brief
Step 2: Agree scope and a written quote
First useful scope, included pages and features, dependencies, review points, future phases, and a written quote, before the build starts.
Build
Step 3: Build and review
Work is built to be reviewable against the agreed job. Feedback expectations are clarified with the client rather than promised as a fixed cadence.
Launch
Step 4: Clarify handover and ownership
Launch, ownership, handover, and any separately scoped ongoing support.
ZUMX is Tahir Rasool's independent practice. He describes his public background as backend and Android development, and his public work spans products and open-source tools. There is no team of specialists between you and the build: the scope, the decision about what to leave out, and the handover all sit with the same person.
Build the smallest useful thing first
A first version that a business can actually use beats a complete one that never ships. The goal is the smallest thing that solves the real job.
Scope in writing, before the build
What is included, what is not, what it depends on, and what a written quote covers. Agreed before work starts, so there is a shared definition of done.
Work that can be reviewed
Reviews only work if there is something concrete to look at. Progress is shown against the agreed job, and feedback expectations are agreed rather than assumed.
Handover and ownership made explicit
Who owns what, how access is handed over, and what happens afterwards. Ongoing support is scoped separately instead of quietly assumed to be included.
If a question is not answered here, ask it directly. Use the project form on the contact page, or write to tahir@zumxlabs.xyz or WhatsApp.
Tahir Rasool. ZUMX is his independent practice, so the person answering your email is the person who designs, builds and hands over the work. There is no account layer or team of specialists in between.
No prices are published on this site, and there is no starting price or package. Project-specific scope and a written quote are discussed before any build starts. Publishing a number that would not apply to your project would only mislead you.
Two sides of one offer: small-business websites and custom web apps, and practical AI or automation where those tools fit a real task. Neither side replaces the other — most projects are a website, an app, or an AI feature inside one of them.
No. AI is added only when it is the simplest useful solution to a real business task. Often the right tool is an ordinary form, an integration or a rule — and that is what gets built instead. Anything consequential keeps a human in charge.
There is no booking link and no online booking system. Email tahir@zumxlabs.xyz or use WhatsApp, and include enough detail to be useful.
No, and this site does not pretend otherwise. The four case studies are Tahir's own independent products and open-source builds. They show how the work is approached, not a client history, and no outcome is claimed for any of them.
Four things: understand the business task and who uses the work; agree the first useful scope, dependencies and a written quote before the build; build work that can be reviewed against that agreement; then clarify launch, ownership, handover and any separately scoped ongoing support. Response times and update cadences are agreed with you rather than promised here.
No service area is published or implied. The contact details on this page are the practical answer — if the work is a good fit and the conversation works, it goes ahead.
A studio site that oversells is worse than no site. These are the lines ZUMX holds, in public and in the machine-readable profile.
The same boundaries are machine-readable in agent-profile.json,
and explained for assistants on the for-agents page.
Email, WhatsApp or the project form on the contact page. Every route reaches the same person: Tahir.
