Blog › ICP guides

Principal engineer on retainer: architectural decision records, engineering standards, technical due diligence, and cross-cutting technical strategy on monthly retainer

August 7, 2026 · ~19 min read

A 200-person B2B software company has grown from 3 to 18 engineering teams over three years. The technology decisions made in the first two years — a PostgreSQL monolith, a monorepo in Node.js, a single AWS region deployment — were appropriate for a 30-engineer organization but are now producing friction at scale: three teams have independently chosen three different message brokers (SQS, RabbitMQ, and Kafka) because there was no engineering standards body to define a shared messaging platform; API design inconsistencies between teams are causing frontend integration delays; and the engineering organization has no formal process for reviewing and ratifying cross-cutting architectural decisions before teams begin implementing them. The CTO recognizes that the engineering organization needs a principal engineer function — a senior IC role that operates above the individual team level to set architectural standards, facilitate cross-team architectural decisions, and ensure that the engineering organization’s technical foundation remains coherent as the team continues to scale. But the company is too early to justify hiring a full-time Principal Engineer at a $350,000 total compensation package; instead, the CTO engages a fractional principal engineer on monthly retainer to establish the architectural decision process, write the first set of ADRs, and begin building the engineering standards program.

In month one: an architectural decision record (ADR) for the messaging platform selection (consolidating on Kafka via MSK, retiring the SQS and RabbitMQ usage in the affected teams over two quarters); an RFC template for the company’s new cross-team architectural decision process (defining the proposal format, the review period, the required stakeholders, and the ratification criteria); and the beginning of the engineering standards program, with the first two standards documents covering REST API design guidelines and observability requirements for production services. The CTO is satisfied. Two months later, the CTO asks why the retainer is running at 45 hours per month when the deliverables are an ADR document, an RFC template, and two standards documents. The principal engineer explains that the 45 hours include the messaging platform research and benchmarking (16 hours), the RFC process design and stakeholder consultation (8 hours), the API design standards research and team lead consultations (12 hours), the observability standards research and drafting (6 hours), and async advisory on three architectural questions from team leads (3 hours). The ADR document is visible. The RFC template is visible. The standards documents are visible. The 42 hours of research, benchmarking, stakeholder consultation, and iteration behind those four documents are not.

Principal engineers and distinguished engineers on monthly retainer — fractional principal engineers, independent technical advisors operating above the team level, and engineering architecture consultants — perform their highest-value work in the architectural research, stakeholder consultation, and decision synthesis that precedes every visible deliverable: the platform benchmarking behind the ADR, the team consultation behind the RFC, the industry research behind the engineering standard, and the codebase analysis behind the technical due diligence report. This guide covers architectural decision governance (ADRs, RFCs, architecture review boards), engineering standards development, technology strategy (technology radar, build-versus-buy advisory), and technical due diligence — and how to structure a principal engineering retainer that makes the hours behind each function visible.

Architectural decision governance: ADRs, RFCs, and architecture review boards

Architectural decision governance is the system by which an engineering organization makes, documents, and communicates significant technology decisions in a way that is transparent, reversible where possible, and accessible to all engineers who will be affected by the decision. Without a formal architectural decision process, technology choices are made ad-hoc by individual teams, accumulating in inconsistency and undocumented technical debt that becomes expensive to unwind at scale.

Architectural decision records: structure and process

An architectural decision record (ADR) is a short document that captures a significant architectural decision along with its context, the alternatives considered, the decision reached, and the consequences — both positive and negative — of that decision. The ADR format was popularized by Michael Nygard’s 2011 blog post “Documenting Architecture Decisions” and has become the standard mechanism for architectural decision documentation in engineering organizations following the practices described in Michael Keeling’s “Design It!” (Pragmatic Bookshelf, 2017) and the Architecture Decision Records patterns documented in the arc42 architecture documentation framework.

