SMTP server tuning · PowerMTA, Halon, MailerQ, Postfix · 14 to 30 days · From $4,890

Your MTA is leaving 30 to 50 percent throughput on the table. We measure it, we fix it, we prove it.

Production-grade tuning audit for self-hosted SMTP infrastructure running PowerMTA, Halon HSL, MailerQ, KumoMTA, or Postfix. Eight diagnostic dimensions across kernel sysctl parameters, NUMA topology alignment, TCP buffer sizing, BBR congestion control, MTA-specific concurrency caps and retry ladders, filesystem and I/O scheduler selection, DNS resolver caching, and TLS handshake optimization. Every audit produces a baseline benchmark dataset before any change is applied, then measurable before/after comparison across throughput sustained over 24 hours, p99 latency to the major mailbox providers, deferral rate, queue depth peak, and bounce categorization accuracy. Enterprise tier carries an explicit guarantee: a minimum of 15 percent throughput improvement or 25 percent latency reduction, otherwise additional remediation at no cost until threshold is met. 16 years operating PowerMTA in production from Panama, independent operator with no vendor partnership bias.

See audit pricing Read framework
Audit dimensions8kernel · MTA · TLS · DNS
Typical timeframe14-30days end to end
PowerMTA experience16y4.x · 5.x · 6.0r2
Guarantee threshold15%throughput min
Audit framework · 8 diagnostic dimensions · methodology survives engagement

Eight dimensions, every one measurable. No black boxes, no proprietary scoring.

The audit covers the eight dimensions where SMTP server performance actually lives. Default Linux kernel ships with conservative TCP buffer values and connection-handling parameters tuned to work reliably across hardware ranging from a Raspberry Pi to a 32-core EPYC server. Those defaults are not optimal for a server handling 50,000 concurrent SMTP connections sustained, which is the load most B2B platforms hit during scheduled campaign windows. Default PowerMTA configuration ships with virtual-mta concurrency caps and retry-interval ladders calibrated for safety, not throughput. The audit identifies which conservative defaults are costing throughput in your specific workload and proposes calibrated values, with explicit rollback procedures documented for each change. No magic, no proprietary scoring, no black boxes that your team cannot inspect after we leave.

DIMENSION 1 · KERNEL SYSCTL

Network stack and connection handling

TCP buffer sizing for the workload, FIN timeout reduction for short-lived SMTP connections, ephemeral port range expansion for outbound concurrency, listen backlog depth aligned to peak connection rate, and BBR congestion control for production where Cloudflare and Google data validate the performance gains.

Tuned: tcp_rmem · tcp_wmem · tcp_fin_timeout · ip_local_port_range · somaxconn · netdev_max_backlog · tcp_congestion_control · tcp_tw_reuse · tcp_no_metrics_save
DIMENSION 2 · CPU & NUMA

CPU governor, IRQ affinity, NUMA topology

Performance governor pinned (no race-to-idle penalties), IRQ affinity aligned to NIC NUMA node, RPS and RFS for receive-side scaling on multi-queue NICs, kernel.sched_migration_cost_ns tuned to reduce gratuitous task migrations, and transparent huge pages disabled if they cause latency spikes during memory reclaim.

Tuned: cpu_governor performance · irqbalance config · /proc/irq/N/smp_affinity · RPS/RFS · sched_migration_cost_ns · transparent_hugepage · numactl pinning · taskset for PowerMTA processes
DIMENSION 3 · MTA-SPECIFIC

PowerMTA, Halon, MailerQ, Postfix concurrency

Per-domain and per-ISP concurrency calibrated to the throttle policies of Gmail, Yahoo, Microsoft, Apple as they stand in 2026, retry-interval ladders that respect 4XX soft-fail backoff without abandoning legitimate retries, queue-buckets distribution to prevent head-of-line blocking, virtual-mta or VirtualMTA pool design aligned to IP reputation tiers.

PowerMTA: max-msg-per-connection · max-smtp-out · retry-after · queue-buckets · virtual-mta concurrency
Halon HSL: queue policies · smtpd profiles
Postfix: smtp_destination_concurrency_limit · default_destination_rate_delay
DIMENSION 4 · TCP STACK

Congestion control, MSS, slow-start behavior

BBR or BBRv2 congestion control where kernel supports it (default cubic is suboptimal for short-lived high-throughput SMTP connections), slow_start_after_idle disabled because every SMTP connection becomes idle between batches and slow start kills throughput, MSS clamping tuned for VPN-tunneled deployments, and tcp_no_metrics_save to prevent stale metrics polluting new connections.

