Bike orders and contracts
I built the staff Admin and the screens business users use to look up their information.
Work context
Orders, contracts, and vehicle handovers in the bike business involved both staff operations and business customers checking their information. The legacy system and manual processes remained in use while the new system was built.
I handled frontend development across this project, building the staff Admin and then a portal where business customers could check their subscriptions and payments. I prepared screens for the new data model and aligned API contracts with the backend team.
I handled the frontend, working with around five backend engineers. I turned the planner’s wireframes into screens following existing Admin patterns and coordinated user-type values and response fields with the backend team. The backend team handled legacy data migration and consistency fixes.
Decisions and implementation
- 01
Order and contract entry points
Staff handled the first order and contract delivery after a sale; business customers needed to check their contracts and payment status.
I split the screens so staff could create orders and send contracts in Admin, while business customers could sign in to My Page to check contracts, unpaid and paid amounts, and their current plan.
- 02
Workflow checks before API finalization
Return, handover, and insurance-change screens had to move forward before their APIs were finalized.
I used fixtures for a nonproduction environment to validate the screens and workflow first, documenting the APIs, fields, and areas to replace during real integration.
Once the actual request and response contracts were available, I connected the vehicle, store, and insurance screens to them and adjusted the UI to remain compatible with existing field representations.
- 03
User-type workflows
We expected a separate model for business customers, but they and regular users shared a model and were distinguished by a type value. Business customers could also use regular SWAP services.
I aligned the type value with the backend team, kept regular-service flows available, and separated business-only menus, pages, and APIs. The frontend handled guidance and navigation after access was denied.
- 04
Response shape missed by automation
Automation based on B2B responses passed, but in B2C responses the business-information object itself was absent, leaving necessary information invisible on the screen.
I requested a backend response fix and updated the UI conditions by user type. I redefined the case and repeated both automated and direct screen checks.
Implementation details
In Admin, I developed screens separately from APIs that were still undefined. Later, in the business portal, I sequenced data lookups after authentication, access checks, and store selection. I handled changes in user type and response shape explicitly.
- 01Authentication ready
Restore saved auth state and complete initialization
- 02Access check
Fetch store access summary and list
- 03Store selection
Fetch details and subscriptions with an ID from the list
- 04Refresh after change
Apply payment results and refetch billing
Fixtures and response contracts
Before the APIs were defined, I checked return, handover, and insurance-change screens with nonproduction fixtures. In the real integration, I incorporated the discriminator in the shared user model. In particular, I found B2C responses where the business-information object itself was absent, and worked with the backend to correct the response contract while updating UI conditions and test cases.
Requests after access checks
After restoring auth state from Zustand and completing initialization, the portal checked the access summary, then fetched the store list and selected store details in sequence. Null SWR keys deferred requests until their conditions were met. Sign-in required, access denied, and lookup error appeared as separate entry states.
Selection state and payment results
The store was chosen from the URL, saved selection, then single-store default, in that order; only IDs present in the list were used for detail lookups. After payment, only successful items were applied to the SWR cache and the billing list was refetched. Partial failure, complete failure, and request exceptions each received separate guidance.
One-time authentication return
When payment-method registration began, the portal saved the return location in sessionStorage and opened authentication through the app bridge. The result screen read and deleted the saved value, then navigated only if it was a same-origin portal path. Without a valid return location, the flow continued to the existing payment-method screen.
Verification and results
- Workflow
I first checked return, handover, and insurance changes with nonproduction fixtures, then integrated them against the actual API contracts.
- User types
I checked B2B and B2C edge cases with Playwright E2E and direct screen inspection, repeating both after the fix.
- Usage scope
I developed the staff flow for first orders and sending contracts. By July 2026, I had also connected the portal flow for business customers to view subscription, unpaid, and payment status and return after payment-method handling. Actual adoption and reductions in manual work were not measured separately.
Implemented staff order and contract flows and self-service lookup screens for business customers, and checked the workflows before and after the APIs were finalized.
The backend owned migration of existing data. I do not present a measured reduction in manual work or costs.
Reflections
I kept areas with undefined APIs separate while checking the workflow early. When actual data differed from our assumptions, I revised the UI and realigned the contract and user experience.
Based on career records and implementation evidence. Diagrams reconstruct the work for explanation; private product screens and data are excluded.