Anup Kejriwal

Why AI changes the deployment conversation

Traditional SaaS gave buyers a fairly simple deployment question: cloud or on-prem, public cloud or private instance, standard controls or extra controls. AI makes that conversation much more important because workforce AI is only useful when it has broader context. It needs to reason across policies, people data, schedules, tasks, training, support history, approvals, and exceptions. That is exactly what makes it valuable, and exactly what makes governance harder.

This is especially true in frontline-heavy organizations. A store manager asking about a payroll exception, a nurse checking a policy, or a plant supervisor escalating a safety issue is not just using generic collaboration data. They may be touching employee records, compliance rules, union agreements, benefits information, schedules, or performance history. That changes the bar for enterprise buyers.

CISOs and enterprise architects need control over identity, keys, network access, logging, data flows, model routing, residency, retention, and incident response. HR and compliance leaders need audit trails, approvals, responsible ownership, and clear boundaries on what an agent can and cannot do. One rigid deployment model will not work for every company, every country, or every workflow.

At MangoApps, this is why we support multiple deployment models instead of forcing every enterprise into one pattern. Some customers want fully managed SaaS. Others need private cloud, customer-controlled network boundaries, or on-premise deployment for stricter regulatory environments. The principle is simple: same app, same AI, deployed where enterprise IT requires it.

The AI conversation cannot just be about better answers. It has to be about where the data lives, how it is accessed, who controls it, how actions are traced, and how safely the system can operate across the rest of the enterprise stack. In the AI era, deployment flexibility is not an infrastructure detail. It is part of the trust model.

AI ARR needs a gross margin test

A lot of AI companies are announcing they grew ARR to 8 or 9 figures in just a few months.

First, congratulations. That is impressive. But we should be careful not to compare apples to oranges.

In traditional SaaS, revenue often came with 80%+ gross margins once the product was built and scaled. In many AI businesses, a meaningful part of every dollar goes back into compute, inference, model costs, and infrastructure.

That does not make these bad businesses. It just means the revenue profile is different.

A grocery store can be a great business. So can a software company. But $100M of grocery revenue and $100M of high-margin SaaS revenue are not the same thing.

The better question is not how fast ARR is growing. It is how much durable gross profit is left after serving the customer. That is where the real comparison should start.

AI will not reduce the need for customer success and implementation. It will make them more important.

Customers increasingly expect software to adapt to their workflows, policies, language, permissions, and operating model. That doesn't happen by bolting on AI features. It takes strong implementation, clean data, thoughtful configuration, workflow design, and ongoing customer success.

Companies that understand this shift and organize around it will lead. Companies that think AI eliminates the need for Customer Success (CS) team and put AI chatbots as the answer will miss the point.

At MangoApps, we've always treated Customer Success as one of our most important functions. Engineering builds the product; Customer Success makes sure it works in the real world, across real organizations, with real complexity. The average MangoApps deployment touches about a dozen systems and 3 policy frameworks before go-live — none of which AI can figure out on its own. Our 75+ NPS score, year after year, reflects that belief.

As AI makes software more personalized for every organization, the winners will be the companies that do the hard work after the sale: connect the right systems, understand the customer's workflows, configure the product correctly, govern the data, and keep improving it as the organization evolves.

That's where SaaS leadership will be decided.

No, companies won’t stop buying software

Companies are not going to stop buying software and start building everything themselves. That idea is not grounded in history. We can all cook at home, but restaurants are massive businesses. We can all make coffee, but people still line up at Starbucks.

The reason is simple: people and companies do not only pay for capability. They pay for convenience, reliability, speed, polish, support, trust, and the ability to focus on their own business. AI coding makes building software easier, but easier does not mean easy, and it definitely does not mean everyone should build everything.

I have been agentic coding for over 18 months. I enjoy engineering. AI coding is a great accelerator and confidence booster. But building a meaningful product at scale still requires architecture, permissions, integrations, UX, security, workflow design, support, and a lot of judgment. AI does not remove those challenges. It shifts where the hard work lives.

So no, I do not think companies will stop buying software. I think we will see more software everywhere. Some will be internal tools, and those tools will get better. But most durable software will still come from teams whose entire job is to build, support, and evolve it. AI will change who can build software. It will not change what it takes to build great software.

There is a lot of discussion right now about the coming “SaaS collapse.”

AI is one of the most important technology shifts we will see in our lifetime. It will reshape software, disrupt categories, and challenge how products are built and priced. That part is real. But what is coming next is not a collapse. It is a reset in how software serves the business.

For decades, companies have been forced to adapt themselves to software. They bought rigid systems, bent workflows to fit predefined models, trained employees around generic experiences, and layered tool after tool to fill the gaps. The result has been complexity and a constant mismatch between how a business operates and how its systems actually work.

AI changes that dynamic in a fundamental way. It makes it possible to deliver software that is contextual, role-specific, and aligned to how each organization actually works, without the cost and time of traditional customization. When that barrier goes away, expectations change. Businesses will no longer accept one size fits all systems.

If there is one thing I have learned from building companies for over 20 years, it is this. You want complete alignment with your customers. When customers are thinking about building custom or in-house solutions, you do not fight that instinct. You enable it. That is what AI now makes possible, and it is a core part of how we think about MangoApps AI.

At MangoApps, we are building for this shift. A unified, brandable workforce platform that adapts to every role, every team, and every workflow. Frontline employees, desk workers, managers, field teams, HR, IT, and communications each get an experience that actually fits how they work.

The future of SaaS is not just more intelligent software. It is software that finally fits the business.

One of the biggest misconceptions I see right now is that AI agents are ready to take over most work. They’re not. Especially in frontline organizations where accuracy directly impacts customers, operations, and safety. Even in one of the most advanced use cases like agentic coding, accuracy is still in the 80 to 90 percent range. For most enterprise scenarios, that simply isn’t good enough. Imagine a store associate, nurse, or technician getting it wrong 20 percent of the time.

We’ve seen this movie before. Voice didn’t really take off until accuracy crossed that ~95 percent threshold. AI will get there. The level of investment going into this space makes that inevitable. But as you get closer to 90 percent, every 1 percent improvement becomes significantly harder.

It works in coding today because developers are used to it. Debugging is part of the workflow. That tolerance doesn’t exist in most frontline environments where errors have real consequences.

So the practical approach is simple. Focus on use cases where 80 percent accuracy is acceptable and keep a human in the loop to catch the rest. That’s exactly where we’re focused at MangoApps, enabling frontline AI use cases that are grounded in reality. From helping a technician troubleshoot an issue in real time to guiding a store associate during a customer interaction, all with the right guardrails in place.

When AI can do 80 percent of the work in 5 to 10 percent of the time, that’s a massive gain. If you’re not leaning into that, you’re leaving real productivity on the table.

At MangoApps, we believe the next generation of frontline software should feel less like software and more like a natural extension of how people already work. Frontline teams should not have to pause what they are doing, find a device, navigate a system, and fill out forms just to get an answer, report an issue, or ask for help. In many of these moments, the most natural interface is voice, and increasingly, live video.

We have been investing in voice-first experiences for over a year. The opportunity is clear, but the economics are still catching up. Today, a minute of live voice interaction can cost anywhere from $0.15 to $0.25, which translates to $9 to $15 per hour. So the real question is not whether voice can be added, but where it actually makes sense.

That is the focus for us at MangoApps. We are looking closely at which frontline workflows are valuable, urgent, and human enough to justify a voice-first or video-first experience. For the frontline, voice is not a novelty. It has the potential to become the interface that finally aligns with how work actually gets done.

“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.