Anup Kejriwal

“AI Employees” — I don’t buy that term.

These systems are not employees. They don’t have judgment, accountability, or context. Calling them employees feels like marketing stretching the truth and it sets the wrong expectations for both the buyer and the team building it.

What we are actually building is closer to an autopilot. In a plane, autopilot handles the routine so the pilot can focus on decisions that actually require judgment. The pilot stays in command. That is the right mental model for AI in the enterprise.

At MangoApps, we think of these as workflow autopilots. A helpdesk that triages and resolves common issues. A hiring pipeline that sources and schedules. A payroll process that flags exceptions. The system runs the routine and people step in where it matters.

This framing matters for two reasons. It tells the buyer the truth. You are not hiring a coworker, you are putting a process on autopilot and the value is in the work it completes. It also tells the team the truth. You are not building a person, you are building a system that can be trusted to run a workflow well.

Software is software. Let’s call it what it is.

From 100+ Spam Submissions to Zero

We were getting 100+ spam form submissions a day. Then zero. Our forms like contact, demo requests, and newsletter signups were getting buried under bot noise. The default reaction is to add CAPTCHA, but we tried something simpler first. A honeypot.

It is just a hidden field in the form. Bots see it because they parse the HTML. Humans do not because it is hidden with CSS. Bots fill it. Humans never do. If that field has a value, we treat it as a bot and drop the submission silently. That is it. Around 15 lines of code, no third party dependency, no extra step for the user.

Spam went to zero overnight and has stayed there. What I like about this approach is that it does not tax real users. No puzzles, no friction, no prove you are human moment. CAPTCHA makes every user pay the price. A honeypot puts the cost on bots. For any public form, this should be the first thing to try. CAPTCHA is the fallback, not the default.

Foundations First

Last week, I visited the Hoover Dam. What stood out to me wasn’t just the scale, but the discipline behind it. They spent years—almost a decade—planning, aligning stakeholders, and setting the foundation before construction even began. And then they built it in just a few years.

That part really resonated. At MangoApps, we’ve spent the last 15+ months laying the foundation for the next version of our platform. A lot of what we’ll be able to do going forward—especially how fast we can build and evolve with AI—rests on this foundation.

Most structures are designed to last a few hundred years. The Hoover Dam is expected to last thousands. That’s how we think at MangoApps—long-term. Build it right. Build it to last. Build it so it can evolve.

The “Alex Rodriguez Rodriguez” Bug

An employee named Alejandro goes by Alex. He sets “Alex” as his preferred name, opens his welcome email — “Dear Alejandro.” Logs into the dashboard — “Welcome, Alex.” Then sees a recognition from his manager — “Great job, Alex Rodriguez Rodriguez!” Same employee, three different experiences. At that point, it doesn’t feel like personalization. It feels like the system doesn’t really know who he is.

Most platforms get this wrong because they treat a name as a single field and reuse it everywhere, then bolt on “preferred name” without defining where it should apply. So the wrong version leaks into the wrong places.

We split it into two: display_first_name for anything user-facing (emails, notifications, recognition, UI), and legal_name for where it actually matters (HR, payroll, compliance). The “Rodriguez Rodriguez” bug was just bad concatenation — preferred name + last name without checking duplication.

It’s a small detail, but it shows up everywhere. When a manager recognizes someone, it should look right across desktop, email, mobile, and feed — not vary by surface. Personalization isn’t about adding a field. It’s about being consistent everywhere it shows up.

Are Dashboards Dead?

Dashboards aren't dead. If anything, they're more useful now than they were two years ago.

There's a narrative going around — mostly from AI vendors — that conversational interfaces replace dashboards. Ask a question, get an answer, done. No need for a screen full of charts.

That framing misses something real.

A well-designed dashboard delivers condensed, high-signal information in seconds — no back-and-forth required. A manager walking into a shift glances at a screen and immediately knows: coverage gaps, open tasks, flagged issues. That's not a conversation. That's a pattern recognized in under five seconds. Chat can't replicate that speed for information you need constantly.

The actual problem with dashboards was never the format. It was the personalization gap. Most dashboards showed everyone the same thing — built for a role that didn't quite fit anyone. A district manager and a shift supervisor have almost nothing in common in terms of what they need to see at 6am.

That's where AI changes the equation. Not by replacing dashboards, but by making them actually personal. Surfacing the metrics that matter to this person, in this role, managing these locations — without requiring a data team to build a custom view for every use case.

The old dashboard was a compromise. The new one is specific.

AI for the Frontline: The Economics No One Talks About

Everyone is excited about AI, and rightly so. But when it comes to frontline organizations, there is a reality we cannot ignore. The cost of AI is still too high for many everyday internal use cases.

Consider the types of questions frontline employees ask every day. How much PTO do I have? Can I take next week off? How much did I get paid last week? What is my employee ID? These are high-frequency, low-complexity interactions that today cost nothing.

Now introduce AI. Even a few cents per query sounds trivial until you do the math. If 20,000 employees each make just two queries a day at $0.03 per query, that is over $1.2M per year. What appears to be a small cost quickly becomes a meaningful expense that is hard to justify.

This is why not all AI use cases make economic sense yet. If a use case does not replace a support ticket or a call, it is often adding new cost rather than reducing it. Process and rule-driven workflows have been optimized over the last 40+ years to be almost free. Anything that is rule-driven today, such as workflows, lookups, or approvals, is already instant and near zero cost. Replacing those with slower and more expensive AI does not hold up.

The reason agentic coding has emerged as such a strong use case is simple. The cost of AI is significantly lower than the alternative, which is engineering time. That is the bar AI needs to meet.

In the enterprise, this means keeping rule-based systems for deterministic and repeatable workflows, while using AI selectively for exceptions that require judgment. In many cases, the right model is a combination of AI and human involvement where it truly adds value.

At MangoApps, we focus heavily on frontline organizations, and this reality shapes how we think about AI. MangoApps Frontline AI is designed with a clear goal in mind: to deliver meaningful value at a cost structure that customers can justify at scale.

If you are thinking about how to bring AI to your frontline workforce in a way that actually works both operationally and economically, let's talk.

AI does not just need to work. It needs to make economic sense.