Undocumented source code is one of the quietest risks a growing platform can carry. Nothing breaks on the day the last engineer who understood a module leaves, and nothing breaks the day an outdated library stops receiving security patches. The cost arrives later, usually during a release that was supposed to be routine. This case study looks at how SHIFT ASIA helped a Japanese logistics marketplace put numbers and evidence behind a codebase nobody could fully explain, using an automated source code analysis tool and a two-engineer team over a three-month engagement.

About the Client

The client operates a marketplace in Japan that connects truck drivers with companies that need freight moved, with the goal of improving revenue and utilization for both parties. In logistics, matching efficiency is the product. Platform availability, data accuracy, and the ability to ship new matching logic quickly are all direct commercial concerns rather than back-office ones.

The platform had been built and extended over several years, with contributions from multiple development vendors. That history is common in the Japanese logistics sector, where systems tend to grow feature by feature alongside the business. It also means the codebase carries decisions that were reasonable at the time and are now difficult to trace.

The Challenge

The client knew they had technical debt. What they did not have was a way to describe it.

• No documentation for large parts of the source code. Design intent existed in the heads of the people who wrote it, or nowhere at all.
• No shared view between the client and their development vendors. Discussions about code quality relied on opinion rather than measurement, which made prioritization difficult.
• No visibility into third-party library risk. Nobody could say with confidence which dependencies were outdated, unsupported, or carrying known vulnerabilities.
• No basis for budgeting remediation. Without knowing where the problems were concentrated, any refactoring plan would have been a guess.

The request to SHIFT ASIA was specific and bounded: analyze the source code, visualize what is there, and summarize the potential technical debt in a form that both the client and their vendors could act on.

Scope of the Engagement

SHIFT Inc. in Japan consulted with the client on the solution approach and agreed the scope. SHIFT ASIA executed against it.

That scope covered static analysis of the client’s undocumented application source code, structural visualization of the codebase, and a written summary of technical debt findings. The deliverable was an assessment, not a remediation project. The client wanted an accurate picture first, with decisions about what to fix and who would fix it to follow.

1. Assign engineers who could learn the tool at speed

The assessment tool at the center of this project was CAST, a commercial platform for automated source code analysis. Three months is a short runway to reach working proficiency with a tool of that depth while also producing client-ready output. SHIFT ASIA staffed the project with engineers selected for strong English reading and speaking skills, which allowed them to work directly through the vendor documentation and raise questions with the tool provider without waiting for translation or intermediaries.

That decision shaped the whole timeline. Learning happened in parallel with analysis rather than before it.

2. Work inside a defined delivery structure, with SHIFT consulting and SHIFT ASIA executing

The engagement ran across three parties: the client and their development vendors, SHIFT Inc. in Japan, and SHIFT ASIA. SHIFT Inc. held the consulting role, working with the client to define the problem, shape the solution approach, and set the scope and reporting expectations for the assessment. SHIFT ASIA held the execution role, taking the agreed approach and carrying out tool onboarding, source code analysis, visualization, and reporting.

That split is the standard SHIFT Group operating model, and it worked well here. The client worked with a Japanese consulting partner who understood their business context. At the same time, the hands-on analysis was delivered by an offshore team with the language skills to work directly with the tool vendor. Project communication ran in Japanese with the client and in English with the tool vendor, and keeping both channels active without losing detail between them was part of the job.

3. Run the analysis, then make it readable

Automated analysis produces a great deal of output. Raw findings from a static analysis platform are useful to engineers and close to unusable for anyone making budget decisions. The team exported and restructured the results in Microsoft Excel to build views that non-specialist stakeholders could work with, grouping findings by severity, component, and type of debt.

This step is where the reporting effort actually sat. The tool identified the issues. The team decided how to present them so that the client could see concentration, not just volume.

4. Deliver findings at line level

The final report went beyond category-level scoring. It identified specific lines of source code requiring correction and named the libraries that should be upgraded, giving the client and their vendors a concrete starting list rather than a general recommendation to improve quality.

Tools and Technology

CAST was selected because the client required an objective, tool based measurement of an undocumented codebase rather than a manual code review. Automated analysis scales across a large body of code and produces consistent results that do not vary with the reviewer, which matters when findings will be discussed with multiple development vendors.

The main limitation encountered was one that applies to most static analysis platforms. Output arrives in a technical format that requires interpretation and repackaging before it can support a business conversation. The Excel layer was necessary work, not an optional extra.

The Results

The client received a detailed technical debt assessment report covering:

• Specific lines of source code identified as requiring correction
• Libraries and dependencies recommended for upgrade
• Structural visualization of a codebase that previously had no documentation
• A grouped view of debt concentration that could be used to sequence remediation

For the first time, the client had a shared factual reference they could put in front of their development vendors. Conversations about code quality moved from opinion to evidence.

The engagement was scoped and delivered as an assessment, and it closed on delivery of the report. SHIFT ASIA does not claim ongoing tool operation or maintenance responsibility on this project. What the client took away was a baseline, and a baseline is what makes the next decision possible.

Why SHIFT ASIA

The client and SHIFT Group had a straightforward requirement. The assessment tool vendor operated in English, the project ran in Japanese, and the analysis had to be completed in three months by a team that did not start with the tool already in hand.

SHIFT ASIA was selected for its combination of English reading and speaking abilities, which enabled direct communication with the tool vendor, and its demonstrated ability to reach working proficiency with an unfamiliar analysis platform within a short window. Both were requirements, not preferences.

That capability generalizes. Assessment engagements often involve tools the client has never used, vendors in a different language, and a fixed deadline set by a budget cycle. The ability to absorb a new toolchain quickly is a service in itself.

Understand What Your Codebase Is Really Costing You

Technical debt you cannot measure is technical debt you cannot budget for.

Get an evidence-based assessment of your source code, delivered by engineers who work to Japan quality standards from Vietnam.

SHIFT ASIA combines SHIFT Group’s quality methodology with an offshore delivery model and engineers who can quickly pick up an unfamiliar analysis toolchains. Whether your codebase is undocumented, spread across multiple vendors, or simply older than anyone still on the team, we can tell you where the risk is concentrated and what it will take to address it.

Contact us to talk about a source code assessment for your platform.

Frequently Asked Questions