Companies with an in-house team but missing direction
Businesses employing a few developers but lacking a senior technical lead. The team works hard, but prioritisation and architectural decisions are left hanging.
CUSTOM SOFTWARE · ARCHITECTURE CONSULTING
Architecture Consulting and Technical Debt Audit: Direction Without Writing Code
We assess your existing software estate independently: an architecture map, a technical debt inventory with prioritisation, dependency and vendor lock-in risk, the team's way of working and a realistic roadmap. It is a piece of work that sets direction without writing code.
As a company grows, its software estate grows with it, and at some point nobody can see the whole picture any more. One system was written in-house, another bought in from outside, a third was built years ago and is still running. Each has a different owner, the connections between them were added over time, and what depends on what usually lives in one person's head only. At that point, every investment decision is taken partly on guesswork.
The second, more insidious issue is technical debt. Technical debt does not mean poor workmanship; most of it is the interest, carried into today, on decisions consciously taken in the past in order to move fast. The problem is not that the debt exists but that no inventory of it has been drawn up. Debt without an inventory shows up as an unexpected delay in every new development and gets read as the team being slow. But the cause of the slowness is not the team; it is the ground being built upon.
This work makes those things visible. The systems are mapped: what exists, what it does, who looks after it, what technology it is written in, what version it is on and what its support status is. The dependencies between them are laid out. Technical debt is written down item by item and ranked by business impact. Vendor lock-in risk is assessed: in which systems you have access to the source code and in which you do not; what happens if you part ways with a vendor. The team's way of working also enters the assessment, because release and review habits directly determine the outcome.
The output is not a list of criticisms but a roadmap you can take decisions on. Which system to keep alive, which to renew, which to take over, and in what order — each step written with its business impact and rough size. The work is designed for companies that are not at a scale to employ their own technology director but need the direction. This page is about software architecture; the digital strategy work on the marketing and growth side is a separate topic.
Who is it for?
Who is Architecture Consulting and Technical Debt Audit a good fit for?
Family businesses passing to the second generation
Organisations where management is being handed over and the state of the existing systems is unknown. During the handover, the software estate should be inventoried exactly like the machine park.
Organisations working with multiple vendors
Companies that have had different systems built by different firms. Each vendor defends its own piece; the question of who assesses the whole usually goes unanswered.
Parties assessing before investment or acquisition
Parties about to buy a company or enter a partnership. The true state of the software estate is an item that needs to be known before the contract is signed.
What we build
What we deliver within Architecture Consulting and Technical Debt Audit
System inventory and architecture map
What each system does, what technology it is written in, who looks after it and the data flows between them are mapped. The map is prepared at a level a non-technical manager can read; a map that is not understood produces no decisions.
Technical debt inventory and prioritisation
Debt items are written down one by one and ranked by business impact: which debt is slowing down new development, which carries risk, which is tolerable for now. Not every debt needs paying off; which ones to pay is a decision, and that decision requires the ranking.
Dependency and version risk
The version and support status of the technologies in use is assessed. Components whose support has ended and systems too far behind to be upgraded are flagged; these items grow heavier on their own and become more expensive the longer they wait.
Vendor lock-in analysis
We assess in which systems you have access to the source code and the data, how intellectual property is arranged in which contract, and what happens if you part ways with a vendor. In most companies this is the question being asked for the first time — and the one that gives the most uncomfortable answer.
Team and working practice maturity
Use of the code repository, branching, review habits, releasing and environment management are assessed. The aim is not to police the team but to identify which practice would make the biggest difference if added.
Roadmap and decision file
Keep, renew, take over or retire decisions are proposed per system; each proposal is written with its rationale, business impact and rough size. The roadmap is given over a 12-24 month horizon, in priority order.
Technologies
The technologies we work with
- System inventory and dependency mapping
- Static codebase review
- Version and support status analysis
- Contract and intellectual property review
- Team practice assessment
- Risk and impact matrix
- Roadmap and prioritisation
- Executive summary reporting
Process
How we move from discovery to go-live
- 01
1. Scope and stakeholders
Which systems will be assessed and who will be interviewed is agreed. The work is not run on code alone; we also talk to the departments using the systems, because they are usually the ones paying the price of the technical debt.
- 02
2. Building the inventory
Systems, technologies, ownership and dependencies are collected. At this step, most companies discover systems nobody owns or whose existence had been forgotten; these are noted separately.
- 03
3. Deep review
The codebase, architecture and data model of the critical systems are reviewed. Findings are recorded with their evidence; what gets written is demonstrable observation, not general impressions.
- 04
4. Risk and impact assessment
Findings are ranked by business impact and urgency. They are described not in technical language but through their consequences: which work this item slows down, which risk it carries, what happens if it is postponed.
- 05
5. Roadmap and presentation
The recommendations are turned into a roadmap and presented to management. The report is written in two layers: a summary for the decision-maker and detail for the technical team. Implementation can be run as a separate engagement if you wish; this work itself is independent.
Frequently asked questions
Common questions about Architecture Consulting and Technical Debt Audit
Is this going to be a sales pitch?
No, and we take care over that. The work is run as a fixed-scope, fixed-duration consultancy; its output is a report and a roadmap. There is no requirement that we do the implementation, and we take particular care that the report shows no bias towards creating work for ourselves. Our recommendation may well be that your current vendor carries on; that outcome is acceptable to us too.
Are you going to criticise our current developer?
The aim is to make the situation visible, not to judge people. Most technical debt comes not from poor workmanship but from decisions taken in the past in order to move fast — and those decisions may well have been right at the time. We write the report in language that can be read together with your team; a document that puts people on the defensive achieves nothing.
How long does it take?
The duration depends on the number of systems and the depth you choose; scope and duration are fixed in writing before we start. Our approach is to see the whole picture first with an inventory pass, then go deep only on the critical systems. Reviewing every system at the same depth is usually unnecessary and expensive.
We don't have access to the source code — can it still be done?
Partly. The inventory, the dependencies, the contract review and the vendor lock-in analysis can be done without source code, and those analyses are among the ones that produce the most value anyway. Code-level assessment requires access; if there is none, that fact goes into the report as a finding, because it is a risk in itself.
Who will implement the roadmap?
That is up to you. Your own team, your current vendor or we can implement it. The report is written clearly enough to be actionable whichever it is. For some of our clients this work turns into an advisory relationship repeated at regular intervals — sustained as a role that sets direction without writing code.
What do we end up with?
A system inventory and a readable architecture map; a technical debt inventory ranked by business impact; a version and support risk list; a vendor lock-in assessment; recommendations on the team's way of working; and a prioritised 12-24 month roadmap with an executive summary.
Contact
Let us talk about your Architecture Consulting and Technical Debt Audit project
In a 30-minute discovery call we listen to what you need and tell you honestly whether custom development or an off-the-shelf product is the better answer.
Related
Related pages and guides
Software Takeover and Recovery System Performance Engineering Test and Quality Automation Off-the-Shelf ERP or Custom Software? Let's Talk About Your Software Estate After delivery: maintenance, support and capacity subscription
Software Productisation: From Project to Product
We turn a working piece of software written for a single client into a sellable product: separating the core from the client-specific layer, a configuration engine, multi-tenant data isolation, installation and release management, and subscription infrastructure.
Details →Supply Chain Management (SCM)
We make it visible from one place where demand and supply diverge, which supplier is holding to its promised date and where the goods are waiting right now. The aim is not to install a new ERP; it is to gather the off-chain information your current system does not know and tie the planning decision to data.
Details →Procurement Management (PMS)
We bring together in a single chain where a request came from, which quotes were obtained, who approved what, and whether the invoice that arrives matches the order. Procurement runs in the system rather than in people's memories; every step can be read back afterwards along with its reasoning. Your existing ERP stays where it is.
Details →Supplier Relationship Management (SRM)
We bring together in one record who the supplier is, when each of its documents expires, how well it kept to its delivery dates last year and which price agreement is in force. The approved supplier list stops being an Excel file. A supplier portal connects to the same structure as an option.
Details →Transport and Fleet Management (TMS)
We build a layer that plans the shipment, assigns the vehicle and the route, compares carriers and freight rates, issues the e-waybill and collects proof of delivery from the field. If you run your own fleet, fuel, maintenance and document costs accumulate in the same system; if you work with hauliers, a record is kept of which job went to whom and at what price.
Details →Order Management and Orchestration (OMS)
We gather orders from your e-commerce site, marketplaces, the B2B dealer portal, the showroom and the telephone into a single pool. Stock is promised from one source rather than divided up channel by channel; the allocated quantity comes off it, and cancellations and returns come back into it. The aim is not to sell the same item twice, and to see where an order stands from a single screen.
Details →