A senior software engineer reads it and replies within one business day with how we would scope it. No sales sequence.
Platforms rarely break at launch; they break in the year the last software engineer who knew why it was built that way leaves.
How we know
Drawn from delivery and maintenance work across 50+ enterprise engagements in 7 countries since 2015, and one engagement still running after more than a decade.
The code is still there. What is gone is the reasoning that made it that shape, and it left in somebody's head.
The one who knew why has gone.
Nobody left can say what the tradeoff was, so nobody will touch it.
The docs describe what, never why.
You can read every endpoint and still not know what was rejected.
A small change now takes a quarter.
Each estimate carries a fear tax nobody can price for you.
None of that is answerable from the code alone, because the code never recorded what it was chosen over.
What the first weeks actually do
An Atyantik software engineering engagement runs in five phases: discover, specify, architect, build and hand over. Each one ends in a document you keep.
01Discover
We read the system you already have and interview the people who depend on it, then write down what we found and what we still cannot establish.
02Specify
Requirements go into a specification set you sign, so what counts as finished is agreed in writing before any code is written.
03Architect
We choose the architecture, record the alternatives we rejected and why we rejected them, and hand you that record instead of keeping it in our heads.
04Build
Delivery runs in short increments against the signed specification, each one reviewed, tested and deployed through a pipeline that you can watch.
05Hand over
You receive the running system, its tests, its pipeline and a runbook, so your own team can operate it without calling us first.
How deep the specification actually goes
Five documents, each settling a different question. We write the ones your project needs and say plainly which ones it does not.
The specification documents, what each settles, who signs, and what its absence costs
Document
What it settlesThe question it answers
Who reads itWhose sign-off it needs
What its absence costsWhat goes wrong without it
BRDBusiness requirements document
What it settlesWhy the project exists at all, and which business outcome counts as it having worked.
Who reads itThe sponsor funding it, and the executive who will be asked later whether it paid off.
What its absence costsScope arguments have no referee, so the loudest stakeholder wins each one in turn.
FRDFunctional requirements document
What it settlesWhat the system does, function by function, in language a non-technical reader can check.
Who reads itProduct owners, plus the client-side reviewer who signs each function off by name.
What its absence costsEvery ambiguity gets resolved by a software engineer guessing, and the guess ships.
PRDProduct requirements document
What it settlesWhat the product has to be for the people using it, and which behaviours are not negotiable.
Who reads itProduct and design, together with whoever will support the thing after launch.
What its absence costsDesign and delivery optimise for different products and only discover it at QA.
SRSSoftware requirements specification
What it settlesThe system requirements in testable form: inputs, outputs, states, limits and error paths.
Who reads itThe software engineers building it and the testers who have to prove it works.
What its absence costsThere is nothing to test against, so finished becomes a matter of opinion.
TRSTechnical requirements specification
What it settlesThe architecture, the stack, the interfaces and the non-functional limits it runs inside.
Who reads itThe software engineers who maintain it after we leave, and your own platform team.
What its absence costsThe reasoning stays in somebody's head, and it leaves the day they do.
What you receive, stage by stage
01
Discovery
We read the system you already have and interview the people who depend on it, then report what we found.
You receive
A findings note listing what exists, what is at risk, and what we could not establish.
02
Specification
Every requirement is written down in testable form and signed off by you before delivery starts.
You receive
The signed specification set: BRD, FRD, PRD, SRS and TRS, all yours to keep.
03
Delivery
Software is built in reviewed increments against that specification, tested and deployed through a pipeline you can watch.
You receive
Working software in your own repository, with its test suite and its CI pipeline.
04
Handover
We write down how to operate it, then prove your team can run it without us in the room.
You receive
A runbook and the architecture decision record, both of them yours to keep.
Ask which of these stages you actually need
Send what you are building and a software engineer replies within one business day with the stages we would run.
10+ YearsLongest continuously active engagement
Measured from engagement start date, client register.
50+Enterprise engagements
Counted from enterprise engagements across 7 countries, 2015 onward.
7Countries we deliver into
Counted from billing jurisdictions on active and closed engagements.
The evidence
Systems still running, years after we shipped them
Three engagements, each anonymized to a class descriptor, with numbers published on its page.
RFID stock audits cut from a full weekend to ten minutes
We built the multi-tenant RFID platform an inventory software vendor sells to optical stores and other small retailers, then merged its separate scanning apps into one.
A stock audit that took two to three people a full weekend now takes ten minutes.
10 minFull stock audit, down from a whole weekend
5 daysMissing or misplaced stock found within five working days
A marketplace storefront rebuilt for low-memory iPhones
We rebuilt the storefront of a hyperlocal marketplace in React with server rendering, cut its memory use on iPhones, and kept the client's existing back end and admin dashboard in place.
A storefront that had to hold thousands of shops was rebuilt with server rendering and a smaller memory footprint. The back end stayed as it was.
0Back-end changes. The storefront was rebuilt for low-memory iPhones on the client's existing API
1,000+Shops on the platform, the client's own count
iPhone memory crashes traced and fixed in the bundle
One sign-in for every application, with Keycloak SSO
We put Keycloak in front of a suite of separate web applications, moved their users into one store and gave every user a single sign-on, with OAuth 2.0, OpenID Connect and multi-factor authentication.
Several application logins became one sign-on, and authentication support tickets fell 70%.
70%Fewer authentication-related support tickets
1 sign-onSeveral application logins replaced by one
The answers you and the person signing the contract both want before anything starts.
How is this different from hiring contractors?
Contractors deliver code and leave. We deliver the code and the reasoning behind it: a signed specification set, a record of the architecture decisions and the alternatives we rejected, and a runbook. If we stopped tomorrow, your team would pick it up from documents rather than from an archaeology exercise.
Do we get the documents, or only the software?
Both, and the documents are yours from the day they are signed. They live in your repository alongside the code, not in a portal we control, so nothing you paid for is behind a login we own.
Which technologies do you build on?
We work primarily in TypeScript and JavaScript across the browser, Node and the edge. The full stack we build on is published, and we pick from it against your constraints rather than against our preferences.
How long does an engagement take?
That depends on what has to keep working, and we will not quote a duration before reading the system. What we can say up front is the shape: discovery and specification come first, and delivery starts once you have signed what finished means.
What happens when our requirements change halfway through?
They usually do. The specification set is versioned, so a change becomes a visible amendment with its own sign-off, rather than a quiet argument months later about what was originally meant.
Do we talk to a software engineer, or is this a sales call?
A software engineer, not a salesperson, replies within one business day. You describe what you are building and you get a technical answer about your system rather than a pitch.
Still deciding whether the paperwork is worth paying for?
Describe what you are building and a software engineer will tell you honestly which of these stages your project needs and which it does not.
A software engineer replies within one business day.
Tell us what has to keep working
Describe what you are building and what it has to survive. A software engineer, not a salesperson, replies within one business day with how we would scope it.
You have seen the phases, how deep the specification goes, and exactly which documents you would receive from each stage. The next step is that shape applied to your own system rather than to a generic engagement.
Tell us what you are building and what has to keep working after handover, and a software engineer reads it and replies.
