Live · 2026

Gopaddi OS

API architecture, integrations, and production delivery across Laravel services for Gopaddi Core products and Unified.

Backend engineer

Laravel
MySQL
RBAC
Realtime

Problem

On Core, supplier and marketplace apps drifted on permissions, design studio relied on polling, and there was no central layer to manage every Gopaddi product.

What I built

Owned API design and implementation across Laravel services on a two-person product squad.
Designed a shared RBAC model on Core used by both supplier and marketplace applications.
Replaced polling with live presence for multi-user design studio sessions on Core.
Modeled booking, quotation, and workspace data on Core and used architecture diagrams to keep service boundaries explicit.
Designed and implemented end-to-end Unified onboarding for new and existing Gopaddi businesses.

Architecture

flowchart TB
  fe[Frontend] --> core[Gopaddi Core]
  fe --> unified[Gopaddi Unified]
  core --> rbac[Shared access control]
  core --> studio[Design studio]
  core --> commerce[Commerce travel workspace]
  unified --> onboard[E2E onboarding]
  unified --> budget[Budget reconciliation]
  unified --> reports[Reporting]
  unified --> audit[Audit log]

Outcomes

One permission model across supplier and marketplace on Core instead of per-service inconsistencies.
Event-commerce and vacation-booking APIs on Core covering pricing, quotations, bookings, and PDF receipts.
Unified onboarding for new and existing businesses, plus budget reconciliation, reporting, and a reusable audit-log on Unified.

Context

Gopaddi is a set of Core products — marketplace, supplier, design studio, commerce, travel, and workspace — plus Unified, the central layer for managing them. I joined as the only backend engineer on a two-person product squad (February–August 2026) and owned APIs across the Laravel services behind that surface.

Frontend and product moved fast. The backend job was to keep service boundaries honest — one permission model, one booking flow, one audit trail — instead of each product inventing the same rules.

Shared access control

On Core, supplier and marketplace had drifted on who could do what. I designed a shared RBAC layer both applications used, so a role meant the same thing on both sides of the marketplace. That removed a class of “it works in this app but not the other” bugs that are expensive in production and worse in support.

Design studio

Design studio sessions on Core were multi-user. The first version asked the client to poll. I replaced that with live presence so collaborators could see who was in the session without a timer. The interesting part was not the transport — it was treating presence as a first-class backend concern with clear ownership, not a frontend workaround.

Commerce, travel, and workspace

Event-commerce and vacation-booking APIs on Core covered pricing, quotations, booking workflows, and PDF receipts. Those paths were designed with frontend sitting next to the API contract, not after it.

I used database models and architecture diagrams while building — not as slideware, as the way we agreed service boundaries and data relationships before writing the next endpoint.

Unified

Unified is not another workspace product. It is the management layer meant to bring every Gopaddi product into one place.

I designed and implemented end-to-end onboarding there for new and existing Gopaddi businesses. Budget reconciliation, reporting, and a reusable audit-log layer lived on Unified as well — so product teams did not each grow a private history table.