The standard ADR structure used by the principal engineer includes six sections: Status (Proposed, Accepted, Deprecated, Superseded By ADR-XXXX); Context (the technical and organizational forces that motivated the decision, including the current state of the system, the problem being addressed, and any constraints that limit the solution space); Decision (the architectural choice that was made, stated as a declarative sentence: “We will use Apache Kafka via AWS MSK as the standard asynchronous messaging platform for all inter-service event streaming”); Alternatives considered (the other options that were evaluated, with a brief description of each option and the key reasons it was not selected); Consequences (the effects of the decision, both beneficial and harmful, including the migration work required to bring existing systems into compliance, the operational overhead introduced, the capabilities unlocked, and the constraints imposed on future decisions); and Compliance (how compliance with the decision will be verified — through automated linting, architecture fitness functions, code review checklists, or periodic architecture reviews). A complete ADR is typically 2 to 5 pages and is stored in a version-controlled ADR repository (a dedicated GitHub repository or an adr/ directory in the monorepo) using a sequential numbering scheme (ADR-0001 through ADR-XXXX) that makes the decision history browsable chronologically.

The principal engineer’s most time-intensive ADR function is the background research behind the decision: reading the documentation, technical papers, and production incident reports relevant to each candidate option; running benchmarks or prototype experiments to validate performance claims; consulting with the engineering team leads and individual engineers who will be affected by the decision to understand their constraints and preferences; and synthesizing the research into a recommendation with well-supported rationale. For a significant architectural decision such as a messaging platform selection, a database engine choice, or a mobile framework adoption, this research phase typically requires 8 to 20 hours — producing a 3-page ADR document that shows the decision and the summary rationale, without communicating the depth of the research behind it.

RFC process design: cross-team architectural proposals

An RFC (Request for Comments) process provides a structured mechanism for engineering teams to propose significant architectural changes that affect multiple teams, collect feedback from affected stakeholders, and achieve organizational ratification before beginning implementation. The RFC process was pioneered by the IETF (Internet Engineering Task Force, which has used the RFC format since 1969) and has been adopted by engineering organizations at scale including Rust (the Rust RFC process for language evolution), Ember.js (the Ember RFC process for framework changes), and large technology companies including Amazon, Google, and Stripe. The principal engineer designs the RFC process for the engineering organization by defining: the threshold for when an RFC is required (changes that affect the public API contracts between services, changes to shared infrastructure or shared libraries, adoption of new programming languages or frameworks not on the current approved list, or changes to engineering-wide standards); the RFC document template (problem statement, proposed solution, alternatives considered, known trade-offs, migration plan for existing systems, and open questions); the review period (typically 2 to 4 weeks for significant proposals, with a defined review start and end date, and a required reviewer list that includes the engineering team leads of all affected teams plus the principal engineer); the ratification criteria (lazy consensus with formal objection period, or explicit approval from a quorum of reviewers); and the ADR that will be created to document the ratified RFC decision.

Architecture review board: facilitation and decision authority

The architecture review board (ARB) is the governance body that reviews and ratifies significant architectural proposals from engineering teams. The principal engineer facilitates the ARB by chairing the regular review sessions (typically bi-weekly or monthly), maintaining the proposal queue and review calendar, pre-reading all proposals before each session and preparing review commentary and questions, facilitating the discussion and decision during each session, and writing the decision record that documents the ARB’s ratification or rejection of each proposal with the reasoning. The ARB composition is typically the principal engineer (or CTO-appointed technical lead), the engineering team leads from each major domain (backend, frontend, infrastructure, data), and invited technical specialists for domain-specific proposals (the security team lead for proposals touching authentication or authorization architecture, the data engineering lead for proposals touching the data infrastructure).

The preparation work for each ARB session — reading and analyzing each proposal, researching analogous architectural decisions at comparable engineering organizations, identifying the technical risks and dependencies that the proposal authors may not have considered, and drafting review commentary and questions for the session — typically requires 3 to 8 hours per session before the ARB convenes. The engineering organization sees the ARB meeting and the resulting decision record; the preparation hours behind each session review are not visible in the meeting output.

Engineering standards development and governance

Engineering standards define the organization-wide rules, guidelines, and requirements that all engineering teams are expected to follow. Well-designed engineering standards reduce the cognitive load on individual engineers by providing pre-decided answers to common design questions (what HTTP status code should this API return for a validation error? what labels are required on every Kubernetes deployment? how many days of log retention is required for production services?), reduce inconsistency between teams, and provide a compliance target that automated tooling (linters, CI/CD checks, architecture fitness functions) can verify continuously.

Engineering handbook development

