I talked mostly to midsize (10-50 employee) startups, but I also included a couple companies with a few hundred employees and one 9-employee industrial design firm. Here's what I learned about them.

1. They pay for a vast patchwork of enterprise SaaS products.

Each company I talked to has at least 10 SaaS products they pay for. These products are some of their largest costs. They range from payroll and 401k software, to ticketing & task management, to Microsoft Office and a ton of APIs. Most of these products take the form of webapps, not their own separate applications. Even when separate apps are offered—i.e. Figma—people still primarily use the webapp version, although I didn't get a clear explanation why.

Naturally, users access these webapps through a browser. Nobody I talked to used an enterprise browser, which makes sense, as there aren't many available. As such, whether they use a personal or company computer, employees have their choice of browsers.

2. LLM adoption is universal, but some people hope AI gets more useful.

Every startup pays for some sort of LLM. While they're used by people on both technical and nontechnical teams, everyone told me that LLMs are more heavily used by nontechnical staff—marketing, product, and sales. They use ChatGPT or Gemini to generate marketing copy, do market research, and find leads, primarily in a chat environment (like a chatgpt.com tab), but sometimes in Google Drive.

In comparison, engineers use LLMs, mostly Claude, to write code in Cursor or other IDEs. They mainly use Claude models. At one company, they liked Sonnet 4.5 so much that a senior engineer had his entire team self-pay for personal Claude subscriptions after their purchase request was denied by finance.

Despite widespread adoption, a few people hoped that LLMs would have more applications over time. One told me that they "have a long way to go before they become fully useful." This could be where Dia Enterprise fits in.

3. These startups are forced to use multiple competing products, which either duplicates or slows down work.

The most interesting thing I learned is that these startups pay for multiple competing products. Google Drive and Microsoft Office, Zendesk and Hubspot, or Rippling and Deel appear together on their balance sheets.

Why? In part, it's because these startups are pulled between the software needs of their customers, advisors, and employees. Many of their teams have a strong preference for certain products, but their customers, VCs, and informal advisors like others. Because they are so dependent on these people for growth, they're willing to bend over backwards to keep them happy—including by buying duplicate software.

In one company's case, although their ~10 employees happily used Notion for file management, an early customer preferred Microsoft SharePoint. So this CPO decided to buy a month of SharePoint and consistently shuffle files and folders to and from Notion, just for one customer.

Startups don't like this. They end up doing duplicate work across multiple competing software products, manually shuffling data around.

This is a problem. Startups have to use multiple competing SaaS products, and not only is this tough on the balance sheet, it wastes significant time. Nontechnical staff spend hours repeating the same task to brute-force interoperability. Sometimes, they copy-paste text from a field in one tab to a similar field in another; other times, they repeat long clickstreams.

Every company I talked to (and probably every company out there) uses some form of text document. Two employees at different companies described an internal preference for Google Drive, but a customer preference for Word docs. So every time they need to send someone a document, they export a Google doc to Word, fix image/table formatting where needed, and send it in an email. Seems trivial, but repeated multiple times over the course of a day, the effort and time adds up.

In another case, one digital healthcare company needed an Electronic Medical Record (EMR) to store patients' health data. An executive told me that their doctors were excited about the feature sets of new EMRs coming out (i.e. Healthie or Carbon Health), but ended up using Epic, which "has evolved very little in the last 40 years." EMRs share data across a patient's entire care team, including their PCP or other in-person doctors. The vast majority of them use Epic, so this company's doctors also had to, despite it being an inferior, weaker, less intuitive product. Shuffling data between Epic and a better EMR was out of the question, because of the sheer effort involved. So this startup avoided using duplicate software, but had to use the worse one instead.

Midsize startups want to spend less time dealing with duplicate software, and more time doing real work.

Skills are Dia's greatest value proposition. While Perplexity's Comet and OpenAI's Atlas have similar features, Dia's skills suggestions and gallery allow many more users to speed up repetitive tasks.

Still, adding agentic ability to skills would make them infinitely more useful. Most users' workflows extend past text generation, so agentic skills will repeat a much wider variety of workflows. I'm sure TBC is working on implementing agents across Dia, and I think skills are a worthy place to start.

The midsize startups I talked to would hugely benefit from agentic skills. They suffer from tedious, repetitive clickstreams, which agentic skills could replicate across contexts. Using the same prompt each time, Dia will perform context-aware task execution again and again, vastly reducing the time employees spend on duplicate software.

Simply giving skills agentic ability isn't enough. There are a couple problems that need to be resolved:

• To use agentic skills, someone needs to recognize that they'll find a skill useful, craft a precise prompt, and enter a slash command in the chat window every time they need to do a task. Faced with this startup cost, many employees will end up just doing the tasks themselves.
• Giving LLMs access to the browser creates a need for monitoring. In a work context, people will want to monitor their agents in case something goes wrong. Agents need to do things right, and I suspect there will be a low tolerance for mistakes.

Agentic skills could be implemented in a number of ways. Here are some features I've thought of.

1. Auto-generated skills
   • Monitor a user's clicks. When they repeat a task multiple times, suggest making it a skill.

(Is this even technically possible? AI has the ability to monitor a user's clickstreams, and then write summaries that could be used as prompts for skills. This requires browser permissions that aren't that different from what most Chrome extensions ask for - "Allow this extension to read and change all your data on websites you visit?" - but some companies will hesitate. )

1. Skills panel
   • In addition to slash commands in chat, add an alternate side panel for skills. This will show all of a user's skills, surfacing those that are relevant to the current tab.

3. In-page skills
   • On pages where skills are commonly used, modify their HTML to add those skills as on-page buttons.
   • This could replace LLMs shoehorned into the products they use, with the advantages of personalization and shared memory.

Here are some possible use cases for agentic skills.

• Format a text document for emailing
• Copy Jira tickets to Linear
• Copy an email with AI-generated meeting notes from Granola into Notion
• Rephrase an internal document for distribution to clients
• Move Zendesk customer support tickets into Hubspot
• Mirror a new EMR entry into Epic

I learned a lot about what these users need from Dia. But I didn't fully confirm my hypothesis that they're good early adopters for Dia. In future interviews, I should find out if they're really familiar with TBC products, and if they have the networks TBC needs from its lighthouse customers.

I also have a limited understanding of the new security concerns that will arise with agentic skills. Doing more security-focused interviews, maybe with current Dia users, would help TBC learn how to assuage these fears.

After more interviews, TBC should run A/B tests with its own employees. This would tell us how to start out with agentic skills for customers—which features to include, and which to remove or save for later.

Finally, we should roll out a closed beta for Dia Enterprise customers to test and refine. These could be current TBC product users or other leads.

Midsize startups are a good early customer base for Dia Enterprise. They have to use multiple software products that do the same thing, and so spend way too much time shuffling data between them. Dia is strategically prepared to fix this problem.

Making skills agentic will increase Dia's value prop even more, for these startups and for other enterprise customers, helping TBC serve a broader market and win the AI browser race.