HourTab

Blog › ICP guides

Application security engineer on retainer: tracking AppSec advisory and demonstrating code-level security value between penetration tests and formal security audits

July 18, 2026 · ~16 min read

The penetration test and the formal security audit are the visible events in an application security engagement. When an engineering director presents the security posture to the board, when a CTO justifies the AppSec advisory investment to the CEO, when a VP Engineering reports the clean penetration test results to the compliance team — those are the artifacts on the table: the third-party penetration test that found zero critical vulnerabilities in the customer-facing API after a two-week engagement, the SOC 2 audit that listed no security exceptions against the access control controls, the OWASP Top 10 assessment that confirmed the application met the industry baseline across all ten vulnerability categories. What none of those artifacts shows is the continuous code-level security governance between those visible milestones, or whether that ongoing advisory is what prevented the injection vulnerability from being introduced during the sprint that added the dynamic reporting feature, triaged the 52 SAST findings to surface the three genuine broken access control vulnerabilities before they reached production, and evaluated the new payment flow design for trust boundary violations before the first line of code was written.

The secure code review that identified a SQL injection vulnerability in a parameterized query implementation — where the application's ORM correctly parameterized the WHERE clause conditions but a dynamic ORDER BY clause was constructed by string concatenation because the ORM's query builder did not support column name substitution as a bound parameter, leaving the sort column and direction values drawn directly from the request URL without sanitization, and where a URL request of GET /reports?sort=id%3B+DROP+TABLE+reports--&dir=DESC would have been passed verbatim into the ORDER BY expression of a privileged SQL query — that prevented a SQL injection vulnerability from shipping inside a feature that had otherwise been built with parameterized queries throughout. The SAST triage session that reviewed 47 static analysis findings from the Semgrep rule set and identified the three genuine OWASP A01 broken access control vulnerabilities — where an administrative API endpoint accepted a userId path parameter and returned that user's data without validating that the requesting user's organization ID matched the target user's organization ID, where the ORM's query builder pattern that the majority of the codebase used correctly scoped queries to the authenticated user's context but the manually-constructed raw query in the administrative endpoint did not, and where the remaining 44 findings were false positives triggered by the raw query method used for full-text search index refresh jobs that used a whitelist-validated table name rather than user input — that prevented both the deployment of three broken access control vulnerabilities and the blanket dismissal of all SAST findings as tool noise.

The threat modeling session that evaluated a new payment flow design — where the proposed implementation would store the payment processor's webhook secret as an environment variable on the application server and validate incoming webhook signatures in the same application process that handled authenticated user requests, and where the threat model identified that the webhook validation logic ran before any authentication check, meaning an attacker who could forge a valid HMAC-SHA256 signature or exploit a timing side-channel in the comparison could trigger payment state transitions on arbitrary order IDs without authentication — that identified the trust boundary violation before the payment integration was implemented, allowing the engineering team to redesign the webhook handler as an isolated service with its own signature validation, no access to the primary database connection pool, and a strict allowlist of the order state transitions it was authorized to trigger. The security champion advisory session that reviewed a junior engineer's implementation of a password reset flow — where the reset token was generated using Math.random() rather than the cryptographically secure crypto.randomBytes(), producing tokens with 53 bits of entropy from a pseudo-random seed rather than the 128+ bits of entropy from a cryptographically secure random number generator, and where the tokens were stored unhashed in the database, meaning a database read by an attacker with SQL injection access would yield valid password reset tokens for every user with a pending reset request — that prevented a weak token generation vulnerability from shipping alongside a password reset feature that would have otherwise passed all functional tests correctly.

Application security engineers and AppSec consultants on monthly retainer do their most consequential work in the continuous stretches between penetration tests and formal security audits: the secure code review that catches OWASP Top 10 vulnerabilities at the pull request stage before they are deployed to production where an attacker can exploit them; the SAST and DAST tool triage that distinguishes genuine vulnerabilities from false positives so findings are remediated rather than ignored; the threat modeling that evaluates new feature designs for attack surfaces and trust boundary violations before the first line of code is written; the penetration test scoping and remediation advisory that ensures test scope covers the highest-risk attack surfaces and remediation addresses root causes rather than surface symptoms; and the security champion guidance that distributes code-level security awareness across the engineering organization so the AppSec consultant is not the sole security review point for every pull request. All of that advisory is invisible to the CTO, engineering director, and compliance team without a work log that connects the ongoing code-level security governance to the clean penetration test results it enables.

