Palantir Foundry for React Developers: 6 Things I Wish I'd Known on Day One

I assumed Palantir Foundry was a fancy dashboard builder.

I was wrong. After years of building in React, where I can wire up anything I want, learning Foundry humbled me for a few weeks. Then it clicked, and it changed how I think about where code should live.

These are general lessons from learning the platform, grounded in Palantir's public documentation and tutorials. If you're a front-end or full-stack developer about to start on Foundry, this is the post I wish I'd read first.

First, a translation table

The vocabulary is the first wall you hit. Most of it maps to things you already know:

Foundry term	Closest thing you already know
Ontology	Your data model and API layer, defined in one place
Object type	A table, or a model in an ORM
Link type	A relationship or foreign key
Action	A validated write operation, like a mutation endpoint
Pipeline	An ETL job that cleans and shapes raw data
Workshop	A low-code UI builder that reads the ontology directly
OSDK	A typed client SDK generated from your ontology
Branch and proposal	A Git branch and a pull request, for data and logic
Space	A top-level workspace: projects plus one shared ontology
Project	A repo-sized boundary for files, folders and who can access them
Marketplace	A package registry for installing and upgrading data products
AIP	The AI layer that works on top of your ontology
AI FDE	An AI agent that builds in Foundry from plain-language requests

Keep this table open for your first week. It saved me hours.

1. It's a data platform first

Ontology, objects, links, actions. The terms sounded intimidating, and the interface looked nothing like the tools I was used to.

Underneath, it's data with an API layer. Once I stopped treating Foundry as a mysterious new paradigm and started treating it like a database with a well-designed API on top, the rest made sense. Objects are rows with types. Links are relationships. Actions are the only sanctioned way to change things, which is exactly what you'd want from a backend.

For me, it clicked the first time I wired a link between two object types. It felt exactly like a foreign key, and from then on the rest of the vocabulary fell into place.

Takeaway: learn the ontology before you touch the UI. Every screen you build sits on top of it.

2. Constraints slow you down, then speed you up

Coming from React, my instinct was to build. I wanted a component, some state and a fetch call. Foundry doesn't work that way, and my first working UI took far longer than it would have in a framework I knew.

Palantir's own tutorials got me unstuck. They're worth doing in order, even the ones that feel too basic.

What surprised me was what happened next. The same guardrails that slowed me down started saving me time: consistent data, permissions handled by the platform, and no glue code to maintain between my UI and my backend.

My own sticking point: I kept trying to change data straight from the UI until I understood that Actions are the only sanctioned way to write. Once I stopped fighting that, things got easier, because every change goes through a path that is validated and permissioned by design.

Takeaway: expect a slow first week. It's the cost of the guardrails, not a sign you're doing it wrong.

3. Build it, break it, fix it

Reading only gets you so far. The fastest way to understand how the pieces fit is to take one small dataset all the way through, the same path Palantir's tutorials walk you along:

1. A pipeline to clean and shape the raw data.
2. An ontology on top of it, with object types and the links between them.
3. A Workshop app to browse and act on that data without writing front-end code.
4. Optionally, your own front end that uses Foundry as its backend through the OSDK.

That last step is where React experience pays off. The OSDK gives you a typed client generated from your ontology, so it feels like working with any well-typed API.

Use branches and proposals from day one. They work much like Git branches and pull requests, and they make breaking things cheap. Expect to break things a lot; each break teaches you more than a tutorial does.

Takeaway: take one small dataset end to end, from raw data to UI. It teaches you how the pieces fit faster than anything else.

4. Your old skills transfer

I expected to start from zero. I didn't.

• Design sense still matters. A low-code builder doesn't make layout, hierarchy or clarity automatic. Users still need a screen that makes sense at a glance.
• Front-end instincts carry over. Thinking in components, state and data flow helps in Workshop just as much as in React.
• Familiar engineering practice, in a new shape. The development cycle maps closely to what you already do:
  • Spaces are the top-level containers. A space holds a set of projects with one shared ontology, and most organizations need only one.
  • Projects sit inside a space and are the main boundary for who can access what. Think of a project as a repo with its own permissions.
  • Branches and proposals are your feature branches and pull requests, for pipelines and ontology changes as well as code.
  • Marketplace is where finished work gets packaged as a data product that others can install, with upgrades delivered through release channels. It's the closest thing to publishing a versioned package and promoting it through environments.

Takeaway: you're not starting over. You're translating.

5. Explore before you build

This was my biggest lesson.

My React habit was to reach for custom code whenever I needed something. In Foundry, that's often the wrong move. The platform already does a lot natively, and a custom function or widget is code you now have to maintain.

Before writing anything custom, I now ask three questions:

1. Does Workshop already have a widget for this?
2. Can this logic live in the ontology, as an action or a derived property, instead of in the UI?
3. If I do write code, is it in the one place every consumer can reuse?

The best code is often the code you don't write.

Takeaway: spend ten minutes exploring what exists before you spend a day building.

6. AI works best on a good ontology

Foundry's AI layer is called AIP. Its builder tools, including AIP Logic for no-code AI functions, Chatbot Studio for building agents and AIP Evals for testing them, run on top of the ontology. That means AI features work with your real objects, links and Actions, under the same permissions, instead of guessing from free text.

The newest piece is AI FDE, which Palantir describes as "an interactive agent that operates Foundry for you through conversational commands." You describe what you want in plain language, and it picks the right Foundry operations, runs them, checks the result and explains what it did. According to the docs, it can:

• build or change pipelines, in Pipeline Builder or Python transforms
• create and update object types, links and Actions in the ontology
• write functions in Logic, TypeScript or Python and test them with AIP Evals
• build React apps and custom widgets on the OSDK
• audit permissions, access controls and data protection

What reassured me as an engineer is the guardrails. AI FDE works within your existing permissions, you choose which tools and data it can use, and branching is the default: its changes arrive as proposals or pull requests for you to review.

This ties straight back to lesson 1. An AI agent is only as good as the model of the world it works on. A clean, well-named ontology makes AIP and AI FDE far more useful, and knowing the platform yourself is what lets you review their proposals properly.

Takeaway: treat AI FDE like a fast new teammate. Give it good context, keep branching on, and review every proposal like a pull request.

If you're starting on Foundry tomorrow

• Do the official tutorials in order, even the basic ones.
• Learn the ontology first. Know where your data model lives and where changes to it should happen.
• Build one small project end to end, from pipeline to UI.
• Default to native features and write custom code only when you have to.
• Use branches for everything, so breaking things stays cheap.
• Bring in AIP and AI FDE once your ontology is solid, and review their proposals like any pull request.

Every platform humbles you at first. This one rewarded me for slowing down.

What platform humbled you when you first picked it up?