Twenty-Four Years of Quality. The Technology Changed.
The Purpose Didn’t.
QASource was founded in Pleasanton in 2002 to give engineering leaders confidence in what they ship. We have done that through waterfall, agile, DevOps, cloud, and now AI-assisted development. What we validate has changed completely. Why it matters has not.
Where the Model Came From
QASource was founded in 2002 by Rajeev Rai, after a decade in engineering leadership at Apple, Informix (later IBM), and Macromedia (later Adobe). The company exists because of a problem he had to solve at Macromedia in 1999: the Bay Area had run out of engineers, and the team had to be built somewhere else.
What came out of that was not a cost-saving arrangement but a design. Quality engineering is the one function where a time-zone gap works in the client's favor—development works the US day and validation runs while the US sleeps, which in India is simply the working day, so work is verified before the team comes back in the morning—provided experienced leaders sit in the US inside the relationship, so nothing important depends on a handoff document. When the dot-com market collapsed, that organization was not cut. It grew to 125 people covering QA, development, and end-of-life for shipped products.
QASource's first client was a VP of Engineering who had started a company and needed a quality function he did not want to build. QASource built it and owned it outright—not people supplied, the outcome owned. Twenty-four years and more than 200 clients later, that is still the purchase, and it is still how the company grows: engineering leaders tell other engineering leaders and bring us with them when they change jobs.
The design has outlived every technology it was built on, and most of the people who first ran it are still here.
Five times the ground moved
Every One of These Forced Us to Give Something Up.
| Era | What changed in software | What we rebuilt, and what we gave up |
|---|---|---|
| 2002–2008 | Waterfall. Eighteen- to twenty-four-month releases, shipped on physical media. Quality meant enormous test plans executed once. | We built the owned-function model: QASource staffs and runs the client's quality organization outright, with US leadership embedded and validation running while the client's developers sleep. |
| 2008–2014 | Agile. Release intervals compressed from twenty-four months to eighteen, twelve, six, then three. | Test planning was rebuilt around iterations rather than milestones. The long-form test plan, the artifact the whole practice had been organized around, stopped being the unit of work. |
| 2012–2020 | Automation. What had been executed by people became code that ran unattended. | We built the automation practice that is now most of the company. The manual test labs and many of the roles inside them became redundant. That was the hardest of these to live through, and it was not painless for the people in it. |
| 2015–2022 | Continuous delivery and over-the-air updates. Weekly became daily, then hourly. Software reached customers without anyone pressing a button. | Validation moved out of a phase and into the pipeline, running on every change rather than on a release candidate. |
| 2022–now | AI-assisted development. Code volume up sharply, change arriving in larger and less predictable pieces, and tests written by the same model that wrote the code. | QASource Intelligent Platform (QASIP) generates and verifies test design against the changed surface. Selenium, which served us and our clients well for twenty years, is being retired in favor of Playwright. Tooling now goes obsolete before it has paid for itself — that is the defining cost of this era. |
The Part We Didn’t Expect
The automation era took the manual test labs away, and that was the right call for the software of its time. This era is asking for them back. Clients putting agents into production are requesting human validators by name—people to work through a workflow by hand and judge whether the system did the right thing, because no evaluation script can answer that.
We are able to say yes to that because we never stopped being a company of people. How human validation works →
How the Work Grows
About 40% of what QASource does today is development, release engineering, DevOps, and in some cases whole products. Not one of those engagements started that way. Every single client came to us for quality first and asked us to build only after we had been inside their engineering process long enough for them to know how we work.
We think that is the right order, and we don't intend to change it. Validation is where trust gets established, and it is the only honest basis on which to be handed a codebase. It also means that if you are wondering whether a QA partner can build software, the answer is that a large share of our clients reached that conclusion themselves, after watching us work.
AI Assurance is the exception, by design: we do not validate systems we built.
The page we wrote for champions who have to justify this internally →Leadership
Tenure at QASource. Most of this team has been here since before the first iPhone, and the company is built so that no single one of them is the reason it works.
Behind them: more than 100 people past ten years with the company, more than 50 past fifteen, and a senior engineering bench whose tenure is measured in decades rather than release cycles.
Where We Are
- Pleasanton, California — Headquarters, client engineering leadership, and the US leaders embedded in engagements
- Chandigarh and Bhubaneswar, India — The largest engineering organizations in two states, each able to carry out the other's work
- Aguascalientes, Mexico — A full engineering center of roughly 40 people for North American time-zone delivery
- Canada — A small presence
A Note From Our Founder
On the two decisions we got wrong, and the one rule that came out of them.
Two things we got wrong are worth putting on a website.
A client once asked us to build their engineering center at a price below what we charge. I said no. They built it themselves, and we lost the account. I still think about that one. I also still wouldn't cut the price. Paying less for the people who verify your software is a decision that surfaces later, in production, usually in front of a customer. We don't compete on price, and if that is the deciding factor, there are other firms.
More recently we agreed to build an agentic platform for a client. The specification was weak—their fault and ours—and scope kept moving. We delivered four months late, which in this market isn't late so much as irrelevant: the ground had shifted, and they could no longer sell it. They asked for their money back, and we returned it in full. I wasn't happy about it, and I don't believe they were either, refund or not. That engagement ended in 2026. The man who owns that company owns several others, and his largest software business is still our client, with work that is growing. A company that has been doing this for twenty-four years has failures, and the ones worth telling are the ones it paid for.
One more, because it says how decisions get made here. For eighteen years we refused to run a night shift. I didn't believe a good engineer should arrange their life around someone else's clock. After COVID, our own people asked for it—many of them women who found that four hours in the morning and four at night fit their families better than a fixed day. So we run it now, because they wanted it, not because a client demanded it.
What comes next is simple. QASource exists to reduce risk—to a company's reputation, to its quality, to its revenue—and to give engineering leaders confidence in what they ship. We are a QA company first, and we will stay one. More software is going to be written, faster, and more of it by machines; more decisions are going to be made by systems nobody can fully inspect. Every one of those organizations will need somebody independent who can say, with evidence, that it works.
That is what this company is for. It was true before I wrote this, and it will be true long after whoever is running the place has stopped signing these.
Twenty-Four Years Is Only Useful If It Still Applies
Tell us what's going wrong and we'll tell you whether twenty-four years of this is relevant to your problem.