We build software for Philadelphia companies
Building the thing is usually straightforward. The conversation that decides whether it happens is about time. Distributed work costs it. Whether that cost is worth what you gain depends on your project and your team.
- When we are working
Monday to Friday, 10:00 to 19:00 IST, 04:30 to 13:30 UTC, all yearIndia does not change its clocks, so that window never shifts with daylight saving. North American teams sit outside it for most of their day. Work gets scheduled around that rather than pretending otherwise.
- Where your code and deployments sit
Your Git hosting and your cloud accountsCode lives in your repositories and deployments run in your cloud accounts. If you do not have them, we provision them and hand the keys over.
- Where we are
IndiaEvery software engineer is based in India. There is no Philadelphia office, no US entity and nobody on your side of the country.
Tell us what you are building.
You get a reply within one business day, with a technical person on the call.
Start with a paragraph
What it does, who uses it, and what has to be true before you can sign. One business day, technical person on the call.
Three ways to solve this
When you need a software team for a non-trivial project, you have three paths, each with what it costs you in time and what you get for that cost.
The trade-off in time, not in money
Three honest routes to a build for a Philadelphia company. Which one fits turns on how much coordination you can carry, and how soon you need people who are already capable.
Build in-house
Choose this when
You can wait for hiring and onboarding, and you want every person on your own payroll, in your own hours.
It costs you
The slowest start of the three. The capability you need is only there once the hires have landed and settled, and the knowledge you build stays with the people you keep.
Hire a local agency
Choose this when
Your process needs the same calendar and the same time zone for most of the working day.
It costs you
Continuity depends on the firm and the engagement. Read what the contract says about work product before you sign, because that clause decides who owns the code.
A distributed team from India
Choose this when
You can work asynchronously, batch decisions into the next morning, and want a capable team on short notice.
It costs you
Coordination. Time zones do not align, sync work has to be scheduled, and some decisions wait a day. The team stays the same year after year, and ownership is written into the agreement before work starts.
The people we hire are the same ones working on yours
We do not rotate teams between projects or pull engineers onto what pays best this month. The same software engineer works on your team for the duration, and most continue longer. That continuity compounds, and it shows in delivery.
Atyantik capability deck, page 2
Atyantik capability deck, page 2
Atyantik capability deck, page 2
*Disclaimer: All of them run from India.
How the working day, code review and ownership actually run
Distributed work costs time in coordination. The cost is real. But time costs differently depending on what you are buying. Here is what happens inside the time that does exist between India and North America.
Four things that happen inside the overlap
The morning sync
Monday to Friday, 10:00 to 19:00 IST, which is 04:30 to 13:30 UTC, all year. India does not change its clocks, so that window never shifts with daylight saving. North American teams sit outside it for most of their day. Work gets scheduled around that rather than pretending otherwise. A 30-minute standup at the start of the Indian working day covers blockers and the day ahead. You attend only the days your own work needs, not every day. Asynchronous status runs the rest of the week.
Code review
Every line of production code is reviewed by a senior software engineer before it merges. Code lands in your repository. Review happens on your PR. Comments are written in your time zone, resolved the next morning.
Scope and change
Scope is agreed before work starts and changes are written down before acceptance. A change request returns time, effort and consequence. You approve before it enters the plan. Nothing moves on a re-scope you do not accept.
Ownership
Code lives in your Git hosting. Deployments run in your cloud accounts. If you do not have them, we provision them and hand the keys over. You own the audit trail and the running system from Day 1.
The three questions you should ask any vendor
When you are evaluating whether distributed work makes sense for your project, there are three questions worth asking of any supplier, in this order.
In order of what you learn
1
Who owns the code?
This is the foundational question. The default is that the firm that writes it owns it. Ownership is the work product, not the service. Before anyone writes a line, the agreement has to be clear.
- Why 2 waits for 1Ownership is settled in writing before anyone starts, so it is answered first.
2
Who actually codes this?
Will you get the same team for the duration, or does the firm rotate people around? Continuity is where quality compounds over time. Rotation is where knowledge walks away when the quarter changes.
- Why 3 waits for 2Team continuity is a policy question, so it is answered second, before any deeper evaluation.
3
What happens when the overlap ends?
The time zone difference is real. How does the firm handle decisions, reviews, and blockers in hours outside the overlap? Some coordinate well. Others let work stall. This decides whether distributed work saves you time overall or consumes it.
Here is the version to paste
At some point you have to explain this to someone who will never read a supplier's website, and who was not in any of these meetings.
Forward this part
Atyantik Technologies, software delivery supplier summary
- Supplier. Atyantik Technologies. All developers currently based in India. No US entity, no Philadelphia office.
- Hours. Monday to Friday, 10:00 to 19:00 India Standard Time, which is 04:30 to 13:30 UTC, all year. India does not change its clocks, so that window never shifts with daylight saving. North American teams sit outside it for most of their day. Work gets scheduled around that rather than pretending otherwise.
- Code ownership. Their position is that from Day 1 every line of code is our IP. Code in our own repositories and cloud accounts, not theirs. If we do not have them, they provision them, set them up, and hand the keys over. Every line of production code is reviewed by a senior software engineer before it merges.
- Team continuity. We get the same software engineer for the duration, and most continue longer. They do not rotate people between projects or pull engineers onto what pays best this month.
- Scope control. Scope is agreed in writing before work starts and a change is written down before it is accepted. Time, effort and consequence are stated before approval. Nothing in the build moves on a re-scope we have not explicitly accepted.
- First response. One business day, technical person on the call. The first conversation returns a scope, and the number follows the scope.
Or put us in front of them instead
Send the paragraph and we bring these six answers to the first call, within one business day.
Whether to call us
Where we fit
You are building or rebuilding a product and want one team on it rather than a rotating bench. You get a core team assigned only to your project, and a lead software engineer you talk to directly. No handoffs you did not agree to.
You can work asynchronously and let decisions batch into the next morning. If your process needs every call same-day and every question answered in your working hours, the time zone difference becomes friction rather than cost.
Your legal team is willing to put code ownership into the agreement in writing before work starts. That clause is what makes the ownership real.
Where we are the wrong call
You need somebody in your time zone for every sync call. Our window covers part of a North American working day, and we do not offer continuous cover. We work the hours we publish and we do not pretend otherwise.
Your process requires synchronous collaboration for most of the working day. That is a valid choice. It is also a choice that makes a time zone difference expensive rather than manageable.
You want to see delivered work before you talk to anyone. There is a better starting point than a contact form.
You want a fixed price on a scope that is still moving. We agree scope in writing before work starts and write a change down before it is accepted, and a number that ignores that is not one we will give you.
Questions about how this actually works
Where do your software engineers actually sit?
How does distributed work actually cost time?
Who owns the code we pay for?
How are scope changes handled?
What if we want to move the work in-house or to another firm?
Tell us what you are building
A paragraph is enough. What it does, who uses it, and what has to be true before you can sign.
If the distributed work question is what is blocking you, say so. We bring those answers to the first call instead of the third.
- You get a reply within one business day with a technical person on the call, not a salesperson with a software engineer copied in.
- The first conversation returns a scope, and the number follows the scope.