A software company building toward a research firm
Atyantik Technologies has shipped production platforms from Vadodara, Gujarat since 2015. The target is to become a research company, and client work is what funds getting there.
Three things you can check on a first call
In the order you would meet them: the first call, the scoping conversation, then the working week.
The co-founders take production calls
Tirth Bodawala, Chief Technology Officer, and Ajay Patel, Chief Executive Officer, still take production calls. That is a claim about who picks up when a live system misbehaves. It is not a claim about who appears on an org chart. It is the one you can settle in a single question, and the answer is the same before and after anything is signed. Ask who is on the call when a production problem is diagnosed, and whether the answer names a person.
Tirth Bodawala, Chief Technology Officer, and Ajay Patel, Chief Executive Officer. Ask, when a production problem is being diagnosed, who is on that call.
We have turned work down
We have declined engagements where taking them would have benefited us but not the project. The work we choose is the research we are funding, which is why that call gets made that way. There is no count attached to it and no rate to quote. Put it to us directly. Ask what we said no to, and why it did not fit. A firm that cannot answer that has not turned anything down.
Where we are the wrong firm is written down further on, with the place to go instead beside each one, rather than held back for a sales conversation.
A small team, in one place
We are a small team based in Vadodara, Gujarat, and distributed across India. The working day is fixed and published in two timezones, so you can plan around it at scoping instead of discovering it in week three. Where an engagement needs overlap outside that window, the commitment is agreed at scoping rather than assumed.
Vadodara, Gujarat. The working day runs 10:00 to 19:00 IST, which is 04:30 to 13:30 UTC.
Where to go from here
Finding out late
Something on the project changes, and you find out when it is already too late to react.
Surprises are not something anyone can promise away, so the commitment is about the warning instead. It says nothing about who pays for a change. That is a separate question and this does not answer it.
What we commit to
When something changes, you hear about it three weeks early rather than three days late.
You need a supplier that holds the certification, and nobody says otherwise until the contract is drafted.
The disclaimer is the claim. An audit-ready system and a certified supplier are two different purchases. If procurement needs the second one, we are not it, and that is better known now than at signature.
What we commit to
We design and test systems to pass those audits, and we do not own the certifications. GDPR, HIPAA and SOC 2 are all in that category.
How an engagement runs
Four named stages. What happens when the scope moves, and who owns the code at the end, are not among them.
- Kickoff
Goals are aligned and a roadmap is defined before build starts, so both sides start the work from the same document.
- Build
Agile sprints with weekly demos and fast iterations, so what exists is visible every week instead of at the end.
- Validate
Continuous QA and security reviews run alongside the build, rather than waiting for a phase once the code is written.
- Track
Transparent reporting and KPIs, so progress is a number you can look at without asking anyone for a status update.
What one engagement changed
A multi-tenant RFID inventory platform, built for a client we do not name, with the figure taken from the engagement's own record.
The constraint
Stock audits were manual. In an optical store, two to three staff spent a full weekend counting, and the record was only true on the day it was taken. Theft and misplaced stock could go unnoticed for long periods.
The decision
One multi-tenant platform rather than a deployment per retailer, with readers feeding a count that is reconciled against the stock record before anything acts on it, and one shared product catalog.
The outcome
A full audit now takes ten minutes, and missing or misplaced stock is found within five working days of weekly scanning. Both figures are from the engagement's own record.
Where it runs
Many retailers run on the same platform, several stores each, none able to see another's stock. The client is not named here and will not be, whatever permission is on file.
10 minFull stock audit, down from a whole weekend
Read the full case studyWhether to call us
Where we fit
You want the people who scoped the work to still be reachable once it is running. You are willing to pick up the phone.
You can work with a day that runs 10:00 to 19:00 IST, or agree the overlap you need at scoping. Either way you want it written into the scope rather than left to goodwill.
You want a system built to pass an audit, and you either hold the certification yourself or do not need one. Continuous QA and security reviews run alongside the build.
Where we are the wrong call
You need live cover through a North American afternoon as a standing arrangement. Our day runs 10:00 to 19:00 IST, which is 04:30 to 13:30 UTC. Where an engagement needs overlap we agree that commitment at scoping, and where it does not we coordinate asynchronously. If neither of those covers what you need, we are the wrong firm.
You need a supplier that holds GDPR, HIPAA or SOC 2, rather than one that designs and tests systems to pass those audits. We do not hold the certifications, and no amount of scoping changes that.
You want no contact with anyone at all. Where an engagement does not need overlap we coordinate asynchronously by default, so a low-touch arrangement is normal here. What we cannot do is run the work with nobody to talk to, because the co-founders taking production calls cuts both ways.
Everything under About
Grouped by the question that brings someone here rather than by the way the site is filed. Each line says what the destination answers, so what you click and what you get are the same thing.
How the work runs
Method rather than outcome: how the work is run, and what is deliberately kept out of it.
- ProcessWhat happens when the scope moves, and who owns the code when it is over.
- Tech stackWhat the stack keeps out, and where our own pinning rule is not yet met.
What it turned out to be
Outcome in two forms: what was built, and what clients said about working with us.
- Case studiesFour engagements: a rebuild, a migration, a ten-week build, and a platform still running.
- TestimonialsThree named clients on three different worries, and what three testimonials do not prove.
The research target is why the work runs this way
If you want a system built by people who will tell you early and say no when the project needs it, that is the conversation to start.
If the answer is no, we would rather find that out on the first call.