LLM-Assisted Coding & Feature Dense Startup Categories
I spend a lot of time looking at feature dense startup categories, where in order to compete you must build a massive number of table stakes features in order to seriously be considered by your users.
Good examples of this include spreadsheets, architecture, computer aided design, anything serving creative professionals (e.g. video editing, motion graphic editing, photoshop, Figma), 3D design, integrated developer environments, chip design (e.g. Altium), simulation (e.g. Mathworks), and CRMs. A good rubric for this type of startup is that a full time professional “lives” in the tool - e.g. it is the primary tool someone interacts with as part of their day-to-day job. Most highly skilled knowledge workers have a core system of engagement that looks like this.
The classic challenge with building startups in these categories is that achieving feature parity is often necessary in order to be seriously considered. It doesn’t matter that your product is multiplayer, or has cool cloud features, or has AI built into it, etc unless you also still allow the professional to do everything they are used to doing.
As a simple example - if you’re trying to displace Excel but are missing one critical built-in function or one critical hotkey, your user will instantly get super annoyed/frustrated and go back to excel. The root cause of this is that users of such tools tend to become extreme experts of such tools, and their productivity is deeply tied to their proficiency with their tool. Correspondingly, they can viscerally feel themselves becoming less productive the second they can’t do X thing they are used to doing all the time.
This is the blessing and curse of such categories - it is super hard to compete, but if you hit escape velocity you have a crazy hard to breach moat. This is a key reason why Salesforce, Altium, Autodesk, and similar are such enduring giants in spite of generally being old, sort of shitty pieces of software.
The classic implication of this for startups is that you basically have two choices if you want to attack a category like this. Option one is raise a lot of money, spend a long time building, and survive until you hit sufficient feature density - e.g. Figma building for 4-5 years before really making money. Option two is attack the periphery of the space - e.g. Frame.io attacked the collaboration layers around Adobe Premiere, but didn’t attack Premiere in of itself. This can work but often limits upside.
What I find interesting is that LLM-assisted code generation tools may dramatically increase the feasibility of option one. The reason for this is that the functionality required in these categories is typically well understood, well defined, and “obvious” to some extent - it just takes a really long time to build it in totality. This is an insanely good match for LLM copilots & agentic systems, which are quite effective at churning out obvious or well understood functionality.
I am starting to see this play out in various startups I work with - who find that tools like Github Copilot have so much latent knowledge from their pre-training corpus about common features in established categories that they can very, very quickly get you to 90% implementation. e.g. Sequence is able to race through implementing many common audio & color features in video editors because LLMs inherently understand them very well. Similarly, I observe that many of the newer CRM startups (e.g. Clarify) are able to race through covering a lot of the functional requirements in CRMs that traditionally would have been a bigger barrier to entry.
This idea likely extends to other categories of startups where defensibility mostly comes from lots of “grunge work”. Integration companies such as MuleSoft, Plaid, and similar are another good example of this - where a lot of the value came from a team chewing glass for years as they built custom integrations into every single API or bank. These tasks are so amenable to LLMs in many cases that I think this form of moat is less relevant today than it was before.
This is exciting to me because I think it allows startups to focus more on the “craft” of seriously improving the user experience in these categories and innovating on fundamental interaction models, rather than mostly having to focus on table-stakes feature parity.