About me

I didn't study computer science. My degree is in Industrial Management, and for a long time I assumed my career would live somewhere in that world: operations, strategy, maybe running a business of my own someday.

What actually happened is that I got into digital marketing. Content, SEO, building WordPress sites for clients who needed a web presence and had no idea how to get one. It was practical work, and I liked it, but every project eventually ran into a wall that marketing knowledge couldn't get past. A site was too slow. A theme couldn't do what a client needed. Search rankings depended on something technical I didn't understand yet.

So I learned it. Then the next project hit a different wall, and I learned that too. JavaScript, then Python, then APIs, then Next.js, then cloud platforms, then automation, then AI. Not because I set out to become an engineer, but because engineering kept being the thing standing between a client's problem and its solution.

Programming was never the destination. It became, gradually and almost by accident, the best tool I had for solving problems that kept getting more complex.

A few years into building things, I noticed a pattern. Projects failed less often because of bad code and more often because of a bad understanding of the business underneath it. A feature nobody needed. A product priced wrong. A workflow that solved the wrong problem elegantly.

That's part of why I went back for an MBA at the University of Tehran, on top of a Bachelor's in Industrial Management I'd completed earlier at Islamic Azad University in Karaj. I wanted the vocabulary and the frameworks for the business side to be as solid as the technical side had become. Pricing, customer behavior, operations, strategy: these turned out to be just as useful for making good engineering decisions as any programming language.

I'm currently continuing that education as a Master's student at Sharif University. Not because a degree changes what I can build, but because I've never stopped finding value in understanding the business layer underneath the technical one. Today the two aren't really separate disciplines for me. I think in both at once, by default.

Where I work from has shaped how I work, probably more than any single degree.

Running an international freelance practice from Iran comes with a specific set of limitations: payment platforms that don't operate here, services that are unreliable or outright inaccessible, infrastructure that isn't built with someone in my position in mind. None of that is something I can fix by wishing it were different, so early on I stopped waiting for ideal conditions and started building around the ones I actually had.

That meant automating anything repetitive, because my time was the one resource I could fully control. It meant getting comfortable adapting tools to do things they weren't quite designed for. It meant treating constraints as a design input rather than an excuse.

I don't think of this as a disadvantage I've overcome. It's closer to training. Most of the resourcefulness I bring to a client's problem today, I built by solving my own problems first, with fewer resources than I would have liked.

Outside of client work, I spend a lot of my free time experimenting. New frameworks, new AI models, new ways of automating something that used to take an afternoon. I'm not particularly interested in chasing trends for their own sake. What I'm actually doing is testing whether a new tool solves a real problem, or whether it's just new.

Sometimes that experimentation turns into something I ship. More often, it just changes how I think about a problem I'll run into later. Either outcome is fine with me.

I also spend a fair amount of time reading about things that have nothing to do with software directly: business, psychology, economics, systems thinking. Most of my better ideas don't come from going deeper into one field. They come from noticing that two unrelated fields are describing the same underlying pattern, and asking what that pattern implies for the problem in front of me.

Day to day, the work spans a few connected areas. I build AI-powered workflows and automation systems that remove repetitive work from a business, not just chatbots bolted onto a website. I build modern web applications, usually with Next.js, React, and PostgreSQL, when a business genuinely needs custom software rather than an off-the-shelf tool. I do technical SEO work: the kind that involves reading server logs and fixing indexing issues, not writing keyword-stuffed articles. And increasingly, I work on backend systems and internal tools that a business uses to run itself, where nobody outside the company will ever see the interface, but everyone feels it when it's built well.

The common thread isn't a technology. It's the question underneath all of it: what does this business actually need, and what's the smallest, most reliable way to build it?

Without turning this into a portfolio page, it's worth being specific about the kinds of things I actually build, because "developer" covers a lot of ground.

I've built AI automation systems that handle work a team used to do manually. SEO infrastructure that makes a site legible to both search engines and, increasingly, AI systems trying to understand what a page is actually about. Full Next.js applications, from database schema to the interface a client's customers use every day. Internal tools that exist purely to make someone else's job less repetitive. Content and admin systems built for a specific business rather than adapted from a generic template. And a fair amount of unglamorous infrastructure work: cloud setup, deployment pipelines, developer tooling, the kind of thing that makes everything else possible.

None of this is exotic. Most of it is the kind of work that doesn't show up in a highlight reel, because it's the work that quietly keeps a business running.

A lot of it happens quietly, in the background of someone else's business. I'm usually not the person a client's customers ever hear about. I'm the person who made sure a site loaded fast enough that they stayed, or built the internal tool that let a team stop copying numbers between spreadsheets by hand.

A few things tend to be true about how I approach a project.

If a workflow change solves a problem better than writing new code would, I won't write the code. If a piece of existing software already solves the problem well, I won't reinvent it just because building my own version would be more interesting. Code is a tool, not the objective, and I try to remember that even when the more technically impressive option is tempting.

Business outcomes come first. That sounds obvious written down, but it's surprisingly easy to lose sight of once you're deep inside a technical problem. I try to stay one level up: what is this actually for, and is the thing I'm building still the most direct path to it?

I'd also rather ship something simple that works than something clever that might. Cleverness is fun to write and expensive to maintain, and most businesses don't need clever. They need reliable.

None of this is a rulebook. It's closer to a filter I run every decision through, learned mostly by building the wrong thing first and figuring out why.

If I zoom out, the thing I'm actually building toward is bigger than any single project.

Most businesses are still treating AI as a content generator or a chatbot bolted onto an existing product, which badly undersells what's possible. I want to build products where AI is part of a business's actual infrastructure: making decisions, running workflows, catching problems, not just generating text. Software that helps a business think better, not just move faster.

That's a long-term direction, not a roadmap with a deadline. But it's the reason technical work still feels interesting to me after this many years of doing it. Every project I take on is, in some way, practice for that.