Consulting & delivery

You have a system that has been running for a decade or more. It still works, but nobody dares touch it — the original author is gone, the documentation is gone, nobody knows what one change will break, and nobody can tell you what replacing it would cost. A health check answers those three questions before you commit: where the risk is now, roughly what replacement costs, and how to phase the work so it stays safe.

When a check is most worth doing

• The person who built the system is leaving or retiring — handover is cheapest while they are still here
• Before replacing the ERP, moving to the cloud or a major change, when you need to know which business rules and interfaces the old system hides
• Someone is coming to check: a customer's supplier audit, ISO 27001 certification, an internal-control review, or due diligence before an acquisition
• After an incident: a security breach, an outage, or a one-line change that broke something else
• Taking over someone else's system: a new vendor, a newly won contract, or a new manager who needs the lay of the land
• Budgeting, when you need a number for roughly what replacing it would cost

Three scopes — starting with the smallest is fine

For the database, the table and stored-procedure scripts are enough — no data, and no connection needs to be opened. If cost figures are not available yet, the work still goes ahead; the cost comparison then covers scope and difficulty only, without amounts.

Prices are exclusive of tax. Taiwanese customers are charged 5% business tax and issued a uniform invoice. The final quote is adjusted for system size and stack complexity; see below for how that works.

How the quote is calculated

Those are base prices; the final quote multiplies them by a complexity factor. A single modern language family with a single database dialect is ×1.0. Two or three languages mixed, or Delphi or Visual FoxPro in the mix, is ×1.3. Four or more mixed, or Pro*C, COBOL, PowerBuilder, VB6 or SAP ABAP, is ×1.6. Pricing tracks the system being analyzed, not the size of your company — the same 50,000 lines take several times longer to interpret when three SQL dialects are involved, and shouldn't cost the same. If you aren't sure which band you fall into, start with a focused check and we'll quote the rest once we know.

What you get

• Current-state inventory: code size, technology mix and third-party packages, plus project-dependency and layer diagrams — the analysis engine draws them, I keep the readable ones and redraw where needed
• Risk list: SQL injection, performance bottlenecks, schema drift, swallowed exceptions and more — graded by severity, with file and line numbers
• Compliance mapping against ISO 27001, Taiwan PDPA, GDPR and other frameworks, selected for your industry
• Migration cost comparison: stay as is, upgrade in place, or change stack — three scenarios side by side
• Phasing advice: what to move first, what to leave alone, with risk and effort estimates for each phase
• A one-page executive summary for whoever signs off

Want to see the finished product first? We ran a real check on BugNET, an open-source issue tracker that is no longer maintained, and wrote up the findings by hand. An open-source project has no running costs, so the sample's cost comparison covers scope and difficulty only, without amounts. Download the sample report (PDF, 12 pages, Traditional Chinese) ›

How it runs (for a focused or standard check, you spend roughly one to two hours)

1. 1 Agree the scope Sign an NDA and draw the boundary around the systems and databases in scope. Typically 1 day.
2. 2 Connect the code Two ways in. The analysis engine (Agent) runs inside your environment and the code never leaves your network; or you give read-only repository access or a ZIP file, and the code is analyzed on my machine under the NDA signed in step one. Typically half a day.
3. 3 Automated scan The Agent runs inventory, dependency, risk and compliance rules. Typically 1–2 days.
4. 4 Human review I go through the engine's output item by item, drop what isn't a real problem, and write up what matters in terms you can act on. Typically 3–5 days.
5. 5 Delivery and walkthrough You get the report, plus a 30-minute online walkthrough for the people who have to decide. Typically half a day.

About cloud AI: by default the report text is polished and translated with the paid Google Gemini API. Only report sections and analysis summaries are sent (for example findings, file paths, class and method names) — no source code; the stage that analyzes your code calls no cloud AI at all. Under Google's terms, content sent to the paid service is not used to improve Google's products; Google keeps it for a limited period only to detect abuse and meet legal requirements, and it may be stored temporarily in any country where Google has facilities. I never use your code to train any model. You can opt out when signing; the engine then uses template text, and the report you receive is still written by me.

The health check covers analysis, assessment, the report and the online walkthrough; the report is delivered as PDF and Word. It does not include performing the migration or rewriting code — that is a separate project, and we only discuss it once you have read the report and decided it is worth doing.

Put a large language model inside your own server room or cloud account, so neither your data nor your prompts leave your boundary. It suits teams under strict compliance rules, or teams that cannot send source code and customer data to an outside service. We handle the work from boundary mapping to handover, and you can maintain it afterwards.

1. 1 Boundaries first We establish what may leave your network and what may not, alongside compliance obligations and the hardware and network you already have.
2. 2 Selection and comparison Open models and hardware options are compared for your workload and traffic, with cost, risk and what we would advise against.
3. 3 Deployed in your environment The service runs on your own GPU hosts or internal network, behind an industry-standard interface, so swapping models later does not mean rewriting applications.
4. 4 Governance and audit Who used what, how much it cost, and which sources an answer drew on — all recorded in a form you can hand to an auditor.
5. 5 Handover, re-runnable Deployment scripts and configuration stay in your repository. Changing models, adding machines or rebuilding the environment is another run, not another project.

What matters on this track is not how new the model is, but settling boundaries, cost and auditability up front — those three decide whether the system survives inside your company.

We can also build an AI workflow made for you. The project below is a subtitle-processing pipeline we planned and built for a client running online courses.

Seven sessions, 22 video segments. Machine transcription arrives full of misheard terms, wrong punctuation and verbal filler. We built a re-runnable AI pipeline for this project that corrects the text sentence by sentence against the vocabulary of the field and the speaker’s own way of talking, then breaks long stretches of speech into lines that read naturally — turning a recording into text people can actually read and subtitles that run correctly and smoothly.

How the pipeline runs

1. 1 Machine transcription Speech is turned into raw text. This is only a half-product: mishearings and stumbles are recorded as-is.
2. 2 Sentence-level correction Wrong words, punctuation and verbal filler are fixed against the vocabulary of the field and the speaker’s own way of talking.
3. 3 Natural segmentation One line per frame, length kept in check, with terms and citations never split across two frames.
4. 4 Automated checks Consistent wording, file encoding, script purity and line length are all enforced by software.
5. 5 Timing and handover Lines are aligned to the video timeline. Where the audio genuinely is not clear we do not guess: those spots go on a list with timestamps, for whoever knows the material best to decide.

The pipeline stayed with the client: every revision of the script saves another full proofread. The same approach works for manuals, courses and product documentation in several languages.