Application security engineer versus cybersecurity consultant versus vCISO: the primary distinctions

Three security advisory roles are routinely conflated in engineering leadership conversations: the application security engineer, the cybersecurity consultant, and the vCISO. The conflation produces situations where the code-level vulnerability prevention function — the discipline that governs secure coding patterns, SAST/DAST tooling, threat modeling, and the review of application implementations for exploitable vulnerabilities — is either missing, distributed across advisors without clear ownership, or assigned to advisors whose expertise is strategic rather than implementation-specific.

A cybersecurity consultant on retainer governs the organizational security program: the security policy framework that defines how the organization identifies, assesses, and mitigates security risks; the vendor risk assessment process that evaluates the security posture of third-party software providers and data processors; the incident response plan that defines the organization's procedures for detecting, containing, and recovering from a security breach; the security awareness training that addresses the human factors in phishing, social engineering, and credential misuse; and the security monitoring tooling (SIEM, EDR, network monitoring) that provides visibility into the organization's threat landscape at the infrastructure level. A cybersecurity consultant who has not reviewed the application's source code, triaged the SAST tool's findings, or evaluated the authentication implementation for security vulnerabilities has not provided the code-level security advisory that prevents application vulnerabilities from being introduced in the development process.

A vCISO on retainer provides fractional security leadership: the security program strategy that aligns the organization's security investments with its risk tolerance and compliance obligations; the board and executive communication that translates security risk into business terms; the vendor management relationships with security tool vendors and managed security service providers; and the compliance program governance that prepares the organization for SOC 2, ISO 27001, or NIST CSF assessments. The vCISO asks “how should the organization structure its security program to manage risk at the level appropriate for its industry, size, and compliance obligations?” The AppSec engineer asks “does this specific code implementation have vulnerabilities that an attacker could exploit to compromise user data, bypass authentication, or escalate privilege?” A vCISO who is directing security strategy and managing the compliance program but not reviewing application source code is not providing code-level application security advisory — and a security program that has strong organizational policies but weak code-level security review is the security posture that produces clean audit results and exploitable production vulnerabilities simultaneously.

An application security engineer or AppSec consultant on retainer focuses specifically on the code-level security of the application implementation: the source code review that identifies OWASP Top 10 vulnerabilities — injection, broken authentication, broken access control, security misconfigurations, insecure deserialization, and cryptographic failures — in the implementation before they are deployed; the SAST and DAST tool configuration that automates vulnerability detection in the CI/CD pipeline and makes static analysis findings actionable through accurate triage; the threat modeling that evaluates new feature designs for the attack surfaces and trust boundary violations that require security controls before implementation; the penetration test scoping and remediation advisory that makes periodic penetration tests more effective and their findings more actionable; and the security champion guidance that distributes code-level security knowledge across the engineering team so security review is embedded in the development process rather than reserved for quarterly external assessments.

What ongoing application security retainer advisory actually consists of

Secure code review advisory

Application vulnerabilities are introduced in code. They are introduced when an authentication check is applied at the wrong layer of the request handling stack; when a database query uses string concatenation for a dynamic clause because the query builder's parameter binding does not support the required substitution type; when an authorization check validates that the requesting user is authenticated but does not validate that the authenticated user is authorized to access the specific resource being requested; when a file upload handler trusts the client-supplied Content-Type header rather than reading the file's actual content to determine its type; when a cryptographic token is generated with a pseudo-random number generator rather than a cryptographically secure one. These vulnerabilities are introduced by competent engineers building features at sprint pace, not by negligent developers — the injection conditions and authorization gaps are often subtle, and the functional tests that verify the feature works as designed do not test the security conditions that would cause it to fail exploitably.

Secure code review on retainer covers the evaluation of pull requests and new feature implementations for OWASP Top 10 vulnerability patterns before they are merged and deployed: reviewing database query construction for injection conditions, particularly in the edge cases where parameterized queries are combined with dynamic clauses that use string concatenation; evaluating authentication implementations for the conditions under which the authentication check could be bypassed, absent, or applied after the sensitive operation it is intended to protect; reviewing authorization logic for the horizontal privilege escalation patterns where one authenticated user can access another user's resources by substituting resource identifiers; evaluating file handling implementations for the path traversal, polyglot file upload, and content type confusion conditions that allow malicious file content to reach execution paths; and reviewing cryptographic implementations for algorithm selection, key size, entropy source, and storage pattern correctness.

