Middleware Requires Three Departments
Isaac Nassimi, SVP of Product at Nylas, on the market for developer middleware
The real moat is moving from raw connectivity into packaged judgment. A company can wire up Gmail and Outlook with enough engineers, but turning messy inbox data into usable fields like sender identity, intent, sentiment, cleaned text, and scheduling context usually means building connector infrastructure, data normalization, and applied ML at the same time. Nylas bundles those layers into one developer workflow, which shifts it from API vendor toward higher value middleware.
-
The hidden work starts well before any model runs. Nylas describes handling OAuth, sync, webhooks, thread state, and database opinions across Gmail, Microsoft, and IMAP. That is the first department. The second is normalization, turning each provider's odd data into one common schema. The third is the intelligence layer on top.
-
This is the same pattern seen across universal APIs. Finch and Pinwheel frame their value as absorbing fragmentation, access headaches, and standardization work that customers do not want to staff internally. In fragmented systems, buyers are not paying only for endpoints, they are paying to avoid standing up teams that babysit brittle integrations forever.
-
The economic implication is that simple connector layers tend to commoditize, while value added services support stronger expansion. In the universal API market, founders repeatedly point to the need to add products on top of the rails, because raw aggregation alone gets squeezed over time. Email intelligence gives Nylas that higher layer to sell into the same installed base.
The next phase is for communication APIs to become decision APIs. The winning platforms will not stop at moving messages and calendar events into an app. They will return structured answers and recommended actions, so developers can ship workflow automation, routing, enrichment, and scheduling features without building separate integration, data, and ML teams first.