Nandigam Vijay Sai
Let’s talk

Co-founder, FinMoon AI · Hyderabad, India

Technology leader who takes products from first commit to production scale.

I’m Vijay Sai Nandigam, co-founder of FinMoon AI in Hyderabad. I build trustworthy AI, cloud platforms and decision systems. I balance speed, cost, reliability and long-term maintainability.

Discuss an architecture challengeView selected workRead my writing
Building production systems
10+ years
Infrastructure cost reduction
40%
Platform uptime
99.9%
FinMoon AI selected, at T-Hub Hyderabad
Google for Startups Hub

Track record

  • FinMoon AICo-founder
  • Google for Startups HubT-Hub, Hyderabad · selected
  • Zemoso TechnologiesPrincipal Software Engineer III
  • Google Cloud CertifiedAssociate Cloud Engineer
  • Amrita School of Engineering, BangaloreAlumnus · 2010–2014
  • AI systems
  • Cloud platforms
  • Kubernetes
  • Product engineering

Selected outcomes

Work with measurable impact.

From a founder’s bet to platform-scale infrastructure. The result first, then how it was built.

All work

01Co-founder · AI product

FinMoon AI

Busy Indian professionals make tax, insurance, loan and investment decisions alone, against products built to confuse.

2,000+

applications, and FinMoon AI was selected for the Google for Startups Hub at T-Hub, Hyderabad

  • 200 users in the first beta

An AI assistant that runs the expert decision process, personalised to each user’s finances. It compares options, surfaces risks and hidden costs, and recommends next steps. Not a generic tip; a structured process.

  • LLMs
  • Agentic workflows
  • Product strategy
Read case study

02Lead DevOps Engineer · Cloud platform

Cloud Infrastructure Migration

Legacy systems had to move to the cloud without betting the business on a weekend cutover.

40%

lower infrastructure cost after moving legacy systems to Google Cloud

Moved legacy systems onto Google Cloud Platform with infrastructure as code and automated delivery, improving scalability while cutting the bill.

  • Google Cloud
  • Kubernetes
  • Terraform
  • CI/CD
Read case study

03Principal Software Engineer · Distributed systems

Microservices Platform

A high-traffic product needed an architecture that keeps serving users while parts of it fail.

99.9%

uptime, a budget of about 43 minutes of downtime a month

  • Millions of users served

Designed and implemented a service architecture for a high-traffic product, with caching, containerised deploys and orchestration built for failure.

  • Spring Boot
  • Docker
  • Kubernetes
  • Redis
Read case study

Operating principles

Engineering decisions are business decisions.

The principles I bring to every team, product and architecture review.

  1. Architecture before AI

    Understand the constraints — cost, latency, trust, failure modes — before choosing a model. AI is a component, not an architecture.

  2. Cost is a feature

    Every architectural decision is also a financial one. I design with the cloud bill open in another tab.

  3. Ship the MVP, earn the scale

    Build the smallest thing that proves the problem is real, with seams in the right places so it can grow without a rewrite.

  4. Platforms are products

    Internal platforms have users too. If developers route around your pipeline, the pipeline is wrong.

What I help solve

Where I’m most useful.

Three kinds of problem I take on, judged by what ships and what it costs to run.

  1. AI systems that reach production

    Take an LLM feature from an impressive demo to something you can trust, measure and afford.

    • LLMs and RAG
    • Evaluation
    • Agentic workflows
    • Retrieval and latency
    • Observability and safety
    Discuss an AI system

  2. Cloud and platform architecture

    A platform developers choose to use: reliable, observable, and designed with the bill in view.

    • Kubernetes
    • Distributed systems
    • Storage and networking
    • Deployment
    • Developer platforms
    Review a platform architecture

  3. Product-to-scale execution

    Ship the smallest thing that proves the problem is real, with seams that let it grow without a rewrite.

    • MVP architecture
    • Cost discipline
    • Engineering practices
    • Scaling strategy
    • Technical leadership
    Plan a path to production

