Mamasan

Mamasan lets people buy from foreign online stores they cannot easily buy from themselves. The customer chooses the products. Mamasan buys them, imports them and delivers them. Eligible customers can pay over time. The product is Spanish-first and includes a mobile app for customers and a web app for staff.

I led the rebuild in a small team. The existing system had business rules spread across database routines and frontends. Order totals could disagree with their lines, and installment schedules could remain after the shopping state was no longer valid. Staff had to repair inconsistencies that the product should have prevented.

The rebuild puts business rules and authorization in one API. The customer app and staff web app call this API instead of keeping their own versions of the rules. Staff tools matter as much as the customer's checkout. Staff need to buy the goods and handle delivery problems.

When a cart becomes an order

I kept a saved checkout separate from an accepted order. A customer needs to change their selection before agreeing to an order. Calling it an order too soon would let other parts of the system act before the customer had agreed to it.

When a customer accepts, the API checks the checkout and prices they reviewed. One database transaction saves the order with the agreed terms and delivery details. It also records the initial payment obligation and replaces the old cart with a new one. Retrying the request must return the same order. A stale checkout must not create another order.

Later changes to a product or address cannot rewrite what the customer accepted. That transaction does not call external services. If a later provider call fails, the accepted order remains recorded so the system can recover the work.

Browsing someone else's store

The mobile app embeds retailer browsing so customers can use the store's own selection controls. I had to decide what that browser was allowed to send to Mamasan. Each retailer gets a separate persistent browser profile. Its login state stays apart from Mamasan's session and from other retailers.

The customer chooses when to import a product. The API treats values from the retailer's page as untrusted and checks them. An allowed domain is not enough to trust everything the page sends.

Staff access needs similar care. A valid login does not prove that someone still has permission to perform an operation. The staff app establishes an active session before requesting business data, and the API authorizes every request. The app waits for that session even though parallel requests could make a direct page load faster. Otherwise, those requests could record misleading permission errors or interfere with session recovery.

The repository has the Hono API on Cloudflare Workers, a Postgres database, the React staff app and the Expo customer app. The rebuild is still in progress. Both apps must replace their old versions together.