On retainer: reviewing new feature pull requests for the OWASP Top 10 vulnerability patterns most relevant to the codebase's architecture; advising on the secure coding patterns that address the root causes of recurring vulnerability classes identified in prior reviews; and maintaining a shared record of review findings that tracks the vulnerability patterns the engineering team most needs to understand to prevent recurrence.

SAST and DAST tool advisory

Static application security testing (SAST) and dynamic application security testing (DAST) tools automate vulnerability detection at scale — a SAST tool can scan an entire codebase for SQL injection, XSS, path traversal, and cryptographic weakness patterns in minutes, producing finding volumes that a manual code review of the full codebase would require weeks to generate. The challenge that makes SAST and DAST advisory a genuine AppSec skill is not running the tools but making their output actionable: a SAST scan of a large codebase routinely produces 40 to 200 findings, the majority of which are false positives against the codebase's specific implementation patterns, and distinguishing the genuine vulnerabilities from the false positives requires both the tool's rule logic and the codebase's actual security patterns to be understood simultaneously. A finding count that is not triaged produces either a false confidence when all findings are dismissed as noise or a remediation backlog of false positives that diverts engineering resources from the genuine vulnerabilities.

SAST and DAST tool advisory on retainer covers the configuration of static and dynamic analysis tools for the codebase's technology stack and security rule priorities; the triage of scan findings to identify genuine vulnerabilities versus false positives against the codebase's security patterns; the documentation of triage decisions that allows future findings in the same pattern to be evaluated consistently; the CI/CD integration configuration that makes SAST findings visible in pull request reviews before merge; and the DAST scan configuration that covers the application's authenticated endpoints, API contracts, and the authentication flows that determine which attack surfaces the scanner can reach.

On retainer: triaging regular SAST scan findings to surface genuine vulnerabilities from false positives; advising on rule suppression configurations for confirmed false positive patterns that should not be re-triaged on every scan; reviewing DAST scan coverage to ensure authenticated endpoints and sensitive API operations are within scope; and advising on the CI/CD gate configurations that block deployment of findings above a defined severity threshold without creating a false positive rate that trains engineers to bypass the gate.

Threat modeling advisory

Threat modeling is the process of systematically analyzing a feature design or system architecture for the attack surfaces, trust boundaries, and data flows that an attacker could exploit, before the implementation is built. The security controls that cost the least to implement and produce the most durable protection are the ones designed into the architecture before code is written: it is structurally simpler to build a webhook handler that processes requests in an isolated service with no direct database access than to retrofit the same isolation onto a webhook handler that was implemented as a controller action in the main application server with full ORM access. A threat model that identifies the same isolation requirement from the design document rather than from a penetration test finding saves the remediation cost of refactoring a deployed implementation and the security exposure of the window between deployment and remediation.

Threat modeling advisory on retainer covers the evaluation of new feature designs and architectural changes for the STRIDE threat categories most relevant to the feature's data flows and trust boundaries: spoofing of identity (can an attacker forge a request that appears to come from a trusted identity?); tampering with data (can an attacker modify data in transit or at rest in ways the system will accept as authentic?); repudiation (does the system log the security-relevant actions that would be needed to reconstruct an attack?); information disclosure (does the feature expose data to principals who should not have access to it?); denial of service (does the feature introduce resource consumption patterns an attacker could exploit to degrade availability?); and elevation of privilege (does the feature allow a lower-privilege principal to perform actions that should require higher privilege?).

On retainer: reviewing new feature design documents and technical specifications for the attack surfaces and trust boundary violations that require security controls before implementation begins; advising on the security control designs that address the identified threats at the architecture level; and updating the application's threat model documentation when architectural changes expand or modify the application's attack surface.

Penetration test scoping and remediation advisory

Periodic penetration tests are the external validation mechanism that confirms the application's security posture against adversarial testing conditions — a skilled penetration tester will find attack chains that automated tools miss and that internal review processes do not consistently catch. The value of a penetration test depends directly on the quality of its scope and the quality of the remediation it drives: a penetration test scoped to IP ranges and URL paths that exclude the most sensitive API endpoints produces clean results that do not reflect the actual attack surface; a penetration test that produces a finding list without distinguishing root cause from surface symptom drives remediation that patches the specific finding while the underlying vulnerability pattern remains in the codebase.

