How I Run a 12-Person Software Company and Still Code

Dolphin Infotek is a 12-person company. We build SEBI-compliant software for capital markets — insider trading and UPSI compliance, ESOP management, financial consolidation — for over 500 clients including some of the largest names in Indian banking and financial services. I lead sales and business development. I also write code most days.

People are often surprised by that combination. Here's how it actually works, and why I think it has to work this way for a company our size.

The team is small by design

Twelve people serving 500+ clients sounds impossible until you look at what regulatory software actually requires. Our clients can't use SaaS — compliance rules mean vendors can't touch their data, so every deployment is on-premise, inside the client's own infrastructure. That constraint, which looks like a disadvantage on paper, is actually what keeps us lean. We're not running multi-tenant infrastructure or scaling a cloud platform. We're shipping software that clients install and run themselves.

That changes what "engineering team" means. We don't need twelve backend engineers babysitting uptime. We need a small group who deeply understands SEBI regulation, writes correct code the first time, and can support a deployment model that doesn't give us the safety net of "just push a hotfix to production."

Why I still write code

I run sales and client relationships — most of my day is proposals, renewals, and conversations with compliance officers at banks and NBFCs. But I never fully stepped away from building, for a simple reason: understanding what we sell requires understanding what we build.

When a client asks whether our insider trading compliance module can handle a specific SEBI circular's edge case, I can't answer that credibly from a slide deck. I need to know the data model. When we scope a change request, I need to know whether it's a two-day fix or a two-week one — not because I'll always be the one doing it, but because I can't sell what I can't estimate.

The other reason is more personal. I like building things. Sales without building becomes abstraction layered on abstraction. Staying close to the code keeps the sales conversations honest.

Where AI tools actually changed things

The biggest shift in the last year hasn't been hiring more people — it's using AI coding tools to close the gap between "I understand this problem" and "I have working code." Debugging a Git issue on a locked file, migrating version control history, prototyping a Flutter screen — these used to mean pulling a developer off client work for half a day. Now I can often get there myself, faster, and hand off something concrete instead of a vague description.

That matters more at twelve people than it would at two hundred. Every hour a developer doesn't spend on my exploratory question is an hour they spend on a client's actual problem.

The trade-off, honestly

This doesn't scale forever. There's a single point of failure risk in a company this size — one person leaving can hurt more than it would at a larger org. We manage that through documentation, cross-training, and a delivery lead who owns continuity even when I'm deep in a sales cycle. It's not a solved problem. It's a managed one.

I'm writing about this now because I think there's a real audience of people running small, technical companies who are quietly doing the same thing — staying hands-on longer than conventional wisdom says they should, and using AI tools to make that sustainable rather than a bottleneck. That's what this blog is going to be about.