Three things before anything else.
We work 10:00 to 19:00 IST, which is 04:30 to 13:30 UTC.That holds all year, because India does not change its clocks. North American teams sit outside that window for most of their day.
Your repositories and your cloud accounts, from day one.Our software engineers are in India.
Nobody on this team is in New York.If you need someone physically in the room, say so in the first message and we will tell you straight away that we are the wrong firm for it.
Tell us what you are building
We will reply within one business day with a technical person on the call.
The team is already full
You run technology and the people you have cannot absorb this build on top of what they already carry. The date has been said out loud in a room where you cannot un-say it.
The signature is yours
You are the one who signs for this. Nobody in the building can tell you whether the choice is going well. Every question you ask, you ask knowing you cannot check the answer yourself.
Somebody else built it first
An outside firm built the system you now run, and may still be running parts of it. You are answerable for all of it either way, including the parts nobody documented.
What you are actually buying
For part of the financial sector in New York, answerability for a software vendor is not a feeling. It is a filing.
The New York Department of Financial Services publishes a cybersecurity regulation, 23 NYCRR Part 500. It binds covered entities, which means firms licensed or registered with that department, rather than every company in New York. If you hold no such licence or registration, Part 500 does not reach you. None of this is legal advice about your situation.
Reading Part 500 as amended effective 1 November 2023: under section 500.17(b)(2) the annual filing is signed by the covered entity's highest-ranking executive and its chief information security officer. Two signatures, both personal, covering work an outside firm may have done most of.
Section 500.17(b)(3) adds a retention rule. Records supporting that filing are held for five years and made available to the department for examination on request. Nothing has to be scheduled for that request to arrive. Five years is longer than most engagements run, so the material has to still make sense to somebody who was never in the room when it was written.
A comment on Hacker News puts the same thing without the citation: in my experience, you are responsible, regardless. It doesn't matter who wrote the code originally.
Part 500 requires a written policy covering guidelines for due diligence and contractual protections relating to third party service providers. Section 500.11(b) then names four things for that policy to address, to the extent they apply. Every one of them is a question about the firm you hire. Put all four to us, and to whoever else is bidding, in the same form.
| What the rule asks about | Who can actually answer it |
|---|---|
| Section 500.11(b)(1): the provider's access controls, including its use of multi-factor authentication. | Who can actually answer itThe provider, and nobody else. You cannot document a control that operates inside somebody else’s estate. |
| Section 500.11(b)(2): how the provider encrypts nonpublic information, in transit and at rest. | Who can actually answer itThe provider, in writing, before you sign anything. |
| Section 500.11(b)(3): notice to you of a cybersecurity event. | Who can actually answer itThe provider has to agree to it. Ask to see the exact wording. |
| Section 500.11(b)(4): representations and warranties covering the provider's own policies. | Who can actually answer itThe provider. A representation is a statement by the party you are relying on. |
The third row moves fastest. Since 1 November 2023 an incident at a third party service provider can start your own 72 hour clock under section 500.17(a)(1), and that clock runs from the point you determine an incident has occurred, not from the moment it happened. It does not catch everything: 500.1(g) names the kinds that count, which are the ones requiring you to notify a supervisory body, or with a reasonable likelihood of materially harming a material part of your normal operations, or deploying ransomware in a material part of your systems. The amendment narrowed this to that defined set rather than widening it to every event. You cannot see inside a provider's systems, so the notice term in the contract is the mechanism you control. Ask for that wording before you sign, because after an event it is somebody's goodwill. Note also that the duty here is yours throughout. No provider, us included, is bound by Part 500 on your behalf. Part 500 binds covered entities, which means firms licensed or registered with the Department of Financial Services, not every company in New York. None of this is legal advice about your situation.
The DORA research programme at Google Cloud put this to 1,200 working professionals for its Accelerate State of DevOps 2021 report. Teams reporting high quality internal documentation were several times more likely to report each of these. Site Reliability Engineering is the discipline of running a system to a stated reliability target rather than to whoever is awake.
| Dimension | Teams with high quality internal documentation | Teams whose internal documentation is not high quality |
|---|---|---|
| Implement security practices | 3.8 | 1 |
| Implement Site Reliability Engineering practices | 3.5 | 1 |
| Fully use the cloud | 2.5 | 1 |
| Meet or exceed reliability targets | 2.4 | 1 |
The report's own model runs one step at a time. Documentation quality predicts how well a team implements technical practices, and implementing those practices is what predicts improvement. About a quarter of those 1,200 people said their own internal documentation was good quality.
We agree what the system has to do, and what it must not do. The constraints your own review will apply get written down here, rather than found later.
The business intent written down, in a business requirements document. Our business analysis team writes it.
A functional requirements document: what the software does, feature by feature.
The software requirements specification, which is what the finished build gets measured against.
The Technical Requirements Specification. Architecture decisions are documented here, so your compliance team can verify the design intent. The technical team carries it forward into delivery.
Every milestone gets exit criteria, written down, before anyone starts on it.
Every change goes through code review by a senior software engineer. We use GitFlow, a branching model for releases, and unit tests, integration tests and continuous integration gate every merge.
None of that is written afterwards to satisfy a review. It is what the work leaves behind while it runs. Answering a questionnaire is then mostly a matter of finding the right file.
Ownership
From day one, every line of code is your intellectual property.
Code lives in your repositories. Deployments live in your cloud accounts. Any documentation we produce is yours to keep. If you offboard us, you keep everything, including the operational runbook. The reason for putting that on day one is the case nobody plans for, which is an engagement that ends early.
If you already have your own Git hosting, cloud accounts and storage, we work inside them. If you do not have them, we provision them, set them up, and hand you the keys. The accounts are yours either way, so there is nothing to negotiate about access later.
After launch there are two ways to keep going. An annual maintenance contract covers ongoing maintenance and growth work. A lean mode arrangement covers lighter ongoing support. Both run through the same change note process as the build.
One thing this is not. Neither Part 500 nor the SHIELD Act says anything about who owns the code, about source escrow, or about assigning intellectual property. Nothing above is required of us by New York. It is how we choose to work, and you should hold us to it on that basis rather than on a regulator's.
That is how we choose to work, and it is worth being exact about why. Neither Part 500 nor the New York SHIELD Act says anything about who owns source code. This is a commercial arrangement we offer, not a rule anyone imposed on us.
We built a cloud-based RFID solution to help SMBs track inventory across multiple stores with real-time scan accuracy, automated vendor reordering, and smart SKU validation.
Designed for scale and built for non-tech teams.
What it does not prove: no New York regulatory review is a variable in our records of that work. Neither is a transition away from a previous vendor. It says nothing about how long the work took, in what order it ran, or what was built alongside it. It is evidence that the way of working above produces a system a business depends on, and nothing beyond that.
Forward this part
Atyantik Technologies
There are two shapes of engagement. A dedicated cross-functional team working inside your sprints, for multi-month work whose scope keeps moving. Or team formation on demand, for a specialist capability gap, a scale-up, or a vertical you cannot staff internally.
Scope is agreed in writing before anything starts. Every change after that goes through a documented change note, with time, effort and cost laid out before approval. Nothing in the build moves on a re-scope you have not explicitly accepted.
Four things move the size of the work. Which shape it is, how long it runs, what mix of skills it needs, and what the review on the other side asks for. Name those four in the first message and the first answer can be specific.
One business day, and a technical person on the call.
Where we fit
The work is a build or a rebuild you want done, rather than seats you want filled.
A written handoff is already normal where you work, so documents are not extra effort imposed on anybody.
You want the material a review will ask for to exist before it asks.
The live time you need is a sync you can name. A project coordinator can host it, or an overlap shift can be arranged on request. Ask at scoping and it is part of the arrangement.
Where we are the wrong call
You want developers hired directly onto your own team, working under your own management. That is a different arrangement, and it is the one to ask us about instead.
You need a vendor that holds the certification itself. We do not hold SOC 2, GDPR, or HIPAA certifications ourselves. We engineer systems that pass your audits. We document architectural decisions in the Technical Requirements Specification, so your compliance team can verify the design intent. If your engagement needs a certified vendor, we will tell you upfront and refer where appropriate.
You need someone physically in the room in New York. Nobody on this team is, and we would rather say that now.
Your busiest hours need continuous cover rather than a scheduled sync. Ours end at 19:00 IST. If your busiest hours are a New York afternoon, our working day has already finished by then, in either half of the year.
We will reply within one business day with a technical person on the call.
Name the work, the date you are working to, and what your own review will ask you for. Then the first answer can be specific instead of general.
If we are not the right firm for it, you will hear that in the same reply.
