BuenoBiteFounder-built venture
From launch to operating marketplace.
How Farley Tech used real merchant and consumer behavior to redesign BuenoBite for reliability, repeat use, and time-sensitive commerce.
BuenoBite is a founder-built venture created and operated by the Farley Tech team.
- Venture
- BuenoBite
- Our role
- Built and operated by Farley Tech
- Market
- Puerto Rico
- In production
- Since July 2026
- Surfaces
- Consumer app, merchant portal, BuenoBiteBiz
The business
BuenoBite is a marketplace for surplus food in Puerto Rico. On the surface, the transaction is simple: a food business has inventory it does not expect to sell, a consumer buys it at a discount, and the consumer picks it up.
Operating that marketplace is less simple.
- Supply appears unpredictably.
- A listing may hold only a handful of units.
- Inventory can disappear within minutes.
- Every purchase ends in a physical pickup.
- The people publishing supply are running a food business, not sitting at a desk.
BuenoBite needed more than a consumer app. It needed software designed around the realities of both sides of the marketplace.
From launch to operation
Jul 2026
Consumer app 1.0 on the App Store and Google Play. Merchants publish from the web portal.
Jul 29, 2026
BuenoBiteBiz started
Aug 6, 2026
Consumer 1.1: recent purchases and daily area alerts
Aug 19, 2026
BuenoBiteBiz released to merchants
Production changed the roadmap
The first version of BuenoBite gave us hypotheses. Real merchants and consumers gave us better requirements.
We used observed behavior, transaction data, support issues, and operating experience to decide what to build next, then changed the product and architecture accordingly.
01
Problem
02
Decision
03
Implementation
04
Production
05
Outcome
Then learn again
This is the method from How we work, run against a live marketplace.
Chapter 01: Merchant operations
We designed for the person actually running the store.
What we launched
Our first merchant experience was web-based. That made sense on paper: merchants needed a place to configure their business, manage locations, publish inventory, and handle operational settings.
What reality showed us
The person responsible for publishing surplus is rarely sitting at a desk. In a food business, the operational device is often a shared phone or tablet, used by staff in the middle of service.
Operating the marketplace confirmed it. When something needed to change during service (a correction, a second batch, a quantity entered wrong), doing it through the portal meant finding a computer. In practice, that meant it did not happen.
It was no longer
“Make the merchant portal work on a smaller screen.”
It became
“Make the few actions store staff actually need extremely fast, persistent, and difficult to do incorrectly.”
Interactive
Both screens work. Publish a bag in each.
Same task, two surfaces. Notice how much surrounds the one action store staff actually need.
Then · Merchant portal, launch week
Horno de la BahíaDisponible para comprar
mié, 22 jul · 4:00 p.m. – 6:00 p.m.
Los clientes pueden comprar esta bolsa ahora. Las nuevas compras se cierran unos minutos antes del fin del horario de recogida.
Programadas
No disponibles
Start with “+ Publicar oferta”
Now · BuenoBiteBiz
Start with “Publicar Bolsa”
Store device · stays signed in
What changed
We built BuenoBiteBiz as a purpose-specific merchant operations app rather than a mobile copy of the full merchant portal.
It centers the in-store experience on the few workflows staff need most: publishing a bag, seeing what is live today, and verifying a pickup when a customer walks up. Navigation is simplified, the active location is always visible, and sign-in is designed for a persistent, store-controlled device rather than one person's laptop.
Why it mattered
The broader administrative workflows stayed where they belong: onboarding, settings, reporting. The operational interface became narrower, and publishing moved to where the work actually happens. The merchant portal now directs merchants to publish from BuenoBiteBiz.
We did not build mobile because mobile was inherently better. We built it because understanding the operation changed the business requirement.
Chapter 02: Consumer discovery
An empty screen can be technically correct and still fail the business.
What we launched
A surplus marketplace has a fundamental timing problem: a consumer can open the app at a moment when nothing happens to be available. The first version showed that state accurately.
What reality showed us
Accuracy was not enough. When supply was thin, the app did not read as “no bags right now.” It read as “this app has nothing.”
A consumer looking at an empty screen had no sign that good inventory had been there an hour earlier, and no reason to know when to come back. The software was correctly describing the present moment while failing to explain the marketplace.
Interactive
Try the empty moment.
Tap “Actualizar” in the first release. Then switch to Now and turn on a daily alert.
Then · v1.0
Now
Con ventasCon ventas
Con ventas
Recent purchases are history, not offers: no price, no quantity, no way to buy.
What changed
We changed both discovery and the return loop.
First, the feed began showing real recent purchases from nearby businesses: bags other customers actually bought, presented as history rather than offers. No price, no quantity, no way to buy. Just evidence that this marketplace is active, and which businesses to watch.
Then we reduced the need to keep checking. Instead of asking a new consumer to find and favorite every business that might eventually publish, BuenoBite lets them choose an area and get a daily alert when bags become available there.
The problem was not
“How do we make the empty state prettier?”
It was
“How should a marketplace behave when supply is intermittent?”
The empty moment now explains the marketplace and offers a way back, instead of implying that nothing happens here.
Chapter 03: Scarce inventory
Success created a different engineering problem.
What demand showed us
As the marketplace developed, some inventory began disappearing very quickly. A French-Japanese bakery in Santurce regularly sells through its bags within minutes of the notification going out.
That changed the significance of edge cases that are easy to ignore in a prototype. When only a handful of units exist, several customers can try to buy the last one at nearly the same moment.
The requirement was not
“Integrate Stripe.”
It was
“Sell exactly the inventory that exists, and safely resolve the transaction when two customers compete for the last unit.”
One bag left. Two customers.
- One bag remaining.
- Customer A and Customer B both check out, and both payments succeed.
- Inventory commit: One at a time, rechecked against what is left.
- Customer A: Purchase confirmed. The bag is theirs.
- Customer B: Refunded automatically. Flagged for a person if the refund fails.
What we built
BuenoBite commits inventory only when a payment succeeds, under a lock on that bag, and rechecks what is left at exactly that moment. If another customer has already taken the last unit, the second payment is cancelled and refunded automatically, instead of producing an impossible order that somebody has to discover and reconcile later. If the refund itself fails, the order is flagged for a person to resolve.
We tested the last-unit cases directly: inventory gone at the moment of confirmation, a merchant closing a bag mid-checkout, duplicate and racing payment confirmations, and a refund that fails.
Notifications as infrastructure
When minutes matter, notifications are part of the marketplace.
The same behavior changed how we thought about notifications. When inventory can disappear within minutes, a push notification is not a marketing feature. It is part of the transaction funnel.
Publishing a bag and creating the work to notify interested consumers happen together: if the bag is saved, the notifications exist; if it is not, nothing is sent. Each consumer is notified at most once per bag, failed sends retry with backoff, a bag that sold out before its notification went out is skipped, and the push provider’s delivery receipts are tracked.
01
Merchant publishes
A bag goes live
02
Saved together
The bag, and the work to notify interested consumers
03
Delivery
Waiting → sending → sent
04
Consumer returns
Minutes, not hours
05
Purchase
While there is still something to buy
- Provider failure: Retried with backoff
- Bag sold out first: Skipped, not sent
The experience is simple. The infrastructure that makes that simplicity dependable is not.
The busiest moments in the marketplace should not become the ones someone has to clean up by hand.
What we learned
The product we launched is not the product we operate today.
Production exposed requirements a specification could not.
- 01Merchant behavior changed how we designed operational software.
- 02Consumer behavior changed how we approached discovery and retention.
- 03Real demand changed how we engineered payments, inventory, and notifications.
That cycle continues.
For Farley Tech, the lesson is broader than BuenoBite.
The job is not to implement the first specification perfectly. The job is to understand what the business needs to accomplish, build the technology, watch what happens in the real world, and keep owning the outcome.
Business outcomes, engineered.
Interfaces are reconstructed from BuenoBite’s product source at the versions noted. Businesses and figures shown inside them are illustrative.
Your problem
Working through a product or operational problem?
Tell us what the business needs to accomplish. We will tell you honestly how we would approach it, and whether we are the right team.