Project gallery
1 / 25 · Possio
The challenge
Restaurant customers, cashiers, kitchen staff, and business operators need different interfaces around the same catalog, outlets, orders, and access rules. Possifi establishes that shared foundation while giving each audience a focused workflow.
Outcome
An end-to-end restaurant SaaS foundation with clear customer, outlet, and operator experiences, supported by a modular backend and a repeatable deployment workflow.
My contributions
- Built the Eats customer ordering PWA, Possio outlet workspace, and Console administration interface with shared product concepts.
- Developed a modular Go backend for identity, access, outlets, catalog, promotions, carts, orders, payments, and notifications.
- Implemented authentication and OTP flows, role-aware interfaces, and versioned API contracts for multiple client applications.
- Created container delivery workflows with image publication, health checks, application rollback, and separately controlled database migrations.
Explore the engineering & delivery
Product surfaces, workflows, architecture decisions, and verification details.
The product, end to end
Customer PWA & API integration
Possifi Eats
Outlet discovery, menu browsing, product customization, favorites, cart, promotions, checkout, order tracking, and account flows in a mobile-first, bilingual experience.
POS interface · staged integration
Possifi Possio
A role-aware outlet workspace for the register, orders, kitchen queue, payments, shifts, inventory, attendance, and reports. Operational screens include demonstration data.
Admin interface · staged integration
Possifi Console
Multi-outlet administration, operational dashboards, catalog and inventory management, access controls, and reporting, with a centralized repository layer prepared for backend integration.
Implemented modular backend
Possifi Service
A shared Go service with PostgreSQL, GORM, Redis, versioned client routes, identity and access modules, and customer commerce APIs.
How the workflow fits together
Discover an outlet and build an order
The customer selects an outlet in Eats, explores the menu, customizes products, adds items to the cart, and applies an eligible promotion.
Check out through shared commerce APIs
The backend handles checkout summaries, order placement, payment status, and order history through client-specific API contracts.
Operate the outlet in Possio
Register, kitchen, payment, and shift interfaces model staff operations around incoming orders. Cross-app operational integration is being completed incrementally.
Manage the business in Console
Operators manage outlets, catalog, inventory, roles, and reports. Demo-backed screens and typed repositories establish the administration workflow while integrations progress.
From product design to delivery
01 / Product & user journeys
Split customer, outlet, and operator workflows into dedicated applications. Shared outlet, product, order, and role concepts keep the suite coherent without overloading a single interface.
02 / Frontend implementation
Used Next.js, React, TypeScript, and Tailwind CSS for responsive customer and staff experiences. Eats includes internationalization and a PWA foundation; Possio and Console use reusable operational screens and role-aware navigation.
03 / Backend & API contracts
Implemented Go modules for identity, tenant/outlet context, catalog, promotions, carts, payments, orders, and notifications. Client-specific route groups serve Eats, POS, and Console, while frontend repositories centralize request handling and resource mapping.
04 / Persistence & access
Used PostgreSQL with GORM and versioned migrations for application data, plus Redis infrastructure. JWT authentication, OTP verification, and role policies support distinct customer and staff access paths.
05 / Integration & quality
Connected customer commerce journeys to the API and kept demo-backed operational modules explicit. Backend test suites cover cart behavior, identity, OTP, authorization, routing, and architectural dependencies.
06 / CI/CD & deployment
Defined GitHub Actions to test, build, publish immutable Docker images to GHCR, and deploy to a VPS with health checks and application rollback. Database changes use a separate migration workflow, avoiding automatic schema changes during application rollout.
Key engineering decisions
Separate experiences, share the domain
Dedicated customer, POS, and administration apps keep each workflow focused while the backend provides common identity, outlet, catalog, and commerce concepts.
Centralize backend integration
Typed API clients and resource repositories keep authentication, DTO mapping, and error handling outside presentation components, making staged integration easier to maintain.
Decouple application and database releases
An application image can roll back after a failed health check without silently undoing a database migration. Schema changes have their own controlled delivery path.
Testing & operational readiness
- Go checks and tests are defined for commerce, identity, policy, route, and architecture boundaries.
- Frontend projects include lint/build checks; the service workflow defines unit tests, static analysis, image builds, health verification, and rollback.
- Possio and Console integration is still incremental. No customer count, revenue impact, or fully operational production POS claim is attached to this case study.
Building something similar?
Let’s discuss the users, workflows, and priorities for your product.
Discuss Your Project