Penetration test scoping and remediation advisory on retainer covers the definition of penetration test scope objectives that prioritize the application's highest-risk attack surfaces: the authentication and session management flows, the authorization boundaries between user roles, the file handling and upload paths, the API endpoints that handle sensitive data or privileged operations, and the third-party integrations that create trust boundaries between the application and external systems. It also covers the review of penetration test reports to distinguish findings that represent genuine architectural security vulnerabilities from findings that represent configuration gaps, and the remediation advisory that addresses root causes rather than patching the specific exploitation path the penetration tester used.

On retainer: advising on the scope definition for periodic penetration tests; reviewing penetration test reports and advising on the remediation priority and approach for each finding; and tracking remediation completion to confirm that the security controls implemented address the root cause of each finding rather than only the specific attack path demonstrated in the test.

Security champion program governance

An AppSec consultant who is the sole security review point for every pull request in a growing engineering organization creates a security review bottleneck that slows development velocity and does not scale with the codebase's growth rate. The security champion program — where engineers within each development team are trained to recognize the most common vulnerability patterns for the codebase's technology stack and to apply basic security review criteria before the AppSec consultant conducts a detailed review — distributes security awareness across the engineering organization and allows the AppSec consultant's detailed review capacity to be focused on the highest-risk implementations: new authentication flows, authorization boundary changes, cryptographic implementations, and the features that handle the most sensitive user data.

Security champion program governance on retainer covers the curriculum design for security champion training sessions that cover the OWASP Top 10 vulnerability categories most relevant to the codebase's technology stack; the code review criteria checklists that champions apply during their team's standard code review process before escalating to the AppSec consultant; the escalation criteria that define which implementation types require AppSec consultant review regardless of the security champion's assessment; and the feedback loop that improves security champion effectiveness over time as the champion population's understanding of the codebase's specific security patterns develops.

On retainer: conducting periodic security champion training sessions covering the vulnerability patterns most relevant to current development priorities; reviewing the security findings that security champions escalate and providing feedback that improves their pattern recognition for future reviews; and advising on the secure coding standards documentation that captures the codebase-specific security patterns the champion program needs to apply consistently.

The work that most commonly goes unlogged in an application security retainer

The most consistently underlogged application security advisory work falls into two patterns: review work that confirmed the implementation was secure, and advisory work that prevented a vulnerability from shipping rather than remediating one after it was found in a penetration test. Both patterns produce the misimpression that the retainer period was quiet when it contained the continuous code-level security governance that enables clean penetration test results and SOC 2 audit outcomes.

Secure code review sessions that approved the pull request are the canonical underlogging case in AppSec retainers. A review of a feature implementation that confirmed the database queries were correctly parameterized, the authorization logic validated the requesting user's access to the specific resource rather than only their authenticated status, the file upload handler validated content by reading file magic bytes rather than trusting client-supplied headers, and the session token was generated with crypto.randomBytes() and stored as a bcrypt hash — that review required the same line-by-line analysis of the authentication flow, the same evaluation of the query construction against injection conditions, and the same examination of the authorization boundary against horizontal privilege escalation patterns as a review that identified a missing authorization check. The pull request that is approved after an AppSec review represents the review's positive security finding, not the absence of security review work.

SAST triage sessions that confirmed all findings were false positives are consistently underlogged by AppSec consultants who conflate “no genuine vulnerabilities in this scan” with “no triage work was performed.” Evaluating 52 Semgrep findings against the codebase's ORM parameterization pattern, the raw query method's whitelist-validated input, and the authentication flow's session token handling to confirm that all 52 are false positives against the codebase's security implementation required the same rule logic analysis, the same codebase pattern comparison, and the same documentation of the triage rationale as a session that surfaced three genuine vulnerabilities. The engineering organization that knows its SAST findings have been triaged and resolved to confirmed false positives is in a materially different security position than one that made the same assumption without the triage to support it — particularly when new engineers are joining the team and introducing code that may not follow the established parameterization patterns.