The engineering handbook is the primary publication medium for engineering standards, collecting all active standards, guidelines, and processes in a searchable, version-controlled document that all engineers can access. The principal engineer structures the engineering handbook around the major engineering domains: API design standards (REST API design guidelines covering URL naming conventions, HTTP verb usage, request and response body format, error response structure, pagination patterns, versioning strategy, and authentication scheme); observability standards (logging format requirements, structured log fields, required metrics for all production services, tracing instrumentation requirements, alert severity definitions, and SLO requirements for production services); testing standards (unit test coverage requirements, integration test requirements, contract testing requirements for API dependencies, performance test requirements for latency-sensitive endpoints, and test data management standards); security standards (authentication and authorization patterns, secret management requirements, dependency vulnerability scanning requirements, security review checklists for production deployments, and data classification requirements for PII and sensitive data handling); and infrastructure standards (Kubernetes deployment requirements including resource limits, health probes, and pod disruption budgets; CI/CD pipeline requirements for all production deployments; infrastructure-as-code requirements for AWS resource provisioning; and tagging standards for cost allocation and ownership attribution).

The development of a single engineering standard document — researching current industry practices, auditing existing codebase patterns to understand the current as-is state, consulting with engineering team leads to understand constraints and preferences, drafting the standard, collecting feedback in a structured review period, incorporating revisions, and publishing the final document — typically requires 15 to 30 hours of principal engineer time for a comprehensive standard (API design guidelines, observability requirements) or 8 to 15 hours for a narrower standard (Kubernetes deployment checklist, secret management requirements). The published standards document is typically 3 to 10 pages; the research, consultation, and iteration hours behind it are not visible in the document.

Technical debt strategy and prioritization

Technical debt strategy is the process of systematically identifying, categorizing, and prioritizing the engineering organization’s accumulated technical debt so that remediation work can be planned and funded alongside feature development. The principal engineer uses Martin Fowler’s technical debt quadrant (reckless vs. prudent × deliberate vs. inadvertent) to categorize identified debt items: deliberate-reckless debt (shortcuts taken knowingly with no plan to address them, representing genuine risk); deliberate-prudent debt (strategic shortcuts taken with a documented plan to address them after the near-term deadline, representing controlled borrowing); inadvertent-reckless debt (poor design resulting from inexperience, representing quality deficit); and inadvertent-prudent debt (design decisions that seemed appropriate at the time but turned out to be suboptimal as the system evolved, representing normal learning in complex systems).

The principal engineer conducts the technical debt assessment by reading the codebase (focusing on modules with the highest commit frequency, the highest bug density, and the most engineering team complaints), reviewing incident post-mortems to identify systemic technical causes, and interviewing engineering team leads to surface the debt items that are actively slowing delivery. The resulting technical debt register categorizes each identified debt item by type (architecture, code quality, test coverage, infrastructure, documentation), estimates the remediation cost (story points or engineering weeks), estimates the carrying cost (how much engineering velocity is being lost each quarter due to this debt item), and assigns a priority score based on the ratio of carrying cost to remediation cost. The technical debt register becomes the input to the engineering organization’s quarterly planning process, providing a principled basis for allocating engineering capacity to remediation alongside new feature development.

Technology strategy: technology radar and build-versus-buy advisory

Technology strategy is the cross-cutting advisory function that ensures the engineering organization makes coherent decisions about the programming languages, frameworks, platforms, and tools it adopts, maintains, and retires — across the multi-year horizon that individual engineering teams cannot see from their team-level vantage point.

Technology radar curation

The technology radar, pioneered by Thoughtworks in its biannual Technology Radar publication (first published in 2010), is a visualization of the engineering organization’s current assessment of technologies across four rings: Adopt (technologies that are recommended for broad use in production, with sufficient organizational confidence in their maturity, team expertise, and long-term viability); Trial (technologies that are being actively evaluated in non-critical production use cases, with the expectation of adopting or dropping within 1 to 2 quarters based on trial results); Assess (technologies worth tracking and exploring, not yet ready for production trial but showing sufficient promise to monitor); and Hold (technologies that are no longer recommended for new use, either because a better alternative has been adopted, the technology has shown insufficient maturity, or the vendor trajectory is unfavorable). The radar covers four sectors: Languages and Frameworks (programming languages, frontend frameworks, backend frameworks, mobile frameworks); Platforms (cloud providers, managed services, container orchestration, database platforms, messaging platforms); Tools (developer tools, CI/CD platforms, observability tools, security scanners, IDE extensions); and Techniques (architectural patterns, engineering practices, delivery methodologies).

