Why I am Building Lama
QA is the first thing teams cut when a deadline gets close. After watching it happen on project after project, I decided to build the tool I kept wishing existed.
Every product I have shipped, mine or a client's, hit the same moment. The deadline gets close, something slips, and the first thing to go is testing. Not because anyone decides testing does not matter. Because manual QA is slow and repetitive, and "we will test it properly after launch" is the easiest promise in software to make and the easiest to break.
That pattern is why I am building Lama.
The problem I kept seeing
At Outecho we build software for companies across mortgage, telecom, automotive, finance, and healthcare. Different industries, different stacks, same story every time. Three weeks before a release, the plan is detailed and the test cases are thorough. Three days before, half of them are getting skipped because there is no time, and everyone quietly agrees to catch the rest in production.
Then production arrives, the team moves on to the next thing, and the bugs that slipped through become support tickets. The cost of skipping QA never disappears. It just moves to a more expensive part of the calendar.
Why automated testing did not solve it
The obvious answer is test automation, and we have written plenty of it. But automated tests have a cost people underestimate: someone has to write them, and someone has to keep them alive.
UI changes and selectors break. A flow gets reworked and ten tests go red for reasons that have nothing to do with real bugs. For a small team, maintaining a test suite can eat more attention than the bugs it was supposed to catch. So the suite rots, people stop trusting it, and eventually they stop running it. A red build nobody believes is worse than no build at all.
Where AI actually helps, and where it does not
What changed my mind was realizing AI is good at exactly the parts that made test automation expensive. Understanding what a screen is for. Adapting when a button moves or a label changes. Generating coverage from a plain description instead of from brittle, hand-written scripts.
I want to be honest about the limits, because "AI" gets used as a magic word and it is not one. AI does not know what your product is supposed to do. It cannot tell you that a discount should never go below zero, or that this one form is the one regulators care about. That judgment is still yours, and it always will be. What AI can do is the grunt work around that judgment: exercising the flows, noticing when something that worked yesterday breaks today, and explaining what changed in language a human can act on.
That split, where humans own intent and AI owns the repetitive verification, is the whole idea behind Lama.
What Lama is
Lama is the tool I wanted to exist on every project where QA got cut. You describe what your product should do. It runs the tests, adapts when the interface shifts instead of falling over, and tells you in plain language what broke and where.
It is not trying to replace QA engineers. The best testers I have worked with are worth far more than any tool. The goal is narrower and more useful: make sure the boring eighty percent of testing happens automatically and reliably, so the people can spend their attention on the twenty percent that genuinely needs a brain.
What building it has taught me
A few things have become clear, some of which I did not expect:
- Build for the moment the work gets cut, not the moment it gets prioritized. Anyone will run tests when there is time. The tool only matters when there is not.
- Trust is the actual product. A testing tool that cries wolf gets switched off within a week. Being quiet and correct beats being thorough and noisy.
- Nobody wants AI. They want releases that do not break on a Friday afternoon. "AI-powered" is how it works, not why anyone would care.
Where it is going
Lama is in beta right now, and most of what I am doing is using it on real projects and closing the gap between what it should do and what it actually does. That last twenty percent is unglamorous, and it is exactly the part that decides whether a tool is real.
If your team ships software and testing is the thing that always slips, that is precisely who I am building this for. You can take a look at Lama.