Technical IT Consulting
An independent analysis of architecture, code and process that ends in a written diagnosis, with risks ranked and a plan your team can actually execute.
A technical second opinion, in writing
Some of a company's most expensive decisions are technical and happen in the dark: accepting a vendor's proposal with nobody to evaluate it, acquiring a company without knowing the state of its software, scaling a system without knowing whether it will hold. Asking the opinion of whoever built it, or whoever wants to sell the solution, returns an answer with a conflict of interest built in.
Consulting delivers the outside view: we analyze code, architecture, infrastructure, security and the development process, and we talk to the people who operate all of it daily. The result is a written diagnosis, in language the board understands and with the detail the technical team needs: what is solid, what is risk and what is urgent.
A recommendation without context is an off-the-shelf prescription. Every finding in the diagnosis comes ranked by risk and cost, and calibrated for the team you have, not the ideal team nobody has. There is no recommendation to replace everything with the fashionable tool: there is the shortest path between the current state and a better one, with the trade-offs of each option made explicit.
The engagement is pointed by nature, with a beginning, a middle and an end: you receive the diagnosis, an executive presentation of the findings and an action plan you can execute with your internal team, with another vendor or with us. We do not condition the diagnosis on hiring the rest, and that independence is exactly what makes the analysis worth anything.
- Written diagnosis of architecture and code
- Security and technical risk assessment
- Analysis of the development and deploy process
- Technical due diligence for acquisitions and investments
- Independent evaluation of vendor proposals
- Action plan ranked by risk and impact
- Stack and architecture recommendations
- Executive presentation of the findings
Discovery
We understand the problem, the context and the constraints before writing the first line.
Build
We analyze code, architecture, infrastructure and process, and interview the people who operate the system daily, crossing what the documentation says with what actually happens.
Evolution
We deliver the written diagnosis and the executive presentation, discuss the action plan with whoever will execute it and remain available to follow the implementation, if you want us to.
What is the difference between this service and the Consulting model?
In practice, two faces of the same thing. The service is the capability: analyzing architecture, code and process in depth. The Consulting model is the format that work is hired in: a pointed engagement, with a defined start and end, that closes with a written diagnosis. This service is typically hired under that model, with no monthly retainer involved.
Won't you use the diagnosis to sell us a project afterwards?
The diagnosis is not commercial bait, and we treat that as a working rule. The report recommends what the analysis supports, including, when it is the case, keeping your current vendor or executing with your internal team. If you want our proposal to implement something, it comes later, separately, and competes like any other.
Does my current vendor need to cooperate? What if they resist?
It helps, but it is not a prerequisite. With access to the code and the environments, the analysis moves forward even without the active collaboration of whoever built them. Excessive resistance, by the way, tends to be a data point in itself. We handle the contact with professional respect: the goal is evaluating the system, not attacking its authors.
What access do you need to run the analysis?
Ideally: code repositories, read access to the environments, existing documentation and conversations with the key people. All of it formalized under a confidentiality agreement, with access kept to the minimum privilege needed. When some access is not possible, we adjust the method and state explicitly in the report what was analyzed and at what depth.
Does this work for acquisition or investment due diligence?
Yes, it is one of the most frequent uses. We evaluate the target company's software as an asset: code quality and maintainability, hidden technical debt, dependency on specific people, security and intellectual property risks. The result feeds your risk assessment with the same weight as the financial numbers.
What if the diagnosis concludes everything is fine?
Then that is what it will say, and that answer is also worth the investment: it closes the doubt that motivated the analysis and unblocks the decision that was stuck. Almost every analysis finds room for improvement, but the ruler is honest. A report that finds catastrophe every time is as useless as one that never finds anything.
Let's get your idea off the ground
Investment is handled later, in the proposal, after the discovery call.