Arnav Mishra, Co-Founder and CTO of Doss – Interview Series

Arnav Mishra, Co-Founder and CTO of Doss, is a full-stack engineer and technical leader with a background spanning early-stage startups and large-scale infrastructure systems. Prior to co-founding Doss, he was a founding engineer at Siteline, where he built core systems including permissions architecture, ERP integrations, and automation frameworks, while also contributing to recruiting, revenue operations, and company culture. Earlier in his career, he held engineerings at Rubrik and interned at companies like Uber and VMware, developing expertise in cloud infrastructure, data systems, and automation. Alongside his technical work, he has been actively involved in mentorship and talent development through organizations like Techquitable Futures and Contrary, reflecting a broader commitment to supporting the next generation of engineers.

Doss is a modern enterprise software company focused on reinventing traditional ERP systems through its Adaptive Resource Platform (ARP), a flexible, AI-native operations platform designed to unify and automate business workflows. Built as a composable alternative to legacy ERP solutions, Doss enables companies to manage inventory, procurement, finance, and fulfillment within a single system that adapts to real-world operations rather than forcing rigid processes. Its platform combines a centralized data layer, no-code workflows, and real-time analytics, allowing businesses to deploy quickly, integrate with existing tools, and continuously evolve their operations without lengthy implementations or costly consultants.n enterprise infrastructure designed for speed, scalability, and adaptability.

The motivation for building DOSS traces back to Wiley watching legacy software disrupt his father’s manufacturing business, and both of you later seeing similar problems firsthand while working with factories and hardware supply chains. How did those experiences shape your decision to co-found DOSS and rethink ERP systems from the ground up?

Before DOSS, I was the founding engineer at a FinTech startup. The #1 reason our buyers – CFOs, Accountants, etc – would not go with our solution was because they were “too busy implementing an ERP”. As I dug deeper into the archaic land of ERP, I was blown away by the existing implementation model. 

What I kept seeing was the same fundamental failure: implementation takes months or years, costs hundreds of thousands to millions of dollars, and is bottlenecked entirely on human consultants with hourly billing. Then, once the ERP ships, it stops changing. The business keeps evolving; the system doesn’t. That’s an architectural problem, not a configuration problem. You can’t patch your way out of it. 

As a software builder, the closest comparison I could think of was the following: imagine a world in which the most important tool you use – as a developer, let’s say GitHub – was built specifically for just your company over the course of years by a 3rd party consulting agency. Then, once the product is finished, the consultants leave with no maintenance, no feature improvements, and no support. Engineers would revolt.

No modern technology company can operate in that model. Wiley and I both came to the same conclusion: the only way to fix it was to build from scratch.

DOSS positions itself as an AI-native operations platform designed to replace traditional ERP systems like SAP or Oracle. What fundamental architectural differences make an AI-native ERP possible today that weren’t feasible a decade ago?

Oracle and SAP were built in an era where, in order to achieve maximized distribution, they needed to simplify the configuration plane of an ERP to be a GUI-based editor that relatively non-technical consultants could deliver at scale. In order to preserve best-practices, they locked down large swaths of the core systems and only allowed composability at the edges. However, in reality, when you look at the spectrum of all businesses in the world, their business applications need maximal flexibility. 

What the AI-native world enables is the transformation of software engineering from a craft to an industrialized machine. No longer do we need software artisans to hand-craft code systems; instead, we are moving into a world in which software throughput is a factor of compute and tokens.

Doss has been architected with exactly this in mind.

We built the ZSL, a declarative domain-specific language (DSL) that describes a customer’s entire DOSS implementation in code. Think what “Terraform” did for the Infrastructure as Code effort, but instead applied to business application logic. By defining ERPs in a relatively low-dimensionality programming language, we are able to deploy agents at scale to deliver ERP solutions. 

Once the ZSL was written, the single most important part of the architecture was baking best practices into the platform itself to prevent agents from building low quality implementations. Our team has delivered a scalable distributed system with a kernel-level scheduler to take on the load of bursty ERP workloads. Furthermore, we built an HTAP database system that blends together the most important parts of a transactional database like Postgres and the analytical capabilities of a Data Warehouse. 

By building the platform to have Enterprise-grade strength early on, the system is set up for entirely agentic distribution. What used to take teams of consultants months and years to do can now be parallelized at scale using agentic infrastructure in our proprietary closed loop system.

