Contact
Let’s talk about the system
Architecture review, a build from scratch, or repairing one that is already in production. Email is the fastest route and always reaches me.
Direct
- Email darshan@digitb.tech Best for project enquiries — usually answered same day.
- Fiverr fiverr.com/darshan272 Scoped, contracted work through the platform.
- LinkedIn Darshan Tiwari
- GitHub github.com/darshan272
Send a message
This form is not connected yet. Nothing typed here is sent anywhere, so please use darshan@digitb.tech — it goes straight to my inbox.
Darshan Tiwari
- Role
- Founder of DigitB Technologies and Solutions
- Based in
- Berlin, Germany
- Education
- Cognitive Sciences, Universität Osnabrück — 2029
I came into this through cognitive science, which is a roundabout way of saying I got curious about how systems learn before I got interested in shipping them. The engineering came after, and it stuck. Now I take a problem from the research question all the way through to the thing that has to stay up on a Monday morning.
Most of my model work has been across three modalities. In vision I fine-tuned a diffusion pipeline for product image synthesis, where the real trick was segmenting the garment and holding it fixed while everything around it gets regenerated. In language I fine-tuned a 7B open-weight model and a smaller SLM for function calling that does not fall over, plus the API ingestion logic feeding them. In speech I did a full fine-tune of StyleTTS 2, building the corpus myself and taking it through a staged training run with style diffusion and adversarial supervision.
Voice agents are where I learned the most about trusting my gut. The transcript is the easy part. The hard part is what happens when a caller talks over the agent, corrects themselves halfway through a sentence, or asks for something the schema never anticipated. You cannot read your way to that. You find it by sitting with enough real calls and rebuilding the turn logic until it holds.
Underneath all of it sits the work nobody demos: retrieval and data pipelines, PostgreSQL and Redis, deployment across AWS, GCP and Azure, containerised services on Linux, and the GPU training infrastructure the model work actually depends on. I treat latency budgets, scaling behaviour and cost per request as decisions to argue out against the specific problem, not defaults inherited from a tutorial.
This field moves faster than anyone can honestly keep up with, so I have made a habit of picking things up quickly and being willing to drop an approach the moment it stops being the right one. Some of the decisions I am proudest of are models I threw away.
Which is why nothing here is a claim you have to take on faith. Every case study names the models I kept, the ones I cut and the reason for each, the papers behind them, and what actually ran in production.