Internal software builders

In 2021, it seemed like there was a new low-code-no-code (LCNC) internal tool builder everywhere you turned. You can define an LCNC tool builder as, “methods of designing and developing apps using intuitive drag and drop tools that reduce or eliminate the need for traditional developers who write code.” These businesses commanded sky-high valuations – Retool at $3.5B – and were viewed as incredibly promising places to work and invest.

In 2024, it feels like the tide has turned. Retool has slowed in revenue growth and has been shedding great people at an alarming clip. The slowing revenue growth seems like a feature of the market over mismanagement of the business: none of the other LCNC companies has been a breakout success.

However, there is some reason to be optimistic: public market competitors like Palantir, Microsoft’s PowerApps, and SFDC’s Force.com and Lightning Platform are doing well, and have specifically called out their LCNC tools as a part of their AI success stories^[1]. Anecdotally, my friends at Watershed talk about the rapid uptake of Dust.tt (AI Retool) within the company, buoyed by the desire to use AI and gain leverage from automating their work.

Could the AI push – forcing every company to think about how it can improve its product or its operations via the new technology – give this sector a new lease on life? Or is the internal tools market an anemic market, doomed to remain fractured and “services oriented” for the near future?

Fig 1. Watch out designers, I’m coming for your job. Sorry this is ugly. I think it illustrates the point that AI could move out the curve here.

I spent 3 months and approximately 80 hours in conversation with users, competitors, and adjacent actors in this space.

User story:

What could an amazing LCNC tool building platform look like?

Imagine that I work as the IT leader at a vertical SaaS series C startup. As the company grows and scales, it feels like we never have enough engineering bandwidth to solve all of the IT, operations and GTM teams’ problems. While the tools in Salesforce, Gong, Notion, or even Marketo can help, the teams really want something custom that might not actually justify a full SaaS purchase. For example, the Security team would like a way to build an intake tool for security RFPs and custom enterprise user requests. They aren’t really frontend people, and building something like this isn’t easy!

As the IT director, I am worried about three things:

• Budget: man, are the SaaS tools getting expensive! I say no to a lot of SaaS buys these days
• Observability & Security: where’s all the data going? Where are people doing their work?
• Efficiency: are the people in the organization able to effectively get things done? The CEO is really worried about efficiency, so I like to show I’m doing my part in enabling the company to do more work/less money.

I buy the Starsmith^[2] platform, a tool builder that makes it easy to spin up, remix, and share AI-enabled internal apps. Unlike Retool, Starsmith makes it easy for everyone in the organization to build AI-powered apps, not just developers. Today, we don’t really think about AI internal tools outside of the silos of specific functions. But with Starsmith, the security team can build an agent to go through all of the RFPs and provide automated responses. The ops team can build a tool that serves as a “queue” for all of the data cleaning requests they get. The data science team can use it to prototype LLM based analyses, like how to align user-submitted schemas with the company’s schema. The product team builds a user-feedback ingestion and summarization tool.

It’s easy for teams to find new Starsmith use-cases because they’re simply able to type in their desired tool in natural language (“I need a tool to help with ingesting user feedback from the support organization around this new beta product, it should integrate with Zendesk, and then allow PM/Eng/Design to sift through auto-categorized data for insight.”) The template gallery is wide and specific – Starsmith can match the natural language description with a customized template very easily. The additional customization by the human involved can be pretty minimal. Any team that can’t “get budget” for a new SaaS tool hears my new favorite saying: “Could you build it in Starsmith?” 

These apps are shared in a gallery that everyone in the organization can access – apps inherit permissions and data visibility from the company’s central auth system. Managers love it, because they can see analytics on the apps and on individual users. The support managers are especially happy to have that visibility! New app builders love remixing apps that others have built. For example, adding little tweaks for the Europe sales team versus the US sales team is a favorite “remix.”

The killer features of Starsmith are:

• Integrations: Starsmith works with our main systems of record, like Rippling, SFDC, and Zendesk. It can write back to these systems via its integrations.  
• Observability: As the IT director, I can see what people are doing, can see analytics on each of the apps, and can be sure our data isn’t leaking.
• Ease of getting started with AI: it’s the best way to prototype AI solutions without having to integrate with APIs or get a full environment set up.  
• Central feed for tool discovery: you can find all of the tools in one place!

Learnings:

