Technical Consulting
Architecture review, technology selection and due diligence, from people who ship rather than only advise.
Overview
A technical read on a decision that is expensive to reverse: the architecture of a system already in production, the stack a new one would be built on, or the codebase behind an investment. It belongs before the contract is signed, or at the point where a project is late and no one can name what is wrong. The engineers writing the recommendation are the engineers who would have to build it.
- Architecture review of a running system
- Technology, vendor and platform selection
- Technical due diligence on a codebase
- Build, buy or integrate decisions
- Cloud cost and scaling limits
- Security, data residency and regulatory constraints
- A second opinion on a stalled build
What you receive
- 01A written architecture review of the system as it is built, not as it is documented.
- 02A decision record for each architectural choice, with the options rejected and the reason.
- 03A risk register covering the code, the data model, the infrastructure and the third-party dependencies.
- 04A target architecture and the sequence that reaches it from the system running today.
- 05A build, buy or integrate recommendation, with what each path costs to staff and operate — not only the licence fee.
- 06A list of the questions to put to a vendor, and the answers that would change the recommendation.
- C4 model
- Architecture decision records
- STRIDE threat modelling
- OWASP ASVS
- AWS Well-Architected Review
- Terraform
- DORA metrics
- OpenTelemetry
- SonarQube
- k6
How the engagement runs
The review starts with access rather than a workshop: the repository, the infrastructure account and the people who operate the system day to day. Engineers read the code and the configuration directly, reproduce the behaviour in question and write down which constraint is actually deciding the design. A diagram is not evidence. Findings are argued in a session with the people who will live with the decision, not sent as a deck and left. What comes back is written, versioned and yours. Oryven can build what the review recommends, and the review is not written to make that the only answer.
- The choice that is hardest to undo is made against a constraint that is written down rather than assumed.
- The stack a business commits to is one it can hire for locally and keep running after the engagement ends.
- Scope is settled in writing before a price is discussed, so the cost follows from the architecture instead of setting it.
- A vendor proposal, an internal plan and an Oryven proposal can be judged against the same written standard.
Tell us what you are building.
Send the outline and we will come back with an honest read on scope, sequence and what it takes to run it in production.