The questions you
should be asking.

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

You do, in your company's name, with us added as users. That applies to your cloud account, your Apple and Google developer accounts, your domain and your analytics. We have inherited situations where an agency held the client's app store account, which effectively held the app hostage — you could not publish an update without them. Access should be revocable by you, immediately, without our cooperation.

You keep everything and we help you leave. Documentation stays current throughout rather than being written in the final week, code is already in your repository, and access is already in your name. We will do a handover call with whoever takes over. A relationship you stay in because leaving is painful is not one we want — and practically, being easy to leave is why clients stay.

Wherever you need it to be. For Gulf clients that is usually a Middle East region; for European clients, the EU. We will tell you plainly where anything sits, including backups, and we do not move data between regions without asking. If you have a specific residency requirement, raise it before we design the infrastructure rather than after — it is straightforward upfront and expensive to retrofit.

Only where the work genuinely requires it, and with the narrowest permissions that allow it. Most development happens against test data. Where production access is needed for a migration or an incident, it is time-limited and logged. If your policies require that no offshore team touches production, that is workable — we will design around it and tell you what it costs in response time.

No, and it is written into our agreements. We use AI tooling in our own work, and where a tool would send your code to a third party we either disable that or use a configuration that excludes it from training. If you want a specific prohibition in the contract, say so and we will include it — that is a reasonable thing to ask for.

We tell you, quickly, including when the cause is our mistake. There is a written process for what gets communicated and when. What we will not do is quietly fix something and describe it as routine maintenance — that is how a fixable problem becomes an unrecoverable one. If your contract requires notification within a set period, we will agree that in writing.

Yes. brainiac/studio has been operating since 2016, founded by Naveed Nazeer, who has worked in technology since 2005 and was CTO of Kuickpay for six years and eHissab for four and a half. The team is eighteen people: twelve-plus developers, two designers, two project managers and two marketing strategists, in one office in Karachi. We are not a marketplace of freelancers assembled per project.

The people you meet. You will speak to whoever is leading your project before committing, and for dedicated developers you interview them and can say no. What does not happen is being sold by a senior person and then handed to someone you never met — that practice is common enough in this industry that it is worth asking every supplier about directly.

We are in Karachi, 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 will say so before you commit rather than after — it is a real constraint and it affects how a project feels day to day.

We are a small studio, so we are the wrong choice for work needing dozens of people at once or a twenty-four-hour follow-the-sun team. We do not do hardware, embedded systems or game development. We are not auditors, so we prepare companies for SOC 2 rather than certifying them. And we will not take a project we think should not be built — that has cost us work and we would still rather say it.