Caxy Innovation & Technology Culture

What is the unique story that you feel your company has with AI? 

Caxy’s story with AI starts where most others fall apart — the execution layer. We don’t build AI for AI’s sake. We came up with a plan for AI to free up cash flow. We work with companies that were never built to be tech-first and we make AI real for them. 

AI isn’t just possible — it’s profitable. The unique twist is that we rarely lead with the tech. We start by uncovering operational bottlenecks and asking, “What’s the decision here? What’s expensive if you get it wrong?” That lens helps us zero in on places where AI can thrive. We build tools that run quietly in the background, but radically improve speed, accuracy or experience. It’s AI, but without the theater.

What was a monumental moment for your team when it comes to your work with AI? 

Our internal motto: AI that ships is better than AI that waits. A turning point came when we helped a company stuck in “pilot mode” — the kind where there’s always another committee review, another data quality fix, another quarter gone. We reframed the problem: instead of trying to solve everything, what’s the $10,000 a day mistake you’re still making because this isn’t live? What’s the ticking time bomb that’s threatening to blow up the business? That conversation changed everything. We deployed a lean, focused solution that solved the real issue in weeks, not quarters. That moment reshaped our entire approach.

What challenges did your team overcome in AI adoption? 

The challenge wasn’t getting buy-in on AI — it was getting clarity on what AI should do. PwC found that 94 percent of executives believe AI is critical to future success. But only 14 percent have implemented it at scale. That’s a 5-to-1 gap. Most clients came in thinking they needed a model. What they really needed was a system. We had to teach teams how to think about AI not as a department but as a layer — one that touches data, ops, UX and strategy. Internally, we built lightweight templates for how to run AI discovery, validate assumptions with fast prototypes and bake in user feedback early. That made AI less intimidating and more repeatable.

How does innovation show up in your company culture?

I think one of the nice things about being a smaller company without as many regulations and slow processes is that we’re able to experiment a lot quicker. As an agency, we work on many different types of projects, which gives us a really good advantage, as we can try different approaches across different contexts. With AI in particular, we started by playing around with smaller concepts. But once we realized it could be pretty good for our developers and speed us up, we then started getting Microsoft Copilot for people and introducing them to how to use it. We did a lot of experiments on the side. 

Once we felt good with a baseline of how we work with it, we decided to try it on a new project fresh. Being able to test it on something new without legacy constraints was really helpful. We could see what worked without things going off the rails. We’re able to rein things in quickly and keep an eye on it from a higher level.

Mike LaVista, CEO: We encourage people to try things. If they go a little further than we expected, that’s actually good. We tested the edges and brought it back. Being a smaller company, we can catch things before they go too far. 

What’s one recent innovation that improved user or employee experience?

Sticking on the AI path: We definitely have developers here who were hesitant and skeptical about AI. On a recent client project, there was a lot of work done to set up Copilot to be really useful for particular things in the codebase.

By doing that setup work, it actually helped with the skepticism. Once you use it, and it finds something you didn’t think of or catches something in code review that you would have missed — something that’s kind of a bigger thing — you realize there’s definitely power to this. And it didn’t code everything for you; it just reviewed your work. Showing small glimpses of proof that it can be effective and powerful has been really good for getting the team bought in.

LaVista: Adding AI into the review process has been interesting. Having automated code reviews on everything has helped us catch more things. It’s also driven more communication on pull requests because often AI will recommend something that’s not necessary or is flat-out wrong. That requires you to think through it and respond. It’s created more conversation, not less.

How do you balance experimentation with stability?

This is a big one. For us, it’s about introducing innovation with a lot of guardrails. It’s “human plus” — we’re still doing all of our human checks. AI is essentially an additional check on top of what we already do with our process.

That way, we don’t just let it run and suddenly have big issues emerge. We introduce innovation in a way that isn’t totally disruptive. We run it alongside our existing process to understand where it fails and where it doesn’t. That’s where experiments have been helpful.

LaVista: I’d add another dimension: How do you balance experimentation with value? You could go down endless rabbit holes trying things. At a certain point, you have to make a judgment call: Is this experiment worth it?

We try to look ahead. If this worked at the end of the tunnel, would it be somewhere we wanted to be? If so, it’s worth pursuing. But sometimes you’re experimenting with something that doesn’t really have the biggest outcome. Knowing when to stop is as important as knowing when to start.

What’s your rule for fast, safe releases — and what KPI proves it works?

Our rule is a marriage of two beliefs.

The size of the release dictates the size of the safety net. A hotfix to one client’s staging branch doesn’t need the same gates as a coordinated multi-tenant production push and pretending otherwise is how teams either release slow or release scared. We size the review, the testing and the human eyes to the blast radius of what’s changing. That same principle governs where AI shows up — the bigger the surface area, the more humans in the loop.

Releases that sit are releases with risk. We want releases at least monthly and no work sitting stale more than six weeks. Stale code creates as much risk as rushed work. Two sides of the same coin.

