Our Blog

At Kaizen, we don’t believe software quality is enforced by a checklist or a single gatekeeper. It’s something we build together, day in and day out, as a team.

We’ve been working on this platform for years. What started with two developers has grown into a 30+ person team building a large-scale logistics system. And like any growing team, we faced a big question:

How do you keep quality high without turning into a slow, over-regulated machine?

We chose trust over set in stone rules. And in doing so, we learned something simple but powerful: Our strongest safety net isn’t a process. It’s each other.

A Team That Catches Each Other

When systems get complex, legacy code, multiple teams, tight deadlines, it’s tempting to respond with more rules. But heavy oversight kills initiative. Instead of building a team that takes ownership, you get one that’s just trying not to mess up.

We took a different approach. We built a system where quality doesn’t rest on one person, it’s shared, distributed, and reinforced by the people around you.

Code review is just one part of that system, but it’s where this mindset comes to life.

​​Code Review as a Conversation

For us, code review isn’t about nitpicking, it’s a technical conversation between teammates.

When I open a PR, I’m not bracing for criticism. I’m inviting collaboration. Together, we’re asking: “Are we solving this clearly, cleanly, and in a way that makes life easier for the next person?”

Code reviews are done by other developers from the same sub-project. That means the person reviewing already has context, and because the reviewer role rotates, everyone gets to both give and receive feedback. It’s collaborative by design, and part of how we grow as a unit.

We review with a few key principles in mind:

• Clarity over cleverness: Can someone new understand this without a full-day walkthrough?
  
  
• Don’t reinvent the wheel: Are we duplicating logic that already exists? If so, we flag it and refactor.
  
  
• Performance with perspective: Are we making smart decisions, like reducing unnecessary database calls?

We refer to our internal Wiki often, not as a rulebook, but as a shared language.

Ownership Starts with One, Backed by All

One of our core beliefs:
“Ownership starts with the person who says it’s done, but quality is everyone’s job.”

We say it often: “The ownership falls mainly on the person who tests it and says it’s okay.”

It’s not about blame. It’s about trusting each dev to be accountable, knowing the team has their back. That shared responsibility creates a culture where people step up, not out of fear, but because they’re supported.

What Happens When Something Slips?

Let’s be honest: we’re human. Not every issue gets caught in review. But that doesn’t break our system, it proves why it works.

Because someone else will catch it later. And when they do, they won’t ignore it, they’ll flag it, fix it, and keep moving.

We log cleanup tasks in our tech debt backlog. It’s not a black hole, it’s a to-do list for continuous improvement. A way to keep tightening the net.

Reviews Are Where We Grow

In our team, code review it’s where learning happens.

New devs get real-time, contextual feedback. Seniors reflect on their habits. We share ideas, challenge each other, and improve as a unit. It’s ongoing, hands-on knowledge transfer, baked into the flow of work.

We don’t trust the code because it’s perfect. We trust it because of how it’s built:
by a team that shows up, collaborates, and looks out for each other.

In the End, It’s the Team

Our confidence doesn’t come from tools or top-down rules. It comes from people who care. People who ask questions, challenge decisions, and leave the codebase better than they found it.

The team is the system. The team is the process. The team is the safety net.
And when that’s in place, you can scale without fear.

"Stack Overflow on steroids." That’s the best way to describe it. But is AI the ultimate productivity hack, or just a faster way to create complex code? From parsing tricky regex in seconds to figuring out how much context to feed the bot, integrating these tools is a skill we are all learning in real-time.

I sat down (virtually) to discuss the art of prompt engineering and the nuances of relying on generated solutions. We dive into why using AI effectively isn't just about getting answers, it's about knowing how to ask the right questions to build better, sustainable software.

‍

*Note: This interview with Dan was conducted by Claude, an AI assistant. Yes, the irony of using AI to discuss using AI is not lost on us.*

Let's start with the basics: How would you describe AI as a development tool in one sentence?

"Stack Overflow on steroids" - honestly, that's what it is for me. It's like having that incredibly knowledgeable senior developer available 24/7, but you need to know how to talk to them.

So where does AI for developers shine day-to-day?

For quick, isolated problems, it's incredible. Need to parse a tricky regex? Convert between date formats? Understand an error message? Just ask. No context needed, instant answer. These small, specific queries are where AI shines brightest with minimal effort.

What are the downsides of using AI for coding?

