I build complete products, on my own: the part your customers use, the system behind it, and everything needed to keep it running. Here is the kind of work I take, how it runs, and how to start.
Available for new projects
01
You have a business idea, or a process you run by hand, and nothing built yet.
02
A developer or agency started it and left. It is not finished, or not right.
03
It was fine at a hundred customers and it is struggling at ten thousand.
04
It still runs the business, nobody knows how, and everyone is afraid to touch it.
You should know how this goes before you commit to it. Nothing here only shows up after the contract is signed.
Thirty minutes on a call to understand the business and the problem. You get back a written plan: what I would build, in what order, what it costs, and what I think could go wrong.
The plan is yours to keep whether or not you hire me. If you take it to another developer, that is a perfectly good outcome and it costs you nothing.
You see the real thing every week, in a browser, not a screenshot. No month-long silence ending in a reveal.
Everything written down, a walkthrough with whoever will be looking after it, and a system that runs without me. The handover is part of the job, not an afterthought.
An agreed period where defects in what I built are fixed at no extra cost. That is what standing behind the work means.
Money and time first, then the ones about risk. If what you need to know is not here, it is a fair thing to open with.
The cheapest way in is Zero to One: a fixed website for $1,500, plus $50 a month to keep it running. For a lot of businesses that is the whole answer.
Anything past that — payments, ordering, booking, a system built around how your business actually runs — is a fixed price for a defined project, or a monthly arrangement for ongoing work. Either way the number is quoted once the plan is written, so it reflects the real work rather than an hourly guess, and you have it before you commit to anything.
Most projects run two to six weeks from the plan being agreed to something your customers can use. Bigger builds go longer, and I will say so in the plan rather than discover it halfway through.
That is the normal case, and it is what the first call is for. You do not need a specification written. You need to be able to describe what is wrong today and what you want to be true instead — working out what that means in software is part of the job, not a prerequisite for starting it.
I am one person, so let me answer that properly rather than wave it away. There is no second developer waiting in the wings.
What there is: you own every account and every line of code from day one, and I write things down as I go — a setup another developer can run, tests that say whether something is broken, and a walkthrough at handover. If I vanished tomorrow you would not be locked out of anything, and someone competent could carry on from what is written.
That is a smaller risk than being unable to reach the agency holding your source code. It is not zero, and you should hear that from me rather than find it out later.
I can confidently say that Hesam is one of the most disciplined person I have ever had the opportunity to work with. His leadership skills are excellent and he always ensures that his team is performing at its best. His commitment to delivering high-quality results shows in every project he handles. If you're looking for a Back-end development role, I highly recommend Hesam who makes a positive impact on any team he joins.
I had the privilege of working alongside Hesam from my very first day as an intern, and I can confidently say he played a pivotal role in shaping my growth as a developer. As a backend developer, Hesam combines deep technical expertise with a rare quality—genuine patience in mentoring others. What sets Hesam apart isn't just his technical skill; it's his willingness to stop what he's doing to explain a concept, debug an issue together, or share the why behind a decision—not just the how. Many of the habits and best practices I rely on today were shaped by his guidance. Beyond his technical abilities, Hesam is the kind of teammate every engineering team needs: reliable, collaborative, and genuinely invested in the success of those around him. Any team would be lucky to have him.
That is enough for me to tell you whether this is a week of work or a quarter, and whether I am the right person for it.