Tuned: net.ipv4.tcp_congestion_control=bbr · net.ipv4.tcp_slow_start_after_idle=0 · net.ipv4.tcp_mtu_probing=1 · net.ipv4.tcp_no_metrics_save=1 · net.core.default_qdisc=fq
DIMENSION 5 · I/O & FILESYSTEM

Mount options, scheduler, fsync behavior

I/O scheduler tuned per device class (none for NVMe, mq-deadline for spinning rust if any remain), mount options aligned to workload (noatime essential, nodiratime, lazytime where supported), fsync behavior on PowerMTA accounting logs balanced between durability requirement and throughput cost, block size alignment to underlying storage geometry.

Tuned: /sys/block/dev/queue/scheduler · mount opts noatime,nodiratime,lazytime · vm.dirty_ratio · vm.dirty_background_ratio · accounting log fsync policy · log rotation interval
DIMENSION 6 · OBSERVABILITY

Metrics, logs, alert calibration

Prometheus exporters covering kernel metrics, MTA-specific accounting, and TCP stack health. Loki or ELK pipeline for accounting log shipping with parsing rules tuned to extract bounce reason, mailbox provider latency, queue depth distribution. Alert thresholds calibrated against the post-tuning baseline so they catch regressions without firing on noise during normal operation.

Stack: node_exporter · powermta_exporter · custom MTA accounting parser · Grafana dashboards (8 panels) · Loki log shipping · alert thresholds (12 rules calibrated to baseline)
DIMENSION 7 · DNS RESOLUTION

Local resolver, MX lookup, recursive redundancy

Local resolver configured with aggressive caching (Unbound or systemd-resolved with appropriate cache size), MX lookup profiling to detect slow recursive paths, secondary recursive resolver configured for failover (because the day Google Public DNS has a regional issue, your bounce rate spikes if you depend on a single resolver), MX prefetching for known high-volume destinations during off-peak.

Tuned: Unbound or systemd-resolved cache size · upstream resolver redundancy (Google + Cloudflare + local) · MX prefetch cron · DNS-over-TLS where MTA supports it · resolv.conf options (timeout, attempts)
DIMENSION 8 · TLS HANDSHAKE

Session reuse, OCSP stapling, cipher ordering

TLS 1.2 minimum with TLS 1.3 preferred per Microsoft 2026 enforcement, session ticket reuse to amortize handshake CPU cost across many connections, OCSP stapling to remove a synchronous round-trip during certificate validation, cipher suite ordering aligned to Mozilla intermediate profile, DANE/TLSA validation if the client publishes records.

Tuned: TLS protocol minimum 1.2 · session_ticket_reuse on · OCSP stapling · cipher suite Mozilla intermediate · DANE/TLSA validation · cert renewal monitoring (no rotation logic touched)
8diagnostic dimensions
Kernel · CPU/NUMA · MTA · TCP · I/O · Observability · DNS · TLS — every dimension produces measurable output
50K+concurrent connections benchmark
Production-proven sysctl values calibrated against servers handling 50,000 concurrent SMTP connections sustained
7days baseline window
Read-only data capture before any tuning change applied — independent reference data the client audits against
15%guarantee floor (Pro+)
Minimum 15% throughput or 25% latency improvement on Professional+ tiers, or remediation at no cost until threshold met
On the methodology: data-driven tuning. Baseline first with observability tools (perf, bpftrace, PSI signals from cgroup v2, Prometheus on top), stress-test under production-like concurrency (wrk, k6, or replayed traffic from accounting logs), identify bottlenecks with specificity (CPU scheduler vs network queueing vs memory reclaim vs lock contention), tune targeted parameters, re-validate p99 and p99.9 tail latencies along with raw throughput. We do not ship a generic sysctl bundle from Stack Overflow. We do not cargo-cult parameters from a 2018 blog post. Every value applied has a measured justification against your specific workload and a documented rollback procedure if regressions appear during the post-deployment monitoring window.
Measured before/after · 24 audits 2024-2026 · representative client baselines

What the numbers actually look like. Average improvement across recent audits.