The big challenge is context, especially for larger projects. That's where things get interesting - and harder.

Tell me about context. How did you initially approach giving context for bigger features?

My initial approach was exhausting. I'd dump everything into the prompt: "Here's my entire file structure, here's the relevant code, here's what I'm trying to do..." I'd spend 10 minutes crafting a prompt, constantly worried I'd forget some crucial detail. It worked, but it was draining.

So what changed? What's a better approach to prompt engineering?

A fellow developer showed me a completely different approach: let the AI build its own context through questions. Instead of front-loading everything, you start with something simple like "I need to add authentication to my Express app," and the AI asks what it needs to know - what auth strategy, existing middleware, whatever. The conversation naturally builds the needed context. You only provide what's actually relevant.

That's a smart approach. Has that solved the context problem for you?

Honestly? I'm still figuring it out. The truth is, I still struggle with prompt engineering. For larger features or refactors, I haven't found the perfect workflow. Sometimes the "let AI ask questions" approach works great. Other times, I need to provide upfront context. It really depends on the complexity and how well I can articulate what I need.

If prompt engineering is hard, why keep using AI?

Because it's not about getting complete solutions - it's about changing how I problem-solve. It's like having a knowledgeable pair programmer who's always available. The skill isn't in knowing everything anymore; it's in knowing what questions to ask and when to ask them.

What are you seeing around you? How are other developers using AI tools?

It's wild, honestly. I've seen colleagues build entire projects from scratch in just days, even hours. I've also seen someone migrate a whole Angular project to a newer technology without writing a single line of code themselves. It sounds amazing, right? 

But here's the catch - if you don't review what AI generates carefully, you can accumulate massive technical debt. The code works, sure, but it might not follow your team's patterns, might have hidden performance issues, or make architectural decisions that don't fit your specific needs. AI can move fast, but someone still needs to be the critical reviewer.

Final question - What's next for AI in development?

I'm still learning, we all are. The tools are evolving, and so is my approach to using them. But one thing's clear: understanding how to interact with AI is becoming as important as understanding the code itself. It's a skill we're all developing in real-time.

I’ve been on this project for years. I was here when "the team" was just two developers in a room, and I'm here now as part of a 30+ person force building a critical logistics platform for our client.

Most stories about scaling a dev team are war stories. They’re all about shipping fast, racking up technical debt, and eventually having to rewrite the whole thing from scratch. Ours is different. It’s about how a deliberate (some might say stubborn) commitment to code quality from day one helped us grow without burning ourselves later.

A Pact for Quality in a Sea of Legacy Code

When Kaizen joined this project, we weren't starting with a blank slate. We were tasked with merging and modernizing several legacy systems into one cohesive platform. The codebase had layers, each with its own quirks and logic. In that kind of environment, the “move fast and fix later” approach would’ve been a disaster.

We knew that if we wanted to build something scalable and sane to work with long-term, quality couldn’t be optional. It had to be baked in.

So from day one, we made it a rule: every single line of code gets reviewed. Whether it’s a new feature or a legacy refactor, it goes through a second pair of eyes.

We framed this to our client not as a slowdown, but as an investment. Spending an extra hour reviewing a PR, especially one touching old code, saves days (sometimes weeks) of tracking down weird bugs later. It was the only way to build a modern, maintainable codebase.

Fortunately, our client’s technical. They got it. And that trust? It became one of the most valuable things in our partnership. It gave us room to do things right, not just fast.

Making Code Reviews a Team’s Habit

We needed a process, a way to keep standards high, share knowledge, and catch issues early. So we built a structured code review system, grounded in Kaizen’s core principle: continuous improvement.

‍

This wasn’t about nitpicking or finger-pointing. It was about creating a feedback loop and turning every review into a learning opportunity.

Here’s what that looks like today:

