Questions

I'm an independent software engineer. I build web applications that work as well on a phone as on a laptop, and I take care of both halves: what your customers see, and the system running behind it.

I'm Persian, and I work from Iran. The clocks here don't change through the year, so the gap between us is the same whatever month it is: about three hours ahead of London, and eight or so ahead of New York.

The work is remote and I take clients wherever they are. Where I sit matters less than which hours you can reach me in, and that one has its own answer below.

Within a day, usually sooner. I read every inquiry myself, because there's nobody else here to read them.

Thirty minutes, and you do the talking for most of it: what the business does, what isn't working, and what you want instead.

Afterwards you get a written plan: what I'd build, in what order, what it would cost, and what I think could go wrong. It's free and it's yours to keep, including to take to another developer. If I'm not the right person for the job, that's the call where I say so.

How the work runs

Please do. There's a form at the end of every page on this site, and a paragraph about what you're trying to build is plenty to start with. Nobody should have to sit through a call to find out whether I'm the right person.

I read every message myself, and I'll tell you straight when it isn't a job for me.

Half an hour on a call, and straight answers in it. You don't need a specification, wireframes, or a list of features written before we talk.

For larger work you'll also need to be reachable for a short call each week. Nothing else is needed up front.

It depends on the size of what you're building. Every job here is built for one business, so anyone who gives you a number before hearing the problem is guessing at it.

What I can put a date on is the plan. You'll have it in writing within a week of the first call: what gets built, in what order, and how long each part takes. That's the point where the timeline stops being a guess.

There's always a contract, signed by both of us before any work starts. It sets out what's being built, what it costs, when it's paid, and what happens if either of us wants out.

You're hiring a person and not a company. I'm a freelancer, I work for myself, and the contract is between you and me directly with my name on it. That's worth knowing up front, and anyone willing to start without putting it in writing is doing you no favors.

Yes, and it's worth knowing what they are before you read them. The reviews on this site are from engineers I've worked alongside. They speak to how I work rather than to what it's like to hire me, so read them for that and nothing more.

The client work is in the case studies: the problem, what got built, and what changed because of it. And if you want to speak to somebody who has actually paid me, ask on the call and I'll put you in touch.

The case studies

No. A website has a fixed price and it's published, so you can read it without talking to me first. A web application is quoted as one number after the plan is written, because until somebody has worked out what it involves, any figure is a guess dressed up as a quote.

Either way you know the cost before you commit, instead of watching a meter run. It also means I carry the risk when something takes longer than I thought. That's the right way round: I'm the one who estimated it.

What it costs

The website price is on the site, so you can settle that question on your own in about ten seconds. For a web application the number comes with the written plan, and both the first call and that plan cost you nothing. You can read the figure and walk away.

If it's more than you want to spend, say so instead of going quiet. There's usually a smaller first version that solves the expensive half of the problem, and I'd rather build that than lose the work over the shape of a quote.

See the numbers

On a larger project a monthly arrangement is optional. It covers whatever we agree it covers, written down before it starts.

Web applications that work as well on a phone as on a laptop. I build both halves: what your customers see, and the system running behind it. There's no seam between them and nobody to coordinate with.

Where a client already has a designer or a front-end team, I take the half they can't do. That's usually the cheaper arrangement for them.

Both projects ran that way

Yes. A few pages that say who you are, what you sell and how to reach you is a real piece of work, and plenty of businesses need nothing more than that for a long time.

It's a smaller job than an application, so it's a smaller number and a shorter wait. Tell me what the business does and I'll say what it actually needs, including the times that's less than you came in expecting.

Often, and it usually costs you less. If you already have a designer or a front-end team, I take the part they can't do and leave the part they can.

What I won't do is join a team as an extra pair of hands with no say in how the thing gets built. That arrangement produces software nobody is responsible for.

Brand and logo design, apps written natively for iPhone and Android (I build web apps that work properly on a phone instead), and anything where the plan is to skip testing to hit a date. I'll say so on the first call, not three weeks in.

No. I build the software and that's the whole of it. No logo, no brand guidelines, no ad campaigns, no SEO. Those are full-time trades, and you're better off with someone who does them all day than with me doing them badly on the side.

If you already have people on that work, I'll build what they need me to build and stay out of their way.

All of it, from the first day. The code lives in your repository, it runs on your hosting account, and the domain stays registered to you. I work inside your accounts, so at the end there's nothing to pry loose and nothing of yours sitting in my name.

Yes, and it's the test I hold the work to. You own the accounts and the code, the setup runs from written instructions, and the tests say whether something is broken.

If handing it on would be painful, I've done the job badly, whatever else is true about the software.

Remotely, and with clients anywhere. I've worked this way for most of my career and I'm good at it.

I work from Iran, and a working day here reaches most of the world at one end or the other. My mornings land in the afternoon across Asia and Australia. My afternoons and evenings land in the working day across Europe and the Americas. Tell me where you are and I'll tell you exactly which hours you get, before you hire me rather than after.

Most people settle into a short call once a week plus email in between. If you'd rather have more or less than that, say so.

Fair question, and the answer worth anything isn't a promise from me. It's the setup.

I work inside your accounts from the first day, so the code, the hosting and the domain are already yours while the work is still going on. The setup runs from written instructions and the tests say what's broken. If I vanished tomorrow you'd hand the repository to another developer and they'd carry on. That's true in week one, not only at the end.

I don't plan on going anywhere. I'd just rather you didn't have to take my word for it.

Sometimes an agency. If the job needs several disciplines at once, has a deadline you can't move, or is large enough that coordinating it is a job in itself, buy the coordination.

If it's one system that has to be right and stay right, the distance between you and the person building it is the thing worth protecting. I've written the comparison out in full, including the parts that don't favor me.

The full comparison

There's an agreed period where anything I built that turns out to be broken gets fixed at no extra cost. After that, some people want a monthly arrangement for changes and monitoring, and some take it in-house. The documentation exists so that second option is genuinely open to you. Both are fine, and neither is assumed.