The questions
people actually ask.

It depends on scope, and we do not publish figures because a range wide enough to be honest would be useless to you. What we can say is what moves the number: how many user types there are, whether payments are involved, whether data has to migrate from an existing system, and how many other systems it must connect to. A scoping conversation gets you a real figure in a few days, and it is free.

Because the same request can differ by a factor of five depending on details that only emerge in conversation. Published ranges are either so wide they tell you nothing, or narrow enough to be misleading. We would rather spend twenty minutes understanding what you need and give you a number we will stand behind.

Both, and we recommend whichever fits rather than whichever suits us. Fixed price works when the scope can be defined — you carry no overrun risk. Time and materials suits ongoing work where priorities move, because re-scoping every change costs more than it protects. There is a full comparison of the two on the comparisons page.

Roughly a few weeks of work. Below that the overhead of starting properly — understanding your business, setting up access, doing a handover — takes a disproportionate share of the budget, and you would be better served by a freelancer. We will say so rather than take something we cannot do well.

A focused first version is usually three to four months from start to app store, including review. Something with payments, several user types or an existing system to connect to is more often five to eight. Store review itself is typically one to three days, but we plan for one rejection because it is routine rather than a failure.

A marketing site is three to six weeks. A web application — a portal, a dashboard, a booking system — is usually two to four months for a focused first version, and five to nine if it spans several departments with data to migrate.

Usually two to four weeks from agreeing scope. If you need something faster we will tell you honestly whether it is possible rather than agreeing and then explaining in week three. Occasionally we have capacity sooner and occasionally we do not — you will get the real answer.

You hear about it in the week it becomes likely, not at the deadline. Projects slip for ordinary reasons and what makes it damaging is finding out late. Because you see working software every two weeks, a slipping timeline is visible to you at the same time it is visible to us.

Karachi, Pakistan. We are one to two hours behind Doha and Muscat, so Gulf clients get a genuinely shared working day rather than overnight handoffs. For European clients there is solid overlap through your morning. For the Americas the overlap is thin, and we say so before you commit rather than after.

The people you meet. You speak to whoever will lead it before committing, and for dedicated developers you interview them and can say no. Being sold by a senior person and handed to someone you never met is common enough in this industry that it is worth asking every supplier directly.

Yes. Some studios route everything through an account manager, partly to control the message, and it slows things down while hiding problems. You get a project manager who owns coordination, and you can also speak to whoever is writing the code.

Daily in writing if you want it, a call weekly, and working software every two weeks — a link you can click and use, not a status report. If a fortnight passes without something you can try, something has gone wrong and you should say so.

Yes — source code, database design and documentation, assigned to you in the contract and in your repository from the first commit rather than handed over at the end. You can take it to another developer tomorrow without asking us. Worth checking with any supplier: some keep ownership of their internal libraries and licence them back, which quietly limits what you can do.

You keep everything and we help you leave. Documentation stays current throughout, code is already in your repository, accounts are already in your name, and we will do a handover call with whoever takes over. Being easy to leave is why clients stay.

Usually, and it is a large part of what we do. We start by reading the code and telling you plainly what state it is in. Occasionally the honest answer is that rebuilding costs less than maintaining, and we would rather say that than bill you monthly to prop up something unmaintainable.

Yes, routinely, and we are happy to sign yours rather than insisting on ours. If you need specific terms about data handling, sub-processors or where information is stored, raise them early — they are easier to accommodate before the infrastructure is designed.