This Portfolio
A SaaS product. The product is me.
The Numbers
1
Product owner & designer
5
Case studies shipped
0
Generic templates used
Live
Deployed and public
01 · The Brief
Most portfolios are documents. This one is a product.
A designer who builds real enterprise software shouldn't present their work in a PDF or a scrollable webpage with a hero image and three project cards. The work is complex. The thinking is layered. The brief was to build something that reflects how I actually think about product design.
The portfolio had to do two things simultaneously. First, demonstrate the quality of the work itself. Second, demonstrate that I can take a product from concept to shipped without handing it to an engineering team.
The constraint was intentional: no traditional dev handoff. I built it using Abacus AI as a collaborative development partner, writing precise product specifications and directing the build through structured prompts. Every architectural decision, every component, every interaction was designed first, then built exactly to spec.
"The dashboard is the portfolio. The portfolio is the point."
02 · The Design Thinking
Why a dashboard, not a website.
The decision to build a dashboard-first portfolio rather than a marketing site was deliberate and came early. A marketing site would have been faster to build. It would also have been indistinguishable from every other designer's portfolio.
The products I design are dashboards: dense, data-rich, high-context environments where decisions have consequences and UI clarity is non-negotiable. A dashboard portfolio says something a website cannot: this is how the designer thinks when the stakes are real.
The dashboard frame also creates honest constraints. Navigation has to work. State has to be managed. The sidebar, the topbar, the component patterns all have to be coherent. There is nowhere to hide a gap in thinking behind a nice hero image.
The navigation logic
Four destinations: Dashboard, Projects, Profile, Settings. Each one serves a different kind of reader. A hiring manager might go straight to Projects. A recruiter might start with the Dashboard to understand scale and output. An engineer might check the Settings page to see how the contact flow is handled. The portfolio is designed for multiple entry points, not a single linear scroll.
03 · The Build Process
Specification before code. Every time.
The build methodology was the same methodology I use in client work: define the problem clearly, write a tight specification, then execute. The difference here is that I wrote the specifications to be understood by an AI development partner rather than a human engineering team.
Every page began as a written specification. Layouts described in detail. Component behaviours defined. Edge cases accounted for. Color tokens documented before the first component was built. The specification was the design work. The build was the execution.
Screen 01
Dashboard
The dashboard is the first thing a visitor sees and the most deliberate screen in the portfolio. KPI cards with count-up animations. A timeline showing output over time. A donut chart showing work distribution by industry. Every element chosen to make the case that this designer thinks in systems, not screens.
KPI Cards
Total projects, industries covered, years of experience. Numbers count up on entry.
Gantt Chart
Project timeline rendered as a real Gantt, not a decorative graphic.
Donut & Sparklines
Work distribution by industry and output trend over time.
Screen 02
Projects
A grid of project cards, each with a distinct color pulled from the project's brand identity. Company badge, status badge, summary, and tags. Five projects, five different entry points into the full case studies.
Card Design
Colour-blocked image area, company tag, status badge, summary, and categorisation tags.
Status Logic
Shipped for completed client work. In Progress for active ventures. Live for work running in production.
Screen 03
Profile
Not a CV. A professional statement. The profile page is structured to answer the questions a hiring manager actually has: What does this person do? What have they shipped? How do they think? What do they believe about design?
Summary & Philosophy
Direct statements about how I approach design work, not a list of adjectives.
Experience Timeline
Work history rendered as a timeline, not a bullet list.
Skills & Context
Competencies framed around the problems they solve.
Screen 04
Settings (Let's Talk)
The contact page inside a settings frame. A hiring manager who opens Settings to find a contact form will notice the design decision. It's a small signal that says: every piece of this was thought about.
Contact Form
Name, email, message. Success state replaces the form with a confirmation.
Right Column Cards
LinkedIn, Medium, and email links. Resume available on request.
Global Footer
'The dashboard is the portfolio. The portfolio is the point.'
04 · Design Decisions
The choices that make it a product, not a page.
The dashboard is the argument
A designer who builds operational software should demonstrate that they can navigate the UI they design for.
Specificity is the point
Every component in this portfolio was built to spec. No UI kit templates.
Stay in the product
A PDF breaks the experience. A profile page that behaves like a SaaS product maintains it.
Every destination considered
Putting the contact form inside Settings is a small design decision with a clear signal.
05 · Reflection
What building this taught me.
Building a product without a traditional engineering team clarifies something that client work can obscure: the quality of the output is almost entirely determined by the quality of the specification. Vague requirements produce vague results, regardless of who is doing the building.
Writing specifications precise enough to be built correctly by an AI development partner is the same skill as writing specifications precise enough to be built correctly by a human engineering team. The output surfaces the gaps in thinking immediately, which makes it an unusually honest feedback loop.
Four lessons
Specification quality determines output quality.
Ambiguity produces approximately-right results. Precision produces exactly-right ones.
The build is feedback on the spec.
Every place the build diverged from the intent was a place the spec was unclear.
Components are decisions.
Every component represents a decision: what state does it need, what does it communicate, how does it behave when something goes wrong.
The product is the argument.
A portfolio that demonstrates how a designer thinks is more compelling than one that describes it.