Skip to content
E-CommerceDirect SellingFlutterLaravelMulti-RegionMulti-TenantMobile AppsTeam Leadership

Salveowell

Client: Salveowell Corp. — delivered at Bixosoft
Visit Live Product
Salveowell
5
Product surfaces I worked on
4
Regional markets
100K+
Installs on the retail app
2021
Engagement began

Technologies & Architecture Stack

HTMLCSSBootstrap 5JavaScriptjQueryFlutterDartLaravelMySQLREST APIs

Overview

Salveowell is a Philippines-based health and wellness company that has traded since 2013 and runs its entire business online. Bixosoft has been its dedicated engineering partner since June 2021, and in that time the digital estate has grown from a single website into five distinct product surfaces sitting on one Laravel commerce and compensation platform, serving four regional markets: the Philippines, Singapore, Hong Kong and the UAE.

Those five surfaces exist because Salveowell has five different audiences. A retail customer wants to buy a product. A distributor wants member pricing, packages and their own storefront. A new distributor needs training. Leadership needs to see the money. Each one gets a surface built for it, and all of them read from the same backend so nothing can disagree.

My role changed as the engagement grew. I joined in 2021 as the frontend developer on the website. In 2023 I built the retail mobile app entirely on my own, including every API integration. From 2024 I have been team lead over the rest of the estate — the distributor app, the training app and the executive admin app were built by my team under my supervision, with me owning architecture, code review and the release process.

The Challenge

The hard part of this system was never any single screen. It is that commerce, membership tiers and compensation are one connected machine, and five different clients all have to reflect its state correctly while the commercial rules keep changing underneath them.

  1. One platform, five front doors. A retail shopper, a distributor, a trainee and a director all read from the same Laravel backend but must see entirely different prices, entitlements and data. Any surface that computed its own view of that would eventually contradict the others.
  2. Price depends on who is asking. Retail pricing, member pricing by package tier, and four regional catalogues with different products and currencies all coexist. No price can be hardcoded or naively cached on a client.
  3. Every member is also a shopfront. Distributors sell from their own subdomain, with member-specific pricing, referral attribution and package visibility — using the same interface as the public site.
  4. Purchases have downstream consequences. Membership package purchases feed a binary and unilevel genealogy that drives commissions, bonus credits and payroll. A client must hand that off cleanly and never predict the outcome itself.
  5. The audience is on low-end hardware. A large share of users are on mid-to-low-end Android devices and metered, intermittent mobile data. An app that only works on a good connection does not work.
  6. Sensitive data on the smallest screen. The admin surface exposes revenue, margin and commission liability across 15+ distinct user role types, so access control could never be an afterthought.
  7. Store review changes the cost of a mistake. With App Store and Play Store review in the loop, a broken checkout is not a hotfix — it is a week of lost sales across two stores.

Solution & Architecture

One component vocabulary

  • Product cards, package tiers, pricing blocks and locators built once and reused across every region and every member storefront.
  • Four regional storefronts and thousands of member subdomains render from the same templates with different context injected server-side.
  • Built as progressive enhancement over server-rendered Blade templates, which gave a faster first paint on low-end Android than a single-page app would have.

Pricing resolved on the server, always

  • The frontend renders whatever price the backend hands it and never computes a member discount itself.
  • This is what keeps retail, member and regional pricing consistent by construction rather than by discipline.

A thin client over an authoritative backend

  • One Flutter codebase serving Google Play and the App Store, now past 100,000 Android installs.
  • Pricing, promotions, stock and order state stay owned by the Laravel platform — the app never reimplements them.
  • Checkout mirrors the web storefront step for step, so a customer who starts on the website and finishes in the app sees the same cart and totals.

Typed API boundary

  • Every endpoint wrapped and validated before responses reach the UI, so a backend contract change fails loudly at the edge instead of corrupting a screen deep inside.
  • That mattered enormously as the sole developer — correctness had to come from architecture, not from a reviewer.

Built for the network users actually have

  • Catalogue and session data cached on device so browsing stays fast and a dropped connection does not end the session.
  • Over thirty published versions since March 2023, shipped in lockstep with backend releases.

Shared foundations, strict separation

  • Shares UI conventions and API patterns with the retail app so developers move between the two codebases easily.
  • Member pricing and package visibility resolved server-side by tier — the client renders what it is told.
  • Membership purchases hand off to the platform, which owns the entitlement and compensation consequences.

Server-driven course delivery

  • Course and lesson structure comes entirely from the backend, so new material ships without an app release.
  • Shares member identity with the commerce apps — one sign-in across the estate.
  • Playback tuned for metered mobile data rather than assuming Wi-Fi.

Read-oriented, role-gated reporting

  • Live profit and loss, revenue charts and KPIs, with all aggregation computed on the platform so mobile and web reporting can never diverge.
  • Binary and unilevel network visualisations alongside commission and bonus tracking.
  • Role-based access determining which dashboards and figures each of 15+ role types can reach.
  • Threshold alerts pushed to leadership when a figure moves, instead of waiting on an analyst.

One source of truth

  • Every surface reads pricing, entitlement and order state from the same Laravel platform; none of them recompute it.
  • Release trains versioned against backend releases so clients and API move together.
  • Architecture, code review and release ownership held centrally once I took over as team lead, which is what kept a multi-team estate coherent.

Results & Outcomes

100K+ installs on the retail app:
The company's highest-reach digital asset, live on both Google Play and the App Store since March 2023.
10K+ installs on the distributor app:
Serving the member side of the business with tier-based pricing and package purchasing.
Four regional markets:
Philippines, Singapore, Hong Kong and the UAE, served from one codebase per surface.
Five surfaces, one platform:
Website, retail app, distributor app, training app and executive admin app, all reading the same backend.
No duplicated commerce logic:
Because pricing, stock and order state stay on the platform, no client has ever needed reconciling against the website.
Pricing that cannot drift:
Retail, member and regional pricing are resolved server-side on every surface, so four markets stay correct without four code paths.
Usable on poor connections:
Cached catalogue and session data keep the apps working through the connection drops that are normal for this audience.
Sustained delivery since 2021:
A four-year engagement with continuous releases across five surfaces, rather than a project that shipped once.
End-to-end ownership:
I built the retail app alone — every screen and every API integration — and built the website frontend before it.
Technical leadership:
Three further surfaces delivered by my team under my supervision, with architecture, review and releases held centrally.
Integration discipline:
Consuming a large existing commerce and compensation backend faithfully is a harder and more common problem than greenfield work.
Range across the stack:
Responsive web frontend, cross-platform mobile, and executive reporting, all against one platform.

Key Takeaway

  1. Let the platform own the rules. The decision that made five surfaces survivable was refusing to reimplement pricing, entitlement or stock on any client. Four years on, no surface has ever disagreed with another about what something costs.
  2. The hardest software is a live business machine, not a screen. Commerce creates volume, volume creates commissions, commissions create payroll — and all of it has to keep working while the commercial rules keep changing.
  3. Design for the network your users actually have. Caching catalogue and session data was not a performance nicety. For an audience on metered, intermittent mobile data it is the difference between an app that works and one that does not.
  4. Validate at the boundary when you are alone. Wrapping every endpoint in a typed layer meant contract changes broke loudly at the edge of the app rather than quietly inside it — which is how a solo build stays correct across thirty releases.
  5. Leading is holding the seams. Once the estate grew past what one developer could write, the job stopped being code and became architecture, review and release discipline — the things that stop five surfaces drifting apart.

Have a similar system to build or scale?

Let's discuss your engineering goals, architecture, and timeline.