DEV Community: Ashar Qaisar

Ashar Qaisar — Full-Stack Developer and AI Integration Engineer

Ashar Qaisar — Mon, 26 Oct 2026 18:29:13 +0000

Hi, I'm Ashar Qaisar — a full-stack developer and AI integration engineer based in Gujranwala, Pakistan, working remote worldwide.

I am currently a Contract AI Engineer at Drytis and the founder of Elevate Mavens. I enjoy building full-stack products and weaving practical AI into them, from the interface down to the data and integrations behind it.

Some projects I am working on:

Gavel — adversarial AI agents with Qloo taste-graph evidence
CardKami — a card collector game
Kairo — a worldwide discovery feed for events, offers and stores
Sonami — a manhwa reader
Airwave — a curated live-TV streaming site

You can find more of my work here:

Thanks for stopping by — feel free to connect if you are building something interesting.

CardKami: a stand generator that became a game because my friends would not let go of the cards

Ashar Qaisar — Mon, 26 Oct 2026 13:39:12 +0000

CardKami started as a JoJo stand generator, just for fun. My friends kept asking if they could keep the cards they rolled, so I kept adding things until it turned into an actual game. It runs entirely in the browser, no download, free to play.

It lives at https://cardkami.vercel.app.

What it is now

Eight views, one game loop:

Auth first, with a username, so a collection belongs to someone
Home: a daily claim board, three face-down cards, claim one a day, plus a check-in streak
Play: Card Grab Rush
Missions, a coin gacha, My Deck with card levels and a six-card showcase, a leaderboard, trading, and a profile

The roster is 162 cards: JoJo, anime, and manhwa. The gacha pool is real Shoob cards only. Cards that do not match sit out, rather than being faked in.

The lesson that mattered most: the server owns the economy

Early on, too much of the game lived in the client. That is fine for a generator. It is not fine for a game where cards, coins, streaks, and missions have value to the player.

So the economy moved to the server. Missions, achievements, daily claims, check-ins, gacha pulls, trades, and battle results are verified on the server through Supabase functions, and the server state is the only record of what a player owns. The client asks, the server decides, and the client shows the result.

That change is boring to describe and it is the whole game. Without it, every reward is a suggestion. With it, a collection means something, because it cannot be edited in the browser and kept.

What I kept, and what I cut

I kept the visual design and the roster data that people already liked. I removed the one-off generator pages that did not fit a game: the destiny match, the vibe check, the index page, and the old summon name.

Custom cards were cut too. They sounded fun and they broke the pool. A game with a shared pool needs shared rules, or the pool stops meaning anything.

What is still honest to say

CardKami is a game my friends play, not a company. It is free, it runs in a browser, and its economy is server-verified. It is still growing, and the next step is the part players ask about most: real battles, not just collecting.

If you build a game, build the collection first, then make the server the source of truth before anyone cares enough to cheat it. By the time they do, it is too late to add.

I am Ashar, a full-stack developer and AI integration engineer. More of my work is at https://asharxyz.vercel.app.

Agents that survive real use: verify, never submit blind, and log everything

Ashar Qaisar — Mon, 26 Oct 2026 13:38:41 +0000

I build agents that act in the real world: a WhatsApp bot with dozens of commands, and an app with server-verified missions. The interesting part is not the model. It is everything around it that keeps the agent from doing damage when it is wrong.

These are the rules I actually work by, learned the hard way.

1. Never submit blind

An agent must never send, commit, push, or publish something I have not seen, unless I explicitly ordered that exact action. Drafts go to a staging area first. Live code is only touched after a check passes in a throwaway copy.

This rule exists because of a real incident: a bot command once committed and pushed a change without my approval. The change stayed, but the rule changed with it. No agent query touches live code or a live repo on its own.

2. Verify the decisive claim yourself

A researcher's report that a site is broken, a listing is dead, or a price is real is not evidence. I check it directly before it reaches a client or a user. A clean build or a 200 response is not verification either. The check has to reproduce the real conditions: the real phone, the real viewport, the real account state.

A screenshot alone is never enough for a diagnosis. Check the live session, the account, and the platform state before asserting what succeeded or failed.