Does the vision sound good? Yes? No? Maybe you’re already seeing the flaws!

I sure didn’t! It took a lot of conversations before I concluded that the market was just not interested in buying a “tool builder” instead of buying a “customizable specific tool that solves my needs.” Tool builders are not vitamins or painkillers – they’re the willow tree that has salicylic acid in the bark. You have to chew it a bunch and apply it to the right part of your body before it can be used for pain relief!

My conclusions from that investigation are:

• Great custom software is a competitive advantage. If the user-facing products set the current revenue run-rate potential, internal software sets the speed limit on improvements. I’ve seen this first hand within Stripe: when the company wanted to build out its underwriting and risk functions, the key differentiator for a payments company, Stripe had to use custom built tools instead of off-the-shelf tools.

• As the Palantir S-1 says, “Most software makes companies more similar, not different. Packaged software tends to be designed to meet standardized needs. But commoditized solutions are only sufficient when keeping up with the market — that is, beta — is the goal. When it is time to generate differentiated value — that is, alpha — we believe that typical packaged software falls short. A company seeking to capitalize on its unique resources or to uncover a need unmet by its competitors requires more than software that simply conforms to well-defined best practices.”
• The “chocolate and vanilla” (aka two most popular flavors) of internal tools are:

1. Inbox Alert and Task Management: Inboxes are commonly used to enable operational users to triage, prioritize and complete tasks. For example, I might have a queue of risk reviews or support tickets.
2. Common Operational Pictures: A common operational picture (COP) is a display of relevant operational information shared across multiple organizations to facilitate awareness and collaboration. For example, you might build an application to serve as an “on-the-wall”, big-screen view of the current situation, containing a map, relevant statistics and charts, ways to filter or drill down on data, and connections to other views or workflows.

• There are many successful companies built on this premise, and many LCNC tool builders as a result. SAP, Salesforce, and even Workday have LCNC platforms. The LCNC platform makes a tool like Salesforce usable by every company's sales team, even if their needs are slightly unique. For example, my past employer needed accounts modeled differently than the default SFDC model, because its customers could be governments or academic institutions. This customization was done with an SFDC engineer and the Lightning platform.

• There are three types of LCNC platforms:

1. Feature of System of Record that sells to the team owning that System of Record. The buyer is HR, Finance, or Sales. The user is the ‘sales engineer.’
2. “Developer productivity” tool (Retool, MSFT Power Apps) that primarily sells to developer tooling, IT, or internal tooling teams. The user is the internal tools engineer, or in a pinch the “lightly technical” person on ops teams. Examples include security ops, TPMs, etc.
3. “Productivity tool” with LCNC vibes (e.g. Slack Automations, Airtable, Coda, Excel macros) that sells to IT and primarily serves non-technical audiences.

• The downside of these platforms is that they are still SO hard to customize. Maybe AI can change that. 

• In order to get up and running with Salesforce, you need a special Salesforce “engineer” to help. This is also true of Workday, SAP, and Service Now. An operational leader must also buy time from a technical consultant in order to get the tool to work in a custom fashion. It is important to note that these technical consultants/”system of record engineers” are cheaper than “regular engineers”, but are still more expensive than your equivalently experienced operational hire.
• These platforms have limitations in their customizability. Stripe’s HR team talked about choosing Retool only after they realized Workday Extend could not meet their needs. The Workday Engineer at Stripe said that the primitives in Workday Extend could not “extend” that far.

1. Stripe ultimately built their tool using Retool, even though they had to stretch Retool’s functionality in new ways. Retool has since rolled out that functionality to everyone. Karan and I used the Stripe requirements as a guide, and rebuilt this tool in Superblocks, Retool, & Coda (to gauge difficulty!)

• Ease of customization can be traded off against “power.” If a tool is easy to customize – like Excel – it ends up sacrificing power for that customizability. A reason to be optimistic about the future here is that AI might lessen the degree of the tradeoff between “power” and “customizability” by making it easier to “write code” and customize the platform to one’s needs. In fact, Microsoft’s Power Platform (Power Apps is their drag and drop app builder which has added some natural language prompting capabilities) has seen usage explode. On the Q2 earnings call: “More than 230,000 organizations have already used AI capabilities in Power Platform, up over 80% quarter-over-quarter.”
• Even Retool has a hard time straddling “ease of use” versus “power.” Retool sells to technical teams (internal tools teams.) From my personal experience building something in Retool (the HR performance app!), despite being reasonably technically fluent, we found it almost impossible to create the “9 grid” for talent review using their drag and drop interface.
• Their audience of developers has a tough time because Retool isn’t “customizable enough” for an eng, yet isn’t “easy enough” for someone non-technical.

