02 // SELECTED WORK // CASE STUDY 01
Domain
Doctor.
A clearer look at what happens when you visit a domain.
A web-based diagnostic tool that brings DNS, TLS, HTTP behavior, and security headers together in one report. Built to make the invisible layers of the web easier to examine and understand.
A domain name is only the beginning.
Typing a web address hides a remarkable amount of coordination. DNS needs to resolve, a secure connection needs to be established, the server needs to respond, and the browser needs to decide what it can trust.
Each layer is usually inspected with a different tool. I wanted to bring those signals together so someone could investigate a domain without constantly switching context.
Domain Doctor started as an exploration of those systems and became a practical exercise in building and operating a public-facing diagnostic application.
Four layers. One clearer picture.
Each section focuses on a different part of a domain's behavior. Together they offer a more useful starting point for investigation than a single pass/fail score.
DNS
Look at the records and resolution details that tell clients where a domain points.
TLS
Inspect the certificate and transport security information behind a secure connection.
HTTP
Follow how a server responds, including status codes and redirects.
Security headers
Surface browser-facing controls and highlight areas that deserve a closer look.
From a domain to a readable report.
A completed diagnostic brings the separate checks into a single interface, making it easier to move between the layers and investigate the details.
Built as a service, not just a script.
The project connects user-facing design with backend diagnostics and the infrastructure required to host an application reliably.
Browser UI
User-facing reportA single interface organizes the checks and makes technical results easier to browse.
FastAPI service
Python backendThe API performs the network-facing inspections and returns structured diagnostic results.
External services
DNS · TLS · HTTPChecks interact with the public systems that determine how a domain resolves and responds.
Container deployment
Docker · CaddyContainerized hosting, reverse proxying, and health checks support repeatable operation.
Deployment
Docker Compose supports a repeatable deployment, with Caddy serving as the reverse proxy in production.
Release discipline
Automated tests, versioned releases, and a protected main branch help keep changes controlled.
Operating in public
Health checks, privacy information, and Umami analytics extend the work beyond feature development.
Making the results useful is part of the engineering.
Clarity over noise. Results need enough technical detail to be meaningful without overwhelming someone who is trying to understand what failed or what to investigate next.
Expect the unexpected. Redirects, inconsistent responses, and unusual domain configurations turn seemingly simple network checks into real application design problems.
Ship, observe, improve. Deploying a public tool means paying attention to tests, configuration, uptime, and how real visitors experience the application.
Diagnostic areas
Automated tests passing at the initial validated release
Documented release milestone
Still asking better questions.
Future improvements focus on stronger diagnostic coverage, redirect handling, and clearer explanations of what each finding means.