Hi, I’m Aasher Kamal. I’m an independent developer based in Pakistan, building AI agents and full-stack software for people with real work to get done.
A lot of my best ideas begin with something that keeps bothering me.
Before I built Invox, I made every client invoice in Adobe Illustrator. Each one took 30 to 40 minutes. I typed the line items by hand, calculated totals on my phone, adjusted the layout, and exported the PDF. It was a small task, but it was needlessly repetitive.
So I built the tool I wanted to use: upload a contract or describe the work, let the software prepare the invoice, then edit everything before exporting it.
That project says more about how I think than a long list of technologies could. I like finding the part of a workflow that wastes someone’s time, understanding why it is awkward, and building something that makes the better way feel obvious.
The work I keep coming back to
The products are different, but the questions behind them are usually similar.
How can an ecommerce assistant answer a useful question and take the right action? How can a business make sense of scattered documents, support content, or videos without searching everything manually? How can an internal dashboard make a complicated process easier to follow without hiding important details?
Those questions have led me to build an ecommerce support platform, a conversational shopping agent, a role-based dashboard for trade data, and a source-grounded knowledge assistant.
In each case, the AI is only one part of the product. It still needs a thoughtful interface, a dependable backend, clear data flow, sensible permissions, and a plan for what happens when the model is uncertain.
That complete system is the part I enjoy building.
AI has to earn its place
I’m excited by what AI can do, but I don’t think every problem needs an agent.
Sometimes the right solution is a tool-using workflow. Sometimes it is retrieval-augmented generation—RAG—over private business knowledge. Sometimes it is a normal API, database, and carefully designed interface. The technology should follow the problem, not the other way around.
Before I build, I want to know what the system is allowed to do, what should remain under human control, where its information comes from, and how it should fail when the evidence is not good enough.
I would rather build something narrow and trustworthy than something impressive in a demo and frustrating in daily use.
Design is part of the engineering
I care deeply about how software feels.
A technically capable product can still be miserable to use. I notice the hierarchy of a page, the rhythm of its spacing, the purpose of its motion, the empty states, and the moment when a user has to wonder what to do next.
To me, the interface is not decoration around the “real” engineering. It is where the system either keeps or breaks its promise to the person using it.
That is why I like working across the whole product: the AI workflow, backend, data, frontend, and the details that make everything feel considered.
How I work with people
When someone hires me, they work directly with me.
I ask questions early because a clear problem is more valuable than a large feature list. I make the important choices visible, explain the tradeoffs in plain language, and build in stages so there is something real to review before too many assumptions become code.
I also care about the less glamorous parts: validation, failure states, documentation, ownership, and leaving the project in a shape another developer can understand.
I communicate uncertainty early, investigate the parts that matter, and recommend a simpler approach when it serves the product better.
Where I’m going
I want to keep building thoughtful software for founders and teams with a real problem, real constraints, and enough care to do the work properly.
I’m especially interested in AI systems that make private knowledge usable, automate multi-step work, support customers, or become part of a larger full-stack product. That might begin as one focused feature or grow into an end-to-end build.
Either way, I want the result to be useful after the novelty wears off.