Audit Availability and Scheduling

How Scheduling Works

Audit Slots and Lead Times

We run a limited number of concurrent audits to maintain the depth of review that each engagement requires. This means scheduling matters. An audit cannot start the day a request comes in.

Typical lead time between initial contact and audit start is two to four weeks. This accounts for the scoping call, NDA execution, access setup, and slot availability. Targeted reviews have shorter lead times than full codebase audits.

If you have a fixed deadline, share it in your initial enquiry. We will tell you directly whether the timeline is workable. If it is not, we will say so rather than commit to something that would compromise the review quality.

Targeted Review

1 to 2 weeks

Single-domain focus. Shorter lead time and faster delivery.

Full Codebase Audit

3 to 5 weeks

All three domains. Includes interim check-in and final walkthrough.

Ongoing Programme

Quarterly or monthly

Scheduled cycles aligned with your development cadence.

Project manager reviewing an audit scheduling timeline on a large digital calendar display in a modern office

Timing Guidance

When to Request an Audit

The right moment to audit is before the moment of maximum pressure. Here is how to think about timing relative to common milestones.

Pre-Launch

Request the audit at least six to eight weeks before your planned launch date. This gives time for the audit itself, remediation of critical findings, and a brief re-check if needed. Launching with known critical vulnerabilities creates risk that compounds quickly once real users are in the system.

Pre-Funding Round

Technical due diligence during a funding round often happens on an investor's timeline, not yours. Having an independent audit report ready before the process begins puts you in a stronger position. Request the audit at least eight weeks before your expected due diligence window opens.

Post-Major Feature Release

Significant new features, particularly those involving payment flows, user data collection, or third-party integrations, introduce new risk surfaces. An audit after a major feature addition confirms that the new code meets the same standard as the existing codebase.

After Team Changes

Engineering team turnover changes the code quality baseline in ways that are difficult to track internally. An audit following significant team changes provides an objective snapshot of the current state of the codebase regardless of who wrote which parts.

How far in advance should I reach out?

Reaching out four to six weeks before you need the audit to start gives us enough time to schedule properly. If your timeline is tighter, contact us anyway and we will tell you what is possible.

Can the audit run while development continues?

Yes, but we recommend auditing a defined snapshot of the codebase rather than a moving target. We typically agree on a specific commit or branch at the start of the audit. Changes made during the audit period are not automatically included in scope.

What happens if we find critical issues during the audit?

Critical findings are flagged to you immediately, not held until the final report. We contact you directly when something requires urgent attention. The final report then documents the finding in full detail.

Do you offer re-audits after remediation?

Yes. A targeted re-audit of previously identified findings is available after your team has completed remediation work. This confirms that the fixes address the root issues rather than just the surface symptoms.

What time zones do you work across?

We are based in Taipei (UTC+8) and work with clients across Asia-Pacific and Europe. Calls are scheduled to accommodate your team's working hours. Asynchronous communication handles most day-to-day coordination.

Check Availability

Tell us your timeline and we will confirm what is possible.

Include your target date in your enquiry and we will respond with current availability and next steps.