The principal engineer maintains the technology radar on a quarterly cadence: reviewing each existing entry for continued accuracy (Has the technology evolved? Has the team’s experience with it changed the assessment?), adding new entries for emerging technologies that the engineering organization’s teams are encountering, and retiring entries for technologies that are no longer relevant. A comprehensive technology radar covering 40 to 80 entries requires 4 to 8 hours of research per entry to produce a well-informed Adopt/Trial/Assess/Hold recommendation with written rationale — representing 160 to 640 hours of cumulative curation work that is underlogged because no single technology radar entry feels like a deliverable proportional to the research hours behind it.

Build-versus-buy advisory

Build-versus-buy decisions — whether to develop internal tooling, use open-source software, or purchase commercial SaaS solutions for specific engineering capabilities — are among the highest-leverage decisions in the engineering organization because they determine the team’s long-term maintenance burden, vendor dependence, and strategic differentiation. The principal engineer structures the build-versus-buy analysis around five dimensions: Strategic differentiation (does the capability represent a core competency that differentiates the product in the market, or is it a commodity capability available from commercial vendors? Build for differentiation; buy for commodity); Total cost of ownership (comparing the upfront development cost and ongoing maintenance cost of an internal build against the licensing cost and integration cost of a commercial purchase, over a 3-year horizon); Time-to-value (how long will it take the engineering team to build and deploy a production-quality internal solution versus how quickly can a commercial solution be integrated?); Vendor risk (how dependent will the engineering organization become on the chosen vendor’s roadmap, pricing, and API stability? What is the switching cost if the vendor is acquired, raises prices, or discontinues the product?); and Engineering team leverage (would the engineering hours spent building the internal solution be better invested in product features that generate direct business value?).

The principal engineer’s build-versus-buy advisory memo synthesizes these five dimensions into a recommendation with supporting analysis, including a total cost of ownership model (engineering hours at fully-loaded cost versus SaaS licensing cost), a capability gap analysis (what the commercial option does not provide that the build option would), and a risk register (the key risks of each option and their mitigations). For significant build-versus-buy decisions (observability platform, internal developer portal, data warehouse, mobile framework, or identity and access management system), the research and analysis phase typically requires 10 to 25 hours before a defensible recommendation can be written.

Technical due diligence for mergers and acquisitions

Technical due diligence is the process of assessing the engineering quality, architecture, technical debt, security posture, and team capability of an acquisition target — providing the acquirer with the information needed to evaluate the technical risk of the transaction, estimate the integration cost, and identify the post-acquisition remediation investment required.

Codebase and architecture assessment

The principal engineer leads the technical due diligence codebase assessment by reviewing the acquisition target’s source code repositories, infrastructure-as-code, CI/CD pipeline configurations, and system architecture documentation. The assessment evaluates: Code quality indicators (commit frequency and contributor distribution across the codebase, test coverage percentage and coverage trend, cyclomatic complexity distribution, static analysis findings from automated linters and security scanners, documentation coverage for public APIs and critical modules); Architecture coherence (whether the system’s actual architecture matches the documented architecture, whether the architecture has a coherent decomposition that will support the acquirer’s integration strategy, and whether the architectural decisions are appropriate for the system’s scale and requirements); Technical debt severity (categorizing identified technical debt items by type and remediation cost, with an estimate of the quarterly carrying cost that the acquiring engineering organization would assume); and Technology stack risk (identifying dependencies on deprecated, unmaintained, or proprietary technologies that would create a migration obligation post-acquisition, and estimating the migration cost and timeline).

Security posture and data infrastructure assessment

The principal engineer’s due diligence assessment includes a security posture review: examining the acquisition target’s authentication and authorization architecture (whether the system uses industry-standard protocols such as OAuth 2.0 and OIDC for authentication and role-based access control for authorization, or whether it uses custom authentication schemes with the associated security risk); reviewing access control policies for production infrastructure (whether least-privilege IAM policies are applied, whether production database credentials are rotated, and whether secrets management uses a secrets manager or environment variables in plaintext); reviewing the vulnerability disclosure and dependency management practices (whether the team uses automated dependency vulnerability scanning with Dependabot or Snyk, and whether known high-severity vulnerabilities in dependencies are patched within a defined SLA); and reviewing the incident response and security monitoring capability (whether the team has SIEM tooling, whether production security events are alerted on, and whether there is a documented incident response process).

