One laptop in Gujranwala, and a question that did not go away
Rubatt did not start with an office, an investor or a plan. It started with one developer in Gujranwala, Pakistan, a laptop and a question about why good technology was so hard for ordinary businesses to reach.
How the company actually came about
Before the company, there was the work
Ahmed Tariq Khokhar learned to build by building. Websites first, then applications, then the systems underneath them, taught by real projects and real clients rather than by a curriculum. Along the way the code stopped being the interesting part.
What held his attention was the gap. A manufacturer with a good product could not reach a buyer in another country. A small business could not afford the software that would have made it competitive. A capable developer in Pakistan had no route to the companies who needed exactly that skill. None of those were technical problems. They were access problems, and technology was the thing that closed them.
2020, and a name that came from home
Rubatt was founded in 2020. The name is taken from the first six letters of Ahmed’s family name, so it carries his own roots rather than a branding exercise. It also echoes the Arabic Rubāṭ, a resting place for travellers, and the idea of a bond between them.
That second meaning turned out to be the useful one. A traveller stops somewhere to work out the road ahead and then keeps going. Rubatt was meant to be that for a business: the place where an idea gets clear enough to build, and where somebody takes responsibility for the outcome rather than the task.
Websites became applications, applications became systems
The work compounded. Brochure sites turned into ecommerce, ecommerce into custom applications, applications into the business systems that run behind them: CRMs, ERPs, integrations, dashboards, automation. Over 1,500 projects and more than 600 clients later, the company had stopped being a web shop and had not yet said so out loud.
Rubatt has been remote first from early on, for a plain reason. The best person for a problem is rarely in the same city as the problem. That belief is also why a company serving the US and UK is run from Pakistan and sees no contradiction in it.
Why AI, and why this particular kind
Ahmed now works primarily in AI: LLM systems, autonomous agents, voice interfaces, retrieval and the automation built on top of them. The move was not a pivot towards a trend. It came from having spent years inside other people’s operations and knowing exactly which parts of them were expensive, repetitive and still human.
It also came with a warning. Software that only reads is safe to get wrong. Software that writes is not, and an agent with write access to a ledger or a CRM can do damage nobody notices for weeks. That single observation is why every agent Rubatt ships stops at the write path and asks. Not because the models are weak, but because being wrong should cost a declined suggestion rather than a bad record.
Since 2020
The route from websites to agents
- Before 2020
Learning by delivering
Ahmed builds sites, freelances and works directly with businesses. The pattern behind every brief starts to look like the same problem.
- 2020
Rubatt is founded
One developer, one laptop, one premise: quality technology should not be a luxury reserved for companies that can already afford it.
- 2021 to 2022
Beyond websites
Custom applications, ecommerce and digital products. The team grows remote first, hired for skill rather than postcode.
- 2023 to 2024
Systems, not pages
CRM and ERP work, integrations and automation. The questions clients ask move from how it looks to how it runs.
- 2025 to 2026
Agents that ask first
The practice narrows to autonomous systems for operations, sales, research and support, built with the write path gated by default.
“I started Rubatt with a laptop and a belief that technology should be reachable. The company grew out of my own work, not out of a business plan, and that is still the difference. We have been the people behind the keyboard, so we know which promises are safe to make.”
How the work actually gets done now
Rubatt is not one developer any more. There is a bench for it now: engineers, designers, data and AI specialists, and people who understand the operational side of a business well enough to argue with a specification before anybody writes code.
We also run agents on our own work, for the parts that deserve a machine: research sweeps, first pass migrations, test generation, the repetitive middle of a build. They are held to the rule we sell, which is that anything irreversible waits for a person. The point is not headcount and it is not automation for its own sake. It is getting the right mix on a problem so the work is fast where speed is free and slow where care is cheaper than a correction.
The agent practice today
What we believe, and why it shapes the code
The write path is the whole problem
Reading is not where agent projects fail. Writing is. Almost every design decision we make follows from taking that seriously, which is why our systems are boring in exactly the places that matter.
Scoping honestly beats building fast
Most failed agent projects failed before any code was written, in a specification that described the process as somebody imagined it rather than as it runs. We would rather spend two weeks finding that out than three months discovering it.
You should own what you paid for
Source, prompts, evals and infrastructure config, in your accounts, from the first commit. We do not operate a runtime you rent, and nothing we build for you becomes a component of somebody else’s system.
An agent that admits uncertainty is worth more
Calibrated uncertainty is more useful than confident coverage. We tune for the system saying it does not know, because that is the behaviour that makes the rest of its output trustworthy.
Engagement models
Three ways to start. The last row is the one most people are really asking about.
| Attribute | Discovery sprintScope one workflow, prove it can be agentic. | Build engagementShip the system into production. | Managed agentsWe run and improve it while you use it. |
|---|---|---|---|
| Best for | Teams with a workflow in mind and no certainty it is automatable | A validated workflow that needs to exist in production | A shipped system that needs to keep working as your tools change |
| Duration | 2 weeks | 6 to 12 weeks, scoped per workflow | Monthly, cancel with 30 days notice |
| What you get | A working prototype in demo mode, an integration map, and a build estimate | The production system, connectors, approval gates, and a runbook your team owns | Monitoring, model and prompt tuning, connector maintenance, and new capabilities as you need them |
| Approval gates | On every write path | On every write path | On every write path |
| Runs without live API keys | Yes, that is the whole point | Yes, demo mode ships alongside production | Yes, retained for staging and demos |
| What you own at the end | The prototype, the code, and the integration map. Yours whether or not you continue. | Everything. Source, prompts, evals, infrastructure config, in your repositories and your accounts. | Everything, continuously. Stopping the retainer stops our work, not your system. |
If you would rather see the mechanism than read about it, the approval gates page explains the part that makes everything else safe.
Great technology can start anywhere. It can start in a technology capital with funding behind it, or in a quiet room in Gujranwala with one developer and a laptop. Rubatt started the second way, and the story is still being written.
The longer version of this story is in how Rubatt started.
Tell us what you are trying to automate
Including the part you think will not work. That is usually the interesting bit.