The KPI that proves it: We look at the story of these two rules by pairing defect escape rate percent with cycle time. Either one alone lies. When velocity is high and escape rate is low, we know we’ve crushed it. We target an escape rate under five percent and a rolling cycle time of 30 days or less. Fast releases with bugs are just technical debt. Slow releases with clean output erodes competitive edge and product experience. Watching them together tells us if the system is actually working — or just feeling like it is.

Which standard or metric defines “quality” in your stack?

Our standard is that quality is a panel — never a single number. Any metric in isolation will lie to you and the team that manages to one number eventually games it without meaning to. We watch several together and the combination is what tells the truth.

The panel is production outages and issues per year, with a target under two. Test coverage on anything high-blast-radius. Escape rate to production. Cycle time under a month so features don’t go stale. And the ratio of bugs and regressions to new features — under 10 percent is good, under five percent is great.

There’s one more in the panel and it’s the one most people miss or misunderstand. It’s evidence your tests are actually finding failures. A 100 percent pass rate isn’t a win — it’s alarming. It usually means tests are exercising code without being written to catch anything — happy paths only, because happy paths are easier to confirm. That’s how blind spots get baked in. To combat this, you need all testing represented: integration, functional and load tests in a combination of automated and manual methods. The mix, balanced to the needs of the product, is what gives you the win.

Name one recent AI/automation that shipped and its impact on the team or business.

For Caxy, AI earns its value in our arsenal by proving itself on a real workflow first. Some recent examples do that well.

For a client, we built an AI proposal generator. Their sales pricing workbook goes in and a fully formatted Word proposal comes out — scope, language and tone pulled from a RAG knowledge base of their own historical proposals. They’re now sending 2-3 times the proposals per week with better consistency. More time in the field, bigger funnel, more sales.

Internally, we built an AI layer over our internal PM tool, PulseCheck. The AI helps forecast risk, suggests process improvements, drafts dynamic status updates, generates reports and surfaces channel sentiment to flag burnout weeks before it shows up in a client meeting. Team leads can act faster and leadership gets involved earlier — issues are anticipated and solved before they can surface.

On a smaller scale, we use AI across our SDLC for test writing, debugging, smaller feature dev, tech documentation, cherry-picking and initial code review against defined standards — all freeing the team for work that actually needs human judgment.

What new technologies or frameworks are helping your teams move faster and build smarter?

The biggest gains for us over the last few years have come from several different technologies. With Copilot in GitHub and in the integrated development environment across the team — the lift on test generation and refactor turnaround is meaningful and agentic coding sessions have made an impact in the speed of bringing prototypes and full features to production. A monorepo for projects gives us GitHub Actions pipelines handling CI/CD end-to-end and Zephyr paired with Playwright speeds up test writing and maintains our test repository; both connect back to Jira for consistency across teams. 

Serverless Lambdas have helped reduce the overhead for more costly workloads — which lets us stretch what we can accomplish. Where we need higher throughput, Kafka manages our event streams and akka clusters distribute actor systems that process them. 

Underneath this newer tech sits our more standardized stack — React/Next.js on the front end, GraphQL as the API, Node or Scala with the Play framework on the back. The right balance of all this lets a smaller team hit monthly release cadences that before would have required more muscle to make happen.

How do you balance experimentation with reliability in your development process?

Reliability is critical to our teams and so is experimentation. Balancing the two is what makes us successful, especially in regulated spaces like gaming and trading.

Experimentation is necessary on an agile team — process, tooling, tech, team structure, none of it’s off limits. We don’t try new things for their own sake; every experiment comes from our metrics, our clients or planning and retro conversations. Trying things on live projects gets better outcomes because we improve as we go, but it requires guardrails: defined success indicators, clear owners, code review, automated test coverage, reversible releases and transparency for buy-in and pivot control.

If an experiment isn’t causing harm but isn’t showing benefit, we tweak. If it’s not working or creates meaningful risk, we suspend it until we have better data. Failure is a risk, but so is rejecting experimentation and delivering the way we did five years ago — practically ancient in tech terms. The systems we build keep pace with our clients’ businesses and being willing to experiment intentionally has been the recipe for success.

What role does collaboration play in turning innovative ideas into products? 

Collaboration takes a good idea in a meeting and turns it into something live and actionable in production. For us, ideas can come from anyone on a project, but they only become a feature or product when the key voices have gotten together and confirmed all the reasons we’re wanting to build, the reasons we shouldn’t build, what we lose if we don’t and everything in between.

A strength at Caxy is respecting the core truth that the person who understands why something matters and the person who knows the viable path to building are rarely the same person; you need both in the conversation. In practice that means clients and stakeholders join working sessions with our product and technical teams, with clarity on who has final say and when to move on.

A tribal gaming and hospitality client we’ve had for years is one example. An overhaul to their player loyalty platform couldn’t be specified upfront; it took marketing and operations folks who knew player behavior, data teams to share the historical context and engineers who knew what the architecture could support. Collaboration keeps the product, team and client evolving together.