Serverly

As companies scale, they often lose track of their digital assets. They no longer have clear visibility into what they own, where it's hosted, whether it's currently online, or when critical assets like SSL certificates and domain names are set to expire. This lack of visibility leads to painful outages, expired SSLs, broken pages, and even security vulnerabilities. Downtime can cost thousands per minute, and a single browser warning about an invalid certificate can instantly erode user trust.

When I joined Serverly, the product was already in motion but it needed a stronger foundation to succeed.

• No clear visual identity

  They needed a logo and design direction that could help them stand out in a competitive, developer-focused space.

• Cluttered and inconsistent UI

  The early version lacked clarity, which could lead to poor first impressions and early user drop-offs.

• No design system

  Without reusable components, scaling the product and collaborating with developers would be difficult.

Working closely with the founder and backend engineer, I restructured Serverly around one question: how do teams see everything that matters about their infrastructure without hunting across five different tools? Every decision below answers that, from how a server gets connected to how an alert reaches the right person before an outage becomes a crisis.

Auto-discovering a user's infrastructure once a server connects, and making monitoring an explicit opt-in rather than automatic, were product decisions made by Anthony and the backend engineer. My job was turning both into something a user could actually operate.

I designed the connection flow as two distinct paths, a single server upload and a bulk upload, rather than forcing every user through one generic form regardless of how many servers they were adding. Once a connection succeeded, I designed how the discovered sites get presented: a scannable table showing name, IP address, and domain type, with a clear Monitored or Not Monitored status per site so a user immediately understands nothing is being tracked until they say so. For the multi-select bulk-enable action, already scoped by the team, I designed the selection interaction and the interface for turning monitoring on across multiple sites at once, so a user managing ten sites isn't stuck toggling them one at a time.

Website Monitoring's structure, tracking uptime, SSL status, domain health, and response time in one place, follows conventions already established in the monitoring category.

I separated domain and SSL expiry into their own row, distinct from the three headline stats above (uptime, last check, incident count). Both dates answer the same underlying question, when does this stop working, and belonged together rather than competing for space with live status metrics.

I also defined the status color system used across the entire product: green for active monitoring with no incidents, red for active monitoring with an ongoing incident, grey for unmonitored, yellow for paused. Keeping that language identical across the server list, monitors list, and detail page meant a user never had to relearn what a color meant moving deeper into the product.

What counts as an incident, and which notification channels exist, were decisions made by the engineering team. I designed the screens where that information actually gets used: the incident record, the incident list, and the monitor configuration flow.

On the incident detail page, I built the activity log as a chronological timeline rather than a single status badge, showing exactly when an incident started and when it resolved. A team member checking back on an issue sees its full lifecycle at a glance instead of just its current state.

Brand identity wasn't the deepest focus of this project, most of the design effort went into the product and design system. I explored a few directions for the mark before landing on the current one, prioritizing legibility across light and dark surfaces, web, and the mobile app icon over a more conceptual approach.

I built a full design system covering typography, spacing, color, and components, structured so every choice mapped directly to something developers could implement in code.

Colors were organized as semantic tokens rather than raw values, named by purpose (Text-primary, Interface-Background, State-Error, Primary-Button-Default) instead of by hex code, and mapped separately for light and dark mode. A developer building an error state didn't need to guess which red to use, the token told them.

Partway through the project, I noticed spacing and layout structure drifting as more dashboard screens got added. I built a layout anatomy reference documenting exact spacing values across desktop and tablet breakpoints, so new screens stayed aligned to the same structure instead of each one reinventing padding and hierarchy on its own.

That direct mapping between design and implementation is what later reduced handoff errors and shortened the release timeline, covered in Outcome.

The marketing site was structured across four pages, home, pricing, contact, and documentation, rather than a single scrolling page, giving Serverly's technical audience room to explore product details and documentation without crowding the homepage pitch.

Serverly is still pre-launch, so there's no market outcome to report yet. What exists is the foundation: a design system built around semantic tokens and a documented layout structure, meant to keep the product visually consistent as development continues past this phase of the build.