Loading
Bhavnagar, Gujarat
A small engineering team in Bhavnagar building software for clients across India and abroad. If you want to see a whole system rather than one corner of one, this is a reasonable place to do that.
We are not going to list perks we do not have. What this job offers is breadth and proximity: a smaller team, a wider surface area per person, and direct contact with the people paying for the work.
On a small team nobody owns a single screen. You will touch the data model, the API, the interface and the deployment on the same project, and you will be in the room when the trade-offs between them get decided.
There is no account layer between engineering and the client. You hear the problem described by the person who has it, which is a faster way to learn what makes software good than any amount of ticket-reading.
Work starts from a documented scope and a review cadence. You should know on a Monday what is meant to exist by the end of the fortnight, and be able to say when that is not realistic.
Code is typed, documented and handed over. What you build here is explainable in an interview years later, because the reasoning behind it was written down at the time.
These are engineering practices rather than culture statements. If any of them sounds like an obstacle rather than a support, that is useful information for both of us before an interview rather than after.
Every change is read by someone else before it merges. The purpose is to spread understanding of the codebase, so review comments explain reasoning rather than just requesting edits.
Strict typing across application code, and automated tests concentrated on the logic that would be expensive to get wrong. We are not chasing a coverage number.
When an architectural choice is made, the alternatives and the reason for rejecting them go in the repository. It takes twenty minutes and it saves the person who inherits it a week.
An estimate that turns out to be wrong is information, not a failure. Raising it early is the expected behaviour, and it is a lot cheaper than discovering it at the deadline.
Deployment, monitoring and the first support questions belong to the person who built the feature. It is the fastest available feedback on the quality of your own work.
New technology enters the stack when a project needs it and someone has read enough to argue for it. Nobody is asked to learn something in the abstract and then never use it.
Most software careers in Gujarat route through Ahmedabad, and from there to Pune or Bengaluru. That path is real and it works. It is also not the only one, and the trade-offs are worth stating plainly if you are weighing them up.
The honest disadvantage of Bhavnagar is density. There are fewer software employers here, so changing jobs means fewer options within driving distance, and there is no weekly meetup circuit to drift into. If your plan depends on moving between five companies in three years, a larger city serves you better.
The advantages are equally concrete. Living costs are a fraction of those in the metros, which changes what a given salary means in practice and how long you can afford to be selective. Commutes are measured in minutes. Family support networks stay where they are. And because the work is delivered to clients elsewhere in India and abroad, the technical exposure is not limited by the size of the local market. The client is remote either way.
The thing that decides whether staying works out is the work itself. A developer in a small city on a maintenance contract for one legacy system will fall behind. A developer shipping current projects, reviewing other people's code and handling their own deployments will not, because those are the same activities that build a career anywhere. Ask any employer here, us included, which of those two the job actually is, and ask for specifics rather than adjectives.
Ask any employer here
Those five questions separate a growing engineering team from a billing operation faster than any careers page can, this one included.
This page lists a position only when a seat is genuinely open and someone is able to make an offer. Nothing is listed today, and we would rather say that than keep a permanent advertisement running to collect applications.
Hiring here follows project work, so openings appear with little notice. A general application costs you ten minutes and means we have somewhere to look first when one does.
How hiring works here
On a team this size there is no ladder with rungs on it, and pretending otherwise would be dishonest. Progression here is a widening of responsibility rather than a sequence of titles.
In the first months the work is scoped for you and reviewed closely. After that you start owning features end to end, including the parts that are not coding: clarifying a vague requirement, saying when an estimate has moved, deciding what is out of scope. Later still, people scope work for others, sit in the first client conversation about a project, and make the architectural calls that everyone else then lives with.
The bottleneck is almost never technical ability. It is whether you can hold a conversation with a client about a trade-off and come out of it with a decision everybody understands. That skill is learned by being in those conversations, which is the main thing a small team can offer that a large one usually cannot.
How responsibility widens
Use the contact form and tell us what you want to work on. Include something you have built and a sentence about why it was harder than it looks.
01
A repository, a live project or a written explanation of something you solved. A CV is fine, but the work tells us more.
02
You get an answer either way. If there is nothing open, we say so and tell you whether we expect that to change.
03
If there is a fit, the technical discussion is about a problem we have actually had, not a puzzle with a trick in it.
Curious about the kind of engineering we write about? The insights articles are written by the same team you would be joining. The team page shows how that team is made up and how the disciplines hand work over.
