AIB Digital
How we work

You should never have to ask how it is going.

Most software goes wrong in the same way: the scope was a conversation, the price was a guess, and the client finds out it is late when it is already late. Every step below exists to remove one of those.

Every working day ● in your inbox

Daily written update

  • MovedWhat shipped since yesterday
  • BlockedWhat is stuck, and on whom
  • NeedWhat we need from you, if anything
Every two weeks

Demo of working software

Recorded if the hour does not suit you.

Milestones

Payment follows what you have seen

Not dates on a calendar.

The sequence

Seven steps, and you can stop after the first one.

Each step ends with something you can hold — a document, a price, a demo, a handover. If you stop after any of them, you keep what you have.

  1. ConversationFree You describe the symptom: something is slow, or manual, or a number nobody trusts. We ask what happens today, step by step, and who it happens to. If we are not the right people, we say so here rather than three weeks in.
  2. DiscoveryPaid, and credited back We map your actual process, screen by screen, and write it down. You get a document with the scope, the screens listed and a fixed price for the build. It is yours to keep even if you then hire somebody else, and if you build with us the fee comes off the price in full.
  3. Written scope and a fixed priceBefore anything is built Before anything is built you know what is included, what is not, what it costs and roughly when. Changes after this point are possible and are quoted separately — so the number cannot quietly drift.
  4. Build in milestonesEvery two weeks You see working software every two weeks, not a progress report. Your lead engineer runs that demo, tells you what moved and what did not, and payment follows the milestones rather than the calendar.
  5. Testing with your own staffYour own staff The people who will actually use it try it on real orders before it goes live. What they find gets fixed first. This step catches more than any amount of our own testing, because they know the exceptions we do not.
  6. Go live and handoverEverything transferred Data migrated, staff trained, documentation written, and the code and accounts transferred to you. You should be able to hand the folder to another developer and have them get to work without a single meeting with us.
  7. SupportThree months included Three months included. After that a monthly agreement if you want one, and it is never compulsory. A named person answers, in your working hours.

Working across time zones

Nine hours ahead, and that is an advantage if it is managed.

Islamabad is UTC+5. A morning in New York is an ordinary evening here, which means work can happen while you sleep — or a week can disappear into one unanswered email. The difference is entirely in how it is run.

  • Daily written updateWhat moved, what is blocked, what we need from you — so your morning starts with an answer rather than a question.
  • Overlap hoursWe hold part of the day open against your working hours for calls, not just messages.
  • One point of contactYour lead engineer. Not a rotating cast, not whichever developer is free.
  • Fortnightly demoRecorded if the time does not suit you, so you are never choosing between sleep and knowing where the project is.
  • Everything in writingDecisions made on a call are confirmed in writing the same day. Memory is not a project management tool.

Before you hand anyone your business data

The questions you should be asking us.

These come up in almost every first conversation, usually hesitantly. They are the right questions and you should ask them of any firm you talk to, including us.

Who owns the code?

You do, on final payment, in writing. Repository, accounts and credentials transfer to you. We keep no lock on your business.

Where does our data live?

Wherever you choose and we tell you exactly where before we start — your own hosting, your cloud account, or ours. It stays yours either way.

What about backups?

Automated, and restores are tested rather than assumed. A backup nobody has ever restored is not a backup.

Can staff see things they should not?

Roles and permissions are part of the design from the first screen, not added when somebody notices. And there is an audit trail of who changed what.

What happens when it breaks at 9pm?

You have a named contact and a documented path. Monitoring tells us before you do, more often than not.

What if you disappear?

This is the fair question and the honest answer is the documentation. Written scope, handover manual, runbooks, schema reference. Another developer can pick it up cold.

Start with the conversation. It costs nothing.

You will know within one call whether we are the right people for this, and so will we. If we are not, we will tell you who might be.