Many companies still rely on spreadsheets and fragmented tools for procurement, inventory, and order management. What are the biggest operational blind spots that arise when core business data isn’t unified into a single source of truth?

The mostect problem is that decisions are made on stale or incomplete information. If your inventory data lives in one place, your purchase orders in another, and your sales orders in a third, you’re always reconciling, manually, slowly, and after the fact. By the time someone realizes inventory is off or a supplier is behind, it’s already a problem in the business. 

Verve Coffee Roasters is a good example of where this breaks down in practice. They run operations across grocery, wholesale, DTC, and cafes in the U.S. and Japan, but were managing all of it across disconnected systems with no real-time inventory visibility. They were running out of their own coffee at high-traffic locations and hit critical stockouts during a major retailer launch that hurt a key retail relationship. The data existed somewhere; it just wasn’t connected in a way that let anyone act on it in time.

The subtler issue is that fragmentation hides the real shape of your operations. You can’t see the relationship between a delay upstream and a fulfillment problem downstream if those two things live in separate tools. You end up managing symptoms, expediting orders, building safety stock, and running manual checks instead of understanding what’s actually happening. A unified system doesn’t just save time on reconciliation. It changes what you can even see and ask questions about.

At its core, imagine running an enterprise business without access to a version control system (Git), an observability tool (DataDog), or a centralized database to query information out of.

ERP implementations have historically required large consulting teams and months—or even years—of deployment. How does AI change the economics and complexity of implementing operational software inside real businesses?

The traditional implementation model is the emergent result of generations-old software practices. We no longer live in that world.

There is a perverse incentive in ERP implementations today – the longer an implementation takes and the less effective it is, the more money the implementers receive. The vast majority of builders would not take advantage of this; however, they are never incentivized to move with pace and quality. 

Furthermore, the ratio of consulting spend to software spend in a traditional ERP engagement runs roughly 9:1, so you’re spending nine dollars on consultants for every dollar you spend on the software itself. For a large enterprise, that’s extremely painful. For mid-market businesses, it’s prohibitive. So they either settle for software that doesn’t actually fit how they operate, delay the project, or abandon it partway through. 

AI changes the unit economics of this entirely. Instead of a consulting engagement, a DOSS implementation is a codebase. As our implementation times continue to shrink, we are able to align incentives with a “pay on delivery” model instead of “pay as you go”. When the business changes, the system changes with it. The need for rooms of consultants and long slide decks are no longer relevant. 

Success at Doss means replacing the $1.86T global IT services spend with agentic implementation and maintenance using our ZSL as the language for business application software. Success at Doss is commoditizing all business applications at scale. 

You’ve deployed DOSS with companies operating in real-world environments like manufacturing, logistics, and consumer goods. What are some of the unexpected challenges that arise when AI meets messy operational data?

The challenge is rarely the AI. It’s the data you’re asking it to reason about. 

Every business we work with has accumulated years of operational workarounds. The data technically exists, it just doesn’t live anywhere that their employees, let alone agentic systems, can reliably act on it. 

One great example is a German furniture manufacturer that creates made-to-order pieces. When we came in, they had 10 years of historical data spread across 8 custom file formats with 11 different data objects and a 3PL sync running on manual copy-paste from FTP folders. The business logic was specific with custom dimensions, configurations, payment methods, and showroom locations, and the whole system needed to work in German. There’s no off-the-shelf schema for that. They had to pay thousands of euros every time they wanted to change simple configuration options, like the status options for a purchase order.

The challenge isn’t the technical complexity of any one piece. It’s that every business has a different version of this problem, and you can’t fully anticipate it until you’re inside their data. The job is to take an accurate imprint of how the business actually operates, not map their data into a generic template and hope it fits.

To build a solution that works for the real world, you need a platform with maximum flexibility. Only then can AI be useful in understanding the underlying data model it’s working from, and building the model that works for each customer.

There’s a lot of discussion about AI copilots and autonomous agents in business software. Where do you see AI adding the most value in operational workflows today, and where does human oversight still remain essential?

At scale, AI has the ability to disrupt all operational work.

Over the near term horizon, Doss’ proprietary models and agents should be able to transform the cores of technical consultants in implementing business applications as well as thes of management consultants in delivering strategic recommendations. Doss will have the largest repository of structured and co-located data representing both schema and operational information for businesses. Our agents can use that data to deliver scalable recommendations.

