Four decisions that get expensive after launch
Who owns the code, whether the interface works for everyone, where the data lands, and what the system costs to run. Decided before code, on purpose.
Where this usually starts
The questionnaire
You have a customer's accessibility questionnaire open and nobody can answer section four.
The signature
You sign for the build, and no one has told you what it costs to run each month.
The long haul
You will still be maintaining this system long after the launch team has moved on.
European Commission, Directive (EU) 2019/882
Freitag et al., Patterns 2(9):100340, 2021
*Disclaimer: Both numbers come from outside Atyantik and describe the category, not results we produced. The lower end of the emissions range is the base 2020 estimate. The upper end includes supply chain and consumer electronics, from the same study.
The order these decisions arrive
Each of the four is cheap at one point in a build and awkward after it. Taken later it becomes a retrofit.
- Scoping
The code is your intellectual property from day one, and it lives in repositories and cloud accounts you own. If you do not have those yet, we provision them and hand over the keys.
- Architecture
You get an answer on where the data lands and what the system costs to run. Edge deployment on green hosting providers, and energy-aware architecture.
- Interface
WCAG 2.2 by default, on every interface we build for you. Higher compliance targets are supported when you ask for them.
- After launch
You get the documentation, the pipelines and the accounts, so a handover is a process you can run without us.
Which of these is yours
Sustainable development
We trace where your cloud spend actually goes, layer by layer. Then we change what the system does, so the monthly bill drops and stays down.
Some of it needs an architecture change.
AI-augmented development
We scope an AI feature against what it will cost to run each month. We also write down the cases where we would tell you not to build it.
Sometimes the answer is do not build it.
Privacy engineering
We test the privacy policy you have already published against what your live product actually does. Then we close the gaps we find, in the product.
The gaps are usually in the product.
What you hold at the end
01
Architecture
The shape of the system. The technical requirements specification records why each decision went the way it did. Anyone picking the system up later can follow the reasoning.
You get
Technical requirements specification
02
Deployment
How the system is deployed, and the CI/CD pipelines that do it, running in your own cloud accounts under your own credentials.
You get
Deployment and CI/CD documentation
03
Requirements
What was asked for, and what was specified, written down before the software was built.
You get
BRD and SRS
04
Change notes
Every change to scope, written down and accepted by you before it enters the plan, with what changed and why.
You get
Signed-off change notes
Get a view on what to settle first
Send what you are building and which of the four is open. A software engineer replies, not a salesperson.
Is this the right place
Where we fit
You have a product in the market and a customer asking questions nobody on your side can answer yet.
You are about to sign off an architecture and want ownership settled before anyone writes code.
Your auditor has a list, and you need systems that satisfy it rather than a certificate from us.
Where to go instead
You have not built the thing yet, so ownership and hosting are decisions inside the build itself.
Your interface frustrates people who can use a mouse just as much, so the problem is the design.
The system falls over under load and the bill grows faster than the traffic does.
For whoever approves this
If you are forwarding this to whoever approves the spend, this is the short version. Four facts, each one standing on its own, so nobody has to read the rest to follow them.
Forward this part
Atyantik Technologies: ownership, accessibility, data location and run cost, decided before code
- Ownership. Every line of code, the repositories and the cloud accounts are yours from the start of the work, not on completion.
- Accessibility. Atyantik builds interfaces to WCAG 2.2 by default rather than on request, and supports higher compliance targets when they are asked for.
- Certification. Atyantik does not certify against compliance frameworks itself. It builds systems that pass the requirements your own auditors set.
- Exit. Architecture, deployment, CI/CD, BRD, SRS and change notes are documented as the work runs, and they are handed over in full.
Questions that come up
If we stop working together, what do we keep?
- Every line of code is your IP, in your own repositories.
- Deployments run in your own cloud accounts. If you did not have them, we set them up and handed over the keys.
- Architecture, deployment, CI/CD, BRD, SRS and change notes are written as the project runs, so they are current rather than reconstructed.
What does WCAG 2.2 by default actually commit you to?
Can you sign our compliance questionnaire?
- We build systems that pass your auditors requirements.
- Your team gets the architecture, deployment and change documentation they need to answer the questions.
- Some questions ask how the software was built, how it is deployed, and who can reach the data. Those are the parts we speak to directly.
What happens when the scope changes?
Does the European Accessibility Act apply to us?
Where does our data actually live?
Tell us what you are building
Send whatever you already have. A repository, a written specification, the questionnaire you cannot answer, or a cloud bill that has stopped making sense. Say which of the four decisions is worrying you and we will start there.
You may actually need the build itself, a design fix, or capacity under load. We will say so and point you at the right place. That costs us the engagement. We would still rather you heard it from us at the start than found it out three months in.
- A software engineer replies, not a salesperson
- Everything you share stays private