The lab

Systems I build after hours.

Where I test ideas before betting a team on them: orchestration, storage and agents, on real hardware at home.

Explore the lab

Kubernetes on Raspberry Pi

A bare-metal cluster with control-plane and worker nodes for experimenting with orchestration and deployment strategies.

  1. kubectl
  2. control plane
  3. workers
nodes
3, bare metal
hardware
Raspberry Pi
runs
Kubernetes
  • Kubernetes
  • Raspberry Pi
  • Docker
  • Linux
Read the build notes

Agentic Home Automation

An n8n agentic workflow that reads email notifications and switches smart MCBs (miniature circuit breakers) accordingly.

  1. email
  2. n8n agent
  3. MQTT
  4. breaker
trigger
email notification
agent
n8n workflow
actuator
smart MCB over MQTT
  • n8n
  • Node.js
  • MQTT
  • IoT
Read the build notes

This site is served from the home-lab Kubernetes cluster, built and rolled out by Argo Workflows and Argo CD on every push.

Writing

Notes from the build.

Field notes on production AI, platforms and leading teams, written down so the next person doesn’t have to relearn them.

All writing

Leadership3 min read

Architecture before AI: a CTO’s checklist for putting LLMs into production

Most teams choose a model first and discover their constraints later. Here is the order I work in instead — and the patterns that make GenAI systems production-grade.

Key takeawayRank what an AI feature needs — accuracy, latency, cost per useful outcome, explainability, data sensitivity — before choosing a model.

Most useful for CTOs putting LLMs into production

Read article

Architecture7-part series4 min read

Enterprise MVP, end to end: from the first workshop to production

An enterprise MVP moves through six phases (requirements, architecture, database design, development, CI/CD and deployment), and each phase must end with a written artefact someone signs off, not just a meeting.

Most useful for Founders and tech leads scoping an MVP

Read article
Portrait of Nandigam Vijay Sai (Vijay Sai Nandigam)
Hyderabad, India

About Vijay Sai Nandigam

I’m a millennial who thinks like a Gen Z hacker in a lab — always asking why, how, and what if.

A decade across the full stack of building software: writing it, shipping it, running it, and leading the teams that do all three. Today I co-lead FinMoon AI, an AI decision assistant for personal finance in India. My engineering home before that was Zemoso Technologies, where I grew to Principal Software Engineer III.

My path went developer → senior developer → lead DevOps engineer → principal engineer → founder. Each step widened the blast radius of my decisions: from a function, to a service, to a platform, to a company. That path is why I think about technology the way an owner does. I weigh risk, cost and speed, and the people who have to live with the system after it ships.

More about me Full history on LinkedIn

Questions

Quick answers.

How Vijay Sai works, in a few short sentences each.

More answers on the About page

How does Vijay Sai approach AI projects?

Architecture first, model second. Vijay Sai pins down cost, latency, trust and failure modes before choosing a model. AI is one component of the system, not the whole architecture.

How does Vijay Sai keep cloud costs down?

By treating cost as a feature. Every architecture decision is also a financial one. That discipline cut infrastructure cost by 40% in a legacy-to-Google Cloud migration.

What runs in Vijay Sai’s home lab?

A 3-node Kubernetes cluster on Raspberry Pi. A ZFS RAID-Z1 NAS on OpenMediaVault. Immich for family photos, and an n8n agent that switches smart circuit breakers. Ideas get tested there before a team bets on them.

Where did Vijay Sai study?

At Amrita School of Engineering, Bangalore, from 2010 to 2014. Vijay Sai is also a Google Cloud Certified — Associate Cloud Engineer.

Contact

Building something difficult?

Turning an AI concept into a reliable product? Untangling a platform bottleneck, or planning the next stage of technical scale? I would be glad to compare notes.

Discuss an architecture challenge