Live MVP
Live MVP
Live MVP
SaaS
SaaS
SaaS
Enterprise Application
Enterprise Application
Enterprise Application
Founding Designer
Founding Designer
Founding Designer
Jan – Aug 2025
Jan – Aug 2025
Jan – Aug 2025
Designing clarity
into complexity
Designing clarity into complexity
Monessy is a SaaS architecture documentation platform for engineering teams. I joined as the founding designer with nothing but a verbal idea and built the entire product experience from scratch.
Monessy is a SaaS architecture documentation platform for engineering teams. I joined as the founding designer with nothing but a verbal idea and built the entire product experience from scratch.
Monessy is a SaaS architecture documentation platform for engineering teams. I joined as the founding designer with nothing but a verbal idea and built the entire product experience from scratch.
The product
The architecture documentation problem no one talks about
The architecture documentation problem no one talks about
Engineering teams lose hours every week to a problem no one talks about: their architecture documentation is always wrong. Diagrams live in one tool. Configs live in code. The actual system state lives nowhere. When something breaks at 2am, the person on call is guessing.
Engineering teams lose hours every week to a problem no one talks about: their architecture documentation is always wrong. Diagrams live in one tool. Configs live in code. The actual system state lives nowhere. When something breaks at 2am, the person on call is guessing.
Monessy fixes this — a single platform to document, visualise, and monitor software architecture, with live metrics overlaid directly on diagrams. GPS for your architecture.
Monessy fixes this — a single platform to document, visualise, and monitor software architecture, with live metrics overlaid directly on diagrams. GPS for your architecture.
I joined as founding designer in January 2025, before a design system, a component library, or a single polished screen existed.
I joined as founding designer in January 2025, before a design system, a component library, or a single polished screen existed.
My role
Sole designer. End to end.
Sole designer. End to end.
Sole designer. End to end.
I worked directly with the founders as my only collaborators. No design lead above me, no existing visual language to extend. A rough early sketch existed before I joined — my final designs share almost nothing with it. Everything was reimagined from first principles.
I worked directly with the founders as my only collaborators. No design lead above me, no existing visual language to extend. A rough early sketch existed before I joined — my final designs share almost nothing with it. Everything was reimagined from first principles.
The team consisted of two developer-founders and me. Working in a lean startup meant wearing multiple hats, collaborating closely with early testers, and iterating quickly based on real feedback rather than formal research cycles.
The team consisted of two developer-founders and me. Working in a lean startup meant wearing multiple hats, collaborating closely with early testers, and iterating quickly based on real feedback rather than formal research cycles.
End-to-end UX and UI design across 100+ responsive screens
Onboarding, organisation setup, and project hierarchy flows
Information architecture across four distinct technical personas
Role-based dashboards for architects, SREs, EMs, and executives
The interactive canvas — the core product experience
Marketing landing page, launch assets, and pitch document
The design challenge
One product. Four completely different users.
One product. Four completely different users.
The hardest part wasn’t the volume of screens. It was that each persona has a fundamentally different mental model of what the product even is. Same platform. Same data. Four completely different definitions of useful.
The hardest part wasn’t the volume of screens. It was that each persona has a fundamentally different mental model of what the product even is. Same platform. Same data. Four completely different definitions of useful.
Architect
"Is my diagram accurate and up to date?"
Canvas
Version history
Import
Architect
"Is my diagram accurate and up to date?"
Canvas
Version history
Import
Architect
"Is my diagram accurate and up to date?"
Canvas
Version history
Import
SRE / DevOps
"Is my system healthy right now?"
Live metrics
Alerts
Heatmaps
SRE / DevOps
"Is my system healthy right now?"
Live metrics
Alerts
Heatmaps
SRE / DevOps
"Is my system healthy right now?"
Live metrics
Alerts
Heatmaps
Engineering Manager
“Who changed what, and was it approved?”
Audit Trail
Branches
Approval flows
Engineering Manager
“Who changed what, and was it approved?”
Audit Trail
Branches
Approval flows
Engineering Manager
“Who changed what, and was it approved?”
Audit Trail
Branches
Approval flows
Executive
“Are we meeting our SLAs and staying compliant?”
Dashboards
SLAs
Cost overview
Executive
“Are we meeting our SLAs and staying compliant?”
Dashboards
SLAs
Cost overview
Executive
“Are we meeting our SLAs and staying compliant?”
Dashboards
SLAs
Cost overview
Serving all four without watering any one of them down drove every major design decision I made.
Serving all four without watering any one of them down drove every major design decision I made.
Process
Learning the domain before designing the product
Learning the domain before designing the product
I'm not a developer — before this, I couldn't have told you what an API actually did. Learning enough about how systems and infrastructure actually work was the first real challenge, and it came before any design challenge. I taught myself what I could, and leaned on the founders for the rest — when I got stuck, they'd walk me through how things actually worked before I could design around it.
I'm not a developer — before this, I couldn't have told you what an API actually did. Learning enough about how systems and infrastructure actually work was the first real challenge, and it came before any design challenge. I taught myself what I could, and leaned on the founders for the rest — when I got stuck, they'd walk me through how things actually worked before I could design around it.
The closest reference I found was IcePanel, built around a fixed way of modeling systems layer by layer. Monessy needed something broader — live operational data, governance, and collaboration in one place, not just a static structural view. So there wasn't much to borrow; most of it had to be reasoned out from scratch.
The closest reference I found was IcePanel, built around a fixed way of modeling systems layer by layer. Monessy needed something broader — live operational data, governance, and collaboration in one place, not just a static structural view. So there wasn't much to borrow; most of it had to be reasoned out from scratch.
I started with the admin's setup flow, not the canvas — understanding how an organisation's structure gets defined before designing what anyone would actually spend their time in."
I started with the admin's setup flow, not the canvas — understanding how an organisation's structure gets defined before designing what anyone would actually spend their time in."
Design decisions
Three decisions that defined the product
Three decisions that defined the product
1
Progressive disclosure over feature completeness
The canvas needed to hold diagramming, live metrics, comments, version history, and more — all at once. Surfacing everything made nothing usable. The fix: show what’s needed at rest, reveal the rest on hover and click. A principle I returned to constantly, every time the canvas felt cluttered again.
1
Progressive disclosure over feature completeness
The canvas needed to hold diagramming, live metrics, comments, version history, and more — all at once. Surfacing everything made nothing usable. The fix: show what’s needed at rest, reveal the rest on hover and click. A principle I returned to constantly, every time the canvas felt cluttered again.
1
Progressive disclosure over feature completeness
The canvas needed to hold diagramming, live metrics, comments, version history, and more — all at once. Surfacing everything made nothing usable. The fix: show what’s needed at rest, reveal the rest on hover and click. A principle I returned to constantly, every time the canvas felt cluttered again.
2
Zero setup for the people actually using the board
My first instinct was one setup flow for everyone. It didn't hold up — most users never touch org structure, only admins do. I split it: admins define the org, projects, and environments; everyone else gets an invite and lands straight on their board, no setup at all.
2
Zero setup for the people actually using the board
My first instinct was one setup flow for everyone. It didn't hold up — most users never touch org structure, only admins do. I split it: admins define the org, projects, and environments; everyone else gets an invite and lands straight on their board, no setup at all.
2
Zero setup for the people actually using the board
My first instinct was one setup flow for everyone. It didn't hold up — most users never touch org structure, only admins do. I split it: admins define the org, projects, and environments; everyone else gets an invite and lands straight on their board, no setup at all.
3
Same system, four different surfaces
Landing on the right board solved setup, but everyone still saw the same view once inside. An SRE debugging an incident and an EM reviewing changes need completely different things. Rather than one adaptive view, I designed distinct surfaces per persona — heatmaps for SREs, approval queues for EMs, the full canvas for architects — all pulling from the same system.
3
Same system, four different surfaces
Landing on the right board solved setup, but everyone still saw the same view once inside. An SRE debugging an incident and an EM reviewing changes need completely different things. Rather than one adaptive view, I designed distinct surfaces per persona — heatmaps for SREs, approval queues for EMs, the full canvas for architects — all pulling from the same system.
3
Same system, four different surfaces
Landing on the right board solved setup, but everyone still saw the same view once inside. An SRE debugging an incident and an EM reviewing changes need completely different things. Rather than one adaptive view, I designed distinct surfaces per persona — heatmaps for SREs, approval queues for EMs, the full canvas for architects — all pulling from the same system.
Where I was wrong
Context switching confusion in early testing
Context switching confusion in early testing
When the MVP went out to early testers, the dominant feedback was confusion around switching context — moving between projects, teams, or environments took too many manual steps.
The fix was to simplify what a user sees first: the moment they open the app, they land directly on the canvas for whatever team, project, or environment they're already in, and can move from there if needed. There's still a small learning curve, since the tool itself is new to most people — but the friction around switching specifically didn't come back in follow-up sessions.
Small change, real signal — and a principle I carried into every decision after:
context should never cost the user their place in the work.
Final designs
The work
The work
Outcome
From a verbal idea to a live product
From a verbal idea to a live product
Monessy launched to beta with a fully realised product - onboarding, canvas, four persona dashboards, collaboration layer, and marketing presence, all designed solo, alongside a three-person team, in eight months.
Monessy launched to beta with a fully realised product - onboarding, canvas, four persona dashboards, collaboration layer, and marketing presence, all designed solo, alongside a three-person team, in eight months.
This is the first version, and it shows - there's a lot still to polish, and the product has a long way to evolve before it's ready for a wider launch.
This is the first version, and it shows - there's a lot still to polish, and the product has a long way to evolve before it's ready for a wider launch.
No hard metrics yet, the product’s still in beta. But the process holds up: real user feedback, fast iteration, decisions that visibly improved how the product felt to use. That loop — test, learn, rebuild — is what I’d point to as the actual outcome of this project.
No hard metrics yet, the product’s still in beta. But the process holds up: real user feedback, fast iteration, decisions that visibly improved how the product felt to use. That loop — test, learn, rebuild — is what I’d point to as the actual outcome of this project.
What I’d do differently
Push for user testing sessions earlier, not just at MVP stage. And build a lightweight design system from day one instead of reconciling inconsistencies later.
Push for user testing sessions earlier, not just at MVP stage. And build a lightweight design system from day one instead of reconciling inconsistencies later.
What this taught me
Designing for technical users means earning their trust before their attention. Learning their language — infrastructure, environments, system design fundamentals, incident severity — wasn’t optional. It was the prerequisite for designing anything credible.
Designing for technical users means earning their trust before their attention. Learning their language — infrastructure, environments, system design fundamentals, incident severity — wasn’t optional. It was the prerequisite for designing anything credible.
What's next
The most consistent feedback we've heard when showing the product to others is that building the architecture manually, one node at a time, takes too many hours. Automating that setup - importing from existing infrastructure instead of building by hand is the priority for version two
The most consistent feedback we've heard when showing the product to others is that building the architecture manually, one node at a time, takes too many hours. Automating that setup - importing from existing infrastructure instead of building by hand is the priority for version two