Mein Weg · Ambala → Kurukshetra → Mohali → Mumbai → Rotterdam → Gurugram

Ein Air-Force-Kind, das Leben entwickeln wollte - und am Ende Software entwickelt.

Die technische Seite zeigt, was ich gebaut habe. Diese hier erzählt, wie ich dorthin gekommen bin: die Entscheidungen, die Umwege und die Dinge, die nicht nach Plan liefen.

Ambala

01 · Ambala Cantt., Haryana

Eine Kindheit beim Militär

Mein Vater diente in der Indian Air Force, also wuchs ich auf, wie Soldatenkinder eben aufwachsen: in Garnisonsstädten, unter Menschen aus allen Ecken Indiens, und Disziplin lag in der Luft. Den Großteil meiner Schulzeit verbrachte ich an der Kendriya Vidyalaya No. 2 in Ambala Cantt., Haryana.

2012

02 · Kurukshetra

Ich wollte Biotechnologe werden

In der 11. und 12. Klasse belegte ich Physik, Chemie, Mathematik und Biologie, weil ich mich nicht entscheiden konnte. Am meisten faszinierte mich die Schnittstelle von Biologie und Technologie: im Labor gezüchtete Büffel und Schafe, die Veränderung der Augenfarbe, Saatgut und Pflanzen, die rauem Wetter standhalten.

Meine Lehrer waren ehrlich zu mir: Damals ließ sich damit kein Geld verdienen. Also entschied ich mich nach der 12. Klasse für Computer Science and Engineering am UIET der Kurukshetra University. Überzeugt hat mich die Reichweite. Eine App, eine Website, heute ein LLM - und man erreicht Millionen von Menschen. Und ja, es wird gut bezahlt, und das zählt mehr, als viele gern zugeben.

Was mir geblieben ist Das Feld wählen, in dem die eigene Arbeit die meisten Menschen erreicht - und ehrlich zugeben, dass Geld mitentscheidet.

2016

03 · Igniva Infotech · Mohali

Der erste Job - und eine erste Lektion in Zerbrechlichkeit

Direkt nach dem B.Tech kam ich als Junior Software Engineer zu Igniva Infotech. Dort entwickelte ich einige Essenslieferdienst-Apps, React Native auf dem Smartphone und Node.js mit MongoDB dahinter, neben Produkten für Healthcare und EdTech. Unser Team gewann den Best Team Project Award.

Dann starb der CEO. Das Unternehmen begann, Stellen abzubauen, und ich lernte früh, dass ein Unternehmen aus Menschen besteht - und sich über Nacht verändern kann. Ich zog weiter.

2018

04 · Epitome Technologies · Mohali

Ein System von A bis Z verantworten

Bei Epitome entwickelte ich Novagems, eine Workforce-Plattform für Sicherheitsdienste, und verantwortete das Backend von A bis Z: GPS-Tracking, Geofencing, Lohnabrechnung und eine Einsatzplanung, die 70% effizienter wurde. Zum ersten Mal lag es ganz bei mir, ein komplettes System richtig hinzubekommen.

Als COVID kam, verschob sich alles, und ich musste weiterziehen.

Was mir geblieben ist Verantwortung ist der schnellste Lehrer. Das Problem um 3 Uhr nachts kann man nicht abgeben, wenn es das eigene System ist.

2020

05 · The Lightning Group · Mohali

Eine ganz neue Art von Unternehmen

The Lightning Group war ein Startup mit der internationalen Aufstellung eines Konzerns: Kolleginnen und Kollegen in Kanada, Dubai, Polen und Indien. Für mich war das eine völlig neue Kultur: asynchron als Standard, alles schriftlich festhalten, über Zeitzonen hinweg arbeiten. Wir bauten Moveable.uk, ein mandantenfähiges White-Label-SaaS.

2021

06 · Jio News · Mumbai

Skalierung in zwölf Sprachen

Zu Jio Media kam ich nach einem wirklich spannenden Gespräch mit den Directors in den USA. In rund acht Monaten leitete ich die Neuarchitektur von Jio News von Go → Node.js (TypeScript), einer Plattform mit ~5M Nutzern in 12+ Sprachen, und wurde für die technische Architektur ausgezeichnet.

Dann wurde das obere Management in einem fünfminütigen Anruf entlassen. Jio ist ein Konglomerat, und trotzdem zeigte mir das, wie schnell sich der Boden verschieben kann. Als dann Angebote aus dem Ausland kamen, hörte ich zu.

2022

07 · Bondify · Rotterdam

Tokio oder Rotterdam

Ich hatte gleichzeitig zwei Angebote im Ausland: eines in Tokio, eines in den Niederlanden. Ich entschied mich für die Niederlande und zog mit einer Aufenthaltserlaubnis als hochqualifizierte Fachkraft (Highly Skilled Migrant) nach Rotterdam, um als Backend Engineer bei Bondify die Vertragserstellungs-Engine Template.io zu bauen.

Wir lieferten das MVP in zwei Quartalen, und ich half dem Unternehmen, 826.000 € EU-Regionalfördermittel (EFRE, über das Programm Kansen voor West III) für die Plattform zur Vertragsautomatisierung einzuwerben, rund 40% eines Projekts über 2,07 Mio. €. Doch das Geld blieb knapp. Nach einem Jahr wollte man meinen Vertrag verlängern, konnte ihn aber nicht finanzieren, und am Ende wurde das Unternehmen aufgelöst.

