How we build software your team can take over.
The engineering practices we follow on every project, written down so you can check them before you hire us and hold us to them after.
Outsourced code is only cheap until someone has to change it.
If you have inherited code from an outside team, you probably know the pattern.
No tests
Every change is a risk, so nobody wants to touch anything.
Secrets in the repository
Passwords and API keys committed where anyone with access can read them.
One-person deployments
Only one developer knows how to release, and they have left.
A README that says “TODO”
The first quote looked good. The next year of maintenance didn’t.
How we approach it
- Ordinary engineering discipline from the first commit. Nothing exotic.
- Applied every time, including when the deadline is close.
- Set out below in specifics, so you can compare it with your own standards.
What you can expect in the repository.
- 01
Pull requests and code review
Work happens on short-lived branches. Every change goes through a pull request with a description and is reviewed by a second engineer before it is merged. Your engineers can review too, or require their approval on protected branches.
- 02
Typed code and automated tests
TypeScript by default on the front end and in Node back ends, with strict settings. We write tests where they add value: unit tests for logic, integration tests for APIs and data access, and end-to-end tests for key flows such as sign-up, checkout or payments. We don’t chase a coverage number.
- 03
CI/CD and preview deployments
A pipeline runs type checks, linting, tests and a build on every pull request. Each branch gets its own preview deployment, so reviewers and product owners can try a change before it merges. Releases to production are automated and repeatable.
- 04
Environments and infrastructure as code
Separate development, staging and production environments with their own data and credentials. Where the project justifies it, cloud infrastructure is defined in code (Terraform or similar), so it can be reviewed, recreated and handed over.
- 05
Security basics, every time
Secrets kept out of code in environment variables or a secrets manager, least-privilege access for people and services, dependency updates and vulnerability alerts switched on, and the OWASP Top 10 used as a checklist in review. We treat this as good practice, not as a certification.
- 06
Accessibility and performance
Accessibility checks on key screens (keyboard use, contrast, labels, screen reader basics) and a performance budget for page weight and load time, checked in the pipeline where the tooling allows.
Our software development process, from first commit to handover.
The stages are the same for a small web app or a larger platform; only their length changes.
- 1
Week 1
Technical discovery
We review your existing code, infrastructure and constraints, agree the stack, conventions and branching model, and write short architecture notes covering the main decisions and why.
- 2
Week 1–2
Foundations
Repository in your organisation, CI pipeline, preview deployments, environments, linting, formatting and a first test so the whole pipeline runs from day one.
- 3
Weekly cycles
Iterative build
Features delivered through reviewed pull requests, deployed to staging, with a weekly written update covering what shipped, what is next and any risks or decisions needed from you.
- 4
Before launch
Hardening and release
End-to-end tests on the key flows, a security and dependency review, accessibility and performance checks, backups and monitoring confirmed, then a scripted production release.
- 5
Launch and after
Documentation and handover
README with setup steps, architecture notes, runbooks for deployment, rollback and common incidents, and a walkthrough with your team. Access is transferred and our accounts removed when you ask.
Teams this way of working suits.
A good fit if
- CTOs and technical founders who want an outside team to work to their standards, not around them.
- Companies planning to bring development in-house later and needing code that can be handed over cleanly.
- Product teams that want extra engineers inside their existing repositories and review process.
Probably not for you if
- Throwaway prototypes where speed matters and the code will be discarded; we can go lighter, but say so upfront.
- Buyers who need formal compliance certifications from their vendor, which we don’t claim to hold.
How engineering work is priced.
Fixed price for a well-defined scope, or hourly and monthly for products that keep evolving. Tests, code review, CI and documentation are part of how we work and part of the estimate, not optional extras. You get a written proposal within 7 working days, weekly progress after that, and no lock-in. If a deliverable doesn’t match the agreed scope, we fix it at our cost.
Questions we’re asked.
Technical discovery, then foundations (repository, pipeline, environments), then weekly build cycles through reviewed pull requests, a hardening phase before release, and documented handover. You see progress every week on a staging or preview environment.
You do. Repositories, cloud accounts, domains and third-party services are set up in your organisation or transferred to it. We work with the access you grant and remove ours when you ask.
Yes, where they add value: unit tests for business logic, integration tests for APIs and data, and end-to-end tests for key flows. They run in CI on every pull request.
Yes, and we encourage it. We can work in your repository under your branch protection rules, so nothing merges without your team’s approval if you want that.
Secrets stay out of code, access follows least privilege, dependencies are kept up to date with automated alerts, and we review changes against the OWASP Top 10. We don’t hold security certifications, and we’ll say so if your project needs a specialist audit.
Usually TypeScript with React, Next.js or Astro on the front end, Node.js and PostgreSQL behind it, and GitHub Actions or a similar CI service. If you already have a stack, we work in yours.
A README with setup and run instructions, architecture notes explaining the main decisions, runbooks for deployment, rollback and common incidents, and a recorded or live walkthrough for your team.
Go deeper
Start here
Start here
A plain guide for founders with an idea: what happens, in what order, and what it costs.
For agencies and consultants
Partners
White-label development, design, marketing and AI delivery for agencies and consultants.
Working with us
Working with us
Time zones, communication, contracts, payments, NDAs and ownership for clients outside India.
Tell us what you’re building.
Share your brief and we’ll reply with a clear plan, timeline and price within 7 working days. No obligation.
hello@amionyx.com+91 79995 86236WhatsAppBook a callOffice: 201, D15, Shree Ji Valley, Indore, Madhya Pradesh, India- Written scope and price
- Direct access to the team
- NDA before the first call
- No lock-in contracts
— The Amionyx founders