Threat modeling sessions where the feature design was assessed as having adequate security controls are consistently underlogged because the evaluation that concluded the design was secure produced no vulnerability list — and retainer logs that only record findings rather than evaluations systematically underrepresent the volume of advisory work. A threat model evaluation of a new API integration feature that reviewed the authentication approach for the third-party integration, the data flows between the application and the external service, the trust boundary between the webhook receiver and the application's internal operations, and the authorization scope of the API credentials used for the outbound calls — and concluded that the proposed design with mTLS authentication, a dedicated webhook processing queue, and credentials scoped to the minimum required API permissions was adequately controlled for the identified threats — required genuine security architecture analysis that justified the advisory hours. The threat model that found no design-level vulnerabilities is the threat model that informed the implementation design, not the one that failed to find any.

Retainer rates for application security engineers and AppSec consultants

Application security engineer and AppSec consultant retainer rates vary with experience level, technology stack depth, and the complexity of the application's architecture and compliance requirements:

Advisory-only AppSec retainers — secure code review, SAST/DAST triage, threat modeling, and security champion guidance — are typically priced differently from engagements that include active penetration testing. Active penetration testing requires explicit written authorization, defined legal protections, and specialized tooling that is priced separately from the continuous advisory function. A retainer that covers the code-level security governance between penetration tests and the advisory that makes each penetration test more effective is the typical engagement structure for an AppSec consultant embedded in an active development organization.

The most common retainer structure is a minimum monthly hour commitment — typically 10–20 hours — with additional hours available at the agreed rate for periods when a significant new feature with complex security requirements, a compliance audit preparation, or a penetration test scoping and remediation cycle requires deeper engagement than the baseline advisory cadence.

Making application security retainer advisory visible to engineering leadership

The central challenge in application security retainer relationships is that the value of ongoing code-level security advisory is structurally invisible to the CTO, engineering director, and compliance team when the advisory is working as intended: the clean penetration test result does not show the SQL injection vulnerability that was caught in code review six months before the test; the SOC 2 audit's clean access control findings do not show the broken authorization logic that was identified in a threat modeling session and redesigned before any code was written; the absence of a data breach notification does not show the SAST triage session that surfaced the three genuine access control vulnerabilities from the 47-finding scan result. The value of AppSec advisory is experienced as the absence of the security incidents it prevents — and the organization that does not see those incidents cannot easily explain why it is not seeing them without a record of the advisory work that produced the prevention.

The work log that connects advisory sessions to specific vulnerability findings, SAST triage outcomes, threat modeling evaluations, and penetration test advisory is the primary mechanism for making code-level security value visible over time. An entry that records the ORDER BY injection condition identified, the feature it was found in, and the SQL that would have been executable against the production database gives the CTO a concrete example of what the secure code review function prevents. An entry that records the 52 SAST findings triaged, the three genuine access control vulnerabilities surfaced, and the organization ID validation added to the administrative endpoint allows the engineering director to understand what the SAST triage function produces. An entry that records the webhook handler's trust boundary violation identified in the threat model and the isolated service architecture that addressed it gives the compliance team visibility into the security control design work that preceded the implementation — and that would be reflected in the penetration test result as an attack surface that was never present rather than a vulnerability that was remediated.

A retainer dashboard that makes the AppSec consultant's work log visible to the CTO or engineering director without requiring the consultant to send a monthly security report email converts the work log from a private advisory record into a shared artifact of the engagement. The engineering leader who can see the full sprint's code review sessions, SAST triage findings, threat modeling evaluations, and security advisory in a single URL understands immediately what the application security retainer is producing — and has a concrete record to reference when making renewal decisions, preparing for compliance audits, or explaining the organization's security investment to the board.

The security advisory events that matter most to log

Not all application security advisory work carries equal weight in the retainer record. Three categories warrant particular attention because they represent the clearest evidence of the code-level security governance function operating as intended and the highest leverage applications of the AppSec consultant's expertise.

Prevented vulnerabilities with exploitation descriptions. The code review that caught the ORDER BY injection condition before the reporting feature was deployed, the SAST triage that surfaced the three access control vulnerabilities before they reached the production API, the threat model that identified the webhook trust boundary violation before the payment integration was implemented — these represent the AppSec function at its highest value. The work log entry should capture the specific feature or component, the vulnerability category, the specific exploitation condition (not just “SQL injection” but the specific query, the specific input, and the specific SQL that would have been executable), and the control that was implemented to prevent exploitation. This is the security equivalent of the structural engineer who prevented the load-bearing calculation error: the value is in the prevention, and the prevention is only legible through the record of what would have happened without it.