Finanziell hat es sich nicht gelohnt. An Erfahrung umso mehr: ein neues Land, eine neue Arbeitskultur und ein Produkt, das wir von null aufgebaut und live gebracht haben.

Was mir geblieben ist Ein großartiges Team und ein finanziell gesichertes Unternehmen sind zwei verschiedene Dinge. Heute prüfe ich den Runway so genau wie die Rolle.

2023

08 · Gurugram

Bewusst zurück nach Hause

Ich suchte meine nächste Stelle in Europa, aber die Bewerbungsprozesse zogen sich, und ich wollte nicht monatelang warten, statt zu bauen. Also kehrte ich nach Indien zurück und kam als SDE-3 zu CapGrid, einer Cloud-Manufacturing-Plattform.

2025 →

09 · CapGrid · Gurugram

Vom Engineer zur Leitung des Engineerings

Bei CapGrid baute ich die KI-Plattform zur Auftragserfassung, die die Angebotserstellung von 45 Tagen auf 5 verkürzte, und übernahm dann die Infrastruktur und die Technologie-Audits des Unternehmens. Im Oktober 2025 wurde ich zum Associate Director of Engineering befördert; heute arbeite ich in der Funktion eines CPTO - Produkt, Plattform, Infrastruktur und KI - mit einer Organisation von 20 Engineers und schreibe weiterhin etwa die Hälfte der Woche Code.

Niemand hat mich gebeten, die Cloud-Rechnung anzugehen. CapGrid war mit 200.000 $ an AWS-Credits groß geworden, also hatte sich nie jemand um die Ausgaben gekümmert. Als die Credits ausliefen, mussten wir die Rechnung selbst zahlen, und als Director konnte ich nicht daran vorbeigehen. Wir haben sie um 86% gesenkt, von etwa 14.000 $ auf 2.000 $ im Monat, ohne Abstriche bei Verfügbarkeit oder Latenz.

Wenn mich meine Laufbahn eines gelehrt hat, dann dies: Der Titel zählt weniger als das, was gerade gebraucht wird. Was eine Organisation braucht (welche Verantwortung, welcher Stack, welches Problem zuerst), bestimmt den Job. Der Titel zieht später nach.

Das nächste Kapitel kann überall spielen, von der EU bis Singapur oder an den Golf: eine Rolle als Principal, Director oder CTO, in der ich dasselbe in größerem Maßstab tun kann.

Was mir geblieben ist Es geht nicht um die Rolle. Es geht darum, was die Organisation gerade braucht.

Fehlerprotokoll

Geschrieben wie Blameless Postmortems: was passiert ist, was ich geändert habe und was ich deshalb bis heute tue.

2024 Wir sind durch unser erstes unabhängiges Technologie-Audit gefallen

Kontext: Ich hatte gerade vom vorherigen Director übernommen, und es war, soweit bekannt, das erste Technologie-Audit des Unternehmens. Kaum etwas war dokumentiert.
Was passiert ist: Wir fielen durch ein unabhängiges Audit. Die Systeme funktionierten größtenteils, aber wir konnten nicht belegen, wie: keine dokumentierten Workflows, keine schriftlichen technischen Richtlinien und Zugriffsrechte, die weiter gewachsen waren, als irgendjemand sie brauchte.
Was ich geändert habe: Die Workflows durchgängig dokumentiert, die technischen Richtlinien geschrieben und Least-Privilege-Zugriffe für Produktion, Cloud-Konsole und Daten eingeführt - so aufgebaut, dass die Systeme ihre Nachweise selbst liefern.
Ergebnis: Das Audit im Folgejahr durch eine Big-Four-Gesellschaft wurde bestanden, mit mir als alleinigem technischen Verantwortlichen.
Was ich beibehalten habe: Was nicht dokumentiert und belegt ist, existiert nicht - egal, wie gut es läuft.

2025 Eine Planungs-Engine neu bauen, die nie jemand dokumentiert hatte

Kontext: Die monatliche Bedarfsplanungs-Engine lief seit Jahren. Sie war primitiv, eingerostet und völlig undokumentiert.
Was schwierig war: Bevor wir irgendetwas reparieren konnten, mussten wir per Reverse Engineering herausfinden, was sie tatsächlich tat, den bestehenden Workflow aufschreiben und erst dann ihre Schwächen auflisten. Das dauerte länger, als irgendjemand erwartet hatte.
Was ich geändert habe: In zwei Iterationen über zwei bis drei Monate eine überarbeitete Bedarfsplanungs-Engine mit integrierter Prognose-Engine ausgeliefert.
Was ich beibehalten habe: Erst das bestehende System dokumentieren, dann das neue entwerfen. Das alte Verhalten ist die eigentliche Spezifikation.

Muster, die mir immer wieder auffallen

Die teuren Probleme sind die undokumentierten, nicht die schwierigen.
Wer ein System erbt, erbt auch die fehlende Dokumentation. Dafür zuerst Zeit einplanen.
Ein gutes Team ist nicht dasselbe wie ein finanziell gesichertes Unternehmen. Ich prüfe den Runway so genau wie die Rolle.

So weit die Geschichte

Wer lieber Systeme, Zahlen und Stack sehen möchte, findet alles auf der technischen Seite.

Zur technischen Version → E-Mail schreiben