THE PERSON BEHIND THE SYSTEMS
Curious about the problem.
Responsible for the result.
I’m Soma, a software and systems engineer based in Sunnyvale, California. I like the point where an unclear need becomes a concrete system people can actually use.
Soma Sundar
Mamilla
Systems foundation.
Product perspective.
Builder’s curiosity.
A career across layers.
I’ve worked close to the machine in C trading infrastructure, close to users in client-facing retail software, and close to the research in self-supervised learning. Each teaches a different part of the same job: make the system useful, and make it hold up.
My M.S. in Computer Engineering at the University of Bridgeport followed a B.Tech in Electronics and Communication Engineering. That path shapes how I move between software, data, and operational constraints.
Today I build backend and full-stack products, own client delivery at KloudC, and develop Flockara as an independent product ecosystem. I’m interested in engineering roles where the problem crosses boundaries and someone needs to carry it through.
My experience ↗MY PROCESS
Fast learning.
Deliberate delivery.
AI shortens the implementation loop.
Ownership closes it.
- 01
Frame the real problem
Understand the user, existing workflow, constraints, and what a successful outcome looks like. Turn ambiguity into acceptance criteria.
- 02
Design the boundaries
Decide where state lives, how components communicate, what failure means, and what the system is allowed to do.
- 03
Build with context
Use Claude Code with repository context, explicit requirements, examples, and constraints. Review the generated implementation against the architecture.
- 04
Try to break the answer
Debug from evidence, test edge cases, inspect output, and verify the user experience. A plausible result is the beginning of validation.
- 05
Ship, observe, iterate
Own deployment and recovery. Use operational behavior and user feedback to decide what to improve next.
WHERE I FIT
Backend. Full-stack.
Applied AI. Forward deployed.
Different titles, one throughline: understand the problem and own the path to a working product.
Let’s talk ↗