It does not need technical language. It needs the facts only you know about your business.

What to put in one page

• The problem: what is slow, expensive or impossible today, in two or three sentences.
• The users: who will use it (customers, staff, managers, drivers) and roughly how many of each.
• The must-have jobs: the three to five things the first version must do. Everything else is a wish list.
• What exists already: current software, spreadsheets, payment providers, anything the new system must connect to.
• Where it runs: website, phone app, both, or an internal tool on office computers.
• Deadline and why: a launch event, a season, a contract date.
• Budget range: even a rough range lets a studio propose the right size of first version.

Must-haves versus the wish list

The most useful thing a brief can do is separate what the first version needs from what would be nice later. A focused first version launches sooner, gets real feedback, and makes the second version better informed.

Why a budget range helps you

What a range lets a studio do

Sharing a range can feel like giving away a negotiating position. In practice it lets a studio tell you honestly what fits: the full idea, a smaller first version, or a different approach such as an existing platform with a few custom parts. Without it, every quote is a guess at what you meant.

What a good studio should send back

• Questions: a good reply asks about the parts you left unclear rather than guessing.
• A written scope: what is included, what is not, and what counts as a change.
• Stages with something you can see and use at each one.
• What happens after launch: fixes, hosting, ownership of code and accounts.

A brief does not need to be long. It needs to be specific about the few things only you know.

Frequently asked questions

Should we include designs or sketches?

If you have them, yes. Even photos of hand-drawn screens or screenshots of apps you like help a lot. They are not required.

Do we need to sign an NDA first?

For most ideas a short description is enough to get a first estimate. If the details are sensitive, ask for an NDA before sharing them; any serious studio will sign one.

Fixed price or hourly?

Fixed price per stage works well when the scope is clear. Hourly suits ongoing work and projects that will change a lot as you learn. Many projects use fixed stages first, then a monthly plan.

How quickly will we get a quote?

For a clear one-page brief, usually within a few working days, often after one short call to clear up open questions.

Start with the Monday questions

Before any chart, we ask each person who will use the dashboard what they need to know each week and what they do with the answer.

• Sales manager: are we ahead or behind target this month, and which branch is pulling us down?
• Store manager: which items will run out before the next delivery?
• Finance: which customers owe the most, and for how long?
• Owner: is this month better than the same month last year?

One screen, top to bottom

• Top: three to five headline numbers, each compared with target or last period.
• Middle: one or two trends that explain the headline numbers.
• Bottom: a short list of things that need action, such as overdue accounts or items running out.
• Everything else goes on a second page or in a filter, not on the first screen.

Trust comes before design

Agree the definitions

The fastest way to kill a dashboard is one wrong number. If the sales figure does not match what accounts reported, nobody will open it again. Before building visuals, we agree definitions in writing and reconcile the numbers with the team.

Small details that matter

• Show when the data was last refreshed, on the page itself.
• Use the currency and number format people use: lakh and crore in Pakistan, not millions.
• Make it readable on a phone, because many managers check it there first.
• Send a short weekly summary by email or WhatsApp with a link, so the dashboard comes to them.

A dashboard is finished when it answers a question someone asks every week, not when every column has a chart.

Frequently asked questions

Power BI or a custom web dashboard?

Power BI is quick to build and familiar to finance teams, with licence costs per user. A web dashboard costs more to build but has no per-user licence and can include actions, such as approving or assigning, not just charts.

Our data is in Excel files. Is that a problem?

Not at the start. Many dashboards begin from a shared folder of spreadsheets. Once the reports prove useful, moving the data into a proper database makes them faster and more reliable.

How often should it refresh?

As often as the decisions it supports. Daily is enough for most sales and stock reports; live data is only worth it when someone acts within the hour.

Who should own the dashboard after launch?

Someone on your side who knows the business. We hand over definitions, data sources and a short guide so they can add filters and pages without us.

What works well now

• Understanding intent: modern language models recognise what a Roman Urdu or Urdu message is asking for, even with mixed English words.
• Replying in the customer's language: the same assistant can answer in English, Urdu or Roman Urdu depending on how the customer wrote.
• Sorting messages: complaints, order questions, price questions and sales leads can be separated reliably.
• Summaries: a long Roman Urdu voice-note transcript or chat can be summarised in English for the team.

