AI-Native Systems Builder

AI-Native Systems Builder

We're looking for builders.

Not product managers. Not software engineers. Not AI researchers. People who happen to do all three when the problem demands it — because they care more about solving the problem than about which lane it falls in.

What this role is

Darwinbox is an enterprise HCM platform used by hundreds of large organizations across multiple countries. We're in the middle of a fundamental shift — rearchitecting the product and the company to be AI-native. Not adding AI features to an existing system. Rebuilding how the system thinks, operates, and delivers value.

This role exists because the most important work in that transformation doesn't fit traditional job boundaries. It sits at the intersection of product thinking, systems engineering, enterprise domain knowledge, and AI — and it requires people who can hold all of that in their head while shipping something that actually works.

You will take ambiguous, high-stakes enterprise problems and turn them into working systems. Some will be customer-facing product capabilities. Some will be internal operational systems. All of them will require you to think deeply about the realities of enterprise software — permissions, auditability, multi-tenancy, scale, configurability, edge cases — because that's where most "AI-powered" systems quietly break.

What the work looks like

You won't get a detailed spec. You'll get a problem.

It might sound like: "Our customers can't tell whether their employees are actually using the platform — and neither can we." Or: "Implementation consultants spend 40% of their time on work that should be systematized." Or: "This workflow was designed for humans filling forms — redesign it for a world where AI handles 80% of the steps."

Your job is to go from that problem statement to a production system. You'll need to understand the business context, design the solution, build it (using AI-native development workflows extensively), validate it against real enterprise complexity, and iterate until it works — not in a demo, but at scale, with real customers, in production.

Who thrives here

People who build things outside of work — not because someone asked, but because they saw a problem and couldn't leave it unsolved.

People who use AI tools daily and have strong opinions about where they're transformative and where they're dangerous.

People who think in systems — who instinctively ask "what breaks downstream?" and "what happens at 100x scale?" and "what's the edge case no one mentioned?"

People who've shipped things. Not prototyped. Shipped. In environments where the user didn't forgive rough edges.

You might come from engineering, product, consulting, design, operations, or a path that doesn't have a clean label. We genuinely don't care about the label. We care about how you think, how you simplify, and what you've built.

What we explicitly don't optimize for

• Resume pedigree as a proxy for capability
• Interview performance on problems you'd never encounter here
• AI enthusiasm without AI execution
• Coordination-heavy profiles that produce slides instead of systems
• Prototype thinking without production realism

Why this role exists

Most companies hire PMs to write specs, engineers to execute them, and analysts to measure the outcome. Three roles, three handoffs, three points of context loss.

We're building a company where one person can hold the full arc — problem to system to outcome — because we believe that's how the best enterprise software gets built in the AI era.

If that sounds like how you already think, we should talk.

Location: Hyderabad