• The main use cases for LCNC products are replacing a spreadsheet. PowerApps, as the most dominant “unaffiliated with a system of record” tool in this space, is primarily used for basic forms and intake processes where Excel was the previous option. Unlike Excel (where users can inadvertently delete rows, view sensitive data, or mess up formulas), PowerApps provides a clean interface, with SharePoint serving as the database in these cases. As a friend who is a consultant implementing PowerApps at various businesses told me, “it’s always some version of intake or decision funnels.” His examples of PowerApps implementations included: user feedback collection from Support Teams, NPS scoreboards. Other use cases are about custom company processes: a replacement for Culture Amp (employee surveys), a tool for booking rooms, etc.
• Here’s a salient quote from an IT admin:

• Power Apps is great for replacing the Excel sheets that propagate all over every single office around the world.
  
  The problem with Excels, especially as seen from the perspective of IT, is that a) they WILL be created (whether you want it or not), and critical information and processes will revolve around them to run the business, and b)there will ALWAYS be lots (and lots) of copies of every Excel sheet, in Sharepoint, email, network folders, laptops, etc, and c) it is very, very difficult to always keep track of what file is the latest and the correct one.
  
  Power Apps, Teams, and Dataverse for Teams help alleviate these problems, without the need for hiring coders, or expensive consultants. Nor will there be any impossible-to-maintain custom made applications (’cause the summer intern who wrote the app has buggered off back to uni, and there is no documentation or source code left, and even if there is, the code is spaghetti and documentation is a few years out of date and bears no resemblance to reality). Power Apps are meant (mostly) for creating simple apps to replace those Excel sheets. And if done right, everyone will have access to them, without having to install anything on their workstations (SOC will love that), and there will never be any duplicates of the data, it will always be up-to-date, and most importantly, IT is hardly needed for any of it, business can (to a large extent) take care of it themselves.

• The “LCNC as feature” companies are more successful than the “LCNC as the whole product” companies.  Salesforce started as a CRM with an opinionated view of the data model for managing your contacts, leads, and opportunities. But when they started expanding to customers that had different requirements for their data model, they realized that customizability (little to no code) would be vital to success. In Salesforce, a user could customize the data model: they could create new tables with custom columns and relationships, complete with data types and constraints. They then launched their AppExchange six years later. The idea was that even though SFDC’s product was primarily this database for sales, the value that “kept the user in the product” was from the infinitely customizable apps built atop that database and core platform. Salesforce even followed up on the AppExchange launch with the launch of Apex, the Lambda-like service that allowed Salesforce users to write arbitrary code, and VisualForce, a component based UI framework, which allowed users to build UIs compatible with the rest of the Salesforce app. Nevertheless, Salesforce doesn’t sell itself as a “low code tool builder.” It’s a CRM whose killer feature is flexibility. This is also true for SAP: it’s an ERP, or a supply chain solution, that happens to be modular and configurable. It just so happens that once they get in the door, teams start using them to build new tools outside of the original use case. This is also true for other big Systems of Record outside of ERP and CRM – your HRMS, like Workday, also prides itself on being an opinionated database with highly modular and configurable “apps” on top.
• DJs, not musicians: Configuration is valuable! But the most important question is "configure what?" -- people want to have some notion of a domain, a set of "default assumptions", and a data model. We are better at "remixing" than whole-cloth building. It’s easier to tweak the Salesforce data model and its apps to fit your needs than build something new from first principles. Templates are insufficiently opinionated, “factored”, and discoverable to fully solve this problem.

• Data, not just applied layer: It seems like the value lies in specifying “what is the data” beneath the tool building layer, which gives you clarity on the types of use cases for the app builder. Housing and even specifying the data model and the types of actions that can be taken (the “ontology” per Palantir) is even more valuable than apps.

• Consulting/“Forward Deployed Eng” is key to unlocking value: 

