You find out whether you were right
Engagements here outlast the decisions made inside them. The longest has run more than a decade, so a year-one shortcut is still there in year four, and so is the engagement.
Three places this work gets done
Most software engineers never learn how their decisions aged, because the contract closes and they move on. Depth, breadth, or the loop that closes: pick two at most, and know which two.
A product company
Choose it when
You want one system, understood to the bottom, over several years. You will know that codebase better than anyone alive.
What it costs you
One problem shape. The market usually decides whether the product survives, which makes your own judgement hard to test separately: a good system inside a failing company looks much like a bad one.
A large services firm
Choose it when
You want scale, a name on your record, and a pipeline of work that keeps you busy without you having to find it.
What it costs you
A ticket wall, usually. Requirements reach you written down by somebody who spoke to the client, and your decision goes back out the same way.
Here
Choose it when
You want the range that comes from 50+ engagements across 7 countries, and you want to be around when the consequences of your own decisions arrive.
What it costs you
An India working day on IST hours, and every change you write read by a senior software engineer before it merges. If you want to ship on your own judgement alone, this is the wrong room.
What gets put ahead of what
1
Holding up under pressure
The output is measured on whether it is tested, monitored and secured, not on whether it demonstrated. That is the standard the work is written to from the first commit.
- Why 2 waits for 1ahead of
2
Architecture that survives the third product line
The brief is to architect for performance, uptime and future growth rather than patchwork fixes. A patch that clears today and blocks the next two years is not a win here.
- Why 3 waits for 2ahead of
3
You in the room with the person paying
No ticket walls. The people who understand the business are the people writing the software. So the reason behind a requirement reaches you as a conversation, not as a line in a tracker.
Every firm claims the first item on a list like this. The second column is the part that costs something.
Three counts of the engagements, not of the people
Three counts of the work itself. How long people stay is a different measure on a different population, and it sits on the page about what happens after you apply.
One engagement, measured from its start date to today.
Counted as engagements, not as companies.
Atyantik capability deck, page 2
*Disclaimer: These are counts of work rather than of people: what has been built, and how long the relationships lasted. None of them says anything about an individual’s terms.
The three kinds of work you would be doing
Each of these builds something different in whoever does it.
| The work | What arrives on your desk | What it makes you good at |
|---|---|---|
| Build and launch | What arrives on your deskA raw idea, or a third pivot, and a date. Nothing exists yet and the shape is yours to choose. | What it makes you good atDeciding under uncertainty, and living with it. Moving fast without breaking later is a single skill. It is learned by being there when the later arrives. |
| Design and experience | What arrives on your deskAn interface that has to load and perform under real use, meeting WCAG 2.2 by default, with higher targets supported on request. | What it makes you good atBuilding for people who are not you. Accessibility and performance are constraints you cannot argue with. That is the fastest way to stop writing for your own machine. |
| Scale and optimize | What arrives on your deskSomebody else’s system, under pressure, breaking. Unstable backends to refactor and pipelines that target 98-99% uptime under normal operating conditions. | What it makes you good atReading code written by strangers under time pressure, and finding the real cause. This is the work that teaches you what the first two get wrong. |
What the years look like from inside
First months
Reading
Joining a system somebody else built
Working inside an existing platform and its written record. Architecture decisions here are documented rather than remembered. The reasoning behind a choice made three years ago is a document you can go and read.
How it feels
Slower than you expected, because every change you write is read by a senior software engineer before it merges.
What that means here
That review is the point, not a probation period, and every change goes through it. Review is not the same as being taught, so there is also a tech lead assigned to you when you join. That is standing practice rather than something you earn by struggling first. Self-teaching is strongly encouraged alongside it, in an environment built for asking out loud, and both halves are true at once rather than one qualifying the other.
The first year
Deciding
Making calls somebody will live with
Choosing the shape of something: the schema, the service boundary, the queue. Whichever one it is, it will be either obviously right or quietly expensive later.
How it feels
Exposed, in the specific way that comes from knowing the engagement will still be running when the answer arrives.
What that means here
The decision is written down with its reasoning. It can be argued with now and understood later. Neither is possible from a memory.
Year two onward
Owning it
Living with what you decided
Carrying a platform through growth, load and the changes nobody scoped. Most engagements continue past launch.
How it feels
This is the hardest stretch and the reason the job is worth doing. Everything you got wrong is now visible, attached to your name, and yours to fix.
What that means here
The commitment on an engagement is no rotation, no context-switching and no handoffs nobody agreed to, so the people who made the decisions are usually the people carrying them. The alternative is that somebody inherits your decisions and you never hear how they went.
Where it ends
Handing over
Leaving something that works without you
Engineering the platform for handoff to an in-house team where that is the direction, or continuing as long as it needs the team.
How it feels
Unusual. Finishing something is not an ending this work often reaches.
What that means here
Both paths are planned for at intake rather than improvised at the end.
Nobody moves through these on a schedule. The phases are what the work asks of you, in the order it tends to ask.
The part of this that is uncomfortable
Where this happens, and what it is for
One building in Vadodara, a firm founded in 2015, and a stated destination that is not staying a services company.
The firm was founded in Vadodara in 2015 and the team is distributed across India. There are no ticket walls, so the person who reviewed your change answers you directly rather than through a tracker. It is also not, in its own account, trying to stay a services company: the stated founding belief is that software only matters if it creates lasting business results, and software engineering only matters if it advances the practice. The target is to become a research company, funded by doing exceptional client work, selectively, for partners who value craft and outcome. That is why work gets declined here even when taking it would have benefited us. If you have ever been put on a doomed project to keep a number up, that sentence is the one worth reading twice.
If you are still deciding
Come and find out whether you were right
Read what is open, and read what happens after you apply before you decide whether to.
Applications go through our hiring system, not a form here.