Sellable quantity reflects both available and reserved stock.
Inventory transactions track purchases, sales, returns, adjustments, and damaged stock—preserving an operational history rather than only the current number.
Case study · 02 AP Enterprises
Commerce is more than a catalogue.
It is a connected operational system.
Building a multi-surface platform that connected customer shopping to the inventory, orders, payments, delivery, and administration required behind every transaction.
SHOP↓ORDER↓OPERATEAP
Platform
Customer, staff, and administration workflows
Role
Full-stack application, backend, data, and deployment
Stack
Flutter · Go · PostgreSQL · Railway
Web
The challenge 01
Connect the customer journey to the work that fulfils it.
The goal was to build more than a product catalogue. The platform needed to carry a customer from discovery and checkout into the internal systems needed to fulfil their transaction.
That meant a backend capable of maintaining consistency across interconnected domains: inventory, carts, orders, payments, deliveries, returns, reviews, coupons, and administration.
Domain model 02
Customer
→Products & cart
→Order
→Payment
→Delivery
The same system also supports inventory, returns, reviews, coupons, staff assignment, and administration. Business rules live on the server so that clients do not become the source of truth.
Architecture 03
Flutter mobile / web→HTTPS→Go backend→PostgreSQL
One business layer, multiple customer and operational surfaces.
Flutter handles the application experience across mobile and web. The Go backend owns validation, authorization, domain logic, and data access. PostgreSQL provides the relational and transactional foundation for the connected commerce model.
FlutterFlutter WebGoREST APIsPostgreSQLRailway
Engineering detail 04
Retrying a request should not create a second operation.
Idempotency keys associate retryable requests with a request hash and stored response, protecting business-critical workflows from duplicate outcomes.
Reviews are tied to verified purchases.
A customer must have a delivered order containing the product before leaving a review, with one review per user per product enforced by the database.
Deletion respects retention needs.
The system supports soft deletion followed by anonymization of personal information while retaining necessary order and financial history.
Security & delivery 05
Server-side control
Authentication, authorization, input validation, role-aware access, secure password handling, verification, recovery, and business-rule enforcement are handled in the backend, supported by database constraints and OWASP Top 10-aligned practices.
Practical production setup
The Go backend and Flutter Web application are deployed on Railway, keeping the infrastructure simple while providing a practical production environment for the application.
Result 06
A cohesive platform for the customer journey and the operations behind it.
- Cross-platform Flutter application and Flutter Web
- Go backend and REST API
- PostgreSQL transactional data layer
- Customer, staff, and administrative workflows
- Product, inventory, order, payment, and delivery management
- Returns, reviews, coupons, and account lifecycle support
What this demonstrates 07
Business workflows need explicit domain models.
Client state cannot own critical transactional rules.
Inventory needs a history, not just a number.
Retries need idempotency in production systems.
Account lifecycle is more than login and registration.
Building connected workflows? 08
Let’s make the
business logic dependable.
If your product needs more than isolated features, let’s talk about the system that will hold the workflow together.
Start a conversation ↗