Five metrics tracked end to end on every audit, sampled over 24 hours of sustained production traffic both before tuning and 14 days after deployment. Numbers below represent the median improvement across the 24 most recent audits completed during 2024 through Q1 2026, anonymized but otherwise unmodified. Outliers excluded: three audits with under 5 percent improvement (workloads already well-tuned by the client team, where the audit produced minor refinements only), one audit with over 80 percent improvement (severely misconfigured production where multiple defaults were never adjusted).

Sustained throughput · 24-hour window +34% median
Before
64K msg/min
After
86K msg/min
p99 latency to Gmail/Yahoo/Microsoft/Apple −29% median
Before
3.8 sec
After
2.7 sec
Soft-fail deferral rate (4XX rebounds) −42% median
Before
12.4%
After
7.2%
Queue depth peak during burst window −52% median
Before
428K msgs
After
205K msgs
Bounce categorization accuracy +8.2pp median
Before
91.3%
After
99.5%

Median across 24 recent audits 2024-Q1 2026. Individual results vary based on starting baseline. Highly tuned starting points yield smaller deltas, severely misconfigured starting points yield larger deltas. Each engagement produces its own benchmark report with the actual numbers measured for that specific workload, not the median shown here. Detailed per-audit anonymized case studies available under NDA during sales conversation.

Comparison · EMP audit vs internal SRE team vs vendor support vs typical agency

Four ways to do this. Three of them have hidden costs.

The four realistic paths a SaaS or B2B platform takes when SMTP throughput becomes a bottleneck. Each has tradeoffs, each fits a specific situation, and each carries hidden costs that rarely show up in the initial conversation. The comparison below uses a representative scenario: a single PowerMTA node handling 5 million messages monthly with sustained burst load three times per week, where the engineering team suspects throughput could be 30 to 40 percent higher with proper tuning.

Approach Time to result Direct cost Hidden cost Knowledge retention
Internal SRE team learns PowerMTA 4-9 months $0 cash, ~80h SRE time $32K opportunity cost, 3-5 production incidents during learning curve Permanent (best outcome if time and tolerance available)
Vendor (Bird) professional services 30-60 days $15K-$30K typical engagement Vendor lock-in to license terms, scope limited to Bird-approved patterns Partial (depends on engagement format)
Typical infrastructure agency 14-21 days $8K-$18K Generic sysctl bundles applied without measured baseline, agency moves on after delivery Low (no documentation, no runbook, no portable artifacts)
EMP audit (Professional tier) 21 days $9,890 fixed None disclosed: methodology, runbook, dashboards, configs delivered as Git repo Permanent (artifacts portable, your team owns them)
Honest reading of the comparison: if your SRE team has 4 to 9 months of slack capacity and the production tolerance to absorb 3 to 5 incidents during the learning curve, internal upskilling is the right answer because the knowledge stays internal forever. If you are running on Bird's licensed PowerMTA Enterprise and want vendor-aligned guidance, vendor professional services makes sense at $15K to $30K. If you need fast remediation with zero learning curve and the agency you would hire actually has measured before/after audits as part of their methodology rather than generic kernel parameter dumps, that path works at $8K to $18K. EMP is the right answer when you want measurable outcomes within 21 days, fixed pricing, and portable engineering artifacts your team owns after we leave. Where we lose: vendor partnerships do not exist (we are independent), highly customized Halon HSL scripting requires partner coordination, and we do not take audits below 500K monthly volume because the engagement economics do not work below that threshold.
Three audit tiers · all fixed pricing · no hourly billing surprises

Pick the tier that matches your infrastructure footprint.

No hourly engagement, no estimate-then-true-up billing model, no scope creep. Three fixed-price tiers calibrated to single-server, single-server with hands-on remediation, and multi-node cluster with shared IP pools. Each tier has explicit deliverables and explicit timeline. The Professional and Cluster tiers carry the 15% throughput / 25% latency improvement guarantee. Express tier is read-only audit with recommendations, no remediation included, suitable for teams that prefer to apply changes themselves with the runbook in hand.

Express audit

Single server. Read-only diagnostics. You apply changes.

$4,890 / one-time
  • Single MTA node remote audit
  • 14 days end to end
  • Baseline benchmark report
  • Tuning recommendations document
  • Runbook for applying changes
  • 30-day question support window
  • No remediation included
  • No improvement guarantee
Book Express tier

Professional audit + remediation

Single server. Hands-on tuning. 15%+ guarantee.

