Back
Trust•2026•Client project•Full-Stack Engineer & Product Designer•Adelaide, AU

Adelhills Bengals

Bengal Cattery · Adelaide Hills

Replaces spreadsheets, paper records, and scattered emails for a registered Bengal breeder with one integrated system covering the full lifecycle from pairing to placement.

Full-Stack EngineeringProduct DesignInformation ArchitectureReactNode / Express
Diagram of Adelhills Bengals' thesis — one integrated platform for a lifecycle run on spreadsheets

Context

Adelhills Bengals is a registered Bengal and Cashmere Bengal breeder in the Adelaide Hills. The platform operates three integrated portals: a public-facing website showcasing cats and taking kitten applications, a buyer portal where approved customers track their kitten's journey, and an admin dashboard where the breeder runs the entire operation — pairings, litters, health records, applications, sales, and finances.

The Problem

The cattery ran on spreadsheets, paper records, and scattered emails, with no single system tying together breeding planning, health testing, buyer applications, and placement. Prospective buyers had no consistent, credible way to apply or follow their kitten, and the breeder had no operational dashboard.

Constraints

Three audiences

One codebase had to serve the public, approved buyers, and the breeder/admin — each with different access and needs.

Trust

The public site has to convey credibility (pedigrees, health badges, testimonials) to families making a long-term decision.

Pragmatic stack

A solo-maintainable system — a JSON file store with file-locking rather than a database — kept ops overhead low for a single breeder.

Strategic Approach

A modular three-portal architecture on a shared React frontend and Express backend, with role-based auth protecting the buyer and admin areas. The public site leads with trust signals; the buyer portal gives a personal journey view; the admin dashboard consolidates the full lifecycle into one operational surface.

Adelhills information architecture — three audiences (public, buyer, admin) on one codebase

Execution

1

Public Site

Built the homepage, filterable cat/kitten/stud/queen galleries, detailed profiles with pedigree trees and health badges, and a three-track application hub.

Adelhills Bengals available kittens listing
2

Buyer Portal

Delivered an approved-buyer dashboard with a kitten summary, photo gallery, and a timeline of updates.

3

Admin Dashboard

Shipped cattery operations — cat and litter management, buyer applications, health testing schedules, sales, and a breeding calendar.

Adelhills Bengals admin dashboard
4

Data & Auth

Implemented a file-locked JSON store, role-based authentication, image processing, and transactional email.

Adelhills stack decision — file-locked JSON store now, SQLite as the documented upgrade path

Outcomes

Shipped three integrated portals on one codebase: a public site, an approved-buyer portal, and a complete cattery operations dashboard.

Adelhills North-Star metric tree — the whole cattery runs in one system

Impact

  • •Gave a working breeder a single operational dashboard for the whole cattery.
  • •Built buyer trust with pedigrees, health badges, and a personal kitten-journey portal.
  • •Kept the system solo-maintainable by choosing a pragmatic, dependency-light stack.

Reflections

Decisions, tradeoffs, and what I'd change.

  • 01

    Made a deliberate dev-mode call: get a complete, usable UX in place first and backlog security, auth hardening, and performance — the right sequencing for a pre-launch client tool, with the risks written down rather than hidden.

  • 02

    Chose a file-locked JSON store over a database because the system serves one breeder (~60 cats); SQLite is the documented upgrade path for when it outgrows that.

  • 03

    Three audiences (public, buyer, admin) on one codebase is an information-architecture problem first — role-based auth is scoped as the next build, not a launch blocker.