Where the gaps are

• Spelling: Roman Urdu has no standard spelling. "Kab", "kb" and "kub" all mean the same thing, which hurts simple keyword search.
• Urdu text in scanned documents: reading printed Urdu from images is still much weaker than reading English.
• Speech: transcription of Urdu voice notes is usable but makes more mistakes with names, places and fast speech.
• Smaller models: compact models that run on a modest server handle Roman Urdu less well than the large hosted ones.

Practical choices

Test with your own messages

Building the test set

The best test set is a few hundred real, anonymised messages from your own customers. They carry the spellings, slang and product names that general benchmarks never include. We measure on those before promising anything.

Customers will not switch to English for your software. The software has to meet them in the language they type.

Frequently asked questions

Can the bot reply in Urdu script?

Yes. It can reply in Urdu script, Roman Urdu or English, usually matching the way the customer wrote. Some businesses prefer always replying in one language, which is a simple setting.

Do we need to label thousands of messages?

Usually not anymore. Large language models understand intent with a short description and a few examples. Labelled messages are mainly needed to test accuracy.

What about Punjabi, Sindhi or Pashto?

Support is weaker and uneven. We test on real samples before relying on it, and keep a person in the loop for those conversations.

Can it understand voice notes in Urdu?

Yes, with a speech model that transcribes the voice note first. Accuracy is good for clear speech and weaker with noise, names and fast talking, so important details are checked.

Start with the shape of the data

• Tables: rows of customers, orders, transactions, sensor readings with named columns. Classic methods such as gradient-boosted trees are usually the strongest choice.
• Images and video: photos, scans, camera feeds. Deep learning, almost always, usually starting from a pretrained model.
• Audio: calls, voice notes, machine sounds. Deep learning, often a pretrained speech or audio model.
• Free text: emails, reviews, chat messages. Pretrained language models, sometimes with a small classic model on top.

Then look at labelled data

Deep networks learn a lot from a lot of examples. With a few hundred labelled rows, a classic model or a pretrained network with a small amount of fine-tuning will do better than training anything large from scratch.

Where it runs matters as much as accuracy

• A model behind a website can use a server GPU. A model inside a phone app has to be small and fast.
• A model reading every frame from ten cameras needs very different hardware from one scoring a hundred loan applications a day.
• Training once on a rented GPU is cheap. Running a large model all day, every day, is where the cost really sits.

Explainability is a feature

When someone has to act on it

When a credit officer or a doctor has to act on a prediction, being able to say why matters. Classic models show which inputs pushed a score up or down quite directly. Deep models can be explained too, but with more effort and less certainty. That alone can decide the choice.

Choose the simplest model that meets the target, on the hardware it will actually run on.

Frequently asked questions

Do we need our own GPU?

For training, usually not: GPUs can be rented by the hour. For running a vision or speech model all day, a GPU on site or a dedicated server is often cheaper than paying per request.

Can we train on our own data without sharing it?

Yes. Models can be fine-tuned and run entirely on your own hardware, so the data never leaves your network.

Is deep learning more accurate?

On images, sound and text, by a wide margin. On ordinary business tables, often not; gradient-boosted trees remain hard to beat there.

Can you start with one approach and switch later?

Yes. We often start with a quick classic model as a baseline and move to a deep model only where the data and the gain justify it.

Page weight is the first filter

Every second of loading loses shoppers. The usual causes are easy to find and fix.

• Images: product photos uploaded straight from a camera at several megabytes each. Resize and serve modern formats such as WebP at the size the screen needs.
• Apps and plugins: each one adds scripts to every page. Remove the ones nobody uses.
• Sliders and videos on the home page that load before the products do.
• Fonts: several families and weights where one or two would do.

Make checkout short and familiar

• Guest checkout. Forcing an account before the first order loses customers.
• Phone number first, with the address filled from the last order for returning customers.
• City as a list, not free text, so delivery charges and courier choice are correct.
• Show the full price, delivery included, before the last step.

Cash on delivery is a feature to manage

Cash on delivery is still how many customers prefer to pay, and refusing it loses sales. It also brings returns and fake orders. The answer is not to remove it, but to manage it.