SAST triage outcomes with genuine findings and false positive rationale. The triage session that reviewed 52 findings, confirmed 49 as false positives against the parameterized query pattern, and escalated 3 as genuine access control vulnerabilities is a more legible AppSec advisory artifact than a clean SAST report with no action items — because it shows both the volume of review work performed and the discrimination between genuine risk and tool noise that makes the SAST results actionable. The work log entry should capture the scan date, the total finding count, the false positive count with the rationale (the ORM generates parameterized queries from the query builder; the raw query method is only used for the full-text index refresh job with whitelist-validated inputs), and the genuine findings with their OWASP category and the remediation implemented.

Threat modeling decisions with security control design rationale. The threat model that evaluated the payment flow design and produced the isolated webhook processing service architecture, the threat model that evaluated the file upload feature and produced the content-type validation by magic byte reading rather than client-supplied header trust, the threat model that evaluated the multi-tenant API and produced the organization ID validation on every resource access path — these represent the security architecture function at the design stage. The work log entry should capture the feature evaluated, the threat categories identified, the risk severity of each, and the security control design that was adopted to address each identified threat. These entries give engineering leadership visibility into the security architecture decisions that shaped the implementation before the implementation existed — and that are therefore not visible in any post-deployment penetration test or audit artifact.

Frequently asked questions

What does an application security engineer on retainer typically do?

An application security engineer or AppSec consultant on monthly retainer typically provides secure code review advisory (reviewing pull requests for OWASP Top 10 vulnerabilities before deployment), SAST and DAST tool advisory (configuring automated scanning tools and triaging findings to distinguish genuine vulnerabilities from false positives), threat modeling advisory (evaluating new feature designs for attack surfaces and trust boundary violations before implementation begins), penetration test scoping and remediation advisory (defining test scope and advising on root-cause remediation for penetration test findings), and security champion program governance (training engineers within development teams to apply basic security review criteria). The penetration test is the visible event; the continuous code-level security governance between tests is the ongoing retainer function.

How is an application security engineer different from a cybersecurity consultant or vCISO on retainer?

An application security engineer focuses on code-level vulnerability prevention: reviewing source code for OWASP Top 10 vulnerabilities, triaging SAST findings, threat modeling feature designs, and advising on secure coding patterns. A cybersecurity consultant or vCISO on retainer focuses on the organizational security program: security policy frameworks, compliance program management (SOC 2, ISO 27001, NIST CSF), vendor risk assessments, incident response planning, and security monitoring at the infrastructure level. A vCISO who is not reviewing application source code is not providing the code-level security advisory that prevents vulnerabilities from being introduced in the development process.

What AppSec retainer work is most commonly underlogged?

Secure code review sessions that approved the pull request, SAST triage sessions where all findings were confirmed false positives, and threat modeling sessions where the feature design was assessed as having adequate security controls. All represent genuine code-level security governance whose value is in the ongoing confirmation and vulnerability prevention rather than in a finding list — and all are systematically underlogged by consultants who conflate “no vulnerability found” with “no review performed.”

What should an application security engineer retainer agreement include?

Codebase and repository read access, scope boundary between advisory and active testing, SAST and DAST tool access and triage responsibilities, explicit written authorization for any active scanning or testing against production systems (separate from the advisory retainer), and a shared work log visible to engineering leadership that documents the ongoing secure code review sessions, SAST triage outcomes, threat modeling evaluations, and security champion advisory that the retainer produces between penetration tests.

How should application security engineer retainer hours be logged?

Log entries should capture the AppSec function (secure code review, SAST/DAST triage, threat modeling, penetration test advisory, security champion guidance), the specific feature, component, or scan reviewed, the vulnerability categories evaluated, and the finding or confirmation. Log every session, including code reviews that approved the PR and SAST triage sessions where all findings were confirmed as false positives. The review that confirmed no OWASP vulnerabilities were present required the same line-by-line analysis as the review that identified one; logging only sessions with findings systematically understates the volume of security governance work and misrepresents the retainer's value to the engineering leadership making the retention decision.

HourTab turns a time-tracker CSV into a public retainer-hours URL your client can bookmark. No client login required. See how it works →