Designing an interconnected cultural, commerce, and planning ecosystem from the ground up.
HPS Shalom began with a broad product idea: create a warm, modern digital experience around Jewish culture, holidays, family life, planning, editorial content, and commerce. The design challenge was not creating one application. It was determining how multiple products and experiences could coexist without becoming a collection of disconnected features.
Role & Ownership
Founder · Platform Architect · Editorial Systems Lead
Responsibilities
The HPS Shalom homepage: a live holiday countdown, candle-lighting times, and today’s Hebrew date.
HPS Shalom needed to support several fundamentally different experiences: editorial discovery, seasonal and holiday content, commerce, products and collections, family planning, subscription services, content management, authoring, and account experiences.
The danger was obvious: each new idea could become another isolated feature.
The Core Product Question
How do you build an ecosystem without building a collection of disconnected products?
Four fundamentally different product areas needed to share one identity: a public editorial experience, a commerce store, a paid planning product, and the content and administration systems behind all three.
HPS Shalom
Product Area
Public Experience
Product Area
Store
Paid Subscription
Planner
Product Area
CMS / Authoring
The Store and the Planner are separate products. The Planner is a paid subscription; a Store purchase does not require a Planner membership. The architectural diagram needed to communicate boundaries as clearly as it communicated relationships.
A unified ecosystem does not mean forcing every experience into one workflow. Editorial discovery has different needs from commerce. Commerce has different needs from family planning. The Planner has different expectations from the public cultural experience.
The product needed shared language, components, identity, and navigation while allowing each product area to behave appropriately for its purpose. This became a guiding architectural principle.
The public experience needed to be warm, illustrated, family-oriented, seasonal, editorial, culturally grounded, and approachable — supporting discovery without immediately feeling like a SaaS dashboard or a storefront.
Editorial Hierarchy
Traditions told as stories, not reference entries.
Content is organized around the character of the Jewish calendar itself, helping visitors understand not only what a tradition is, but why it matters.
Seasonal Storytelling
Food, memory, and tradition presented as one story.
Recipes connect meals to the celebrations, history, and family memory that surround them, rather than living as an isolated recipe index.
Discovery, Calendar Awareness, and Family Learning
Family learning, structured for every age in the household.
Calendar awareness that stays relevant every day, not only on holidays.
Inclusive design that gives children their own way into the story.
The Store is a distinct commerce experience: products connected to the traditions they support, presented through the same visual and navigation system as the rest of the platform.
Store
Cultural Experience
vs.
Commerce
HPS Shalom is an editorial and cultural platform first. But it also needed a real commerce experience, connected to the same traditions the content already told stories about.
Resolution
Let commerce participate in the broader visual and navigation system without turning every editorial interaction into a shopping funnel.
The public HPS Shalom experience is editorial and exploratory. The Planner is task-oriented and persistent. Users need state, accounts, saved information, planning workflows, subscription status, billing, and family context — a different interaction model than the one that serves discovery.
Planner
Shared brand. Different job to be done.
Shared components and product architecture kept the public experience, Store, Planner, and CMS from drifting apart as each area grew on its own timeline.
Shared Foundations
The public experience can look simple while requiring real operational structure behind it. Editorial content, holidays, products, and subscription plans all needed management workflows that stayed out of the customer-facing experience.
CMS Capabilities
Traditional Workflow
DiscoverDesignPrototypeHandoffWait for ImplementationReview
That workflow is not obsolete. It is still the right model for a great deal of product design work. What changed on this project was the distance between a decision and the ability to evaluate it.
AI-Enabled Workflow
Frame
Define the problem and the product boundaries before any interface exists.
Design
Structure the experience and interaction model for the specific product area.
Functional Prototype
Build something that behaves like the real product, not just a static mockup.
Implement
Move the validated interaction into working, connected software.
Experience It
Use the actual product to evaluate the decision, not a simulation of it.
Critique
Judge the result against the product architecture and the intended outcome.
Iterate
Adjust based on what the working software actually revealed.
The distance between designing the experience and experiencing the design got much shorter.
AI-Assisted Work
AI could generate implementation. I still had to determine whether that implementation belonged in the product.
AI-assisted development made it possible to create a large amount of functionality quickly. That created a new design problem: the ability to produce features faster than they could be critically evaluated.
Some generated work could be incomplete, inconsistent, disconnected from the product architecture, visually acceptable but operationally weak, technically present without being genuinely useful, overly generic, redundant, or built on assumptions that needed verification.
Generated ≠ designed.
The designer’s role increasingly included:
An Expanded Role
AI made judgment more important, not less.
AI accelerated implementation. It did not remove the discipline of verifying that what got built actually behaves correctly. Routes, authentication, billing, CMS workflows, and commerce paths needed to be exercised deliberately, not assumed correct because they were generated quickly.
Build
A workflow or product area is implemented against the shared architecture.
Test
The built experience is exercised against its intended behavior.
Find Issues
Gaps, inconsistencies, and defects surface under real use.
Fix
Issues are resolved at the appropriate level: component, pattern, or product area.
Reverify
The fix is confirmed against the original issue, not assumed correct.
Iterate
The cycle repeats as the product continues to grow.
Ecosystem
vs.
Product Boundaries
A connected platform is only valuable if each product area still makes sense on its own terms.
Resolution
Create shared foundations while keeping Store, Planner, editorial, and CMS responsibilities explicit.
Speed
vs.
Coherence
AI-assisted development could produce new functionality quickly, but speed alone does not keep a growing product architecturally coherent.
Resolution
Use AI to accelerate execution while repeatedly returning to product architecture and shared patterns to prevent fragmentation.
Automation
vs.
Judgment
AI could generate a large amount of working implementation. Deciding whether that implementation belonged in the product still required a designer.
Resolution
Let AI handle repetitive implementation and exploration while preserving human responsibility for product decisions and acceptance.
Feature Breadth
vs.
Product Quality
The ability to produce features quickly created pressure to keep everything that got built, whether or not it belonged.
Resolution
Treat removal, consolidation, and refinement as product work rather than assuming generated functionality deserves to remain.
Shared System
vs.
Specialized Experience
Editorial, commerce, planning, and administration are different jobs to be done, even inside one connected ecosystem.
Resolution
Reuse foundations and interaction language without forcing editorial, commerce, Planner, and CMS workflows into identical interfaces.
AI-assisted tools increased the amount of implementation I could explore and evaluate directly, but I remained responsible for the product decisions: what should exist, how it should behave, how the pieces should connect, and whether the resulting experience was good enough to keep.
HPS Shalom became an interconnected product ecosystem spanning public editorial experiences, commerce, a paid planning product, CMS workflows, and shared platform foundations.
But the deeper lesson was methodological. AI did not remove the need for product design. It increased the amount of product that could be created quickly enough that product judgment, architecture, critique, and validation became even more important.
AI made it possible to build more. Product design determined what was worth keeping.
The future of product design is not choosing between designing and building. It is staying responsible for the experience across both.
An enterprise white-label, multi-tenant pharmacy platform. One system, three applications, one designer.
Another problem solved through sole design ownership and a shared component system, this one built entirely through traditional product design methods.