Who we are
Clients work directly with the engineer who designs the schema, writes the queries, ships the release and answers the phone when production misbehaves.
01The practice
There is no account layer between the brief and the build. That is the whole operating model, and it is only viable because the scope is narrow: we do eight things, we have run all eight in production, and we say no to the rest.
The practice rests on roughly nine years spanning IT infrastructure support, database engineering, enterprise application development, security engineering and technology operations — including sustained work on production examination and digital-evaluation platforms serving multi-campus universities, where database architecture, high-volume ETL, enterprise reporting and application security had to hold up under live exam-cycle conditions.
That experience is the reason our work starts at the data layer rather than the interface. Most systems that fail in production do not fail because the screens were wrong; they fail because the model, the transaction boundaries or the reconciliation logic were never made explicit.
Dot Logic India is based in Vadodara, Gujarat, and works with clients across India — on-premise, hybrid or hosted, whichever the operation actually needs.
02Principles
Business rules get modelled in the database, tested, and only then wrapped in screens. An interface over incorrect logic is a faster way to be wrong.
Every capability on this site has been run in production. Where our evidence is narrower than a reader might assume, the page says so.
Application, database, server, network. A firm that only writes code cannot run what it built, and the client ends up holding both ends.
Customisation by extension on a shared codebase, never by forking. The decision that keeps a platform maintainable past its third customer.
03Evidence
Delivered by our principal engineer in prior enterprise roles. Presented as evidence of engineering capability, not as a guaranteed service level.
04Quality & testing
Queries and stored procedures are read through their execution plans before they ship. Implicit conversions, table scans and lock contention get found at design time rather than in the middle of a busy cycle.
Reporting and calculation changes are checked against stakeholder expectations — and against ground-truth data where it exists — before deployment, not after a discrepancy is reported.
Releases are planned around live operational cycles. Changes have gone into production during active examination periods without interrupting them; the same care applies to payroll runs, month-end and audit windows.
Migrations are dependency-mapped before they run: indexes, views, procedures and constraints identified, compatibility assessed, change planned, then validated against row counts and business totals.
Where a process produces numbers someone must trust, we build the check that flags the outlier automatically instead of relying on a person to notice it.
OWASP-based review, least-privilege design and audit logging are treated as continuing obligations across the life of the system.
05How we work
We use LLM tooling deliberately — for first drafts, debugging, architecture exploration, documentation, test-case generation and code review. Every engineering decision, every line that reaches production, and all testing and deployment remain a named human responsibility.
06How we engage
A defined system delivered end to end — requirements, data model, application, tests, deployment and handover.
An existing system that is slow, unreliable or no longer trusted. We diagnose against the real workload and fix the causes.
Ongoing ownership of a running system: releases, production support, incremental capability, and someone who answers.
Describe what it has to do and where it currently breaks. You will get a reply from the engineer who would do the work.