Meet the founders of Ampersand: Ayan Barua and Lauren Long

Every enterprise software company eventually hits the same wall when integrating with a customer's product. You build a Salesforce integration, close a deal, and discover the customer’s Salesforce looks nothing like the one you built against. They have different objects, fields, and permissions. So you build it again and again. Senior engineers come off the roadmap just to sit in onboarding calls and chase schemas that drifted overnight.

Co-founders Ayan Barua and Lauren Long started Ampersand after six years of living the problem. The thesis was simple: a developer should declare an integration once and have it work in every customer’s environment at runtime. Agents make this problem even more urgent to solve because an agent can’t absorb a customer’s integration the way a solutions engineer can.

In our Roadmap: AI systems of action, we argued that the deepest moat protecting legacy systems of record is the cost of implementing and customizing them for every enterprise. Ampersand is dissolving that problem from the inside, turning the per-customer integration project into a line of version-controlled code. This is why Bessemer is proudly leading Ampersand’s $15M Series A. We sat down with Ayan and Lauren to learn more about what the team is doing to earn a 90% success rate of PoCs becoming paying customers.

Q&A with the founders of Ampersand

You started Ampersand before systems of action and tool-use by AI agents entered the mainstream dialogue. What gave you the foresight to work on this problem?

Ayan: It wasn’t foresight about agents; it was six years of living with the problem. At Siftery, and later as VP of Engineering at G2, I watched CRM and ERP integration work consume insane amounts of product engineering time nearly every quarter.

Lauren: I saw it from the infrastructure side, building Firebase Extensions at Google at a scale of billions of executions a day.

Ayan and Lauren: Despite our shared experiences (and pain), we spoke with more than 100 companies in various domains on the application layer that have to deal with customers’ systems of record. They all said the same thing, in different words: connecting to Salesforce isn't the hard part. Connecting to each customer's Salesforce is. And then HubSpot, Dynamics, Oracle, SAP—every vertical has several systems of record.

So this deep integration problem was true long before agents. Agents just made it urgent, because an agent can't learn a customer's configuration on the job the way a product engineer or a solution engineer can. We weren't waiting for a market to appear. We were working on a problem that was always there, but is 100x more complex at agentic scale.

Your core idea is that a developer declares what they want once, and Ampersand handles every per-customer instance at runtime. What does that replace in practice? What were teams doing before, and where did all their time actually go?

Ayan and Lauren: It replaces one integration per customer.

Before Ampersand, a vendor selling into enterprises would build a Salesforce integration, then rebuild pieces of it for every new account. Each customer has its own custom objects, fields, and permissions, so engineers wrote per-tenant scaffolding, sat in onboarding calls mapping fields, and then kept all of it running as schemas drifted and credentials expired.

Their time went to three places:

• Onboarding each customer
• Fixing integrations that broke quietly
• Pulling senior engineers off the core product to do both

With Ampersand, a developer declares the integration once, in version-controlled code, using five primitives: read, write, subscribe, search, and proxy. It ships through the same review and deployment process as the rest of the product. At runtime, we handle each customer's schema, and the customer's own admin does the field mapping inside the vendor's onboarding flow. Integration ships with the product, not after it. This architectural approach reduces 1) the product-to-FDE gap and 2) the need for babysitting an integration.

Plenty of vendors claim to “solve” integrations, yet many of your customers arrive after a failed deployment somewhere else. What architectural choices did you make that enable Ampersand to get customers to success where others have failed?

Ayan and Lauren: We made three bets.

First, we don't flatten. Many tools force every system into a lowest-common-denominator schema. That works in a demo and breaks on a real enterprise account, because the custom objects and fields are where the business actually lives. We read and write in each system's native structure, so an agent knows which record it can touch and which field marks a deal as qualified.

Second, engineers stay in control. The integration logic lives in the customer's own repository as code, not inside a black box. Their team can see it, change it, and ship it like anything else they build.

Third, we built for day 200, not only day one. Agents run continuously, so a changed schema or expired credential can break production without anyone noticing. We audit for schema drift, manage credentials automatically, and alert in real time, cutting resolution time from days to seconds and creating a self-healing architecture. Every tenant is fully isolated, so the same integration works for one enterprise customer or hundreds.

You can see it in conversion. Teams that finish a proof of concept with us become paying customers 90% of the time.

Enterprise systems each look like a snowflake because of years of customization. Is that something the industry will eventually fix or simplify, or a permanent feature of how enterprises work, and how does your answer shape what you build?

Ayan and Lauren: It's permanent, and it should be. Customization isn't technical debt. It's how a company encodes the way it sells, bills, and runs. It’s years of change management around a company's identity. The field that marks a deal as qualified is different at every company because every company is different.

So we don't build for a world where enterprises standardize. We treat variation as the default, not the exception. Schema discovery is automatic, the customer's admin handles mapping, and every tenant is isolated. If every enterprise system is a snowflake, the only way to scale is to make each one legible to software without an engineer in the loop.

Every durable infrastructure company ends up making something that used to be hard feel invisible. What's the thing you most want to have made invisible? What changes about how software gets built for the developer who never has to think about this problem again?

Ayaan and Lauren: The per-customer integration project. Another way to look at this is the implementation burden that enterprise software companies have to take on. Today, when a vendor closes an enterprise deal, someone still has to ask how long it'll take to connect to that customer's CRM, ERP, Payroll systems, their communication stack, and other critical systems. We want that question to disappear.

For developers, that means the roadmap stops bending around integration timelines. You decide what your agent should do and what data it needs, and it works in every customer's environment. Deals stop stalling on engineering work, and your best engineers get back to building the core tenets of the product.

We're starting with deep CRM and ERP integration. From there, we're moving into broader enterprise software, and eventually a shared interoperability layer any agent can use. Enterprise systems were built for people, then hardened for engineers. Our job is to make them legible to agents. That's the generation gap we're closing.

You’ve been deliberate about scaling, such as hiring carefully, protecting the culture, and holding a high bar rather than growing headcount for its own sake. As you enter this next phase, how are you thinking about maintaining that discipline while the team grows?

Ayaan and Lauren: Critical infrastructure products manifest the culture of the teams building them. Our customers trust us with handling systems that run their customers’ businesses, so the stakes are high. We aim to be a constant they can depend on, and this responsibility shapes how we function as a company.

We have five core values that are cornerstones of our culture: craft, customer empathy, ownership mindset, velocity, and humility. We think they tend to reinforce one another. Craft helps you move with velocity because you know which pitfalls to avoid and the shortest path to excellence. This pursuit of excellence ensures that, deep down, you know it's a never-ending journey, which keeps us humble. Having customer empathy ensures we seek to understand both our customers and their customers. And taking ownership means taking responsibility for the whole problem; we don't want to simply sell you a tool and walk away.

These are the characteristics we look for in people as we build the next iteration of our company. We’re an in-person team, and our interview process includes candidate on-sites spending half a day in our office and sharing lunch with the whole team. Both sides get to experience how we would think, collaborate, and solve problems together.

Ampersand is hiring; see what available roles they have and join the team!