3. The phone is the final gate

I build on a desktop, but most of my users are on phones. Every visual or interactive deliverable is judged on a real phone, not on a clean build log. When my rig cannot reproduce those conditions, I say so before delivery, and the first real run becomes the test.

When a fix fails on a phone, the next attempt starts by reproducing that exact phone scenario in a test, never by deploying and hoping.

4. Every failure must produce a permanent adaptation

A bug that is fixed and forgotten will return. A failure class that is understood gets a standing check that makes that class impossible, or at least caught early.

Examples from my own work: verification must reproduce touch with jitter and a phone viewport. A watchdog must check a service by its port and status endpoint, not by a process name that changed months ago. A commit must be authored by the account that owns the deployment target, or the deploy will be blocked.

5. Log silently, speak only when it matters

A watcher that reports every routine event becomes noise, and noise gets ignored. Losses, enters, and reassignments log silently. The watcher speaks only when a ticket is won, when a human hand is needed, or when the watcher itself breaks.

The same applies to an agent's output. One complete report at the end beats a stream of partial updates.

6. Keep secrets out of the work

Keys, tokens, and passwords live in a vault or a designated env file, never in memory, ordinary files, chat, or a repo. A credential delivered in chat is treated as exposed and rotated at the next login.

This is not paranoia. It is the only way a system with many moving parts stays trustworthy.

The short version

Build the agent, then build the guardrails around it: staging before live, verification before claims, a phone check before delivery, a permanent adaptation after every failure, silent logging, and secrets kept out of the work entirely.

The model is the easy part. Surviving contact with real users is the job.

I am Ashar, a full-stack developer and AI integration engineer. More of my work is at https://asharxyz.vercel.app.

I shipped a real app on a GitHub JSON backend, and it works until it doesn't

Ashar Qaisar — Mon, 26 Oct 2026 13:38:08 +0000

I needed a backend for a small discovery feed app. No database was provisionable at the time, and I did not want to pay for one before the app had any users. So I used what I already had: a private GitHub repo, a JSON file in it, and Vercel serverless functions.

This is not a recommendation for every app. It is a record of what worked, what broke, and where it stops working.

The shape

The app is a feed of events, offers, and stores. Viewers are read-only. Only an admin can post, edit, delete, or hide a post. There are no accounts and no payments yet.

The data lives in one file, data/kairo.json, in a private repo. Nothing reads or writes that file from the browser. Every read and write goes through a serverless function, and only the server holds the token that can write to the repo.

The admin page is key-gated. The key is never in the repo and never in client code. The server checks a hash of the key, and without it the admin API returns 401 and no data.

What the server actually does

Votes, saves, and reposts are one per browser, using a device id in localStorage, with server-side dedup. That is gameable by clearing storage, and I say that plainly in the app's own limits. It is a tradeoff, not a feature.

Analytics are computed only from persisted events: per-device voter, saver, and reposter lists, plus a view counter. Seed numbers are ignored in code. When I cut over to real analytics, the old inflated totals were zeroed and the real totals were small. That is the honest number, and it is better than a big fake one.

Admin input is validated on the server: control characters stripped, length caps, country and type checked against an allowlist, and an image URL must be https and return 200 before it is accepted.

Rate limits are persisted in the same data file: votes, saves, and reposts are limited per device and post, views are limited per device and post, with a batch cap. Rapid repeats return 429.

Where it breaks

This works because traffic is low. A JSON file in a repo is not a database. Concurrent writes can conflict, reads are a full file read, and every write is a commit. If traffic grows, the next step is Postgres, not a bigger JSON file.

The data token is currently broad. After launch, it should be replaced with a fine-grained token scoped only to that one repo.

Hosting is on the Hobby plan, which is fine while there is no commercial use. Once paid listings begin, that plan no longer fits, and the cost becomes about $20 a month for Pro.

The lesson

Start with the cheapest backend that is honest about its limits, and write those limits into the code, not just into a README. When the app outgrows it, the migration is a known step, not a rewrite done in panic.

I am Ashar, a full-stack developer and AI integration engineer. More of my work is at https://asharxyz.vercel.app.