everybody has a palantir take, but almost all of them are descriptions of the visible output.
vcs think it is a services company… and sometimes just a “defence company”
data engineers think it is a shitty data product that is closed off
detractors think that it’s a shitty body shop that brands FDEs as tho they’re different from mckinsey
snowflake & databricks thinks they’re “shitty distributed compute services”
consulting firms think of them as “the assholes who only get up or $1M/year minimum”
bulls think that it’s an unbeatable stock that advertises “ontology”, as tho “ontology” is a product category on its own
if i ask claude what does palantir do, i get an extremely strange response….
palantirians themselves describes themselves in equally esoteric terms or strange terms. in a famous article by former FDE Nabeel S. Qureshi, he talks about what palantir is not.
For long-time employees and alumni of the company, this feels deeply weird. During the 2016-2020 era especially, telling people you worked at Palantir was unpopular. The company was seen as spy tech, NSA surveillance, or worse. There were regular protests outside the office. Even among people who didn’t have a problem with it morally, the company was dismissed as a consulting company masquerading as software, or, at best, a sophisticated form of talent arbitrage.
then in 5755 words, he never once tries to say what palantir is. snowflake is a data warehouse. aws is a cloud provider. retool is an internal tool builder. tableau is a business intelligence tool. mckinsey is a management consulting firm. accenture is a technology consulting firm.
but when Alex Karp the ceo is asked “what is Palantir”, his answer was:
which is far from the most esoteric explanation he has ever given when posed this question:
if you have spoken to anyone from palantir, you have heard the same evasive answers: “every problem is a data problem,” “we make software, not slide decks,” or simply “we solve problems.” it took me two years to realize that the ambiguity is intentional. palantir muddies the water because a clean category label would make its operating model much easier to copy.
after 4 years of research, reading & indexing very single page of their product documentation, over 30 conversations w/ friends who used to work there and customers of the company, hundreds of expert interview transcripts, i feel confident that i know more about the company than anyone else on the planet who hasn’t been employed there.
i wrote this essay bc i want to move the discourse away from the low signal bullshit around ”what is or isn’t an FDE”, and towards what is palantir? why is it so hard to compete with? why are there no other companies really in its weight class when every other tech trend (data warehousing / ERP / always has a competitor? why do no CIOs believe that snowflake or databricks or AWS or GCP or Azure can compete w/ Palantir? why do i believe all palantir competitor deploycos funded in the past venture batch are destined to fail? how do you actually build a credible palantir killer?
so… for everyone who isn’t interested in reading 10,000 words about the company’s origin and how they got here completely by accident: what is Palantir at a high level?
Palantir is a vertically integrated outcome based software solution provider
they offer the product of a Tech Consulting (e.g. Accenture)
AKA “solution selling” or “systems integrators”
they offer the product of a Software Company (e.g. Databricks)
they do so w/ a unique outcome based business model (no it’s not even remotely similar to what Sierra / Decagon mean by “outcome based”)
this business model lets them bypass the traditional trade offs of both traditional consulting and software companies.
they’re vertically integrated because they have an extreme elitism towards using their own software and their own services, unlike the rest of the market which is much more polyamorous
so let’s dive in.
this is what the landscape looks like today
when a cio wants to implement a new technology, they usually buy software from one company and implementation or transformation services from another. databricks, snowflake, and aws provide horizontal infrastructure. oracle, sap, workday, salesforce, servicenow, uipath, and retool provide operational or transactional software. then accenture, deloitte, capgemini, mckinsey, or another systems integrator connects it to the actual company through implementation, integration, requirements gathering, change management, and process redesign.
basically every company sits on one side of this divide because the local incentives keep it there.
consulting firms like deloitte are private partnerships, where partners who make decisions are the ones who sell labor hours. while they might market accelerators, platforms, and proprietary software, most of their money flows to the sales teams
this results in their primary investments going towards hiring better sales people
refining their business model around selling “consulting hours” on a regular basis
their engineering teams end up staffed w/ engineers who cannot get jobs at software companies for 2x more
their software platforms end up being one off built every time, bc it isn’t their primary differentiator
on the other side of the market, software companies are valued on high gross margins and scalable product revenue, and services harm those gross margins
VCs encourage founders to dump their services arms / pro-serve teams whenever possible, and outsource to consulting firms
tech company founders early days often try to use consulting firms as distribution into accounts
databricks boasts that 60%+ of their implementations are done by consulting partners
the CEOs of software cos are often awkward engineers, who want to avoid talking to customers / leaving the “selling to sellers” as much as possible.
“solutions engineers” are paid meaningfully less than their software engineering counter parts
this results in solutions engineers being seen as a cost center internally
the result is a mostly empty top-right of the market. deloitte tech is high-services and comparatively software-light. oracle, sap, workday, and salesforce own a lot of software but still rely heavily on external implementation. databricks and snowflake are even more software-heavy and services-light.
then there is palantir. it has actual horizontal software infrastructure through foundry, actual operational interfaces and workflows through ontology and its applications, and actual implementation and transformation responsibility through fdes. it is unusually software-heavy and unusually services-heavy at the same time.
what’s more - the palantir foundry platform is also the most extensive operating system on the market, even among software companies. it can process petabytes of data across systems like databricks, execute transactional tasks like salesforce. if you’re wondering “what can foundry do?” - basically anything that can be done by companies on firstmark’s “MAD Landscape” can be done in Palantir. it is the definition of boiling the ocean, and anyone who tries to pitch a VC on building out this much surface area today would immediately get their term sheet pulled.
the normal ecosystem is also much more polyamorous. pwc, deloitte, accenture, and the other integrators each work with snowflake, databricks, oracle, sap, salesforce, and whatever other package the customer already owns. in fact those consulting firms usually make these combination solutions that involve combining services from AWS, Snowflake, Retool, etc. regularly.
palantir’s services organization and palantir’s software are far more tightly coupled than the partner ecosystems above.
an FDE once told me a story about how “they heard a rumor that a palantir project had an @accenture.com email domain staffed in their channel and billed like an FDSE” — the way he said it made it sound like it was the most horrendous thing in the world. they’re kind of like the apple of the software ecosystem.
so how did palantir get here?
the three things that make palantir special—and the three inputs that made them possible
palantir occupies this position because three unusual historical inputs reinforced one another. it spent twelve-ish years wandering through the commercial product-market-fit desert—meaning a long period before broad, legible, repeatable commercial product-market fit, not twelve years without customers or revenue. it had access to patient capital, including peter thiel and the founders fund network. and it worked in government environments that lacked the modern cloud primitives snowflake already had.
those inputs produced three things.
first, palantir built a differentiated talent pool: software-engineering-quality people doing implementation work, selected by a brutal and unusually orthogonal talent filter while the company was still messy, ugly, and not particularly hot. the long gestation period also let palantir promote much of its leadership from inside.
second, it built an unusually broad product relative to this comparison set. early government environments lacked a usable modern stack. software-engineering-quality people spent their time inside the customer and fed what they learned back into product design. the resulting platform touches petabyte-scale analytical workflows, transactional and operational guardrails, and on-premises environments at the same time.
third and most importantly: it built an outcome-driven, project-like business model and culture. palantir’s s-1 described pricing as generally fixed, multi-year, and based primarily on anticipated customer value. this outcomes based pricing model let’s them suffer from NONE of the misaligned incentives with customers that traditional software and consulting companies produce at scale, when working forward from consumption or billable hours. it makes edge cases economically possible when they do not fit an hours- or consumption-driven model, and supports a longer bet on a customer than a conventional consultancy makes when each project has to stand on its own.
the rest of the essay is those three outputs, starting with the people.
being a not hot company w/ a high talent bar for 12 years produced differentiated talent
the cliché is that palantir hires stanford and mit kids. that is true-ish, but analytically weak, because every technology company claims it hires smart people. the actual insight is that palantir stacked a series of mostly independent filters on the same person.
the fde archetype in my interviews had to pass a real software-engineering interview. they had to have a school or background that gave them very good outside options. they had to be willing to travel and live inside the customer’s mess. they had to want operational work instead of a comfortable consumer-software job. they had to join when palantir was neither cool nor especially legible. and they had to be mission-driven, contrarian, or patient enough to stay.
every filter removes a different kind of applicant. what survives is not merely a smarter consultant. it is a very specific kind of engineer.
former employees told me palantir recruited fdes from substantially the same pool as its core software engineers. the company applied a computer-science, coding, and systems bar, then forward-deployed those people into airlines, factories, armies, insurers, and other operational environments. that is very different from hiring an operator and teaching them to configure software. mckinsey does not interview its average consultant for production-engineering skill. generalist consulting, implementation, and solutions roles apply a different interview and selection process from infrastructure-engineering roles.
palantir began with engineering talent and taught them operations. traditional systems integrators begin with implementation or domain talent and add technical training. because palantir’s fde pool also built infrastructure, each deployment produced both an immediate customer result and a reusable software primitive for the next customer.
conceptual comparison of two recruiting architectures and their compensation bands.
the elite-school background matters to this argument as a proxy for optionality, not as proof of “better humans.” someone with stanford, mit, cmu, or berkeley credentials had credible alternatives in big tech, finance, consulting, and startups. taking the weird palantir offer therefore revealed a real preference: mission, risk tolerance, contrarianism, or an appetite for hard and unglamorous work.
palantir also recruited this pool with an unusually concentrated strategy. a contemporary stanford observer described palantir sponsoring quarterly gatherings for stanford computer-science teaching staff, recruiting through friend groups, and drawing an estimated 40 to 50 percent of its interns from stanford. course staff interned at palantir, graduated into full-time roles, then identified the next class of course staff. a narrow network kept selecting and reproducing itself.
imperial became a similar beachhead in london. an imperial student interned at palantir in 2015, joined full-time, and later returned for a dedicated department recruiting presentation. other london universities had never heard of palantir - they were surgically asymmetric with their hiring concentration
the cleanest counterfactual is a stanford computer-science student choosing between airbnb immediately before its ipo and palantir. airbnb offered legible prestige, upside, consumer-scale engineering, and a relatively comfortable job. palantir offered government work, constant travel, ambiguity, and materially lower paper compensation. one interviewee remembered a 40 percent gap in a specific comparison. the candidate had already cleared the optionality filter; choosing palantir revealed a preference for the less-consensus work.
travel was another important selector, not merely an annoying part of the job. travel does not itself select for infrastructure skill, and infrastructure skill does not itself select for field tolerance. an fde had to do both. that filters for discomfort tolerance, agency, and risk appetite, and filters against someone optimizing for the most comfortable possible software job.
the role also required operating without formal control of the customer. ted mabrey’s formulation:
“act as if you are the ceo, but with zero authority.”
— ted mabrey, sorry, that isn’t an fde
the fde had to enter an unfamiliar institution, find the actual constraint, persuade the operator, and ship the system.
the talent filter only mattered because palantir gave the people who survived it unusually broad scope. palantir did not send an fde out merely to configure the product, protect a fixed roadmap, or turn requirements into tickets. it treated important customer problems the software could not solve as evidence that the product was incomplete. barry mccardel describes this as distributed r&d:
“individual deployments can have terrible margins, because it’s really r&d, not cogs.”
— barry mccardel, fde culture
by choosing individuals who could clear the engineering bar to contribute to a distributed systems software product, they ensured that all field knowledge gathered by the FDSEs could be communicated as product features to people who considered them peers. the average GCP engineer doesn’t register a sales engineer’s feedback as worth anything, because of structural incentives, but the palantir “devs” and “deltas“ being pulled from the same pool let them turn customer work into R&D.
operational work selected for a rare kind of computer-science graduate. most stanford cs students do not dream about reconciling erp data, fixing factory scheduling, or tracing food waste. the ones who choose that work care about outcomes outside the codebase and tolerate messy human systems. they can move between a database, a user interface, a stakeholder meeting, and a warehouse floor.
palantir was therefore not simply “uncool.” it was obscure to the broad market while already becoming extremely high-status inside a few tiny computer-science microclimates. the mass-market prestige choice moved from google, microsoft, ibm, and apple, to facebook, uber, airbnb, and doordash, then to crypto, and now to the ai labs. palantir built a private prestige market inside selected classrooms and friend networks. that is a much more precise talent strategy than buying broad employer awareness, and it created a useful double filter: the candidate could know palantir was elite while still having to explain the weird government company to almost everyone else.
one former tech-lead manager described palantir’s hiring bar as orthogonal to market consensus, not simply higher. they saw palantir hire candidates rejected by other prestige employers and reject candidates holding offers from them. palantir cared about a separate internal shape: independent thought, high agency, and the ability to cross technical and human systems.
but none of this would’ve been possible w/o having extremely patient capital from founders fund that was willing to underwriting an extremely long R&D time horizon.
the willingness for investors to let Palantir have a 12 year R&D cycle let them build a surface area unimaginable to any other company
foundry combines three capabilities that normally live in different products.
the first is analytical infrastructure at real data scale and latency: large-volume and streaming data, pipelines, models, and analytics—the territory of databricks, snowflake, and bigquery.
the second is operational and transactional systems: applications, workflows, decisions, guardrails, actions, and writeback—the territory of sap, salesforce, servicenow, uipath, and retool.
the third is the ability to run the whole thing on-premises, air-gapped, or at the edge. foundry is not a thin application sitting on top of an assumed public-cloud stack.
ontology is the connective tissue between all three. it maps the underlying data and models into objects, relationships, permissions, and business logic. it turns analytical results into governed operational actions, then writes those actions and decisions back as new analytical data. “ontology” itself is not new. the differentiation is using an object-first semantic layer as the read-write operational layer for the entire company.
the rest of the data industry arrived at the semantic layer through business intelligence and olap. lookml and older bi semantic layers translated warehouse tables into dimensions, measures, relationships, and centrally defined metrics. their job was to define revenue once, generate the correct sql, and make every dashboard return the same answer. the loop was warehouse to semantic model to query to dashboard. it ended with an answer.
the modern data stack tried to pull that logic out of the bi tool and make it universal. in 2021, benn stancil called the metrics layer the missing piece of the modern data stack. transform and metricflow, supergrain, cube, dbt, and others pursued versions of it. the technical idea was mostly right, but the standalone category never became the center of the ecosystem. supergrain pivoted, dbt acquired transform, and downstream applications refused to surrender their semantics. tristan handy described the problem as both technical and distributional when dbt acquired transform. snowflake’s open semantic interchange attacks the interoperability problem, but its nouns remain datasets, metrics, dimensions, relationships, and contexts. it still standardizes how bi tools and ai agents interpret analytical data.
workflow automation developed from the opposite direction. zapier and n8n begin with triggers and api actions. retool begins with an interface over databases and apis. uipath begins with a robot operating existing applications. these products execute verbs, but they inherit the nouns and state maintained by the applications they connect. their architectures do not repeatedly reason across billions of historical and streaming records. the market therefore split the problem in half: the data stack has analytical scale without action, while the automation stack has action without analytical scale.
palantir’s ontology developed in the delta between those two ecosystems. it models both the nouns—aircraft, parts, suppliers, and orders—and the governed verbs—reschedule, allocate, approve, and write back. the loop is data to object to analysis to decision to action to updated state. lookml standardizes how an organization reads its data. ontology attempts to standardize how the organization reads, decides, and acts.
the modern data stack built semantics without action. the automation ecosystem built action without analytical scale. palantir built the connective tissue between them.
the sprawl of the product makes the same point another way. most individual foundry surfaces have a recognizable public counterpart. workshop resembles retool. workflow builder overlaps with uipath. contour overlaps with hex. quiver overlaps with tableau. vertex overlaps with neo4j bloom. pipeline builder overlaps with dbt canvas. ontology manager overlaps with lookml. slate overlaps with webflow as a visual application canvas.
palantir did not invent every interface, and the pairs do not have feature parity. the public counterparts are eight separate companies with separate data models, permissions, state, and commercial incentives. the palantir surfaces share the same objects, actions, permissions, lineage, and operational state. an fde moves from a pipeline, to an object model, to an analysis, to an application, to a writeback workflow without asking eight vendors to agree on what an aircraft is.
so how did this start?
palantir did not begin as “the ontology-powered operating system for the modern enterprise.” it began as what we would now call a neo4j competitor, building graph-database software for counterterrorism operations. this is, in retrospect, a completely normal route into airline scheduling.
palantir began in 2003 and released gotham in 2008 for intelligence customers. gotham turned signals, informants, accounts, locations, devices, and events into objects and relationships, then let investigators traverse the network. this graph-database origin explains the word “ontology.” olap products built semantic layers to make every dashboard agree on revenue. gotham built an ontology to find out who owned the burner phone.
government customers then forced palantir to build extremely dense data connectors below the graph. they had no public cloud, clean apis, standard identity, or even a connected network. palantir built synchronization, lineage, permissions, deployment, and upgrades across on-premises, classified, and air-gapped systems. “just push it to aws” is not useful deployment advice inside a bunker. the government turned a graph product into a full-stack data platform.
once palantir controlled the graph and the connective tissue underneath it, it added analytical workflows and sold the commercial version as palantir finance, later metropolis: fraud and investigation wearing a collared shirt. jpmorgan engaged palantir in 2009, and its insider-threat team used metropolis to combine employee emails, browser histories, phone gps, downloads, calls, and badge activity. a 2018 bloomberg investigation documented how a 2013 leak investigation exposed the system’s reach and led jpmorgan to drastically curtail its use. the scandal poisoned the metropolis brand, palantir retired it, and the company rebuilt the commercial product as foundry.
palantir released foundry in 2016, combining petabyte-scale pipelines, applications, and governed actions around the original object model. even that date lies: the same s-1 says credit suisse used something called foundry in 2013. palantir product history is less a launch calendar than an archaeological site. deployments accumulated capabilities first; marketing named them later.
covid revealed the value of carrying the whole stack. palantir moved the same system into public-health and vaccine-distribution workflows. in 2023 it began deploying aip, adding models and agents to the same governed data-to-action loop. today palantir presents gotham, foundry, apollo, and aip as distinct platforms. technically, they are. spiritually, palantir product naming is a tolkien-themed witness-protection program for one recurring worldview: model reality, govern who can touch it, and make the answer operational.
this volume of R&D and build out is something no other startup can replicate, and was only possible bc they had 12 years of venture funding to set on fire inside the government w/ no existing data stack.
this is why the government plus the desert mattered. most startups have to find a narrow wedge, show arr, control burn, and deepen the point solution that already sells. palantir spent roughly twelve or thirteen years between its founding and the official release of foundry. “desert” does not mean no customers or no value. it means no broad, clean, legible commercial product-market fit.
patient backing and paying government deployments gave palantir time to keep the ugly shared infrastructure instead of cutting it. software-engineering-quality people inside the customer fed deployment work back into real platform design. every deployment left behind a connector, permission model, object abstraction, workflow primitive, security capability, or deployment tool. enough reusable debris across enough hard environments eventually became foundry.
the government constraint forced full-stack ownership while the time horizon allowed the full stack to compound. a hard environment without capital produces a bankrupt integrator. capital without a hard environment produces a bloated platform looking for a problem. both together, over more than a decade, produced a product that spans analytics, operations, and deployment.
snowflake, databricks, retool, and uipath started from different assumptions. snowflake assumed public cloud, object storage, sql, and an existing warehouse-shaped problem. databricks assumed spark, a data or machine-learning team, and modern cloud primitives. retool and uipath assumed the database or api already worked well enough to build an operational interface on top. palantir’s early deployments had none of those guarantees, so it accepted responsibility from the raw source all the way to the operational result.
those starting points became p&l constraints. snowflake and databricks deepen usage-driven analytical primitives. retool and uipath deepen the operational surface. building the opposite half requires huge r&d, deployment labor, and customer-specific workflows that would conflict with the economics and product focus those businesses currently optimize for.
palantir’s differentiation is not “better etl,” “a graph database,” or “an ontology” in isolation. it is the connective tissue across analytical scale, operational action, and hostile deployment environments. foundry did not create the deployment model. more than a decade of deployments created foundry.
the deployment model shaped more than the product. it also shaped the economics of the account.
building for a monopsony buyer meant they could develop a unique business model aligned w/ the long term
the business model is genuinely different because the three comparison sets run three different meters.
snowflake and databricks run a usage meter. compute and consumption drive revenue. software margin subsidizes solutions architects, but their work still has to create enough future consumption to justify their salary. a project can create enormous customer p&l value and remain unattractive when it barely moves consumption. helping the customer do the same work with fewer queries reduces consumption revenue at the margin. the product company therefore prioritizes workload growth even when everyone involved genuinely wants the customer to succeed.
accenture, deloitte, and normal consultancies run a labor meter. more hours, people, and scope mean more revenue. each project carries its own delivery margin. putting $20 million of people against a $10 million contract is not a long-term investment; it is a blown engagement. the consultant does not own the recurring value of the software or process that remains after the team leaves, so it cannot justify a giant current loss in exchange for the customer becoming much better five years from now.
palantir runs an account or outcome meter. contracts vary, but palantir underwrites the future cash flows of software embedded inside the customer. in a stylized example, a $10 million deployment creates $100 million of customer value and becomes a durable $10 million annual software relationship. palantir rationally puts $20 million of effort into year one. the initial deployment looks irrational on a project p&l and rational on the lifetime economics of the account.
former employees tell a palantir legend that makes the philosophy comically literal: karp sits with a customer ceo at the end of the year and negotiates over the value created. palantir says the deployment delivered $25 million; the ceo says $15 million; they split the difference. the folklore reveals how people inside palantir saw the relationship: a high-trust argument about institution-level value, not a seat count, a compute meter, or a rate card.
the incentives created by each primary business model.
this is principal risk, not hours or consumption. palantir puts its own labor and capital at risk before the account proves it will pay back. the initial overinvestment produces attractive lifetime economics only when the account becomes important enough to renew and expand.
palantir described this directly in its 2020 s-1 as acquire, expand, and scale. in acquire, palantir offered pilots at no or low cost, paid the bill, and operated accounts at a loss with no guarantee of future returns. in expand, the company invested again to understand the customer’s principal challenges and make the software create results; palantir defined those accounts by negative contribution margin. the 2019 expand accounts had a negative 43 percent contribution margin, and the same customers reached positive 35 percent in the first half of 2020. in scale, the customer became more self-sufficient while the software spread across the operation, so palantir’s investment cost fell relative to account revenue. the 2019 scale accounts had a 55 percent contribution margin, and the top quartile reached 87 percent. contribution margin here is palantir’s non-gaap account-level measure.
one deployment therefore has a very different cash-flow shape from a conventional consulting project. in the stylized model, the customer pays $10 million in year one while palantir spends $20 million and loses $10 million on the account. in year two, the customer pays the same $10 million while delivery cost falls to $2 million. by years three through five, the customer keeps paying $10 million while delivery cost falls to $1 million. the year-one loss bought an installed and configured asset that keeps producing revenue while requiring much less labor. a consultancy cannot underwrite this because the next year’s software cash flow does not belong to the consultancy.
successful deployments also create account expansion. once the first project works, palantir can sell the next p&l-moving workflow into the same institution. in the illustrative expansion case, the $10 million project is not merely renewed; it earns the right to launch several more $10 million projects. every new deployment has an expensive acquire or expand period, while older deployments mature into scale and subsidize the new ones. in the model, account revenue compounds while total delivery cost eventually flattens.
this is why palantir invests in a first small or stupid project far more aggressively than its apparent contract value justifies. the commercial model changes which projects the company takes. usage-priced software deprioritizes valuable workflows that create little consumption. a consultancy avoids work whose current-year delivery cost exceeds the contract. palantir takes the edge case with low immediate revenue and high implementation cost when the workflow will become a durable software asset, the customer will renew it, and success will open several larger projects elsewhere in the institution. weird customer-specific requirements become shared platform capability instead of dying as out-of-scope requests.
the business model buys the freedom. the culture determines what palantir does with it.
a repeated interview theme is that the customer is the institution, not merely the buyer. doing exactly what the buyer says protects the deployment only until that buyer leaves. former employees told me palantir aims to become known inside the institution as “the thing that reduced food waste,” “the thing that helped airbus ship airplanes faster,” or “the thing that increased conversion.” a p&l result survives an executive sponsor. a good relationship with the buyer does not.
one friend who spent years at palantir called the culture “a secret mission from karp to save the company from itself.” buyer happiness still matters, but it is a constraint rather than the final objective. customer teams optimize for local scope, political safety, and ordinary work constraints. palantir people genuinely give a fuck about improving the institution anyway.
the archetypal fde enters through a dashboard, workflow, or shitty project that barely matters, then wanders the hallways looking for the coo or operator who cares. they find a sponsor for a much larger project attached to revenue, cost, throughput, waste, or readiness, and use the success of the first deployment to earn the next one. this looks arrogant because the fde does not simply take requirements from the official buyer. they carry a second mandate to find the most important problem the company is failing to solve.
this is the cultural opposite of conventional value engineering. consultancies earn money from stakeholder confidence and perceived value as well as delivery; storytelling, stakeholder management, slide decks, dinners, and political alignment are therefore rational parts of the service. palantir’s cultural claim is that it makes software rather than slide decks. karp publicly contrasts palantir with relationship-led sales, steak dinners, and conventional salesmanship. palantir treats delivering the value as the real work and narrating the value as support.
this mission survives only with the differentiated talent model and internal leadership compounding. you need people capable of finding and executing p&l-moving projects, not merely delivering the scoped implementation. early fdes and leaders learned the model through years of deployment rather than from an external playbook. many leaders entered palantir early and grew up inside the company. structurally, it looks closer to mckinsey’s internal partner pipeline than to a normal technology executive market. people who lived through the desert understand why the company loses money on apparently irrational deployments, and they do not optimize those choices away as obvious inefficiencies.
the continuity is unusually visible at the top. palantir’s entire current executive-management page consists of people who arrived by 2013: alex karp and stephen cohen from the founding era, shyam sankar since 2006, ryan taylor since 2010, and david glazer since 2013. the people with the most authority to normalize the company spent thirteen to twenty-plus years learning why its abnormalities exist.
this business-model layer is the hardest thing to replicate. the payoff now looks obvious, but palantir’s stock still took roughly four and a half years to exceed its 2021 peak after the ipo. even today, almost every vc would balk at flat-pricing a project, putting more delivery cost into year one than the contract is worth, and waiting years for the account to mature. the costliness of the entry point is exactly what keeps competitors from following.
so where does that leave the world?
w/o the opportunity to do R&D over an extremely long and un-specified time horizon, to the tune of up to 10 years — there’s little hope of any company being able to catch up to Palantir.
what really stands out is that no single feature that Palantir Foundry is capable of doing is that special — from UI path to storage to spark processing, every single feature can be notionally cloned by any other vendor, but the detail required to make every single one of those features play well with each other, in an integrated ecosystem that hasn’t leaned on acquisitions to give it features that it’s missing, is polish that most companies cannot afford to subsidize.
palantir, in a lot of ways, cannot be built today, because
it built up a psuedo-monopoly of talent (faang tier software engineers willing to spend 4 months a year in customer offices) that was being systematically underpriced by the market due to locally optimal incentives
it made sense to add infinite scope to it’s product offering over a long time horizon bc their customer was extremely unsophisticated (government) and their investors were infinitely patient with bankrolling the long R&D cycle
if anything, AI makes this even harder to bridge, bc while it might be possible to build foundry in 5 years today, the perception that coding agents are more productive than they are drives VCs & decision makers at big tech companies to demand results in 3 months (which means VCs are basically making it systematically impossible to invest in a foundry scale product)
and the government business model of project based incentives let it find it’s own local optimal business model - something genuinely unique, that none of the new “deploycos” share - that over 5 years produce better results on a per dollar invested basis than the syndicated projects that consulting firms x software companies compete with.
the incentives for traditional software companies to try to build feature parity w/ Palantir are pretty low:
companies like Databricks can’t afford to invest in rebuilding all the transactional capabilities built into Salesforce, bc competition from Snowflake forces them to keep investing all their R&D dollars into improving their point solution for high volume data processing
companies like Deloitte can’t ask partners to lose money for 5+ years to hire a strong team of engineers to spend time in customer offices and try to replicate a platform like this, because the depth of foundry is deceptively deep — and saying “oh add this capability” is trivial to do w/ AI now… but the integrated polish is impossible to replicate w/o a ton more time
i’m extremely bearish on all the deploy co’s abilities to meaningfully compete w/ palantir at all in the next 5-10 years, mostly because the patience to inest and the lack of “grokking” the reasons why Palantir was successful in the first place, so hopefully this shift the narrative a little bit more.
i’ll probably write another write up next week detailing what i perceive as the biggest weaknesses of the existing deploycos on the market (teaser below)… followed by an essay on the chink in palantir’s armor, and another one on how to build a palantir killer
thank you to Nikunj Kothari, Gokul Rajaram, Benn Stancil, Jason Ganz, David Krevitt, Aman Kishore, Eli Draluk, Caelin Sutch, & other members of the TextQL team for reviewing this essay
The reality in technology, including AI, is that 80% of software projects fail.
Palantir projects fail too, at the same rate or potentially higher.
This is worth highlighting in the analysis, particularly given the focus of the article.
There is nothing inherently different about Palantir in this respect. What is different is the overly strict NDAs and security restrictions imposed on customers, which make it much harder for them to speak openly about failures.
My first thought halfway through this was to draw parallels to Epic EHR.
I understand your point on the graph about depth of customer immersion, but I actually think the early days of Epic were "forward deployed" and since its vertical, key business nouns are already defined. I think palantir has to repeatedly discover nouns/workflows since it operates horizontally across industries