$9,890 / one-time
  • Single MTA node remote audit
  • 21 days end to end
  • Baseline + measured before/after
  • Hands-on remediation included
  • Reproducible tuning bundle (Git)
  • Grafana dashboard + Loki pipeline
  • 30-day post-deployment monitoring
  • 15% throughput or 25% latency guarantee
Book Professional

Cluster audit + remediation

2 to 12 nodes. Shared IP pools. Load balancer tuning.

$24,890 / one-time
  • Multi-node cluster (2-12 nodes)
  • 30 days end to end
  • Per-node baseline + cluster-wide benchmark
  • Hands-on remediation across cluster
  • Load balancer tuning (HAProxy/NLB)
  • Centralized observability stack
  • 90-day post-deployment monitoring
  • Weekly check-in calls during 90d
  • 15%/25% guarantee per-node + cluster aggregate
Book Cluster tier
On the guarantee: Professional and Cluster tiers commit to a minimum of 15 percent throughput improvement OR 25 percent p99 latency reduction, measured under controlled load against the baseline captured during week one. If the threshold is not met, additional remediation is included at no additional cost until the threshold is met, OR the audit is refunded in full at the client's option. The guarantee does not apply to hardware-bound bottlenecks where physical capacity is the limiting factor (a 1 Gbps NIC physically caps throughput regardless of tuning, a single core CPU under TLS-handshake load caps latency regardless of tuning). When we identify hardware as the bottleneck, we say so explicitly during the baseline phase and the client decides whether to upgrade hardware or descope the engagement before any tuning charge is incurred.
Hard questions that come up on the technical call

What CTOs and SRE leads ask before signing the SoW.

"Why should I trust an operator from Panama on PowerMTA tuning?"

Fair question. The honest answer: geography is irrelevant to MTA expertise, production exposure is what matters. EMP has operated PowerMTA in production since 2010 across 4.x, 5.x, and 6.0r2 release cycles. The audit team has hands-on tuning experience on PowerMTA deployments handling between 500K and 50M monthly messages, across Linux distributions from CentOS 7 LTS through Rocky 9 and Ubuntu 24.04. We do not have a Bird partnership, which is intentional: it means we operate without vendor pressure to recommend specific licensing tiers or upsell paths that benefit Bird more than the client. Postmastery, the global reference partner for PowerMTA, charges €10,000 to €25,000 for similar engagements. EMP ships comparable depth at $4,890 to $24,890 because Panama operating costs are structurally lower than EU or US, and we pass that cost difference through. If geographical concern about jurisdiction is the issue, our infrastructure is operated under Panama Ley 81 which sits outside the US CLOUD Act, which is a feature for clients who prefer that posture. If you want a US-based vendor, Postmastery and Bird's professional services team are both excellent choices at their price points.

"What if my MTA is Halon and you said your depth is partial?"

Honesty over revenue capture. For a Halon shop where the bottleneck is core infrastructure (kernel, NUMA, TCP stack, queue management, IP pool design), we ship excellent results at the same depth as PowerMTA. For deep HSL scripting work where the audit needs to evaluate complex policy logic, mail flow rules with custom Lua-style HSL functions, or AMQP integration patterns with MailerQ, we coordinate with the certified European partner at our cost without markup, OR we recommend the client engage the partner directly and we limit our scope to infrastructure tuning explicitly. The decision is made during the discovery call before any contract is signed. We do not take engagements where we know we cannot deliver the full audit at full depth, because the audit reputation is more valuable than any single engagement revenue. About 15 percent of inbound Halon inquiries get redirected to specialist partners during discovery for this reason. About 85 percent fit our scope cleanly because the bottleneck is infrastructure rather than scripting depth.

"How is this different from a generic Linux performance audit?"

A generic Linux performance audit looks at CPU, memory, disk, and network in isolation, applies common sysctl recommendations from production runbooks, and ships a tuning bundle calibrated to typical web server or database workloads. That is useful but insufficient for SMTP server tuning because the workload pattern of an MTA is characteristically different: short-lived TCP connections to a fanned-out set of destinations, each destination having its own throttle policy enforced by mailbox providers, with TLS handshake CPU cost dominating the connection lifecycle, with bounce categorization logic that is wrong by default in 4 to 9 percent of cases, and with queue management dynamics that depend on retry-interval ladders calibrated against per-ISP soft-fail policies. An SMTP-aware audit tunes the kernel AND the MTA AND the resolver AND the TLS path together, because optimizing one in isolation creates new bottlenecks elsewhere. Pure-kernel tuning typically captures 30 to 40 percent of available improvement. SMTP-aware tuning captures the remaining 60 to 70 percent that lives in MTA configuration, throttle policies, and TLS handshake amortization patterns.

