A build is judged on the first change after launch
Launch day is the easy part. The harder question arrives months later, the first time something has to change, and whether the people doing it can. Everything between the first call and handover is arranged around that. We write the decisions down, review every change against a standard, and hand over a runbook, so that the next change stays cheap for whoever makes it, including a team that is not us.
Start the conversation
Tell us what you are building. We reply within one business day with a technical person on the call.
A build can ship on time, do everything it was asked to do, and still leave you with something nobody can safely change.
How it shows up
None of that shows up on launch day. It shows up the first time a modest requirement lands and the estimate to deliver it comes back far larger than anyone expected.
The pattern repeats. No source control anyone can trace. No tests, so nobody knows what a small edit breaks. A framework somebody invented in-house that only they understood. Security holes found by whoever arrived next. By then the people who wrote it have moved on. Whoever picks it up has to read the code to work out what was intended, because nothing else records it. The cost lands long after anyone is still watching for it.
We write architecture decisions into the technical specification. Any software engineer reading the system years from now, including ours, can see why it is shaped the way it is. That document is not written for us. It is written for the person who has to change the thing after we have gone. The same goes for the deployment setup and the pipelines. Those decisions are written down while they are fresh, rather than reconstructed later from the code.
The cost question comes first in every one of these conversations, and it should. The number follows the scope, and the scope is the first thing we produce. We define it in days rather than weeks, so the work starts instead of stalling. Discovery produces a business requirement document and a functional specification. A system specification and a technical specification follow. Milestone planning comes next, and execution after that. Each milestone carries a documented exit criterion. Our business analysis team turns what you want into a buildable specification, and every requirement document is reviewed with you in plain English before any code is written.
What the number is attached to
Scope fixed up front
Choose this when
Pick this when the requirement is stable and you want the whole picture agreed first.
What it means in practice
The full specification is approved before execution begins. You know what is being built, and what each milestone has to clear, before anyone writes code.
Milestones running in parallel
Choose this when
This pattern is more common than people expect, and it suits a requirement that is still moving.
What it means in practice
Work begins on the parts that are ready once confidence and budget are locked. The team grooms and refines the later components while execution runs on the earlier ones.
What moves the scope is how much of the requirement is already written down, whether the work needs DevOps engineers and QA engineers alongside developers, and whether you need overlap with your own working hours beyond ours. All of it is agreed at scoping.
Two questions arrive together, right behind cost: how long, and who is actually on it. The second one decides more than the first. A way of working only means something if you can name who does each part of it.
Who is on it, and who checks their work
Three things you can name and check before you sign, in the order they come up
A core team assigned only to your work
You get a core team assigned to your project and a lead software engineer you can talk to directly.
No rotation. No context-switching onto somebody else's priority. No handoffs you did not agree to.
Every change reviewed by a senior software engineer
We run GitFlow with unit tests and integration tests, and CI/CD that gates every merge. Nothing reaches the main line without clearing that gate, and nothing clears it without a senior software engineer having read it.
That is a standard you can hold us to, and you can ask whoever else is bidding for theirs in the same form.
Where the tooling stops and a person starts
AI tooling assists inside a secure development environment. The judgment behind every decision stays with a human. We would rather say that plainly than leave you to assume it.
Nobody here approves a change because a tool produced it.
Each stage hands you something you can hold and check, rather than an activity we tell you we performed.
What arrives, and when
01
Discovery
Reviewed with you in plain English before any code is written.
You get
A business requirement document and a functional specification.
02
Specification
Architecture, deployment and pipeline decisions are written down here, with the reasoning attached.
You get
A system specification and a technical specification.
03
Milestone plan
The work is broken into milestones you can check the build against.
You get
A milestone plan, each milestone carrying a documented exit criterion.
04
Build
Daily standups, and sprint reviews and demos that show working software rather than slide decks.
You get
A shared dashboard you can check yourself rather than ask us for, and documentation that starts on day one and stays current through delivery.
05
Handover
Everything that moved during the build is written down while it is still fresh.
You get
A change note for everything that moved during the build, and a written runbook for the system as it stands.
We are not going to tell you there will be no surprises. When something changes, you hear about it three weeks early rather than three days late.
Ask us what the first milestones would be
Send the outline of what you are building. The first reply comes from a technical person.
There is a reason we write so much of this down, and the reason is not our own opinion. Bent Flyvbjerg and Alexander Budzier studied 1,471 IT projects and published the result in Harvard Business Review in September 2011. Of that set, 92 percent were public agencies and 83 percent were based in the United States.
27%
Average cost overrun, all 1,471 projects
200%
Average cost overrun in the one in six that ran to the tail
A documented exit criterion and a written change note are how you find out early which group you are in.
| Option | Cost overrun |
|---|---|
| Average cost overrun, all 1,471 projects | 27% |
| Average cost overrun in the one in six that ran to the tail | 200% |
Their own finding is that the average hides the thing worth planning for. One project in six ran to an average of 200 percent over cost, with a schedule overrun of almost 70 percent. Planning against 27 percent means planning against the number the people who measured it say is the wrong one to watch.
What happens when the scope moves
Your requirements will move. They always do, and that is usually the moment a supplier becomes difficult to deal with. We would rather show you how this runs now than explain it during the first disagreement about it. Here is what happens, in order.
- Every change request becomes a written change note.
- Time and effort are laid out in that note before approval.
- The change enters the plan only once you have signed it off.
- Your sign-off is confirmed in a meeting and in writing.
- Nothing in the build moves on a re-scope you have not explicitly accepted.
The same rule applies after launch, not only during the build. Once the system is live and we are still looking after it, a change still starts as a written note and still waits for you. You see what is involved before you decide, and you can decline it. None of that depends on how well the relationship is going that week.
These targets belong to an ongoing support arrangement, agreed separately from the build, so a build-only engagement does not carry them. Under that arrangement, support runs Monday to Friday, 10:00 to 19:00 IST, which is 04:30 to 13:30 UTC. The targets below count working hours inside that window rather than hours on a clock. Each one is a target for a named person to acknowledge the issue and start working on it. None of them is a time to fix. What a fix takes depends on what the issue turns out to be, and we do not commit to that.
What happens when something breaks, once support is running
Something critical is down. A P1.
Response target
Four working hours to acknowledgement by a named person who engages with it.
Something important is degraded but the system is running. A P2.
Response target
Twenty-four working hours to acknowledgement by a named person who engages with it.
Everything else, including questions and small requests.
Response target
Seventy-two working hours to acknowledgement by a named person who engages with it.
Who owns it, and what you leave with
Forward this part
Atyantik: who owns the code, and what you leave with
- Ownership You own it. From day one, every line of code is your intellectual property.
- If you already have accounts If you already have your own Git hosting, cloud accounts and storage, we work inside them.
- If you do not If you do not have them, we provision them, set them up, and hand you the keys, so the repositories, the cloud accounts and the storage are all in your name from the start.
- Documentation Documentation starts on day one and stays current through delivery, so the handover is never a document assembled in the last week that nobody reads. There is no point in the build where the only copy of the reasoning is in somebody's head.
- If you leave If you decide to move the work in-house or to another partner, we hand over a written runbook. So far no client has needed to use it, so that is a path we are describing rather than one we have walked often.
- Our rule as a supplier The freedom is yours from day one either way. Our rule as a supplier is to leave you able to go elsewhere, and the handoff is a process rather than a hostage situation.
When we are the wrong firm for this
Where we fit
If none of these describe your situation, tell us what you are building.
When we are the wrong call
Your engagement needs a supplier holding SOC 2, GDPR or HIPAA certification in its own name. We do not hold those certifications. All three are frameworks we engineer for, so we build systems that pass your audits, and we document architecture decisions in the technical specification so your compliance team can verify the design intent. If the certificate itself is the requirement, and not the engineering behind it, we will say so at the first call and point you to someone who has one.
The work sits in a domain where we would have to ramp rather than one where we are already deep. We have declined work that would have been good for us and wrong for the project, and we will tell you where a specialised supplier would serve you better.
You want a team that picks the stack it knows best and calls that the right answer. We choose the stack that fits the project instead. You do not need to bring a technology opinion to the first call.
Four questions that usually arrive next
How long does a build like this usually take?
Can I talk to the person writing the code?
Whose repository is it, and what if I have no cloud accounts?
Do you use AI to write the code?
Tell us what you are building
Send us what you are building and where it is stuck. Whatever shape you have it in is fine, a document, a set of notes, or a paragraph. We read it before the call.
We reply within one business day with a technical person on the call. If we are not the right team for it, we will tell you that and say why. Both of those are useful answers to have this week.
The first change after launch is a cheaper conversation to have now than after the code is written.
- We reply within one business day.
- Everything you share stays private.