• McKinsey^[3] and Palantir often sell together, with McK doing the “management” consulting, and Palantir doing the “software, with a side of tech consulting.” For a hypothetical customer like Delta Airlines, McKinsey and Palantir might be hired for the project of improving the flight tracking and staffing system. However, McK might make $5M and Palantir might make $2M for the initial job (caveat: my guess is that Palantir contracts have way better LTV.) McKinsey will get the contract, define the problem, outline a potential solution, and get buy-in from executives. Palantir does the actual buildout: they unify all of the data, deploy the “ontology”, and build the apps on their low-code-no-code platform. The fact that Palantir makes less money despite doing “more work” was surprising to me, until I realized that it was more valuable to initially ID the problem and get buy-in on the solution than actually build it out. The “how” is much less valuable than the “what” and “why” behind the process, which is why Palantir makes less money at the initial sell. Of course, total LTV is a different story.^[4]
• As my friend said of Stripe’s HR team building in Retool, “The problem is not that HR people lack tool building functionality, or that they couldn't learn the minimal amount of javascript you need to use Retool. The problem is that they build the wrong things: the HR team’s bad policies become bad tools." The management consulting mindset is harder to apply (“is this the best possible HR process?”) than the engineering skillset (of tool building.)
• Salesforce was exceptionally clever here: their ecosystem allowed them to get consulting off their own books, but still allow their users to have hand-holding in problem identification, process recommendation, and implementation. The Salesforce consultant can tell the sales team what to build and why, and then execute the task. Salesforce the company can simply act as software.
• This is one of the places Retool falls down.

1. Retool’s sales team has to serve as consultants, akin to Palantir’s FDEs. Palantir made FDEs work for a software biz with software margins by raising their contract value to $2M minimum^[5]. That’s how they can hire and afford to deploy insanely good FDEs. On the other hand, Retool doesn’t make that much money per contract. I assume their sales team is actually good, but it’s hard to compare quality to a Palantir FDE^[6] 

• To quote an operations person at Flexport: “Our CTO was like, I'm worried about their [Retool’s] business. I don't understand how they're charging rates this low. It doesn't really register for us, it's not a meaningful expense. We're spending 5x as much – really, way more than that – on OpenAI API calls, for example.”

2. Retool is starting to build a consultant network. But in this case, I’d be worried about their speed to jump start that network. It’s hard to do so over such a wide range of domains. Retool is for “everything and everyone”, which makes sourcing a consulting network quite difficult. If they were HR tooling, or CRM, or even “tools for healthcare”, they’d be able to find stronger consultants and build even better templates. Given their very horizontal nature, they can’t come into organizations with deep opinionation about “intelligent defaults” for workflows and dashboards. They couldn’t tell Stripe’s HR team, for example, that 4 rounds of calibration for performance processes in 2024 was truly bananas.

So what?

I think there are two types of “tool builders” that can become $10B+ companies:

• A very vertical specific tool builder (“Retool for trucking”) that can be deeply opinionated about the space. 
• A tool builder as a feature of a broader functional-specific platform that differentiates based on user experience, unique sources of data, and flexibility.

The vertical specific tool builder can command a higher price than the more domain agnostic tools. This is because it can come in with a very specific set of problems and data sources that it already solves, extremely tailored to the company in question. It still might require implementation effort, but finding the right implementers and partners should be easier. For example, a trucking focused Retool competitor might be able to target transportation and logistics consultants, and then have 5 “default modules” it deploys at every business, enriched by some proprietary source of data. The differentiation story against PowerApps will be cleaner than Retool’s story, akin to how Watershed can tell a differentiation story against Salesforce or Microsoft (“SFDC and MSFT consider this a tiny fraction of their business and will never put their best people on it. We’re entirely focused on this domain with the best people, are paying attention to the latest developments, and are perfectly compatible with SFDC and MSFT!”)

The system of record with a tool building platform could be interesting – “provide opinionated software, where the opinions are easily unwound.” For example, an issue that SHV described with Greenhouse was “its data model doesn’t allow an engineer to be a candidate for two jobs at once.” This is because today, Greenhouse has an opinionated data model that users cannot change. However, if Greenhouse made that data model modifiable, like Salesforce’s data model, SHV might have kept using GH. In a world where GH builds an LCNC tool like Salesforce’s tool, a user like SHV could tweak the one or two aspects of the Greenhouse data model that they disagree with, but leave everything else the same. And if AI makes it even simpler for Greenhouse to add that functionality (remember that SFDC had to invent a whole programming language), great, they won’t have to build out such an exclusive consulting network.