"What happens if the tuning regresses production?"

Three layers of defense. Layer 1: staging mirror. All tuning changes are applied first to a staging environment that mirrors production sysctl state and MTA configuration as closely as the client's infrastructure allows. Synthetic load test runs against staging for 24 hours before any production change. Layer 2: canary deployment. When changes move to production, they apply to a canary subset (typically 10 percent of traffic or a single VirtualMTA out of the pool) for 72 hours of observation against the calibrated alert thresholds. Full rollout only after canary metrics confirm the expected improvement and zero unexpected regressions. Layer 3: documented rollback per change. Every applied change has an explicit rollback procedure documented in the runbook with the exact command, the timestamp it was applied, and the success criteria for the rollback to be considered complete. Rollback can be applied per-change rather than as a full revert, so if change number 12 of 18 introduces an unexpected behavior, you roll back change 12 specifically without losing the gains from changes 1 through 11. Post-deployment monitoring window (30 days Pro, 90 days Cluster) catches regressions that surface only under specific traffic patterns the staging environment cannot reproduce. We respond to regression signals during the monitoring window at no additional charge.

"Can you handle Windows Server PowerMTA deployments?"

Yes, with explicit caveats. Windows Server PowerMTA is supported at depth across Server 2019, 2022, and 2025 with the relevant cumulative updates. The tuning is structurally different from Linux: registry-based kernel parameters instead of sysctl, NIC offload settings via PowerShell rather than ethtool, PowerMTA's Windows-specific config flags, ETW for low-level observability instead of bpftrace. We use Windows Performance Recorder and Windows Performance Analyzer for kernel-level profiling. The caveat: Windows-specific MTA tuning gets less common every year as the industry consolidates around Linux for production email infrastructure. About 8 percent of our PowerMTA audits are Windows Server. The audit framework, deliverables, and pricing tiers are identical, but we adjust the methodology section of the report to reflect Windows-specific tooling. What we will not do: install Linux compatibility layers (WSL2 or otherwise) to retrofit Linux-style tuning onto Windows. If your production target is Windows, the audit operates natively on Windows. Cross-platform tuning recommendations across Linux primary plus Windows secondary deployments are also supported when the client runs both.

"How do I justify $9,890 to my CFO?"

Three angles, depending on what your CFO cares about most. Angle 1: ROI on sender reputation. A 30 percent throughput improvement on a 5M monthly volume means roughly 1.5M additional successful deliveries per month at the same sending cost. If your average revenue per email is even $0.001 (extremely conservative for B2B), that is $1,500 per month in incremental revenue, paying back the audit in 7 months. Most B2B platforms calculate at $0.01 to $0.10 per email which compresses payback to weeks. Angle 2: avoided hardware spend. The typical alternative to tuning is throwing more nodes at the problem. A new bare metal node with PowerMTA license runs $4,000 to $8,000 in setup plus $400 to $1,200 in monthly costs. Tuning the existing nodes to push 30 to 50 percent more throughput often eliminates the need for the next node entirely, paying back the audit on the avoided capex alone. Angle 3: deferred SRE upskilling. 80 hours of SRE time at $150 per hour fully loaded is $12,000, and that is the optimistic case where the SRE is already strong on Linux performance and only needs PowerMTA-specific exposure. The audit costs $9,890 fixed and produces portable artifacts the team learns from anyway. CFOs who have priced engineering opportunity cost find this conversation easy.

FAQ · technical questions covered on every discovery call

What the discovery call covers.

What MTAs do you actually tune in production?
  • PowerMTA 4.x / 5.x / 6.0r2: 16 years production exposure, deepest expertise
  • Halon HSL clusters: infrastructure tuning at depth, scripting via partner coordination
  • MailerQ XML config: production tuning fundamentals, AMQP integration via partner
  • Postfix high-volume: BDAT pipelining, smtp_destination_concurrency_limit calibration
  • KumoMTA Lua: Apache 2 license, modern async runtime, Rust internals
  • Sendmail / qmail / exim4: we do not take audits, volume too low to maintain expertise