The data infrastructure assessment examines the acquisition target’s data architecture for integration compatibility and data quality risks: the database technology stack and schema design for compatibility with the acquirer’s data infrastructure; the data retention and purging policies for compliance with GDPR, CCPA, and sector-specific data regulations relevant to the acquirer’s operating context; and the data quality practices (whether the team has data contracts, data validation pipelines, and data quality monitoring, or whether data quality is managed ad-hoc with no systematic monitoring). A comprehensive technical due diligence assessment for a 30-person engineering team with 3 to 5 primary product repositories typically requires 40 to 120 hours of principal engineer review and analysis time — producing a 20 to 40 page due diligence report that the acquirer’s leadership team reads in 90 minutes.

Tracking principal engineer retainer hours with a shared dashboard

Principal engineers and distinguished engineers on monthly retainer perform their highest-value work in the architectural research, stakeholder consultation, and decision synthesis that precedes every visible deliverable: the platform benchmarking behind the ADR, the team consultation behind the RFC template, the industry research behind the engineering standard, the prototype experiments behind the technology radar entry, and the codebase analysis behind the technical due diligence report. None of these activities produces an artifact that communicates the hours behind it.

An ADR is a 3-page document. An engineering standard is a 5-page document. A technology radar entry is a paragraph. A technical due diligence report is a PDF. None of these artifacts communicates whether the underlying research and analysis took 5 hours or 50 hours. The CTO who approved a $20,000/month principal engineering retainer and sees two ADR documents and one engineering standard at the end of month one may question whether the investment is generating appropriate returns — unless the work log shows the 16 hours of messaging platform research and benchmarking behind the ADR, the 12 hours of team consultation and drafting behind the API design standard, and the 8 hours of RFC process design and stakeholder alignment behind the template.

A retainer dashboard that gives the CTO real-time visibility into the principal engineer’s time allocation transforms the engagement from a monthly technical advisory invoice into a documented engineering governance build record. The work log entries — service area (ADR research, RFC process design, ARB facilitation, engineering standards development, technology radar curation, technology selection advisory, build-versus-buy advisory, technical debt strategy, technical due diligence), specific task, architectural domain, output or decision enabled, hours — give the CTO a running account of the principal engineering investment that connects each hour to a specific architecture decision being researched, standard being developed, or due diligence finding being documented.

HourTab provides a public, no-login retainer dashboard URL that the principal engineer sends to the CTO once, and the CTO bookmarks for the duration of the engagement. The dashboard shows the current retainer burn-down (hours used versus hours remaining in the monthly cycle), a chronological work log of entries from the consultant, and the reset date for the next billing cycle — giving the CTO a self-serve view of the principal engineering work that connects each hour to a specific architectural decision, engineering standard, technology strategy recommendation, or due diligence assessment.

Frequently asked questions

What does a principal engineer on retainer typically do?

