In 2026, if you are a Fortune 500 enterprise deploying Claude against a real workflow, Anthropic does not hand you a portal and a SLA. They send engineers. Same for OpenAI’s largest accounts. Same for every Palantir Foundry deployment going back twenty years. The most sophisticated AI and data infrastructure companies in the world all converge on the same delivery model for their top customers: forward-deployed engineering.
Institutional commercial real estate has not caught up to this yet. Most CRE technology is still delivered as licensed SaaS with a support portal, or as a 12-month custom build with a hand-off at the end. Both models fail for the work that matters most. Here is why, and what the alternative looks like.
What forward-deployed engineering actually is
A forward-deployed engineer (FDE) is a senior engineer who embeds with the client team during the work. Not a ticket queue. Not an offshore handoff after kickoff. The engineer sits in your workflows, pairs with your analysts, ships code into production that your team uses on Monday morning, and is accountable to outcomes, not deliverables.
Concretely, an FDE engagement looks like this. The engineer learns your IC house view, your reporting cadence, your chart-of-accounts conventions, and the dozen little operating decisions that make your firm yours. They write code into the same repo every cycle, ship it into your tenant, watch how your operators actually use it, and adjust. The cadence is weekly, not quarterly. The interface is a Teams channel and a shared roadmap, not a JIRA queue.
Where it came from: Palantir popularized it
Palantir popularized the forward-deployed engineer in the enterprise software world. From the early Gotham deployments in defense and intelligence through the Foundry rollouts in banking, healthcare, and manufacturing, Palantir made FDE the default delivery model for any engagement where the data was messy, the workflows were idiosyncratic, and the outcome actually mattered. The argument was simple: the customer cannot specify what they want in a SOW because the customer does not yet know what is possible. An engineer in the room figures it out together with the operator.
Two decades later, every category of enterprise software that involves messy data and judgment calls has adopted some version of this model. The reason is not aesthetic. It is that nothing else works.
Why the frontier AI labs all use FDE for top accounts
Anthropic and OpenAI both ship forward-deployed engineering to their largest enterprise customers. The reason is structural. AI deployment is not a one-shot project. The prompt, the schema, the context window, the tool definitions, the guardrails, and the eval set all need iteration as the workflow runs in production. Frontier model capability changes every few months. Customer data drifts. The line between “model issue” and “context issue” and “workflow issue” is impossible to draw without an engineer who lives in the workflow.
A ticket queue optimizes for SLA. An FDE optimizes for outcome. For a chat product where most queries are stateless, a ticket queue works fine. For an AI agent running in your acquisitions pipeline, drafting IC memos with citations against your portfolio, a ticket queue means the customer files a bug, waits three days, and gets back a one-line response. The work degrades. An FDE in the room fixes it that week and ships the fix into your tenant.
Why this matters specifically for institutional CRE
CRE is the textbook case for forward-deployed engineering. Every firm has its own definition of NOI. Its own recoveries logic. Its own waterfall mechanics. Its own LP reporting templates. Its own conventions for how a watchlist property gets escalated. A SaaS platform cannot encode this without flattening every customer into the same opinionated model. A 12-month custom build cannot evolve fast enough to match the actual cadence of a CRE business: a new fund structure, a new asset class, a new LP requirement, every few quarters.
The shape of CRE work also fits the FDE cadence. Deals come in waves. Reporting has quarterly rhythms. AM cycles run monthly. An FDE embedded with the firm ships the new capability it needs this cycle, then the next one, then the one after that. The platform stays current because the engineers who built it are still in the room.
What it looks like inside the firm
In practice, forward-deployed engineering at a CRE firm means the engineer is in your Teams channel for acquisitions, your standup for asset management, and your weekly cadence with your IR team. They have read access to the relevant SharePoint sites and the underlying Yardi instance. They write code into your Azure tenant, deploy it, watch your analysts use it, and refine. They join the IC dry run when the new variance agent is about to run for the first time.
They are also not running an offshore body shop. The engineering leadership is onshore and senior. The augmentation underneath is also senior, working in your business hours, accountable to your operators, not to an account manager in another country.
The honest tradeoff
Forward-deployed engineering is more expensive than a SaaS license. It is also more expensive than a one-shot custom build. The reason firms pay for it anyway is that the work compounds. Each quarter, the platform gets more capability, the team gets more leverage, and the marginal cost of the next workflow drops. Five quarters in, the firm is running on capability that no SaaS vendor and no in-house build could have produced in the same time.
The honest counter-positioning: if your firm has stable, predictable workflows that match an existing SaaS product, buy the SaaS. If your firm has a deep engineering bench and wants permanent in-house control, build it yourself. If your firm is in the middle, growing, evolving, and not interested in either flattening your operation to fit someone else’s data model or carrying a 12-month custom-build risk, forward-deployed engineering is the model the frontier labs all converged on, for a reason.
How RealQuant Labs does it
Our engagements run on the same model. Senior engineers embed with your team after the data layer and the initial AI workflows are deployed inside your Microsoft Azure tenant. The roadmap is tied to AUM growth, deal velocity, and what the business needs this quarter, not to a generic feature backlog. New funds, new asset classes, new LP requirements, new agents, new integrations each become another workstream the team ships.
If this is the model your firm wants, the place to start is a conversation about what to ship in the first quarter. We deploy the platform, run the workflows day to day, and ship new capability on a quarterly cadence after that. Same team, more leverage every cycle.
Want to see what your first quarter would look like?
A first call to assess fit. Paid Discovery scopes the architecture and the first workstreams. Forward-deployed engineering ships from there.