• Dedicated Review Stage: When a dev finishes a story, it moves to “Code Review” in Jira. It’s not a nice-to-have, it’s a required step.
• Peer-Powered: Another dev from the same sub-project picks it up. They already have context and can give meaningful feedback. We use Azure DevOps to review, leave comments, and suggest changes.
• Beyond Just Bugs: We ask more than “does it run?” We ask:
  
  • Does it actually solve the problem the ticket described?
  • Is there a better, more efficient way to do this? (e.g., “Could these five DB calls be one?”
  • Does it follow our naming conventions and practices?
  • Is the code readable and maintainable for whoever works on it next?

Scaling the Blueprint

Going from 2 to 30 devs is one thing. Scaling a culture of quality across all of them? Way harder.

‍

Our code review process became the backbone of both onboarding and team growth.

• The Wiki = Our Shared Brain: Standards don’t work if they only live in someone’s head. We documented everything in an internal Wiki, from naming conventions to architecture decisions. Reviewers link to it often, turning corrections into coaching moments.
• Reviews as Mentorship: For new devs, their first code reviews are where the real onboarding happens. They get real feedback from teammates who know that part of the system inside and out. It’s how we share the team’s DNA. It's how we say, “This is how we do things here.”
• Same Rules for Everyone: Junior or senior, every dev’s code goes through the same review process. It keeps egos out of it and keeps the bar high across the board.

The Payoff: Growth Without the Chaos

Was this a quick win? No. It took time and buy-in. But the impact has been huge.

“I remember a case where we brought a function’s execution time down from 10 seconds to under three. The client was thrilled,” one of our devs shared. “That’s when it clicks. This isn’t just about ‘clean code’, it’s about delivering real value.”

‍

Some of the benefits we’ve seen:

• Reduced Rework: Catching logic errors in reviews cut down on production issues.
• More Trust: Our client saw the difference. They knew we weren’t just ticking boxes, we were building for the long haul. That made it easier for them to vouch for us internally and bring us more projects. 
• Better Knowledge Sharing: Juniors learned from seniors. Seniors got fresh eyes on their code. Everyone leveled up.
• Smooth Onboarding: With strong processes and a healthy codebase, bringing in new devs got easier. We could grow without sacrificing quality.

And yeah, we still have technical debt. We even have a “tech debt bucket” in Jira. But it’s not this ominous, growing monster anymore. It’s a manageable list. A conscious decision, not a side effect of bad habits.

Wrapping Up

Code reviews aren’t magic. They won’t solve everything. But done right, they can become the heartbeat of a team that cares about quality, about learning, and about building something that lasts.

That’s how we did it. That’s how we’re still doing it.

AI is evolving fast, and it's easy to get lost in the sea of online hype and conflicting advice. To help you cut through the noise and start building solid foundational knowledge, our Innovation Hub has curated a list of four essential books. Each one tackles a different but interconnected layer of the AI stack, offering the practical knowledge you need to stay ahead of the curve.

1. AI Engineering: Building Applications with Foundation Models By Chip Huyen

Get a complete guide to "AI Engineering," the new discipline of building powerful applications with readily available foundation models, and understand how it differs from traditional ML engineering.

This book teaches you how to:

• Understand the new AI stack and its key differences from traditional machine learning.
• Apply a complete framework for developing an AI application, from choosing the right models and datasets to efficient deployment.
• Use a wide range of model adaptation techniques, including prompt engineering, RAG, fine-tuning, and building agents.
• Implement different methods for evaluating open-ended models, including the modern "AI-as-a-judge" approach.
• Overcome common bottlenecks for latency and cost when serving foundation models in production.

2. Hands-On Large Language Models - By Jay Alammar

Jay Alammar moves past abstract theory and superficial prompts to teach you how to build modern, end-to-end AI applications. His famous visual style makes complex architectures and cutting-edge techniques easy to understand and implement.

This book teaches you how to:

• Understand the Transformer architecture that powers models like GPT.
• Build powerful semantic search systems that go beyond simple keyword matching, using methods like dense retrieval and rerankers.
• Use the full spectrum of generative models, from prompt engineering all the way to Retrieval-Augmented Generation (RAG).
• Train and optimize LLMs for your specific needs using techniques like fine-tuning and in-context learning.

3. AI Agents in Action - Micheal Lanham

This book takes you to the next level of AI development. It goes beyond simple chatbots to teach you how to build and orchestrate fully autonomous, production-ready AI agents. Micheal Lanham’s guide focuses on creating trustworthy systems capable of handling complex, real-world tasks like high-stakes negotiations.

This book teaches you how to:

• Create agents that can plan, collaborate, and self-improve using feedback loops.
• Implement robust knowledge management and memory systems for your agents.
• Orchestrate collaborative multi-agent systems using cutting-edge tools like AutoGen and CrewAI.
• Enhance your agents with multimodal capabilities, including speech and computer vision.

4. LLMs in Production - By Christopher Brousseau

Get a practical, example-rich guide that bridges the gap between a promising concept and a successful, scalable product, focusing squarely on the MLOps strategies needed for real-world deployment.

This book teaches you how to:

• Evaluate when to use a premade LLM versus building your own from scratch.
• Scale your MLOps platform to handle the unique demands of LLMs.
• Fine-tune, train, and deploy foundation models using advanced architectures like RLHF.

Keep Learning

The world of AI won't be slowing down. Getting grounded in the fundamentals is the best investment you can make in your career. We hope this list of AI books for developers gives you a clear starting point to take these concepts, experiment with them, and start creating

The Transportation Intermediaries Association (TIA) Technovations 2025 Conference in Phoenix, AZ, was a highly focused and valuable event. Held at the JW Marriott Phoenix Desert Ridge Resort & Spa, this gathering, while smaller and intimate with an estimate of 200 attendees, was a powerful showcase for the best of logistics technology.

The central theme was clear: Automation and AI are driving the industry forward, and the sheer volume of high-quality, off-the-shelf software available is impressive.

The Technovations Experience

The conference structure was engineered for engagement, primarily through product-focused interaction:

• Focused Showcases: The agenda featured multiple "Technovator Showcase" segments, where innovative software companies provided quick demos of their solutions.
• The Kiosk Ecosystem: The Kiosks, which served as the hub for the Networking Breakfast, Lunch, and Evening Reception, were populated exclusively by Software Product companies. This provided an ideal environment for meaningful, quick exchanges between vendors and attendees.
• Key Industry Insights: Panels stressed that technology evaluation should center on core business metrics: Differentiation, Revenue Increase, Scalability, and Protection.

The Unified Message: AI is the Cost of Entry

The consensus across the keynotes and educational sessions was clear: AI and automation are the cost of entry for survival and scaling.

• Automation vs. AI: A critical distinction was made: Automation is often a prerequisite for effective AI adoption. The goal isn't just to automate a task, but to use AI to smooth out high-volume, repetitive processes, like reformatting RFPs or triaging a sales team's worst 10 emails for managerial review, as highlighted by an attendee’s high-value use case.
• The AI Roadmap Dilemma: Many attendees and panelists are struggling with how to start an AI initiative. The advice was to abandon the idea of a massive, costly roadmap and instead focus on a small, measurable Proof of Concept (POC) that targets a specific pain point with clear KPIs. If you can’t measure the ROI, it’s not worth doing.
• A Word of Caution on Tech Adoption: Panelists stressed that technology failures are overwhelmingly due to the client specifically, their lack of preparation, poor data, or failure to commit to the change management process. They noted that implementing new tech can often feel like taking on a "second job" due to the integration and rollout time required.

The Customization Opportunity: Solving for the Unique

While the product ecosystem is robust, our conversations with leaders across the industry revealed a clear, unmet need:

• Top-tier TMS providers and logistics operators acknowledged that for many scaling $50M-$250M 3PLs, a standard product simply cannot address the 1-2 unique, complex operational processes that truly drive their differentiation and growth (e.g., highly specialized niches or proprietary client models).
• For these unique challenges, the best approach is often a tailored technology solution. This isn't about criticizing products; it's recognizing where the product lifecycle naturally reaches its boundary and a custom approach becomes necessary to avoid bottlenecks.

This is the true next step for growth: building proprietary technology that hard-codes a competitive edge directly into the business model.

How Kaizen Softworks Partners for Differentiation

At Kaizen Softworks, we partner with logistics leaders to:

• Pilot Custom POCs: We build targeted, measurable Proofs of Concept around your unique challenges, allowing you to quickly test and measure ROI on advanced AI or operational automation without the risk of a massive system overhaul.
• Engineer Proprietary Systems: We create tailored software that enhances your core differentiator, be it a specific carrier-sourcing model, a unique compliance layer, or a specialized "Cradle to Grave" client experience, ensuring your technology is a true competitive weapon.
• Ensure Alignment: Our focus on cultural fit, time-zone synchronization, and clear communication ensures that partnering on strategic development is smooth, effective, and less likely to feel like a "second job."

TIA Technovations 2025 confirmed that the logistics industry is healthy and focused on innovation. We look forward to working alongside our peers to help freight leaders build the tailored solutions necessary to thrive in the complex, digital landscape ahead.

At Kaizen, design critiques began as a simple idea for peer learning, but quickly became the most valuable part of our UX culture. Our philosophy is to build by co-building. Feedback isn’t something we fear; it’s something we train for. We prefer to face tough input at the right time rather than too late.

We use design critiques to connect, exchange perspectives, and train our critical eye. It's not about one UXer working alone; it’s about bringing diverse viewpoints together to strengthen ideas early, before they go live. We hold these sessions weekly across all projects, from small features to large redesigns.

What is a Design Critique (and How We Run Ours)

A design critique is a structured, collaborative review where peers evaluate a design, prototype, or concept. Its main objective is to gather constructive feedback to identify strengths and weaknesses, leading to significant product improvements.

Our sessions last one hour. One person moderates while others present their work. Each presentation is about 15 minutes, split evenly between context and feedback.

Every UX design critique follows a three-part structure. The core rule is that feedback must be objective analysis (e.g., based on user needs and UX principles) and never personal judgment:

1. The Critique Itself: Observations, reactions, and questions about the design.
2. The Theoretical Grounding: The reasoning behind the comment, often supported by heuristics or UX principles.
3. The Proposed Solution: A suggestion on how to address or refine the issue discussed.

The Dual Purpose of Our Critique Process

What makes the Kaizen design critique process unique is the dual purpose it serves:

• Training the Muscle of Critique: Every session is both practice and contribution. We grow as designers while simultaneously improving the work for our clients.
• A Consistent Quality Check: Having many eyes on one piece of work means issues surface before production, improving quality and reducing design debt. This means a client's project benefits from the entire UX team's perspective.

Our golden rule for giving a design critique remains simple: “Critique, explain, propose.” It’s how we stay grounded, theoretical, and solution-oriented at once.

Integrating Critiques into the Workflow

When the critique ends, the feedback doesn't vanish, it's immediately actionable:

• For open tickets: The designer integrates the insights into the next iteration of the work.
• For closed work: We record suggestions for future reference and share them with the client if relevant.

Every session becomes part of our collective learning system, building a repository of UX design best practices.

More Than a Routine: Our Ritual of Learning

For us, design critiques are not mere meetings; they are a ritual of learning. They remind us that good design doesn't happen in isolation, and that growth comes from openness, respect, and shared curiosity.

When asked how Kaizen’s UX team achieves consistent quality, we point to this practice: a warm group of people, united by listening deeply, questioning respectfully, and building better designs together.

‍

Working with AI in its default state is a manual loop: you prompt, get a result, tweak it, and repeat. The core problem is that this approach has no memory or system. A lesson learned in one prompt is forgotten by the next.

This inevitably ends in frustrating loops, where the AI goes beyond what is asked and gets stuck solving the wrong problem while we waste time and energy trying to prompt it back on track.

Breaking the Loop: Creating a Repeatable AI Process

We learned that the agent's effectiveness skyrocketed when we stopped treating it like a single-use tool and started building a system around it by:

• Enriching the context with clear documentation.
• Limiting its actions with explicit rules to prevent it from going off-course.

Initially, each developer solved this in their own way, creating custom prompts and conventions. It worked, but it didn't scale. The solution was to systematize this knowledge and turn it into shared workflows and rules using the Windsurf Editor.

The windsurf-devsuite Repo

Our Innovation Hub created a repository that functions as an additional workspace, providing a set of workflows and rules that standardize how we interact with the AI on development projects.

Workflows: The Process Steps

Building a workflow in Windsurf is like creating a smart recipe for your AI assistant. You're giving it the ingredients, the rules, and the step-by-step instructions separately so it can deliver a perfect result every time.

Location: .windsurf/workflows/ These are executed with slash commands and orchestrate the entire flow of a task:

• /0-task → Initializes the task and sets up tracking.
• /1-discovery → Analyzes the current state of the code.
• /2-design → Proposes design options and documents the chosen one.
• /3-implement → Incremental implementation with logs and validations.
• /4-clean → Refactoring and cleanup with approval.
• /5-test → Plans and executes tests.
• /6-document → Audits and generates technical and user documentation.
• /status → Shows progress and next steps.

Using Rules as AI Guardrails for Code Quality

Location: .windsurf/rules/

This is where you enforce quality and consistency. You create "rules" that act as non-negotiable guardrails for the AI's output.

global.md 

Guidelines for architecture, TypeScript conventions, use of Tailwind + shadcn/ui, testing, performance, error handling, and the assistant's expected behavior (e.g., do not assume or invent libraries).

devsuite-workspace-paths.md 

This file tells the AI "where" to work. It defines that process tracking and documentation are centralized in docs/development/current-task.md  within the devsuite. This maintains order and traceability.

You can explore all the DevSuite guidelines and workflows directly on our GitHub repository here.

Benefits of Using Windsurf Workflows

Consistency → The same rules applied across all projects.

Standardization → Clear steps and documented outcomes in each workflow.

Traceability → All decisions recorded in a single location.

Productivity → Less friction; the assistant knows what to do at each stage.

Current Status and Next Steps 

Today, we are in the middle of the adoption phase: each team at Kaizen is incorporating the workflow set into their daily routine while we gather feedback to improve it. The goal is for these workflows to evolve with use:

• Adjusting rules that prove to be too restrictive.
• Adding steps where they are needed.
• Refining the generated documentation to make it truly useful.

We want this to become a common and living foundation that empowers every dev, regardless of their seniority, and facilitates collaboration between teams.

In Summary 

We went from "fighting with the AI to make it understand what we want" to having a structured and reliable process where the assistant works with focus, within a common framework, and without endless prompt loops. 

With Windsurf + devsuite, AI has stopped being an isolated experiment and has become a real pillar of our daily operations.

Is your logistics operation running smoothly, or does it sometimes feel like a daily firefight? Do you make decisions based on real-time data, or do you rely on gut feelings and the expertise of a few key employees?

Every company is on a unique journey. For many, the challenges come from patchworks of disconnected systems, manual workarounds, or processes that haven’t yet scaled with growth. This isn’t a failure, it’s simply where you are today. The important thing is recognizing opportunities to grow stronger, more efficient, and better connected.

This framework is designed to help you quickly assess where you are today and what opportunities exist to unlock your next stage of growth.

Stage 1: The Reactive Firefight

You may be here if:

• Spreadsheets, email, and phone calls are your main tools.
• Processes are manual, inconsistent, and depend heavily on “tribal knowledge.”
• Data is limited or unreliable, so decisions are often based on instinct.
• Most time is spent putting out fires instead of planning ahead.

Opportunities to Grow: Reduce inefficiency, errors, and stress by introducing simple, repeatable processes and basic technology tools.

Stage 2: The Functional Silos

You may be here if:

• You’ve adopted basic systems (like a TMS or accounting software), but they don’t connect.
• Processes are documented but live in departmental isolation.
• Data is being captured but remains trapped in separate systems.
• Miscommunication or rework happens between teams.

Opportunities to Grow: Focus on connecting systems and sharing data to improve collaboration and visibility across teams.

Stage 3: The Integrated Powerhouse

You may be here if:

• Core systems (ERP, WMS, TMS) are connected and share information.
• Internal processes are unified and standardized.
• Automation is in place (e.g., barcode scanning).
• Reliable KPIs are available to understand performance trends.

Opportunities to Grow: Build efficiency, scalability, and consistency by leveraging integrated systems and measurable results.

Stage 4: The Collaborative Optimizer

You may be here if:

• You use modern APIs and BI platforms to connect with partners.
• You have end-to-end visibility across your supply chain.
• Data helps you understand not just what happened, but why.

Opportunities to Grow: Use collaboration and data insights to strengthen partnerships, anticipate challenges, and improve customer experience.

Stage 5: The Digitized Leader

You may be here if:

• You’ve built or adopted advanced proprietary tech (TMS, WMS, CRM).
• AI and Machine Learning help forecast, optimize, and prevent disruptions.
• Automation drives predictive and proactive decision-making.

Opportunities to Grow: Turn technology into a true strategic advantage by moving from reactive problem-solving to proactive, optimized decision-making.

The Cost of Standing Still

No matter where you are currently, staying stagnant can hold back your growth. Every disconnected process, data-entry error, and missed insight make it harder to compete.

Your Competitors Are Advancing: Companies at later stages are moving faster and more efficiently.

Inefficiency Eats Profit: Manual processes and disconnected systems act like a hidden tax on your margins.

Blind Spots Limit Strategy: Without integrated data, decisions remain educated guesses.

The question isn’t if you should progress, it’s how and when. And the best time to start is now.

Ready to explore your next stage of growth? 

Let’s work together to assess your current systems and design a roadmap that fits your business goals. 

SET UP A FREE CONSULTATION

A transparent, decentralized, and human approach to compensation

Let’s face it, salary decisions in most companies feel like a black box. You work hard, get good feedback… and still wonder: Am I being paid fairly? Who decides that, anyway?

At Kaizen, we decided to do things differently.

We built a transparent and collaborative salary policy, one that doesn't rely on negotiations behind closed doors, or a single person pulling the strings. Instead, it's a decentralized, data-informed system that values fairness, context, and sustainability.

Here’s how our salary policy actually works, and why we believe it reflects the culture we’re building every day at Kaizen.

From a Centralized Bottleneck to a Collaborative System

In the early days, our CEO, Bruno, handled all salary reviews. His intentions were fair and well-meaning, but the process just wasn’t scalable. Reviews took time, data was hard to update, and decisions were largely centralized.

So a few Kaizeners decided to change that.

Martin (our Agile Coach), along with Nacho and Eduardo (two of our tech leads), proposed a change. They started codifying the values and principles Bruno used to make decisions and turned them into a transparent, repeatable process the whole company could see.

They focused on four main goals:

• Standardize the principles that guide compensation.
  
• Reduce how long salary reviews take.
  
• Replace case-by-case negotiation with proactive, periodic reviews.
  
• Open up the process so more people could contribute, not just leadership.

The Four Pillars of Our Compensation Model

We based our salary policy on four clear, concrete pillars. Each one helps us make decisions that are fair, sustainable, and rooted in reality.

1. Market Competitiveness 

We subscribe to trusted market surveys (CPA Ferrere and Búsquedas IT) and build salary bands by role and experience.

Instead of guessing or benchmarking against vague “industry averages,” we aim to land between the 20th and 80th percentile of real-world salaries. This gives us flexibility to reward growth while staying competitive across roles.

2. Real-World Purchasing Power

A salary isn’t just a number, it’s what it can actually buy.

That’s why we track inflation, currency fluctuations, and cost of living. We don’t just raise salaries because it’s time; we raise them when people’s actual purchasing power is impacted. It’s about making sure people can live well, not just look good on paper.

This principle of real-world stability also applies to when you get paid. We pay salaries on the first day of each month. If that day is a holiday or weekend, you get paid on the last business day of the previous month. 

3. Business Sustainability

We’re transparent about the fact that salaries are a big investment, and we need to manage them responsibly.

We track our Gross Margin (revenue minus direct project costs), and aim to keep it around 50% to stay healthy. Every proposed salary adjustment gets run through simulations to see if it keeps us on track.

It’s a way of saying: yes, we care about people, and we also care about keeping this company strong for the long haul.

4. Internal Equity 

Similar work should mean similar pay across different departments, with room to recognize impact.

We use years of experience as our starting point (it’s a reliable guide about 80% of the time), and then enrich that with input from team leads and principals. This helps us identify people who are growing fast and contributing at a higher level, even if they’re earlier in their careers.

How a Salary Review Actually Works

Anyone at Kaizen can request a salary review, for themselves or a colleague. But we also run company-wide reviews twice a year (around March and September), and on every Kaizener’s yearly anniversary.

Here’s what the process looks like:

1. Update the Data: We bring in fresh market numbers and adjust our salary bands.
   
2. Analyze the Business: We review company metrics like Gross Margin and economic indicators.
   
3. Evaluate Individually: We assess each person’s place in their band using experience, feedback, and performance.
   
4. Run Simulations: Before making any changes, we simulate the financial impact to ensure company health.
   
5. Build the Proposal: All proposed changes are put together in one doc.
   
6. Final Review: Bruno steps in here for a final pass; not to make top-down decisions, but to ask thoughtful questions and give input.
   
7. Communicate: We sit down with each team member and talk through the outcome and reasoning.

Why This Matters

Our salary policy isn’t perfect. But it’s transparent, thoughtful, and built by the people who live it every day.

It reflects who we are as a company: collaborative, transparent, and constantly evolving. And because we value that long-term commitment, we have other ways of showing it. For example, after three years at Kaizen, your personal laptop bought with an allowance benefit, is 100% yours to keep. 

So if you’re someone who values honesty, ownership, and real context behind how things work, you might feel right at home here.

Curious to learn more about life at Kaizen or how we work?

Check out our open roles or reach out to [email protected], we’re always happy to talk.