A principal engineer or distinguished engineer on monthly retainer provides ongoing cross-cutting technical leadership and advisory across four service areas: architectural decision governance (writing architectural decision records that document significant technology choices with context, alternatives, rationale, and consequences; designing the RFC process for cross-team architectural proposals; maintaining the engineering organization's ADR repository as a searchable decision history; and facilitating the architecture review board that reviews and ratifies significant proposals from team-level engineers); engineering standards development and governance (defining API design guidelines, observability requirements, testing standards, security controls, and operational readiness checklists; publishing standards in an engineering handbook; and managing the standards amendment process); technology strategy (maintaining the technology radar with Adopt/Trial/Assess/Hold recommendations for languages, frameworks, platforms, and tools; advising on technology selection decisions; and producing build-versus-buy analyses for significant capability decisions); and technical due diligence for M&A (assessing codebase quality, architecture coherence, technical debt, security posture, data infrastructure, and engineering team capability for acquisition targets). The distinction from an engineering manager is that a principal engineer operates as a senior IC (individual contributor) providing technical expertise and judgment, not organizational management — making architectural decisions and setting technical standards rather than managing engineers or engineering processes.

What principal engineering work is most commonly underlogged?

The most systematically underlogged categories in principal engineer retainers are: ADR background research (platform benchmarking, documentation review, and team lead consultation before the ADR document can be written — typically 8 to 20 hours invisible in the 3-page ADR); engineering standards development (industry research, codebase audit, team consultation, and drafting iteration behind each standard — typically 15 to 30 hours invisible in the 5-page standards document); technology radar curation (researching each technology entry including documentation review, prototype experiments, and engineer interviews to produce a well-informed recommendation — typically 4 to 8 hours per entry invisible in each radar paragraph); architecture review board preparation (pre-reading proposals, researching analogous decisions at comparable organizations, and drafting review commentary before each ARB session — typically 3 to 8 hours per session invisible in the resulting decision record); and technical due diligence (reading and analyzing tens of thousands of lines of code, reverse-engineering undocumented system architecture, reviewing security configurations, and synthesizing findings — typically 40 to 120 hours invisible in the resulting due diligence report).

What should a principal engineering retainer agreement include?

Principal engineering retainer agreements should specify: services covered (ADR writing and governance, RFC process design and facilitation, architecture review board facilitation, engineering standards development, technology radar curation, technology selection advisory, build-versus-buy advisory, technical debt strategy, technical due diligence for M&A, or engineering handbook development); the scope of cross-team visibility required (read access to all engineering repositories, design documents, and incident post-mortems; participation in architecture reviews and engineering all-hands; access to production metrics and cost dashboards); deliverables format (ADR documents, RFC templates, engineering standards documents, technology radar, technology selection recommendation reports, build-versus-buy memos, technical debt register, or technical due diligence reports); the communication model (synchronous hours in architecture reviews and engineering syncs; asynchronous advisory via pull request reviews and design document comments); and the work log format giving the CTO visibility into hours by service area and deliverable. Monthly retainer amounts range from $10,000 to $50,000 depending on scope and time commitment.

What are typical retainer rates for principal engineers?

Independent principal engineers with 12 to 18 years of engineering experience and a track record of significant cross-team architectural contributions at tier-1 technology companies typically bill at $225 to $450 per hour. Distinguished engineers and former Staff or Principal engineers at FAANG or top-tier technology companies with industry-recognized expertise command rates of $350 to $600 per hour. Principal engineering consultants at boutique technology strategy firms typically bill at $275 to $500 per hour. Monthly retainer amounts range from $10,000 to $25,000 per month for part-time advisory engagements (20 to 50 hours per month), increasing to $20,000 to $50,000 per month for near-full-time fractional principal engineering engagements where the principal engineer is embedded in the engineering organization's architectural decision process on a daily basis.

How should principal engineer retainer hours be logged?

Principal engineer retainer work log entries should capture: the service area (ADR research and writing, RFC facilitation, ARB preparation and facilitation, engineering standards development, technology radar curation, technology selection advisory, build-versus-buy advisory, technical debt strategy, or technical due diligence); the specific task performed; the architectural or standards domain; and the output or decision enabled. A useful format is: [Service Area] + [Specific task] + [Domain] + [Output or decision enabled] + [Hours]. Example: “ADR Research — async messaging platform selection: Kafka versus RabbitMQ versus SQS versus Pulsar. Research: read Kafka partition replication and ISR guarantee documentation; ran Confluent benchmark toolkit on 3-broker Kafka cluster to validate 100,000 msg/sec throughput requirement (achieved 340,000 msg/sec with acks=all); reviewed RabbitMQ quorum queue retention constraints against the 7-day retention requirement; reviewed SQS FIFO queue throughput limits (3,000 msg/sec with batching — insufficient); interviewed three engineering team leads on current messaging experience and constraints. Decision: Kafka via MSK. Output: ADR-0047-messaging-platform.md with full alternatives analysis and migration plan for teams currently using SQS and RabbitMQ; presented to ARB for ratification. 16 hours.” Entries that capture the research methodology, the benchmark data, the team consultation, and the decision rationale transform the messaging platform selection from a configuration file into a documented architectural decision record that any future engineer joining the organization can read to understand why the platform was chosen and what trade-offs were made.

HourTab gives principal engineers and distinguished engineers a public retainer dashboard URL their clients can bookmark — no client login, no portal, just a URL that shows hours used, hours remaining, and the work log connecting each hour to a specific architectural decision record, engineering standard, technology strategy recommendation, or due diligence assessment. Learn more at hourtab.com.