I spoke to someone at Netflix who described their use of Airtable – they use Airtable for tracking content production, building essentially a new type of system of record for all the little images and assets associated with a title. I could imagine flexible tools like this (custom to the very specific workflow of the company, but a system of record nonetheless) actually benefiting from some audience specificity. In this case, I could imagine the use case being “marketing ops teams” (that is a broad definition!) that would enable these teams to build workflows in a way they haven’t been able to until now. You can imagine that a lot of the macro-writing here can be entirely abstracted by AI.

It’s not a system of record, but Slack’s “automation” functionality hints at LCNC potential. In many of our user interviews, we found that the nontechnical people within the company relied on Slack automations to do things like offboard large customers. Slack’s “automations” allow you to build tools that involve messaging people within your company, moving content into Slack, or customizing your channels. They could push this opportunity much further, if they invest in it.

Palantir is the most excellent example of this combination: Initially, the vast majority of engineering effort within Palantir was in the handling of data for large government organizations and enterprises. Palantir was opinionated about these choices, and sent Forward Deployed Engineers into these organizations as consultants in order to specify the “ontology” of the data. Once the data stack and data model were clear, Palantir added a product layer on top of the data stack This included a UI builder (Slate), a graph viewer of the ETL (Monocle), a report builder, RBAC, a time series processor, data lineage, versioning of the code, a web-editor and so on. Over time, it became clear that Palantir was a “database with a low-code tool builder on top.” It’s a full solution for a very specific vertical of customers. And it’s paying off. Palantir is currently valued at $53B^[7].

As far as my next steps go, I can’t imagine building a vertical specific version of Retool personally, because I’m not moved by a particular vertical. If I decide to build another type of platform (an HR platform, or a comms platform, or something entirely different!) I think it’d be best to approach it from the angle of “what is the platform and why is it needed” instead of from the LCNC angle.

Appendix:

Malleable software

The whole point of personal computers was to enable personalized software. The vision of the computing pioneers of the 60s was that if the application didn’t do what you want, it would be easy to tweak or augment it to suit your purposes.

However, every development in software seems to be pushing us in the opposite direction:

1. Mobile apps are “walled gardens” that don’t let end users configure apps. While there are more app developers, there are no “editable apps.”
2. Web apps are equally rigid: there are many more apps, but end users still can’t “remix” the app.
3. “Databases” attached to these apps are really hard to access.

To quote Patrick Collison, “Emacs, Smalltalk, Genera, and VBA embody a vision of malleable end-user computing: if the application doesn't do what you want, it's easy to tweak or augment it to suit your purposes. Today, however, end-user software increasingly operates behind bulletproof glass. This is especially true in the growth areas: mobile and web apps. Furthermore, not only is it getting harder to manipulate the application logic itself, but it's also becoming harder to directly manipulate your data. With Visual Basic, you can readily write a quick script to calculate some calendar analytics with Outlook. To do the same with Google Calendar is a very laborious chore.

End-user computing is becoming less a bicycle and more a monorail for the mind.

As a consequence, we need ever more domain-specific software. Rather than use universal tools for handling charts and for manipulating data, we tend to use separate analytics packages for every conceivable application. This is not all bad. Domain-specific tools can maximize ease-of-use and help amortize the cost of complex, specialized functionality. Sublime's built-in ⌘-T works better than every third-party Emacs package. Still, despite these benefits, the popularity of macros and browser plugins strongly suggest that users are smart and want more control.

Should we just give up on our earlier visions of empowered users or is a better equilibrium possible?”

This little bit of tailoring is especially justifiable in the context of an enterprise, when you can measure the incremental value that this tailoring would give you.

The buyer of LCNC tools

There are three types of LCNC platforms:

• Feature of System of Record that sells to the team owning that System of Record. The buyer is HR, Finance, or Sales. The user is the ‘sales engineer.’
• “Developer productivity” tool (Retool, MSFT Power Apps) that primarily sells to developer tooling or internal tooling teams. The user is the internal tools engineer, or in a pinch the “lightly technical” person on technical teams. Examples include security ops, TPMs, etc.
• Feature of a productivity tool (e.g. Slack Automations, Coda, Excel macros) that sells to IT and primarily serves non-technical audiences.