After the order: tell them where it is

Updates without asking

Most "where is my order" messages disappear when customers get updates without asking: order confirmed, dispatched with the courier's tracking number, out for delivery. WhatsApp updates work better than email for most shoppers here.

Test the store on a cheap phone over mobile data. That is the store your customers see.

Frequently asked questions

Shopify, WooCommerce or a custom store?

Shopify is quickest to launch, WooCommerce gives more control on your own hosting, and a custom store makes sense when the business has rules neither handles well, such as complex pricing or tight links to an existing system.

Which payment options should we offer?

Cash on delivery plus at least one local online option such as a card gateway or a mobile wallet. Bank transfer with a screenshot works for small stores but needs manual checking.

How do we know if the store is fast enough?

Measure it on a real mid-range phone over mobile data, and with free tools such as PageSpeed Insights. We aim for the product page to be usable within a few seconds on that phone.

Should we build a mobile app as well?

Usually not at first. A fast mobile website covers most shoppers. An app makes sense later for repeat customers, push notifications and loyalty features.

Signs of a good first candidate

• It happens often: daily or many times a week.
• It follows rules someone can write down on one page.
• The inputs arrive in a predictable place: an inbox, a form, a spreadsheet, a WhatsApp number.
• A mistake is easy to spot and cheap to fix.
• The person doing it today would be glad to stop.

Copying order details from emails into a sheet, sending payment reminders, posting new leads to the sales group, creating a weekly report from three exports: these are the classic first wins.

Score the candidates

We list every repeated task the team mentions and score each one quickly. It takes an hour and usually makes the first choice obvious.

Where AI fits in

Plain workflow tools such as n8n handle the moving of data: watch an inbox, call an API, update a sheet, send a message. AI is useful at the messy edges: reading a free-text email, pulling fields from a PDF, transcribing a voice note, sorting a message into the right category.

• Keep the AI step small and checkable: "extract these five fields", not "handle this customer".
• Validate what it returns: dates are dates, amounts add up, required fields are present.
• Send anything that fails validation to a person with the original attached.

Keep a human in the loop at first

Approvals first

For the first few weeks, the automation prepares and a person approves. The draft reminder is written, the row is filled, the reply is suggested, and someone clicks send. Once the approvals are almost always "yes", that step can be removed for the routine cases.

An automation nobody trusts gets switched off. Earn trust with approvals first, then remove them.

Frequently asked questions

Do we need to buy a lot of software?

Usually not. A workflow tool, which can run on your own server, plus the accounts you already have (email, sheets, WhatsApp Business) cover most first automations.

What happens when something breaks?

Every workflow we build sends an alert when a step fails and keeps a log of each run, so a broken step is noticed the same day and can be re-run.

Can an AI agent do the whole job?

For narrow, well-defined jobs, increasingly yes. For anything involving money, promises to customers or judgement, we keep a person approving the important steps.

How long does a first automation take?

A simple workflow, such as emails to a sheet with an alert, is often a few days including testing. Steps that read documents or voice notes take longer because their output needs checking.

The goal is not a bot that can talk about anything. It is a bot that answers what the business has written down, does the actions it is allowed to do, and hands everything else to a person.

Answer from your documents, not from memory

The common pattern is called retrieval-augmented generation. In plain words: when a question comes in, the system first searches your own material (policies, price lists, product pages, FAQs) for the passages that match, and then asks the model to answer using only those passages.

• The bot can quote the policy page it used, so staff can check where an answer came from.
• Updating the bot means updating a document, not retraining a model.
• If the search finds nothing relevant, the bot knows it has no basis for an answer.

Let rules handle numbers

Prices, balances, stock levels and delivery dates should never come from a language model's guess. We fetch them from the real system and give them to the model as facts, or skip the model entirely for those answers.

Design the handover first

When to hand over

The handover to a person is not a failure path; it is a feature. A good one passes the whole conversation along, so the customer never repeats themselves, and it happens early, before the customer gets frustrated.

• Hand over when the search finds nothing, when the customer asks for a person, or when the topic is a complaint, a refund or a legal matter.
• Outside working hours, take the details and promise a callback rather than pretending to resolve it.
• Log every handover. The most common reasons show which documents to write next.

