Quality gates fail quietly
Lint errors, type errors, and skipped tests get normalized. The gate everyone ignores is a gate that no longer protects anything.
Product & Technical Audit
Find what's broken. Before your users do.
An evidence-backed audit for early-stage SaaS teams: code quality gates, technical SEO and indexing, UX friction, and measurement gaps — delivered as a prioritized issue register you can act on.
- Evidence-backed findings
- Repro steps included
- Production changes only with approval
audit / auralock
Verified
- 1,654 tests passed 151 suites
- 6,255 links checked 0 broken
- ESLint errors 4 → 0
- Type errors surfaced 382 logged
3 fixes shipped · 1 pending deploy 2026-10-17
What an audit surfaces
Five quiet failure modes.
None of these show up in a demo. All of them compound. An audit makes them visible, scored, and fixable — in that order.
SEO & indexing issues
Canonicals, hreflang, redirects, sitemaps, and duplicate URL forms — small signals that decide whether pages get indexed or ignored.
UX & accessibility friction
Core journeys — signup, upgrade, activation — lose users at predictable steps that are visible once someone measures them.
No measurement baseline
Without before/after numbers for performance and conversion, every optimization is a guess you can't defend.
Documentation gaps
Known risks, decisions, and manual steps live in someone's head instead of a register a team can act on.
Method
Read first. Judge second. Fix last.
The method is deliberately boring: run what already exists, record raw results, classify every finding, and only then touch anything.
01
Inventory
Repositories, entry points, product surfaces, and marketing claims — mapped before anything is judged.
02
Baseline
Run your existing tests, type checks, builds, lint, and link checks exactly as they are — no code changes.
03
Classify
Every finding is labeled verified, suspected, or needs evidence — with reproduction steps attached.
04
Prioritize & verify
Scored by severity × confidence × effort. Only low-risk, high-confidence fixes are implemented — then the gates are re-run.
Confidence labels High confidence — directly reproduced Medium — strong code evidence Low — hypothesis needing data
Evidence, not opinions
A real audit, documented end to end.
Before offering audits to anyone else, I ran the full method on my own product — AuraLock's Android app, website, and extension claims. Every number below comes from a command or a live check.
Full transparency
This is a self-initiated audit of my own product — not a paid client engagement. That's the point: you can read the method, the raw results, and the limitations before hiring me.
- 1,654 tests passed across 151 suites, run serially
- 6,255 internal links checked 0 broken · verified by link checker
- 4 → 0 ESLint errors clean lint gate restored
- 382 type errors surfaced documented and deferred — not hidden
Before → after
AuraLock · October 2026- ESLint errors (app repository)Fixed and verified — lint, typecheck, and all 1,654 tests re-run green.4 0
- Root hreflang slash consistencyFixed in the website layout and verified in built HTML.Inconsistent Consistent
- Trailing-slash duplicate URLsPending deploy verification — tracked honestly rather than claimed.Both forms HTTP 200 Permanent redirect configured
- Internal links (website)Unchanged, but now proven with evidence for the first time.6,255 checked 0 broken
- Astro type-check errorsSurfaced, documented, and deferred as a separate cleanup engagement.382 382
What this audit did not measure
- No Core Web Vitals or Lighthouse run — performance work starts with a measured baseline.
- No analytics, conversion, or real-device data — those need client access to be meaningful.
- 36 lint warnings and 382 type errors remain open, documented instead of silently ignored.
- The trailing-slash redirect is configured but not deployed or verified yet.
Every audit I deliver keeps this section. If something wasn't measured, it's stated — never implied.
The prioritized issue register
Severity × confidence × effort on every finding. Filter it the way a founder reads it: what was fixed, what needs a decision, what stays open.
- A1
Formatting errors blocked a clean lint gate
FixedCode quality High severity Confidence: High Effort: Small - A3
No end-to-end tests for core user flows
OpenTest coverage High severity Confidence: High Effort: Large - A6
Duration parsing ambiguity in assistant
OpenCorrectness risk Medium severity Confidence: Medium Effort: Small - W1
Trailing-slash duplicate URLs both returned 200
FixedTechnical SEO High severity Confidence: High Effort: Small - W2
Localized pages canonicalize to English
ProposedTechnical SEO High severity Confidence: Medium Effort: Medium - W3
Root hreflang slash inconsistency
FixedTechnical SEO Medium severity Confidence: High Effort: Small - W5
Astro type check carries 382 errors
OpenCode quality Medium severity Confidence: High Effort: Large - W6
Unverified schema rating and platform claims
OpenStructured data Medium severity Confidence: Medium Effort: Small - W7
No measured performance baseline
OpenPerformance Medium severity Confidence: N/A Effort: Medium
Fixed — verified by re-running the gate Proposed — needs approval — indexing impact Open — documented with effort estimate
What you get
A register, not a vibe check.
- Repository & live-site inspection Code, configs, metadata, redirects, sitemap, robots, and headers.
- Baseline metrics Numbers from your existing tests, lint, type checks, builds, and link checks.
- Prioritized issue register Severity, confidence, and effort scored on every single finding.
- Recommended fixes & verification What to change, and the command or check that proves it worked.
- Before/after measurement template So improvement is measured, not assumed.
Acceptance criteria
- Every finding includes evidence and reproduction steps.
- No unsupported metrics or claims.
- Fixed items verified by tests or commands.
- Remaining risks and manual steps documented.
What I need from you
- Repository access and setup instructions
- Staging or test environment access
- Analytics / Search Console access if SEO is in scope
- Approval for any production-facing change
Engagement
Start small. Prove value. Then go deeper.
Starter audit
3–5 business days
One surface, ten sharp findings.
A focused first engagement on one product surface — app, website, or API — designed to prove the method before any larger commitment.
- One product surface, inspected end to end
- Up to 10 prioritized findings with evidence
- Reproduction steps for every finding
- Severity, confidence & effort on each row
- No production changes unless you approve
Extended engagement
After a starter audit
Fix, test, document, verify.
Turn the register into shipped improvements — each change gated by the verification step defined in the audit itself.
- Implement approved fixes, verified by tests
- Add or update tests for every touched area
- Documentation and measurement setup
- A follow-up verification pass with before/after numbers
Pricing is scoped per engagement — it depends on scope, repository size, access, and implementation effort. Findings always ship with evidence; no business outcomes are guaranteed.
See a sample finding register Illustrative — a fictional product, clearly labeled. Real audits use your data only.
Fictional sample
TaskFlow (hypothetical project management SaaS) — all findings illustrative.
- S1
Pricing page lacks a canonical tag
Technical SEO Medium severity Confidence: Medium - S2
Trial signup form has no inline validation
UX High severity Confidence: Medium - S3
Dashboard LCP estimated above 4s on mobile
Performance High severity Confidence: Low - S4
Missing alt text on feature screenshots
Accessibility Medium severity Confidence: High - S5
No password-reset rate limiting observed
Security High severity Confidence: Low
Real audits never include invented numbers. If a control can't be verified without access, the finding is labeled as needing evidence — not claimed.
Questions
Before you ask.
What exactly do I receive?
A repository and live-site inspection, baseline metrics from your existing tests, lint, type checks, and builds, a prioritized issue register scored by severity, confidence, and effort, recommended fixes with verification steps, and a before/after measurement template.
How long does a starter audit take?
Three to five business days for one product surface — app, website, or API — with up to ten prioritized findings. Larger scopes are split into clearly bounded engagements.
Will you change my production code?
Not without approval. The starter audit is read-only unless you approve specific low-risk fixes. When fixes are approved, each one is verified by re-running tests or commands, and nothing ships to production without your sign-off.
How is pricing determined?
Pricing is scoped per engagement — it depends on scope, repository size, access, and implementation effort. Every finding includes evidence; no business outcomes are guaranteed.
Want to know what's actually broken?
Tell me about your product and what's been nagging you. I'll reply with an honest read on whether an audit is worth it — and what the first findings would look like.