MahabubDecision
Redux Toolkit for shared booking state
Reason
Reservation steps need predictable, inspectable state transitions.
Trade-off
More ceremony than local component state for simpler screens.
Full StackLive2024
Ubaky
A food-tech booking experience focused on discoverability, availability, and a polished interface that feels ready for real diners — not just demos.
- Role
- Frontend / Full Stack Contributor
- Industry
- Food Tech
- Team Size
- Product engineering team
- Duration
- Feature delivery cycles
- Platform
- Web · Mobile-first
- Status
- Live
Case narrative
Engineering story
Ubaky helps diners reserve tables across Spain and Portugal — a product where clarity in each booking step directly affects completion.
Problem
Reservation flows often feel cluttered or inconsistent, which increases drop-off before confirmation.
Why it was difficult
Multi-step booking state, availability feedback, and UI density had to stay understandable under real diner impatience.
Approach
I contributed React + TypeScript interfaces with Redux Toolkit for shared booking state and a design-system baseline for consistent actions.
Why this approach
Predictable client state and reusable UI patterns reduce edge-case bugs in flows that users abandon quickly when confused.
Outcome
A more productized booking experience — clearer actions, more consistent screens, and safer state handling as features grew.
What I learned
Reservation products succeed when each step feels obvious Shared state needs discipline as features grow Design-system reuse accelerates trustworthy UI
Responsibilities & features
My responsibilities
- Implemented reservation-oriented interactive UI
- Structured shared client state with Redux Toolkit
- Supported frontend–backend integration for booking flows
Key features
- Discovery and booking-oriented navigation
- Responsive layouts for mobile diner behavior
- Structured multi-step reservation interactions
- Polished product UI patterns
Trade-offs
Engineering decisions
Choices that shaped the architecture — including what we accepted in return.
Decision
Design-system baseline (Ant Design)
Reason
Accelerates consistent UI without inventing every control.
Trade-off
Requires discipline to avoid generic, overloaded interfaces.
Decision
TypeScript-first React UI
Reason
Protects complex booking props and API contracts as the product evolves.
Trade-off
Slightly slower initial wiring for safer refactors later.
System shape
Technical architecture
- Component-driven React UI with shared state slices
- API-integrated booking pathways
- Reusable form and feedback patterns
- Client
- React App
- Node API
- Data Services
Technology stack
- React
- TypeScript
- Redux Toolkit
- Ant Design
- Node.js
- Avoided unnecessary re-renders in interactive flows
- Kept screens focused to reduce cognitive and render cost
Visuals
Project screenshot
A product screenshot from this project. Select it to open a larger view.
Outcome
Business impact
Practical results across experience, maintainability, scale, and value — without invented metrics.
User experience
Diners encounter clearer booking actions and less visual noise during reservation.
Maintainability
Shared state patterns make multi-step flows easier to extend safely.
Scalability
Consistent UI primitives support growth across restaurant and booking surfaces.
Business value
A more completeable booking journey supports the product’s core conversion path.
Explore the live product
Open the deployment, or continue to another case study below.