The clearest value today is more specific than that. It is in work that’s repetitive, rules-based, and currently done by people who have other, more strategic priorities: processing purchase orders, reconciling inventory, and routing fulfillment decisions. These tasks have well-defined inputs and outputs, and AI can handle them reliably at scale. 

For now, human oversight is essential wherever the cost of a wrong decision is high, and the system doesn’t yet have enough context to be confident. Today, the right model isn’t autonomous agents replacing human decision-making wholesale; it’s agents handling the high-volume, well-defined work so people can focus on the decisions that actually require their judgment.

Many enterprises are trying to layer AI on top of existing software stacks. In your view, why does retrofitting legacy systems with AI often fall short compared to building AIectly into the foundation of the platform?

Legacy systems weren’t built to be reasoned about by AI. The data models, the APIs, the way information is structured, all of it was designed for humans to interact with through interfaces. When you try to layer AI on top of that, you’re asking it to work around constraints it wasn’t meant to work around. 

Even if you attempt to throw an MCP server on top, in reality, an MCP server needs extremely specific design patterns. Most MCP servers today actually introduce greater context window bloat and blow up performance. 

However, the deeper issue is the implementation model. In a traditional ERP, the configuration of the system is stored in the system itself. It’s not code you can read, test, or version. There’s no way for an agent to understand what the system is doing, let alone change it safely. We built ZSL specifically so that the configuration is a proper codebase: readable, testable, and deployable in a closed-loop system. We are building a fully agentic software development lifecycle (SDLC). That’s the prerequisite for AI to actually operate on the system rather than just sit on top of it.

As AI becomes capable of generating workflows and interactingectly with operational systems, how do you think the of traditional enterprise software interfaces will evolve?

The interface question is really about who needs to use the system. Right now, ERP interfaces are built around a small set of power users, the people who were trained on the system during implementation. Everyone else either can’t use it or gets a degraded version of it.

What we’re building is a composable UI, which treats the interface like a website builder. The interface itself is also backed by the closed-loop ZSL. Every, the CFO, the warehouse manager, the supply chain analyst, gets a dashboard and data views composed around how they actually work, not around how the software was configured. As AI handles more of the underlying workflow execution, the interface becomes less about data entry and more about visibility and decision-making. You need to see what’s happening, understand why, and make judgment calls. The software should handle the rest.

Startups like DOSS are entering a market dominated by decades-old incumbents. What advantages do AI-native startups have when competing against established enterprise platforms?

The incumbents have the opposite problem from startups. They have enormous installed bases to protect. Every architectural decision they make has to be backward compatible. They can add AI features to existing products, but they can’t rebuild the underlying systems without breaking everything that runs on them. That’s not a failure of ambition; it’s structural.

In ERP specifically, they are also laden with business decisions that drove them down a path where revenue is driven from the specific function DOSS is looking to eliminate – professional services consultants. Given that users spend nine dollars on consultants for every dollar they spend on the software itself, the ability to transform 90% of their source revenue is untenable for large incumbents.

An AI-native system can be designed from the start so that AI is part of the core architecture, not a layer on top. The implementation model, the data model, and the way configuration works are all designed with AI as a first-class participant. That’s a compounding advantage where every deployment makes the system better, and the implementation agents get more capable with each new customer. That kind of improvement loop doesn’t exist in a system where implementation is still a human consulting engagement.

Looking ahead, how do you envision AI transforming the “operating system” of a business over the next five to ten years, particularly in areas like supply chain visibility, real-time decision making, and automated operations?

We founded DOSS on the conviction that enterprise systems would be able to build themselves. Three years in, we’ve entered Phase 2 of Doss: the agentic self-driving implementation. The platform can already generate, validate, and evolve a customer’s system rather than relying on manual consultant configuration, and it gets better with every deployment.

Theection this is heading is a system that’s always in lockstep with the business. Today, the gap between how a business operates and what the software knows about it is months or years. The system was configured at a point in time and hasn’t changed since. What becomes possible when that gap closes, when the system adapts in real time as the business changes, is a different category of operational capability. Real-time visibility isn’t just faster reporting; it’s the ability to catch a supply disruption before it becomes a fulfillment failure. Automated operations aren’t just about efficiency; it’s the ability to run a more complex business with the same team. That’s the version of operations software we’re building toward.

Thank you for your detailed responses, readers who wish to learn more should visit Doss.