Problem
JUO Company grew into three shapes at once — a pet-adoption franchise, a pet-care commerce platform, and pet-friendly travel — and the systems grew apart with it. The franchise still ran on a Spring Boot stack from an earlier era. Each service carried its own member table, so one customer was three different people depending on which product they opened. Shared work like image processing was reimplemented per service, each catching the same problems on its own.
Approach
We pulled identity out first. A central member system now owns profiles, membership tiers, consent records, and account lifecycle for every JUO service — credentials, social login, two-factor, sessions, and service-to-service tokens handled in-house rather than delegated to an external IdP. Session tokens are stored only as hashes, rotate on every request, and if a spent token reappears the whole family is revoked. Services on other domains receive a 60-second handoff token instead of a shared cookie.
Three independently deployed products sit on top: the LoveJuo pet-care commerce platform, the franchise ERP, and JuoTrip, which takes a pet profile and trip constraints, filters and scores candidate places, then has an LLM write the itinerary. The ERP was rebuilt from the Spring Boot original onto a Node stack with the data and business rules carried over intact.
Outcome
One account now spans the products, and membership and consent records live in exactly one place. Each service keeps its own repository and release cadence — deliberately uncoupled — with only the genuinely shared pieces split into a common repository. LoveJuo and the ERP are in production; JuoTrip was built as the delivery for a Korea Tourism Organization Innovation Voucher project, starting with the Namiseom, Gapyeong, and Chuncheon region.