What kernel and OS stack do you tune against?
  • Linux LTS branches: 5.15 / 6.1 / 6.6 / 6.12
  • Distros: RHEL 9 / Rocky 9 / AlmaLinux 9 / Ubuntu 22.04 + 24.04 / Debian 12
  • Modern features (6.6+): io_uring, EEVDF scheduling, eBPF observability
  • Older 5.15: epoll, taskset/irqbalance NUMA pinning
  • Windows Server: 2019 / 2022 / 2025 supported natively
  • FreeBSD/BSDs: not supported, volume too low
What measurable improvements should I expect?

Calibrated against measured baseline. Typical median across the last 24 audits:

  • Throughput: +18% to +45% sustained over 24h
  • p99 latency to top 4 mailbox providers: −22% to −38%
  • Soft-fail deferral rate: −30% to −55%
  • Queue depth peak: −40% to −60%
  • Bounce categorization accuracy: 91% → 99.5%

Pro+/Cluster guarantee: minimum 15% throughput or 25% latency improvement, otherwise additional remediation at no cost.

How do you measure baseline before changing anything?

Read-only access during week one. Baseline captures:

  • PowerMTA accounting logs sustained 7-day sample
  • Kernel metrics via node_exporter (CPU, memory pressure, network drops, NUMA cross-node)
  • TCP retransmit rate, connection establishment latency (ss output, tcptraceroute)
  • DNS resolution time per MX target (dig + dedicated profiling)
  • Synthetic load against canary subdomain (no production deliverability impact)

Baseline report delivered before any production change applied. No modifications without written client approval at each step.

What about TLS and security-side tuning?
  • TLS 1.2 minimum, 1.3 preferred per Microsoft 2026 enforcement
  • Session ticket reuse to amortize handshake CPU
  • OCSP stapling removes synchronous round-trip in cert validation
  • Cipher suite ordering aligned to Mozilla intermediate (Gmail/Yahoo expectation)
  • DANE/TLSA validation if client publishes TLSA records
  • Cert renewal automation: reviewed, not modified (out of scope unless requested)
How does this compare to running my own SRE team?

Internal SRE upskilling is the right answer if you have the time and incident tolerance. The realistic gap:

  • PowerMTA-specific operational knowledge: 18-24 months hands-on production exposure
  • General SRE without MTA exposure leaves 30-50% of improvement on the table
  • Audit ships domain knowledge as portable artifacts (runbook, dashboards, configs)
  • After engagement: your team owns everything, EMP not required for ongoing operation
Do you support Halon and MailerQ at the same depth as PowerMTA?

Honest answer: no, not at the same depth.

  • PowerMTA: 16 years production, deepest expertise across all release cycles
  • Halon HSL: solid on infrastructure tuning, partner coordination for HSL scripting
  • MailerQ XML: solid on tuning fundamentals, partial coverage on AMQP advanced patterns
  • For Halon scripting depth, we coordinate with certified European partner (transparent pricing)
  • About 15% of Halon inquiries redirected to specialist during discovery
What deliverables remain after engagement ends?

Eight portable artifacts delivered as Git repository the client owns:

  • Tuned sysctl file with comments and source citations per parameter
  • MTA configuration files annotated inline (config.xml / virtual-mta / mailerq.xml / main.cf)
  • Prometheus exporter setup with metric definitions
  • Grafana dashboard JSON (8 panels)
  • Loki/ELK pipeline with parsing rules for accounting log shipping
  • Runbook covering 8 most common failure modes with detection signal + remediation
  • Baseline benchmark dataset (anonymized) for future comparison reference
  • Written report: methodology, every change applied, measured impact, rollback per change

Discovery call: 45 minutes. We diagnose, you decide.

Discovery format: 45-minute video call covering your current MTA stack, sustained volume, peak burst pattern, mailbox provider distribution, current pain points (queue depth, latency, deferrals, throughput ceiling), and existing observability stack. Output of the call: explicit fit verdict (this engagement is right for you, this engagement is not, OR we should talk to a specialist partner first), proposed audit tier with rationale, proposed timeline, and a draft Statement of Work delivered within 48 hours of the call. No commitment, no pressure to sign on the call. We sign mutual NDA before any technical detail is exchanged. About 60 percent of discovery calls convert to engagement, about 25 percent get redirected to a more appropriate solution (vendor support, internal upskilling, specialist partner), about 15 percent decide to defer or not pursue at all. The discovery call is genuinely diagnostic, not a sales pitch in disguise.

Book 45-min discovery Re-read pricing tiers
45-min discovery · Mutual NDA · Fit verdict · No-pressure SoW within 48h