How Rubatt started, and why it ended up building agents

Most company origin stories get tidied up afterwards. This one is worth telling straight, because the messy parts are the parts that explain what Rubatt builds today.

It started as a skill, not a company

I am Ahmed Tariq Khokhar, and before Rubatt was anything I was a developer in Gujranwala, Pakistan, learning by shipping. Websites first. Then the applications behind them. Then the systems behind those. There was no plan at that stage, only an appetite for problems slightly larger than the last one.

What changed was not my skill level. It was noticing that the same shape kept appearing behind very different briefs. A manufacturer with a genuinely good product could not reach a buyer two countries away. A small business could not afford the software that would have made it competitive with a larger one. A capable developer here had no route to the companies who needed that exact skill. None of those are technical problems. They are access problems, and software happens to be very good at closing them.

2020, and where the name comes from

Rubatt was founded in 2020. The name is taken from the first six letters of my family name, so it carries something of where I am from rather than the output of a branding session.

It also echoes the Arabic Rubāṭ, which describes a resting place for travellers and the bond between them. That meaning turned out to be the one I kept coming back to. A traveller stops somewhere to work out the road ahead, and then carries on. I wanted the company to be that for a business: the place where an idea becomes clear enough to build, and where somebody takes responsibility for the result rather than the task.

The original idea was never that we build websites. It was that we help a business move forward, and the website was just what that looked like that year.

Websites became applications, applications became systems

The work compounded in the ordinary way. Brochure sites turned into ecommerce. Ecommerce turned into custom applications. Applications turned into the business systems running underneath them: CRMs, ERPs, integrations, reporting, automation. Somewhere past a thousand projects, the company had stopped being a web shop and had not yet said so out loud.

Two decisions from that period still hold. The first is remote first, for a plain reason: the best person for a problem is rarely in the same city as the problem. The second follows from it. A company serving clients in the US and UK can be run from Pakistan, and there is no contradiction in that worth apologising for.

Why AI, and why this particular kind of AI

My own work moved into AI over the last few years: LLM systems, autonomous agents, voice interfaces, retrieval, and the automation you can build once those pieces are reliable. That move was not chasing a trend. It came from having spent years inside other people’s operations and knowing precisely which parts were expensive, repetitive and still being done by a person who resented it.

But the same experience produced a warning, and the warning is the reason Rubatt builds what it builds.

Software that only reads is safe to get wrong. You notice, you correct it, nothing is lost. Software that writes is a different category. An agent with write access to a ledger, a CRM or a fulfilment system can do damage that nobody notices for weeks, and by then the damage has been reconciled into everything downstream. The model does not have to be bad for this to happen. It only has to be confident and slightly wrong, which is its most common failure mode.

The error rate is not really the number that matters. What matters is what an error costs you, and that is a design decision rather than a model property.

So every agent we ship stops at the write path and asks. The gate shows the concrete change, the record, the field, the before and after, and the evidence behind it. A person approves or declines in seconds. Being wrong costs a declined suggestion instead of a bad record, and that single property is what makes a team willing to let a system near their systems at all.

Who does the work now

Rubatt is not one developer any more. There is a proper bench: engineers, designers, data and AI specialists, and people who understand operations well enough to argue with a specification before anybody writes code. That last group prevents more failures than any amount of testing.

We also run agents on our own work, for the parts that genuinely deserve a machine. Research sweeps. First pass migrations. Test generation. The repetitive middle of a build. They are held to exactly the rule we sell to clients, which is that anything irreversible waits for a person.

• People for the judgement calls, the scoping and the arguments
• Agents for the volume work where a mistake is cheap and visible
• A gate wherever the two meet something irreversible

The point is not headcount, and it is not automation for its own sake. It is getting the right mix onto a problem, so the work is fast where speed is free and deliberately slow where care is cheaper than a correction.

What it adds up to

Six hundred or so clients and more than fifteen hundred projects since 2020, and the thing I would point at is not the count. It is that the company was built by someone who did the work, which means we know which promises are safe to make and which ones quietly depend on nothing going wrong.

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. This one started the second way, and the story is still being written.