The best measure of a support bot is not how much it answers. It is how rarely it answers wrongly.

Test it like a customer would

Before launch we write a test list of real questions, including the awkward ones: misspellings, Roman Urdu, two questions in one message, questions about competitors, attempts to make the bot promise a discount. Every release is checked against that list.

Frequently asked questions

Can it run on WhatsApp?

Yes. The same assistant can answer on a website widget and on WhatsApp through the official business platform, with the same documents behind both.

Do our documents leave our control?

That depends on the model you choose. A hosted model receives the passages it needs for each answer; a self-hosted model keeps everything on your own server, at the cost of running it.

Will it ever make something up?

The risk can be reduced a lot, never to zero. That is why we limit it to your material, keep numbers in lookups, show sources, and review conversations regularly after launch.

How do we keep the answers up to date?

By keeping the documents up to date. When a policy or price list changes, the bot uses the new version on the next question; nothing has to be retrained.

Most of the effort in a camera project goes into the conditions the demo never showed. Planning for them early is cheaper than discovering them after installation.

Where models fail in the field

• Light: low sun straight into the lens, headlights at night, a shop window reflecting the street.
• Weather: rain on the lens, dust in summer, fog in winter mornings.
• Angle: a camera mounted high looks down on objects the model only saw from the front.
• Motion: fast vehicles or people blur at low shutter speeds, especially at night.
• Change: new uniforms, new packaging, a repainted wall, seasonal decorations.
• Hardware: compressed video streams, dropped frames, a camera that reboots at midnight.

Collect data from the real camera, early

The single most useful step is recording a week or two of footage from the actual camera position before training anything serious. Public datasets and stock images help a model learn what a car or a box looks like. Only your own footage teaches it what your gate looks like at dusk.

Picking the hard frames

From that footage we pick frames on purpose: the brightest, the darkest, the busiest, the rainiest. A few hundred carefully chosen frames of hard cases often help more than thousands of easy ones.

Fix it at the camera before the model

Some problems are cheaper to solve with hardware than with training data. Before adding more images, we look at the camera itself.

Design for the frames it will get wrong

No vision system is right on every frame. A good one knows when it is unsure and says so. Every prediction carries a confidence score; below a threshold, the frame goes to a person instead of straight into the record.

• Combine several frames: a number plate read the same way on five frames is more trustworthy than one read once.
• Keep a review queue for low-confidence results, and use what people correct as new training data.
• Track accuracy per hour and per camera, so a dirty lens shows up as a drop on one chart, not as a mystery.

A vision system that says "not sure" on one frame in fifty is more useful than one that is confidently wrong on the same frame.

Frequently asked questions

Can you use our existing CCTV cameras?

Often, yes. We first check resolution, frame rate and placement on recorded footage. Some tasks work on ordinary CCTV; small details such as text at a distance may need a better camera.

Does it need a GPU on site?

Not always. Small models run on a modest computer or an edge device for a few cameras. Many cameras, or heavier models, need a GPU on site or a server the video can reach.

How accurate will it be?

We only quote a number after testing on footage from your cameras, across day and night. Accuracy on someone else's dataset says little about your gate.

What happens when we add a new camera?

We record from it for a few days and check accuracy on that footage before switching it on. A new angle or lighting can need a small round of extra training.

That existing rule is the bar a model has to clear. Not zero, not a random guess: the thing people already do. We write it down and measure it before anyone trains anything.

What a baseline is

A baseline is the simplest prediction that makes sense for the problem. It costs nothing to build and it is easy to explain, which is exactly why it is useful.

• Forecasting sales: next week equals the same week last year, or the average of the last four weeks.
• Predicting churn: customers who have not ordered in 60 days will leave.
• Classifying support tickets: a list of keywords mapped to departments.
• Pricing: the median price of similar items listed this month.

Why it saves projects

Measuring the baseline first changes the conversation. Instead of "the model is 87 percent accurate", which means little on its own, the result becomes "the model cuts forecasting error from 22 percent to 14 percent compared with how you plan today". That is a number a manager can turn into money.