But what kinds of companies buy and use these tools in the first place? Companies that invest in customized internal tools must be companies that think in the long term. They are “deepest growth” companies who see the potential for internal tools to be a way to compound differentiation or further culture. They need to be companies that expect to change so much and scale so quickly that only something custom will do.

This can include early stage, high growth startups (maybe Doordash in 2018?), or big profitable public companies, or big financial firms (Goldman, etc.) Companies that are “deepest growth” companies see custom tooling as a big advantage.

Here’s an example of a brand new startup that is considering a custom stack:

What are “deepest growth” companies? Quoting Byrne Hobart’s framework:

• Shallow companies manage towards whatever the next reporting period is. That might be a month, a quarter, or a year, but regardless they're willing to sacrifice overall expected value if it means that revenue lands in the current period, or if it pushes expenses out to the next one. (If you're ever negotiating a big purchase with a big-enough-to-be-public company, it can be worthwhile to time negotiations so that they're finalized in the last few days of the quarter. If nothing else, salespeople are very responsive then.)
• Mid-depth companies try to target a growth rate over time, and execute a controlled descent towards growth at roughly the pace of GDP.
• The deepest growth companies are the ones that optimize in year N for being able to grow at a fast pace in, say, year N + 5. It's not just "what can we do to hit the numbers this quarter and this year?" but "What can we do today that will be accelerating our growth years from now, and accelerating it enough to overcome the natural course of entropy and of slower growth at scale?"

The key use cases:

• HR tools (build apps that are specific to the company’s culture.)
• Marketing (they rarely have great dedicated tools, and tool churn is common.)
• Rev ops tools (Retool is really trying to push this use case in external marketing)
• Security tools (Snowflake uses Retool for security team’s apps!)
• Support (this is the vast majority of Retool’s existing use cases.)

The history and problem

In 1972, SAP was started as a software consulting company with two core innovations: 1) outputs would be presented on a screen instead of printed out on a tape at the end of the day 2) everything was built atop existing, extensible software rather than built from scratch for each new client.

After two years of running a purely consulting oriented business, SAP released their financial accounting software in 1974. Their intention was to build additional software modules on top of this first accounting module that would use the same underlying database. This was revolutionary at the time.

Salesforce took that idea even further. They started as a CRM with an opinionated view of the data model for managing your contacts, leads, and opportunities. But when they started expanding to customers that had different requirements for their data model, they realized that customizability with (little to no code) would be vital to success. In Salesforce, a user could create new tables with custom columns and relationships, complete with data types and constraints. But it turned out that just customizing the db wasn’t enough. They then launched their App Exchange six years later. The idea was that even though SFDC’s product was primarily this database for sales, the value that “kept the user in the product” was from the infinitely customizable apps built atop that database and core platform. Salesforce even followed up on the App Exchange launch with the launch of Apex, the Lambda-like service that allowed Salesforce users to write arbitrary code, and VisualForce, a component based UI framework, which allowed users to build UIs compatible with the rest of the Salesforce app. They launched Force.com in 2008, which made it easy for developers to launch new apps on SFDC without worrying about infrastructure. Salesforce’s value went beyond just infra, they also provided valuable distribution in the App Exchange.

These companies didn’t market themselves as “all purpose tool builders” even if that is what they were in practice. Even today, Salesforce doesn’t sell itself as a “low code tool builder.” It’s a CRM whose killer feature is flexibility. This is also true for SAP: it’s an ERP, or a supply chain solution, that happens to be modular and configurable. It just so happens that once they get in the door, teams start using them to build new tools outside of the original use case. This is also true for other big Systems of Record outside of ERP and CRM – your HRMS, like Workday, also prides itself on being an opinionated database with highly modular and configurable “apps” on top. Your IT system of record (ServiceNow) is also an opinionated database with a configurable app platform on top.

Palantir arrived on the scene in 2003. It originally sold itself as a data tool. It wasn’t head-to-head competing with an existing software category, like ERP or CRM. Instead, Palantir functioned as a consulting company for large government agencies who had very rigorous security and political standards. They framed their value as collecting and consolidating the data within these organizations and creating a custom ontology. Like SAP, their differentiation was in their own operations: they eventually could build from their platform’s components instead of building something fresh each time. The vast majority of engineering effort within Palantir was in the handling of data – data pipelines. Then, they added a product layer on top of the data stack to make Spark work in an enterprise environment. This included a UI builder (Slate), a graph viewer of the ETL (Monocle), a report builder, RBAC, a time series processor, data lineage, versioning of the code, a web-editor and so on. Over time, it became clear that Palantir was a “database with a low-code tool builder on top” just like all of the other companies. Palantir’s lowest contract size is $2M, and it’s currently valued at $53B. Palantir is often sold via Accenture, Deloitte, and other consulting firms.

