Everything people ask, answered properly.

You do, on final payment, in writing. The repository, the hosting accounts, the credentials and the documentation all transfer to you. We keep no licence, no lock and no dependency on us.

If you later want to work with a different developer, nothing about that is our decision or our permission to give.

You do, in your own name, from day one. We will set it up for you and point it where it needs to go, but the registration is yours.

We are firm about this because a developer who holds your domain holds leverage over you, and we have seen how that conversation goes when a relationship ends badly.

The honest answer is documentation, not a promise. You get a written scope before the build, a handover and operations manual after it, runbooks for the things that go wrong, and a database and schema reference. Another developer should be able to pick that folder up and start working without a single meeting with us.

That it protects you from us is the point. Software you cannot move is not software you own.

Yes, and before you send us anything sensitive rather than after. Send yours, or ask and we will send ours.

We also will not use your project as a case study, name you as a client, or screenshot your system without asking you first in writing.

That is what Discovery is for, and we would rather you did. You get your process mapped properly, a written scope with every screen listed, and a fixed price for the build — and it is yours to keep even if you then hire somebody else.

If you do build with us, the fee comes off the price in full. It is the cheapest way to find out whether we are the right people without committing to a project.

Because a conversation that was never going to work costs us both the same week. Firms hide the number so they can work out what you can afford; we would rather you knew in thirty seconds whether we are in your range.

The ranges are real. See pricing.

Fixed price against a written scope, for anything we have scoped through Discovery. You know the number before work starts and it does not drift.

Changes after that point are possible and are quoted separately, so a new idea in week four is a decision you make with a price in front of you rather than a surprise at the end.

40% to start and 60% before go-live for most projects. Larger builds split 40 / 30 / 30 against milestones you can see rather than dates on a calendar.

Bank transfer, JazzCash, Easypaisa, or Wise for international clients. Monthly plans are billed in the first week of the month, in advance, and can be cancelled any month.

Say so and we will make the package smaller rather than the rate smaller — usually by starting with the part that is costing you most and adding the rest once it has paid for itself.

Cutting the rate would just mean cutting the care somewhere you cannot see, and you would find out which part eventually.

They might well do it for that, and sometimes the cheaper quote is the right call — particularly if what you need is genuinely small.

What we would check before deciding: is there a written scope, who owns the code, what happens after launch, and is there a named person who answers in six months. Those four answers usually explain the difference in the number.

Islamabad is UTC+5 — nine hours ahead of US Eastern, four ahead of London, one behind Dubai. Run badly that gap eats a week; run deliberately it means work happens while you sleep.

So: a written update daily, part of each day held against your working hours for calls, a fortnightly demo that is recorded if the time does not suit, and every decision confirmed in writing the same day.

A project manager who owns your delivery, from the first call to go-live. Not a salesperson who then hands you over, and not whichever developer happens to be free that week.

The engineers who start your project are the ones who finish it. Nobody inherits your codebase halfway through and learns it on your time.

Every two weeks, and working software rather than a progress report. Payment follows those milestones, which keeps both of us honest about whether progress is real.

Before go-live, your own staff try it on real orders. What they find gets fixed first — they know the exceptions we never will.

Yes. Extra capacity on an existing team, a specific piece nobody in-house has time for, or taking over a system somebody else built and left.

For that last one we will usually want a short paid review first, so we can tell you honestly whether it should be extended or replaced before you commit to either.

Business systems first — orders, stock, invoicing, dealer ledgers, dispatch, reporting. Then everything around them: web applications and sites, mobile apps for iOS and Android, Windows desktop software, databases, cloud and deployment, documentation, and search.

All nine are written out at length on services.

.NET and ASP.NET Core, PHP and Laravel, Angular and TypeScript, SQL Server, MySQL, PostgreSQL and SQLite, Azure and Cloudflare.

We pick for maintainability over novelty. You should not have to pay somebody later just to understand what we chose.

Yes, and without asking us first. A full order and inventory system is open with no sign-in — change an order, watch the stock ledger move, then try to make it do something wrong. A live recruitment platform is public at kafeelmgt.com.

Everything open, plus the systems that sit behind client logins, is on work.

It is built against a mid-range Android on mobile data first, because that is where most of your visitors and most of your field staff actually are — not on a developer's laptop.

There are phone captures of every live thing we have built on the work page, so you can judge rather than take our word for it.

We will not build on spec, learn a skill at your expense, hold your domain or accounts, cut the rate to win a job, or promise you an SEO ranking nobody can guarantee.

And we will not put a photograph of somebody who does not work here on this website. The full list is on about, and it tells you more than the list of what we do.

Three months after go-live, included. After that a monthly agreement if you want one — and it is never compulsory and can be cancelled any month.

We would rather keep it because it earns its place than because you are tied to it.

You have a named contact and a documented path, and monitoring usually tells us before you do. The question of who finds out and what they do is decided at the start of the project, not after the first outage.

Backups are automated and restores are tested. A backup nobody has ever restored is not a backup.

For content, yes — sites come with a CMS from the Business tier up, and staff training is part of handover.

For the system itself, changes are development work, but the documentation means that work can be done by us or by anybody else you choose.

Often, yes. We will want a short paid review first to see what is actually there, and then we will tell you honestly whether it is worth extending or whether you would spend less replacing it.

Sometimes the answer is that it is fine and you do not need us. We would rather say that than bill for a rewrite you did not need.