It also protects against a common failure: a model that looks impressive but only matches what a simple rule already does. When the gap is small, the honest recommendation is often to improve the rule, not to deploy a model that someone has to maintain.

Measure it the way it will be used

Testing it fairly

A baseline is only fair if both it and the model are tested the same way. The test must look like real use, or the numbers will flatter the model.

• Hold out time, not random rows: train on January to September, test on October to December. The future is what the model will face.
• Hold out whole customers or stores when the model will meet new ones.
• Use the measure the business cares about: money lost on stock-outs, not just average error.
• Look at the worst cases, not only the average. A forecast that is usually right but misses Eid completely is not usable.

When the honest answer is "keep the rule"

Sometimes the data simply does not hold enough signal, and no model beats the simple rule by a useful margin. That is a real result, not a failed project. It saves the business from maintaining a model that adds nothing, and it often points to the data that should be collected next.

A model is a cost. It has to earn its place against the rule it replaces.

Frequently asked questions

What if we do not have an existing rule?

Then we build the simplest sensible one together, usually in an afternoon, and measure it. It becomes the bar the model has to beat.

How much better does a model need to be?

Enough that the gain pays for building and maintaining it. For a forecast that drives ordering, a few points of error can be worth a lot; for a report nobody acts on, nothing is worth it.

Can the baseline and the model run side by side?

Yes, and that is how we prefer to launch. Both make predictions for a few weeks, and the team sees which one was closer before switching.

What data do you need to measure a baseline?

Usually the same history the model would learn from: past sales, past decisions, past outcomes. A year or two of records is enough for most forecasting and scoring problems.

None of this is a reason not to build. It is a reason to plan for the second year before signing for the first, so nobody is surprised when the first small change request arrives.

The four costs that start on launch day

• Hosting: the server or platform the app runs on, the database, file storage, backups and the domain. Small for most business apps, but it grows with users and stored files.
• Third-party services: email delivery, SMS codes, maps, payment gateways, error tracking. Each is cheap on its own; together they are a line on the monthly bill.
• Updates: frameworks, libraries and the operating system all release security fixes. Skipping them for a year turns a one-hour update into a week of work.
• Change requests: the field that should have been a dropdown, the report the accounts team now wants, the new branch that needs its own login. This is usually the biggest of the four, and the most useful.

A rough way to budget

Every app is different, so treat this as a rule of thumb rather than a price list. For a typical business application in steady use, plan a yearly running budget of roughly 15 to 25 percent of what the build cost. The lower end is an internal tool with a few dozen users and few changes; the upper end is a customer-facing app that the business keeps improving.

Decisions at build time that lower the bill later

Build-time choices

Running costs are mostly decided before launch. A few choices make the difference between an app that is cheap to keep and one that needs a rescue project after eighteen months.

• Fewer moving parts: one well-chosen framework and one database beat five services that each need their own updates.
• Automated tests on the parts that handle money, stock or permissions, so an update can be checked in minutes instead of by clicking through every screen.
• Settings instead of code: tax rates, branch names, email text and price lists that staff can change themselves never become a change request.
• Logs and error alerts from day one, so problems are found by the team before a customer reports them.
• Written handover notes: how to deploy, where the backups are, which accounts own which services.

The cheapest change request is the one staff can make themselves from a settings page.

Questions to ask before you sign

• Who owns the hosting accounts, the domain and the code once the project ends?
• What happens if a security update breaks something six months after launch?
• How long are fixes covered for free, and what does a change cost after that?
• Can we see the backups being restored, not just being taken?

Frequently asked questions

Can we just host it ourselves to save money?

Yes, if someone on your side is comfortable with servers, updates and backups. The hosting bill is rarely the expensive part; the time spent looking after it is.

Is a no-code tool cheaper to run?

Often, at the start. The trade-off comes later: per-user pricing grows with the team, and some processes simply do not fit the tool. It is a good choice for simple internal workflows.

Do you offer support after launch?

Yes. Every project includes a period of free fixes after launch, and after that we work either on a small monthly plan or per change, whichever suits how often the app changes.

Will we need a redesign in a few years?

Rarely a full one, if the app is kept current. Most apps change in small steps: a new report, a faster screen, a new branch. A rebuild is usually a sign the updates were skipped.