The latest entrant to the “low code tool building” space is from the Palantir lineage: it’s an open secret that Retool is a clone of Slate. Retool has reportedly hit ~$75M in revenue and stalled there, despite a valuation of $3.2B. They are having a hard time expanding outside of their existing target market of high-budget software companies and product lead growth with startups: notable users are Coinbase, Doordash, and Stripe. Retool has not landed the motion that is necessary for a low code tool building company: 1) an opinionated view on the data that will be the “foundation” for the tool building workflows 2) an implementation consulting arm to customize and build the first versions of the tool 3) a way to implement their solution in the cloud instead of “on prem.”

Most companies who sell a “low code tool building” product do so as a part of a broader “system of record” (database) offering. Companies like ServiceNow, SFDC, Microsoft, and SAP have large businesses in the “low code tool building” space, but it’s unclear how many of their users are paying for the feature simply because it’s a part of using the CRM or ERP product.

The two exceptions to that rule are Palantir and Retool. Palantir has built a huge business combining the data products with low code tool building, but it’s worth noting that they sell to very specialized clients. Retool is one of the new independent companies in the tool building space, and primarily sells to competent software developers. They are still too small to serve as validation that a large market exists.

Market players

Upmarket Leaders

Microsoft Power Apps

• Integrates deeply with Microsoft 365 and offers robust enterprise features.

Appian

• Strong in case management and workflow automation, appealing to large businesses.

Palantir

• Primarily known for its data integration and analysis capabilities, Palantir has ventured into the low-code/no-code space. It targets sectors like retail, financial services, manufacturing, healthcare, and telecommunications​

(SNOW) Streamlit

• Recently acquired by Snowflake, Streamlit is a framework that allows the creation of custom web apps for data science and machine learning with minimal coding. It's popular among data scientists and is used to build interactive dashboards and applications quickly, though it is more code-intensive compared to traditional low-code platforms​

Upmarket Laggards

OutSystems

• Known for its extensive feature set and strong enterprise customer base.

Mendix

• Offers comprehensive solutions for both developers and business users, excelling in the enterprise segment.

Downmarket Leaders

Retool

• Focuses on building internal tools quickly with a hybrid drag-and-drop and code interface. Used by enterprises to streamline internal processes and integrate various data sources easily​

Betty Blocks

• Focuses on citizen development with strong security and governance, targeting large enterprises.

Quick Base

• Known for its adaptability and strong data management, favored by businesses for quick application development.

Salesforce Lightning

• Provides a powerful platform for building enterprise applications with deep CRM integration.

Downmarket Laggards

Bubble

• Popular among startups and SMEs for creating interactive web applications, with enterprise use cases for custom solutions and integrations.

Adalo

• Geared towards building consumer-facing mobile and web apps with a user-friendly interface.

Glide

• Simplifies app creation from Google Sheets, suitable for small projects and rapid MVP development.

Zapier

• Specializes in automation by connecting various web apps, making it ideal for small businesses needing efficient workflows.

Directual

• Offers a scalable solution for businesses and independent developers with strong data modeling and workflow automation capabilities.

Appgyver

• Innovative but struggles with scalability and enterprise-level features.

Backendless

• Primarily backend-focused, it lags in providing a complete no-code front-end experience compared to others.

Thunkable

• More focused on educational and hobbyist projects, lacking enterprise-grade features.

Airtable Apps?

• https://www.airtable.com/platform/apps-by-airtable

Defunct Companies (Grayed Out)

Kony

• Once a significant player, acquired by Temenos and has since faded from the standalone low-code market.

Skuid

• Struggled to gain significant market traction and has been overshadowed by more robust platforms.

Airplane

• Good read: https://www.onlycfo.io/p/airtable-acquires-and-kills-airplane 

Pending Classification

Superblocks

• Targets developers with a focus on internal tools and aims to centralize various internal processes. It is robust but less widely adopted compared to Retool​​. People using SB say that: 1) they prefer Python to JS 2) it’s much, much cheaper.