Skip to main content
CASE STUDY

Owning the store instead of renting the shelf

An Indonesian snack brand that still sells on marketplaces, and now owns the storefront, the operations platform, and the data. Built from the inside. Prototype in April, live on their own domain by July.

Client
Loves Semprong
Year
Services
Custom ecommerce, Operations platform, Tier pricing, Fulfillment, In-house courier
Loves Semprong

Overview

Loves Semprong is a semprong and kue gapit brand with a real following: the kind of product people buy in tens, put in hampers, and resell in their own cities. For years, the way to buy it was through an Indonesian marketplace, or by chatting with customer service on WhatsApp.

Then the marketplace math started to move.

Every order through a marketplace carries a fee you do not set and cannot negotiate, and that fee has a habit of moving in one direction. Underneath it sits a larger problem. The buyer belongs to the platform. So do the pricing rules. So does the data: who reorders, who is growing, which city is quietly becoming your best market.

None of that matters much when marketplaces are cheap. It matters a great deal when they are not. That is the moment Loves Semprong called us. Not to leave marketplaces, since they still sell there and should. To stop being a tenant everywhere.

The work was to own the channel and own the data. A storefront on their own domain. An operations platform behind it. The brand holds both. We are an embedded tech team. We built it from the inside.

The argument (why a kuliner brand should own ops instead of renting the stack) is in an owned ops system for Indonesian F&B. Loves Semprong is the proof.

The other half of the problem

The bigger build was not the storefront.

Loves Semprong does not only sell to individuals. It sells to a ladder of buyers (Customer, Reseller, Agen, Dropshipper), each on different pricing, different minimums, different terms. That entire business ran through WhatsApp.

Which meant customer service spent the day as a typist. Look up which tier this buyer is on. Look up that tier's price for this product. Add it up by hand. Type an invoice. Send it. Then answer "sudah dikirim belum?" forty more times before closing.

Every one of those minutes was a minute not spent on the thing that actually grows the business: moving buyers up the ladder. A dropshipper ready to become a reseller is worth far more than a perfectly typed invoice. Nobody had time to look.

That is the job of an integrated ops system for a kuliner brand. One place for orders, tiers, payments, packing, and the courier. Not six logins that each own a slice of Tuesday.

What We Built

Two applications over one shared backend: a storefront for buyers, an operations portal for the team. Full operational support, registered to the brand. Not a rented SaaS tenant store.

For their buyers, the storefront knows who you are. Sign in and you see your own prices, because tier pricing is built into the catalogue rather than bolted on: four buyer tiers, per-tier minimums, and a volume ladder that rewards bigger orders. Place an order and the invoice generates itself as a proper PDF. Ask for a tier upgrade and there is a form for it instead of a negotiation over chat.

For their team, the portal is where the business runs. Orders and invoicing at the right tier price. Payments and finance, where overpayment is credited to the buyer's balance instead of becoming an awkward conversation. Fulfillment with pick lists, scan-based packing, waybills, and delivery proof photos. Their own in-house courier, modelled properly, down to per-tier delivery rates that vary by city. Pre-orders on a preparation calendar. Vouchers scoped to specific tiers, kept deliberately separate from structural pricing so a promo can never quietly rewrite the price list. Eight staff roles, each seeing only what their job needs.

Payments are something we pick and wire, not a product we sell. How that stack gets chosen is in a payment stack for Indonesian lifestyle and F&B brands.

The flow the whole project was really for: the tier pipeline. Upgrade requests arrive as a queue to review each morning.

  • Custom Ecommerce
  • Tier Pricing Engine
  • Operations Platform
  • In-House Courier

Results

We started in April with a clickable prototype: no backend, no database, just the flows made real enough to argue about. It is much cheaper to discover you scoped something wrong while it is still a mock than after it has a schema.

Through May it became a real system. June and July were operations. The hundred small things that only surface once actual staff use the thing for actual orders. By July it was live on their own domain, running their business.

Prototype to production
Apr → Jul
Commits to first release
On one shared backend
2 apps
Staff roles modelled

Conclusion

The part we are most pleased about is not the launch. It is that the release cadence has not slowed down since. Every week there is another piece of manual work to remove: a report someone was still assembling by hand, a step in packing that took one click too many, a screen that made sense to us and not to the person using it eight hours a day.

A platform like this does not get valuable at launch. It gets valuable on the fiftieth improvement, when the team stops noticing it and just gets on with the day. That is the point of embedding. Scale Smarter, Not Harder.

Owning your channel stops being a vanity project the moment the fees you pay for someone else's audience grow faster than your margin does. Then it is just arithmetic.