Public diagnostic products
MrUsman Tools Platform
A shared platform for five public diagnostic tools with deterministic scoring, bounded evidence collection and reusable reporting patterns.
- My role
- Product design, implementation, testing and deployment
- Status
- Five live public tools
Context
The system behind the screenshot.
The platform began with a reusable tools foundation and then expanded through five focused products: website health, SEO, DNS/email, tracking and landing-page conversion readiness.
Each tool reads a bounded set of public evidence, applies explicit rules and returns findings with detected evidence and a practical next action.
Reality first
The problem
A collection of unrelated calculators would create duplicated UI, inconsistent reports and repeated security risks.
The product needed a common standard for input validation, progress, evidence, scoring, errors, mobile reports and deployment while allowing each diagnostic to remain technically specific.
Constraints
- User-supplied public URLs and domains must be validated safely
- Private, internal and unsafe destinations must be blocked
- Responses require time, size and redirect bounds
- Scores must be deterministic and explainable
- Static-source limitations must be stated honestly
- Result interfaces must remain useful on small screens
My role
The tools were built one at a time on a shared foundation so each release could be validated before the next product expanded the platform.
- Shared tool architecture and interaction patterns
- Purpose-specific evidence and scoring models
- Public URL and domain safety controls
- Responsive result interfaces
- Build, deployment and production regression checks
System architecture
One product foundation, five evidence models
A common safety, request and reporting layer supports purpose-specific analyzers and scoring rules for each tool.
- 01Validated input
- 02Bounded public fetch
- 03Evidence analyzer
- 04Deterministic scoring
- 05Responsive report
Implementation
What was built.
Feature groups are kept specific to the system instead of repeating a generic services list.
Tool 1
- Website Health Scanner
- SEO, technical, tracking, lead-capture and security signals
Tool 2
- SEO Audit
- Metadata, crawlability, structure, links, media and schema evidence
Tool 3
- DNS & Email Health
- DNS, mail authentication, routing, TLS and website reachability
Tool 4
- GA4 / GTM Checker
- Static source evidence for analytics, tags, consent and conversion elements
Tool 5
- Landing Page Auditor
- Capture, CTA, trust, tracking and conversion-readiness evidence
Progressive disclosureTechnical details
SSRF-aware URL policy
Public HTTP/HTTPS targets are normalized and checked against private or reserved destinations. Redirects are revalidated rather than trusted automatically.
Bounded network work
Connection time, total time, redirect count and response size are constrained so a public tool cannot fetch indefinitely or accept unbounded payloads.
Deterministic rules
Category and overall scores come from centralized weights and explicit findings. The report does not imply that AI generated the score.
Short-lived reuse
Recent results can be cached briefly to reduce repeated requests while avoiding a permanent public scan-history product.
Quality system
Testing is part of the build.
Checks focus on real failure modes, evidence boundaries and the public experience after deployment.
Input safety
Exercise malformed, credential-bearing, non-HTTP and private/reserved target cases.
Redirect safety
Revalidate every redirect destination and reject a chain that moves from a public URL to a blocked target.
Evidence accuracy
Compare findings against known page, DNS, TLS and source-code signals for each diagnostic category.
Deterministic scoring
Repeat the same input against the same evidence model and verify stable weights, severities and summaries.
Responsive reports
Test input, progress, result tabs, matrices, findings and actions across mobile and desktop widths.
Production regression
After deployment, load and exercise all five tool routes while checking the shared Header/Footer contract.
Problem → system
What changed in the operating model.
Five separate interfaces and reporting conventions
One shared product shell with tool-specific evidence modules
Opaque scores with little proof
Detected evidence, explicit severity and a next action for each finding
Public scanners without destination controls
Validation, DNS checks, redirect revalidation and bounded requests
Evidence-backed
Outcomes
Five live tools now share a consistent product standard while retaining purpose-specific evidence and scoring.
- 01
Five live diagnostics available without an account
- 02
Consistent input, progress, result and error behavior across the suite
- 03
Reusable safety and reporting foundations for future tools
- 04
Clear limits that separate public evidence from claims the tools cannot prove
Honest reflection
Lessons carried forward.
A reusable platform is valuable only when tool-specific evidence remains accurate and understandable.
Public scanning products need safety controls before feature expansion.
Stated limitations increase trust when a check cannot observe JavaScript execution, private analytics or provider-side behavior.
Next system
Need something similar?
Bring the business problem. We can map the workflow, architecture, build and verification plan from there.