The working day ends at 19:00 IST
We run on IST, 10:00 to 19:00, which is 04:30 to 13:30 UTC. The hours are protected because a rested developer ships better code than a tired one.
Whether this suits you
Where this fits
You want a stated end to the working day, and an evening that belongs to you rather than to a backlog.
You want your code read by a senior software engineer before it reaches production, on every change you write.
You want the reasoning behind an architecture decision written down somewhere you can go back and read it later.
You want the standards the work is measured against stated before you join, rather than discovered in a review.
Where it does not
Your life runs on another clock, and you need a working day that begins after the India evening has already ended.
You are looking for a role you can do from outside India, from wherever in the world you happen to live.
You want to ship on your own judgement at your own pace, with nobody else signing the change before it merges.
The shape of a working day
The hours are fixed and published in two timezones. Where an engagement needs time outside them, there is a named mechanism rather than an expectation.
- 10:00 IST
The working day starts, and in UTC that is 04:30. Neither end of the range moves when the clocks change somewhere else.
- The default
Coordination runs asynchronously, carried by written updates and shared dashboards. The day is not built around waiting for somebody else to wake up.
- Where overlap is needed
Some engagements need live hours. Where they do, that commitment is agreed at scoping, before anyone is assigned to the work.
- When a sync comes up
A project coordinator can host it, or an overlap shift can be arranged on request. Each of those is an arrangement somebody agrees to.
- 19:00 IST
The day ends, 13:30 UTC. The hours are protected because a rested developer ships better code than a tired one.
What happens to code you write
Every change meets the same sequence before it reaches production, and one of the gates is a person.
Work sits on its own branch. The branch model is GitFlow, so a change has a place to live while it is still wrong.
Unit tests run against it. Integration tests run against it. CI/CD gates the merge. A branch that fails either suite does not go in on a promise to fix it later.
Then a person reads it. Every change goes through code review by a senior software engineer. There is no exception for a small change and none for an urgent one. Nothing you write reaches production on your own signature.
Continuous QA and security reviews run alongside the build rather than after it. It is a named stage of how an engagement runs. A defect found late is not the first time anyone has looked.
Architecture decisions are documented in the TRS, the Technical Requirements Specification. The answer to why something was built one way rather than another is a document. You can read it a year later, rather than needing somebody to still remember.
For full-team buildouts, we pair developers with at least one DevOps and one QA engineer. The pipeline and the test strategy are somebody's job rather than everybody's spare time.
Two things follow from that sequence. The first is that your work gets read, and somebody will have an opinion about the code you wrote on a Wednesday. The second is that the reading is not a formality, because the merge is gated whether or not anybody is in a hurry.
All of it is checkable. Ask about any part of it in an interview, then check it again in your first month.
How the week reaches the client
01
Kickoff
The engagement opens with the client in the room. The outcome for the first release is agreed before anyone opens an editor.
You get
The agreed outcome for the first release, which every demo later in the engagement is measured against.
02
Build
Work ships in increments the client can see. Daily stand-ups and weekly demos are part of the week rather than an interruption to it.
You get
A weekly demo of working software, and a shared dashboard the client can open without asking anyone first.
03
Validate
Continuous QA and security reviews run against the build as it goes. Nothing waits for a phase at the end.
You get
The review findings, raised against the release they belong to while there is still time to act.
04
Track
The work stays visible after it is live. A change to the plan is raised the moment it is known.
You get
The change, told to the client early. We do not promise no surprises. The client hears three weeks early, not three days late.
The bar the work is held to
These standards apply by default. They are the settings the work starts from, so nobody has to argue for accessibility or for a performance budget partway through a build. Every one of them is checkable in an interview.
- Every build designed to be inclusive, WCAG 2.2 by default
- Higher compliance targets supported on request
- Frontends that meet performance budgets on every device
- Speed and smoothness treated as quality criteria, not features
- Edge deployments on green hosting providers, with energy-aware architecture
- Research, tech meetups, open-source contributions and a research arm
- Developers drawn from a pool the firm trains continuously
What that bar produced
A European hyperlocal marketplace connecting independent shops to nearby buyers. This is the performance standard above, applied to a real product.
The constraint
The catalogue had grown faster than the frontend that rendered it, and carts were slow on mid-range phones.
The devices
Performance was measured on the phones buyers actually owned, rather than on a development laptop.
The rendering
Server-side rendering moved the first paint off the phone, so the device itself did less work.
The state layer
The client state layer was rebuilt so a large catalogue no longer meant a large memory footprint.
The onboarding
Onboarding was made repeatable, so a new city was a configuration step rather than bespoke work.
1000+Shops onboarded
Read the full case study
Inside the Vadodara office
The open floor. Founded in Vadodara in 2015, the office runs on one open floor: rows of desks under linear ceiling lights facing a living green wall carrying the Atyantik wordmark.
The meeting pods. Glass-walled rooms sit off a planted corridor, sized for a round table and a printed document rather than for an audience.
The terrace. A planted roof terrace under a canopy of coloured panels, with long tables, wicker seating and planted screens between them.
The lounge. A coral sofa sits under a wide mural of flowing blue and violet gradients, a few steps from the reception desk.
The corridor. A planted corridor runs alongside the glass meeting rooms, connecting the open floor to the rooms that have doors.
Reception. The entrance lobby carries a backlit signage wall reading Delivering Excellence, between a living green wall and a wood counter of snake plants.
The windows. A row of desks runs along the tall windows, looking out over the neighbouring buildings.
When it goes wrong
The project you are on fails.
Software projects do fail. On a small team, the distance between a production incident and the person who wrote the code is short, and that is worth knowing in advance.
What we commit to
Our co-founders Tirth Bodawala, the CTO, and Ajay Patel, the CEO, still take production calls.
You are put on work that should not exist.
The worst stretch of a software engineering career is usually spent on a project a firm took because it could be won rather than because it fitted.
What we commit to
We are success partners. We have declined engagements where taking them would have benefited us but not the project. A project turned down at the start is a year nobody on the team has to spend inside it.
Questions that come up
These are the answers you would get in an interview, which is the reason for putting them in writing first.
Does everything really stop at seven?
What does code review actually consist of?
Do I get DevOps and QA alongside me?
Where is the work actually done from?
Where to go next
Two states, and a different page for each: if you already know the kind of work you want, start with how hiring runs here. If you are still building a picture, the other pages each answer a different question.
Ready now
For a role you would want to apply for today.
- How hiring works hereWho the firm hires, and why hiring runs on no fixed calendar.
- How to applyApplying starts through the careers contact form.
Still deciding
For the questions the evidence above does not answer.