Skip to main content
Autodesk Authorized Developer +91 40-4528 7403 sales@fdestech.com

The FDES story · Hyderabad, 2007

An engineering company
that happens to
write software

FDES started in 2007 because one mechanical engineer got tired of watching good engineers lose their weeks to repetitive drawings — and watching software firms fail to fix it. This page is the longer version of that story.

15+Years turning engineering rules into software
20+Countries running FDES systems in production
Autodesk Authorized Developer Network Autodesk Authorized Developer
Read the Origin Story Hear It from Clients

The company we keep

Teams Who Handed Us Their Hardest Workflows

TITAN Phoenix Mecano Bajaj Mukand Grid Structures MTailor Satrac Vagen AS

The origin

Why the Generic IT Firms
Kept Failing

"I saw engineers wasting hours on repetitive tasks. I knew code could solve it — but generic IT firms didn't understand the engineering. So I built FDES." Kora Nagarjuna Reddy (Nag) · Founder & Managing Director

Here's the gap Nag kept running into: a software firm looks at a drawing and sees a file to generate. An engineer sees tolerances, load cases, and a standard that explains why every dimension is what it is. You can't automate what you don't understand. So FDES was built the other way around — engineers first, who then learned to write serious software.

2007One office in Hyderabad, a handful of AutoCAD scripts, and a strong opinion about who should be writing them.
First winRailway signaling circuits — work everyone said was too complex to automate. It wasn't. It was logic nobody had written down yet. That became the house rule: if the logic exists, it can be engineered into a system.
TodayThose scripts have grown into production automation platforms that engineering teams across the US, Europe, and Asia run every working day.

House rules

How We Decide What Good Looks Like

A rule we can't state in one plain sentence isn't ready to become code.

Ask again

rather than assume once

Engineer it

rather than patch it

Write it down

rather than remember it

Own it for years

rather than ship and vanish

If you're a client

The system does what the spec says — and still does after the third requirements change.

If you work here

You maintain code you'd sign your name to, built on rules anyone can read.

Joining the team

What Working Here Is Actually Like

You'll fit right in if you

  • Need to know why a system behaves the way it does
  • Push back when a requirement doesn't add up
  • Chase the edge case nobody put in the spec
  • Would rather master one domain than sample ten frameworks

What lands on your desk

  • Automation that factories run every working day
  • Problems with no ready-made answer online
  • Codebases we've kept clean across years of change

Look elsewhere if you want

  • High-volume outsourcing tickets
  • Pure UI work with nothing underneath
  • Quick hacks nobody plans to maintain

Depth compounds here. If that's the kind of engineer you're becoming, we should talk.

On the record

What Clients Say Once the Work Ships

"Nag is excellent to work with. They figured out a difficult API that 3 other developers couldn't figure out and delivered 2 days ahead of schedule." Andy Arledge · President, Appraiser Genie
"Although our project was very open-ended and hit many unforeseen obstacles, Nagarjuna and his team were very adaptable. Their Windows Automation expertise is top-notch." Eli Cohen · Founder, MTailor
"FDES allowed us to meet our goals in time and on budget. They always put in the extra efforts to deliver a great result. Highly recommended." Marty Thomasson · President, Gearbox Solutions

Next step

Sound like your kind of company?
Then the next step is a conversation.

Tell us what your team draws, calculates, or configures by hand. We'll tell you plainly what's worth automating — and what isn't.

Talk to an Engineer