Forward-Deployed Software Engineer (FDSE)

Overview

WFO Bangalore | 5+ years | AI-native product & engineering

About TPH

The Product Highway is an AI-native product strategy and engineering firm that partners with businesses from the earliest spark of an idea through to enterprise scale. We grew from zero to multi-million ARR in our first year, working with clients across India, APAC, Europe, and North America.

AI got very good at the how. It ships code faster than ever. Almost nothing has changed in the what: deciding what to build, why, and in what order. That's where we live. Software is an approximation of the real world, and what matters isn't lines of code or sprint velocity. It's whether the solution maps to how a business actually works, how customers actually think, and how value actually gets created.

We've rethought our processes from first principles around that belief. In-house AI project managers, near-universal use of tools like Cursor and Claude. AI isn't a feature we sell. It's how we think, build, and deliver.

We take on problems we find genuinely worth solving, and we don't ship things we wouldn't stand behind. Every hire gets us closer to that standard.

The role in one paragraph

When we drop into a client engagement today, the founders and a few senior engineers carry the full technical weight: architecture, integration calls, the 11pm production fire, defending last week's decision to the client's CTO. That worked through year one. It won't scale to fifteen concurrent engagements. We need someone whose job is to be that person at the client. Not the architect who designs and walks away. Not the engineer who waits for a spec. The engineer who lives in the client's codebase, ships the system, owns the technical decisions, and is taken seriously by the client's CTO from the first conversation.

The model is borrowed from Palantir. The FDSE goes where the work is, embeds in the client's reality, and brings TPH's engineering quality to whatever problem is in front of them.

You won't always have the same support structure. Some engagements pair you with a product partner who owns direction. Some give you a PM or the client's own product owner. The smallest ones give you neither, and you carry more of the product weight yourself. Your center of gravity is engineering, but you have the product instinct to operate well regardless of who's in the room.

This is not a role for someone who needs a defined stack, a tight scope, or a manager who breaks down tickets. You get a problem, a client, and a team. You work out the rest, and you have founders and senior engineers behind you when an engagement gets hard.

How we'd like you to apply

Before the requirements, the thing we actually care about: tell us about the most ambiguous engineering problem you've owned end to end. Not the most technically complex. The most ambiguous. We want to see how you scope, sequence, and ship when the answer wasn't obvious.

Send a short write-up with your resume or LinkedIn to chitrarth@theproducthighway.com. We read every response carefully.

What you'll own

Engineering execution on the engagement. Lead the engineering side of one client engagement end to end: architecture, integration choices, deployment, observability. You write production code daily, in whatever stack the engagement requires. This is not a hands-off lead role.

The engineering quality bar on the project. Code review, technical patterns, testing strategy, deployment hygiene. The bar is yours, not the team's average. Speed and quality both come from the same place, which is judgment, so you don't trade one for the other.

Stack-agnostic problem solving. One quarter you're in a Next.js frontend, the next you're refactoring a Django service, the one after that you're wiring up a RAG pipeline. Bring real depth in at least two production stacks and the judgment to pick up a third. Make build-vs-buy-vs-integrate calls with conviction. Build AI-native components (LLM integrations, retrieval, model serving, eval harnesses) where they earn their place, as part of the engineering work rather than a separate practice.

Client-facing technical authority. Sit across from the client's CTO, VP Eng, and lead engineers and hold your own. Translate ambiguous business asks ("we need X by Q3") into an architecture, a sequence, and the risks they need to know about. Be the engineering face of TPH on the engagement, and write the artifacts that matter: ADRs, integration specs, runbooks. Clear enough for engineers to build from, structured enough for a CTO to evaluate.

Leading the engagement team. Set technical direction by having thought hardest about the problem, not by org chart. Mentor SDE2s and SDE3s so your reviews teach them how to think, not just how to fix the PR. Pair tightly with whoever owns product so what gets built and how it gets built stay in lockstep. Most engagements break at that seam, and you're the one making sure ours don't. When there's no PM or product partner, you can scope a feature, write a clear acceptance criterion, and run a sensible trade-off conversation with the client without waiting for someone else.

Must-haves

• 5+ years building production software, with at least two as the most senior engineer on a project or small team where you were the technical decision-maker.
• Real depth in at least two production stacks. Not "I touched it once." You shipped, debugged, scaled, and on-called.
• Embedded client experience: a consulting firm, a high-touch B2B context, or a forward-deployed role at a product company. You know what it feels like to operate inside someone else's business and codebase.
• Strong architectural instincts. You can sketch a system, point at the risks, and propose a path without a separate architect validating every decision.
• Comfortable in front of senior technical stakeholders. You've defended decisions to engineering leaders without hiding behind jargon.
• Shipped AI features in production: LLM integration, retrieval, evals, or a real ML pipeline at scale. Something real users hit, not a side project.
• Product instinct, not just technical instinct. You can scope a feature, push back on a fuzzy requirement, and make a sensible call when the usual owner isn't in the room.
• AI tools are part of how you work daily (Cursor, Claude Code, or equivalent), and you can demonstrate the pace they give you.
• Strong written communication. Your specs, PR descriptions, and async updates are crisp. People know what you decided and why without asking.

Strong pluses

• Background at Palantir, Thoughtworks, a solutions-engineering org, or a similar firm where forward-deployed or embedded engineering is the model.
• First technical hire or early engineer at a startup, where you owned the stack and the direction with no playbook.
• Led or significantly contributed to a legacy modernization: reading old code, finding the seams, replacing it without breaking production.
• Built voice, real-time, or event-driven systems. WebSockets, streaming, audio pipelines, queues at non-trivial scale.
• Multi-tenant SaaS or enterprise platform experience: isolation, billing, RBAC, the messy reality of selling to enterprises.
• Cross-platform mobile (React Native or Flutter) to complement web and backend depth.
• Written publicly about engineering. Not required, but it tells us how you think.

How we work with AI

• Cursor, Claude Code, or equivalent as your primary environment.
• Spec first, then code. You plan work in writing and don't let AI freestyle into a codebase.
• AI across the lifecycle: research, prototyping, review, debugging, test generation, docs, evals.
• AI output is a draft, never a commit. You review everything and know when the model is confidently wrong.
• AI as a system-design lever. When scoping, you consider whether a model, a classifier, or a retrieval pipeline beats handwritten logic.

Probably not your role if

• You've spent your career at large product companies on a single team. You're likely excellent at depth and untested on the range and ambiguity this role demands. Talk to us anyway, but be honest about that gap.
• You think senior means stepping away from code. The most senior people here are the ones still shipping.
• You see client-facing work as a tax. It's half the job.
• One week an engagement is in crisis, the next you're shaping a new one in pre-discovery with the founders. If that volatility wears you down, this will be a hard place to be.

Where it goes

This role grows two ways. Deepen into running multiple engagements at once, becoming the person we call when a project needs serious technical leadership without added overhead. Or move into an engineering leadership track, owning the practice (architecture standards, hiring bar, mentorship across the firm) as TPH builds toward a VP of Engineering function.

Either way the work compounds. Every engagement adds a stack, a domain, and a client relationship. After two years here you've built across more surface area than most engineers see in a decade.