I just lost a lot of money!

Better me than you right?!

Just kidding. Not that much money, but enough to learn a lesson or two.

This is a postmortem deep dive on the failure of my first business, Chowtime!

I’ll give you a brief overview of the business and why we started it, then walk through why it didn’t work in gruesome detail.

This is a long one.

I’ll repeat, a DEEP dive. Shallow divers may want to look elsewhere or read the below tl;dr.

This is a cautionary tale for those who might be grappling with similar issues in their businesses.

For new founders, it’s a warning of the unexpected challenges they may face when starting a company.

Let’s go.

What was Chowtime!?

Chowtime! was a mobile ordering and payments software platform for restaurants in Hong Kong.

It was a straightforward application that supported 2 modes of automated bill payment at restaurants:

1. “Order & Pay”: Guests scan a QR code at their table, access a digital menu, place their order, and pay through their mobile device. (check out this demo)
2. “Pay-at-table”: Guests order traditionally through the wait staff then scan a QR code at the end of their meal, access their digital receipt and pay or split the bill through their mobile device. (check out this demo)

We made money by charging restaurants a percentage of the order value paid for through our app.

This product is not new. It exists in several other developed markets around the world, but we saw a gap in Asia (more on that below).

My partner and I founded the Company in mid-2021 and shut it down at the end of 2023.

Why we started Chowtime!

This is a post about why it failed, but here’s the quick pitch.

We saw an opportunity to solve a problem for restaurants in Hong Kong.

It came down to this: the ordering and payments process at certain types of restaurants is too manual.

This leads to a poor guest experience and lost revenue for the restaurant.

The problem is made worse by an F&B labor shortage in Hong Kong.

Ask any restaurant about their biggest headache.

Staffing. 10 times out of 10.

Our product moved the operationally intensive tasks of order taking and bill paying from staff to guests.

This reduced the burden on thin staff, allowing each server to comfortably cover more tables.

Staff time was freed up to focus more on serving food and actually delivering hospitality, rather than running around like maniacs under constant stress (as is the norm in many Hong Kong restaurants).

Guests ordered and paid faster, leading to more table turnover for venues (read: more money), and happier guests and staff.

It was an elegant little system when you saw it humming along on a busy restaurant floor.

We looked at the restaurant market on a “fancy” scale, from super casual quick service restaurants up through ultra high-end fine dining experiences, and avoided restaurants where excellent human service was a core piece of their offering.

Our target market was casual dining venues and below.

There wasn’t anything particularly innovative about the software itself.

Technology products to solve this problem already exist, with many companies having successfully deployed them all over the world (a few notable examples include Toast, Sunday, Flipdish, and me&u). There’s a good chance you’ve placed your order and/or paid through a QR code before.

Hong Kong (ex. China) and Southeast Asia are unique.

The F&B technology stack is several years behind what you’d find in major developed restaurant markets (US, UK, Australia, etc.), and Hong Kong and Southeast Asia are early on the mobile ordering and payments adoption curve.

We were starting to see Hong Kong’s restauranteurs embrace the technology, and a number of competitors had popped up to fill the demand.

But restaurant owners were unhappy.

The few apps that do exist delivered a poor UX, an unreliable payments experience, and did not offer point-of-sale integrations (more on that later).

This came through in app usage rates as low 5% (app order value as a % of total dine-in sales) in our competing venues.

We saw an opportunity to take a proven product to under-penetrated market in Hong Kong and Southeast Asia, full of under-optimized restaurants.

We got as far as a fully point-of-sale-integrated product that processed USD 250K of order value (GMV) in it’s first year, with usage rates of up to 85% in its best performing venues.

Here’s our full pre-seed pitch deck.

Why we shut it down

$250K of GMV was a far cry from where we ultimately needed to be, but it was a good start. And GMV was growing.

We were delivering a clear value proposition to both guests and merchants, getting positive feedback, and had decent pipeline of new business lined up, some of it even under LOI.

So why pull the plug? 2 reasons:

1. We ran out of financial risk appetite. Our core product was a software application, and our founding team consisted of exactly zero software developers. We had to outsource, and outsourcing = a big burn rate.
2. Limited upside. We launched the business in the wrong market (Hong Kong), and chances of penetrating the bigger, more exciting market (Southeast Asia) were so low that we couldn’t underwrite it. Even if we succeeded in Hong Kong, we’d have a relatively modest business that we didn’t own that much of. The realistic upside was not compelling enough for the risk we were taking.

Plus, the opportunity cost of our time is high.

So we shut it down.

Could it have worked? Maybe. But the odds did not look good.

3 reasons it was probably doomed to fail

A few structural problems were holding the business back.

One of them alone could have killed the business, and we faced 3:

1. Wrong launch market. Much of the Hong Kong F&B sector was not part of our addressable market, making it difficult to get initial traction quickly.
2. Capital intensive growth. As non-technical founders, it essentially cost money to breath.
3. Prohibitive pricing environment. The baseline cost of processing online payments in Hong Kong was higher than restaurants could afford.

Not great! Let’s break ‘em down.

Reason #1: 🚀 Wrong launch market

Hong Kong is a small market… but we thought it was big.

17,000+ restaurants right in our back yard! More than half of which were casual dining or lower on the “fancy” scale.

Surely, if we capture even a small percentage of those venues, we’ll have a business.

A large portion of the casual dining segment in Hong Kong was off limits to us for 2 reasons:

1. Restaurants’ desire to maintain the human interaction between guests and staff
2. Local restaurant configuration for paying the bill at the counter

🤝 Guest/staff interaction

We aren’t fancy guys, but we’ve been to our fair share of nice restaurants.

We understood and respected the importance of hospitality when dining out.

However, in more casual settings, we equated good service with fast service and were often annoyed when it took a long time to flag down a server, place our order, or pay our bill… a sentiment echoed by everyone we spoke to.

This problem was particularly acute in Hong Kong’s chronically understaffed restaurants.

Turns out, Hong Kong restauranteurs care about preserving the human interaction a lot.

So much, in fact, that even restaurants with objectively terrible service still saw their guest/staff interaction as a point of differentiation for their businesses.

Owners continued to tell us this, but we remained determined to convince them that our product would enable faster service and higher quality guest/staff interaction by reducing the servers’ operational workload and freeing up time to deliver more traditional hospitality.

Hong Kong’s restauranteurs didn’t buy it, or if they were open to the idea, we were pushing a rock up a hill.

They heard “app” and equated it to a dining experience void of any human interaction.

Any casual dining restaurant that remotely saw themselves as providing good service was effectively not a potential customer.

Our determination came from observing this product working in other markets. Take Australia and the UK, 2 markets highly saturated with mobile ordering and payments solutions.

A key difference: Physically massive venues.

It’s difficult to provide consistent, fast service across the sprawling restaurant floors of Australia and the UK.

Imagine running all over the place trying to keep hundreds of guests happy all the time.

This “big restaurant” issue is problematic enough that any loss of human interaction at the hands of our technology is offset by the value gained in faster service, reduced staff stress, and more table turnover.

Been to Hong Kong? The average restaurant is tiny.

We were getting traction in some of the bigger venues, but there just aren’t that many of them.

⚙️ Local restaurant configuration

Okay, so the casual dining segment is not part of our addressable market.

What about the deep casual and quick service restaurant (“QSR”) segment?

Beyond basic server pleasantries, these restaurants only care about speed and table turnover, and many of them are physically large.

If you’ve never eaten at a fast casual spot in Hong Kong, here’s how it often works:

You sit down, place your order with a server, and they give you a receipt immediately.

When you’re done, you take the receipt up to the counter to pay on your way out.

We referred to this configuration as “pay-at-counter”. Sounds pretty simple, right?

That was our problem. It is.

Many quick service restaurants are not configured to benefit from ordering and paying at the table. Things are working pretty well for them as is.

Okay, but there are some apps in this segment that allow guests to order from the table, but not pay. We rationalized this:

“Payments is a harder business. The moment you start handling money, stakes go up for both you and the client. Other apps lack either the technical knowledge or risk appetite to offer a payments product. A market gap must exist.“

Not so much.

Operational workflow was already optimized at these venues.

Digitizing the ordering component alone generates some marginal efficiencies, and that’s about as much as these venues demanded.

The upshot?

Our payments product had no value proposition in Hong Kong’s quick service segment.

---

So, in painfully obvious conclusion:

Hong Kong is a deceptively small F&B market for our business.

🎓 Lessons learned?

We spoke to hundreds of restaurants before spending a dime, and feedback was mixed.

Some restaurants bought into the technology, giving us more confidence than was due, but many did not.

I was so hungry to have a go, and that hunger made me stubborn.

The positive feedback gave us enough space to get some traction, but it clouded my judgement of whether the opportunity was big enough beyond that.

I believed the business would work with the yay-sayers which would convince the nay-sayers.

“I’ll show them!”, I said. Classic founder mistake.

Reason #2: 💸 Non-technical founders = capital intensive growth

So Hong Kong is small market, but it’s not like there are zero restaurants.

There are enough to prove out our value proposition, raise capital, and expand into bigger markets.

What bigger markets? Southeast Asia baby (“SEA”).

SEA, for our purposes, comprises Thailand, Vietnam, Singapore, Malaysia, Indonesia, and the Philippines.

These are the largest, fastest growing economies in the region with big F&B sectors, young, tech-enabled populations, and relatively little competition.

Our initial growth strategy can be summarized as follows:

1. Grow “horizontally” in Hong Kong → add point-of-sale (“POS”) integrations to acquire more of the same types of customers
2. Grow “vertically” in Hong Kong → expand our feature set to acquire different types of customers (different venue formats that require different features, regardless of which POS they use)
3. Expand the pie → configure our product to penetrate each new SEA market

There’s one thing that each leg of this strategy has in common: more software.

We had no software engineers on our founding team.

Let’s deconstruct how each one sucked up cash at every turn.

1. Adding POS integrations in Hong Kong

A quick primer on POS systems.

When you dine at a restaurant, the server most likely comes to your table to take your order, then walks away to enter it into a tablet or computer stationed near the kitchen.

This device is called a point-of-sale system.

This system tracks orders, revenue, and inventory, prints tickets for chefs in the kitchen, generates reporting, manages menu pricing, table layouts, employee rosters, and a whole host of other things.

It is the beating heart of restaurant operations and management. No surprise the POS industry is a massive one unto itself.

Integrating our product with the POS is absolutely critical to adoption, as we’re about to see.

But first, let’s say we don’t integrate with the restaurant’s POS.

We would need to provide our own tablet dashboard that displays orders placed through our app in real time.

Servers would need to be constantly checking our dashboard for new orders, then manually key them into the POS to get orders into the venue’s workflow.

If it’s not obvious, this would have the exact opposite effect compared to what we were going for: adding operational friction, not reducing it.

With a POS integration, the impact on operational efficiency is dramatic, but in the other direction.

Our integrated app automatically inserts orders into the POS workflow, tickets are automatically printed, and all servers have to do is serve food, clear tables, and tend to guests.

No more taking orders and dealing with credit cards. It’s pretty awesome when you see it working.

We attempted to push a non-integrated product to get traction faster. We even spent time working at our pilot restaurants, keying in orders for the staff to reduce some of the operational burden, but to no avail.

Restaurants screamed from the rooftops: a POS integration is a minimum viable feature, end of story.

Got it. POS integrations are critical. So what does building one entail?

The short answer, a bunch of complexity.

An integration is essentially just a big new software feature that allows our app to talk to the POS.

It’s built from scratch based on the (hopefully extensive) API documentation offered by the POS company in question.

But what if the API documentation is thin? What if the quality of the API itself is poor?

Indeed, those are problems, and common ones at that.

Even with an API up to industry standards, we needed buy-in from the POS company to give us access. It’s additional work for them, and they often stonewall unestablished upstarts like us.

But say your relentless hounding of the POS partnership team is effective, and you get access.

Then comes the additional fees borne by us and the restaurant (you thought it’d be free? 😂), a new failure point introduced into our application, and longer support times for our clients.

Oh, and don’t forget the ongoing development required to stay ahead of API updates to keep the integrations live.

If all that wasn’t enough, the POS landscape in Hong Kong is highly fragmented.

It’s not like we could invest time into 2 or 3 POS integrations and have access to a huge installed base of venues overnight.

We faced many POS integrations.

This magnified the amount of development work required to achieve any meaningful scale and was a significant barrier to growth.

The fragmentation created additional pressure to target large, multi-unit restaurant groups who used the same POS system across many locations, which led us to a chicken-egg situation:

“We’ll sign with you once you’ve built the POS integration”, but we needed a signed deal to justify the risk of building it.

Classic!

2. Adding product features

We made it as far as deploying a live and stable integration with a POS system that is used in about 200 venues in Hong Kong. Solid start.

But just because we’re POS-integrated at a bunch of venues that are a fit with our core value prop doesn’t mean we have all the features necessary to deliver a smooth experience in every one.

You may not notice it as a guest, but if you peek behind the curtain and look at the inner workings of a restaurant, there are nuances that make seemingly similar restaurants operationally unique.

It could be a result of the dining experience they’re offering, the layout of the venue, or even just the style of the restauranteur themself.

The list of examples is endless, but here are a few notable ones:

• Unique happy hour scheduling logic at 2 otherwise identical bars
• Different menus between floor sections at the same restaurant
• Complex product combo structures and pricing
• Laws restricting wait staff from serving outdoor patio or streetside tables

Features are required to accommodate these differences, and features can be time consuming, expensive, and complex.

Of course, there is a core set of functionality required for the app to deliver its value prop in very basic use cases, but basic is the exception, not the rule in F&B.

3. Configuring for new markets

I keep saying “expand into SEA”. This is misleading.

SEA is not one market, it’s several.

Several unique markets with their own idiosyncrasies to grapple with.

Establishing a presence in even a single new market is not easy, and you better believe it’s capital intensive:

Licensing and administration requirements, local staff, office space, travel costs, banking considerations, local product configuration, multi-language support, new payments processors, different mobile wallets, localized marketing and sales.

Oh, and don’t forget, a new landscape of POS systems.

Yay!

Some of the most critical requirements are technical in nature, requiring a bunch of additional development.

This effectively made each individual SEA sub-market inaccessible to us unless we had significant capital, not to mention how difficult it would be to execute if we did.

---

So, POS integrations, new features, and new markets.

What’s the one thing each of these have in common? A ton of software development.

We aren’t software engineers, so we had to outsource. At risk of stating the obvious, this had 2 negative impacts:

On our finances

Outsourcing development dramatically increased our burn rate.

Growth became unnecessarily capital intensive, requiring constant fundraising.

The result: dilution baked into success.

On our ability to execute

We couldn’t react to the market fast enough.

We were bankrolling the business which forced us to overly scrutinize every decision and new feature.

This massively hamstrung our ability to remain nimble, respond to customer demands, and experiment.

🎓 Lessons learned?

Having the right founders cannot be emphasized enough. The implications for the business and it’s likelihood of success are profound.

This was avoidable. I learned the hard way so you don’t have to.

Reason #3: 🏷️ Prohibitive pricing environment

We intended to make money by charging restaurants a percentage of the order value placed through our app.

We accomplished this by adding a 1% markup to our cost of processing payments through Stripe.

Stripe charged us ~2.6% per transaction.

We added 1% and charged customers 3.6% per transaction.

So we earned the 3.6%, then paid Stripe the 2.6%, netting us 1%.

On a 300 HKD order, we booked 3 HKD as net revenue (1% * 300 HKD).

With me?

Payments platforms like Stripe offer volume-based pricing discounts.

Process a bunch of transactions, get a rate discount. Process even more transactions, get another rate discount, and so on.

Our strategy was to accumulate GMV by adding venues to our platform, access greater discounts over time, and expand our margin.

Sounds good in theory. Here’s why it didn’t work:

Restaurants in Hong Kong are single digit net margin businesses.

Stripe’s starting price was 2.6%. This is a huge slice of a restaurant’s profitability.

Early discussions with customers indicated that 3.6% all-in was palatable.

But when it came time to actually sign a deal, it became clear that no one would sign up to this rate.

If we wanted customers, we had to charge less.

Our Stripe costs were fixed, so we were forced to reduce our commission from 1%…

…drumroll please…

To 0%.

We ended up giving the product away at breakeven to win early clients (passing through our Stripe costs with no added commission).

This created a vicious cycle that worked against us:

We weren’t generating cash to cover our burn…

…which created pressure to grow GMV and drive down processing costs,

…which created pressure to raise money to invest in the product,

…which was harder to do because of this very situation,

…which increased pressure to generate cash, and so on.

Ouch.

Okay, so Hong Kong’s restaurants are especially low margin, but restaurants aren’t exactly high margin businesses elsewhere in the world.

And yet, this revenue model works in many other markets.

What gives?

Hong Kong suffers from 2 structural problems that many other markets do not:

1. Online payments are uniquely expensive in Hong Kong
2. Rent is uniquely expensive in Hong Kong

💳 Online payments in Hong Kong

You might wonder why processors like Stripe would charge a borderline predatory rate to such a low margin sector.

The answer is they don’t, most of the time.

Other developed markets have regulation that prohibits charging unfair online payments processing fees to lower margin sectors.

Rates charged to dine-in payments platforms like us in Europe, Australia, and the US are at least a full 1% lower depending on the processor.

But it’s not Stripe’s fault.

Without getting too technical, the rate Stripe charges is not pure profit for them.

Stripe is just a platform that utilizes already existing infrastructure to offer a seamless payments solution to online businesses like us that don’t want to build it themselves.

For this service, they add their own small markup to costs they incur for using the existing payments gateways (the main cost they incur is called an “interchange fee”).

Unlike other markets, Hong Kong lacks regulation that caps online processing rates for certain lower margin sectors like F&B.

Even if Stripe processed our payments for free, we would still be subject to an interchange fee that is too high for Hong Kong’s restaurants.

We were starting from a losing position.

🏠 Rent in Hong Kong

Ah, Hong Kong real estate. Can’t live with it…

…can’t afford it either.

Hong Kong is one of the most expensive real estate markets in the world, and it’s notorious for having completely inflexible landlords.

This means death for many-a-Hong Kong restaurant, crushing their profitability.

The ones that do survive heavily scrutinize every line item, especially something like the cost of payments processing, which they believe shouldn’t be more than 2% to 2.5%.

We were giving away our product for free at 2.6%. That got us going, but any conversation about building in some margin for us was met with pushback.

Our pitch:

“Not only are you gonna make more money by turning more tables and increasing order sizes, but you’re gonna SAVE money by operating with fewer staff.”

Their response:

“Yeah, sounds good, but we still can’t afford a 1% to 2% increase in our cost of payments processing.”

Saving money on labor is a solid value prop that has been proven out in other markets.

But that’s only because labor is a much higher percentage of the average restaurant’s cost structure in those markets.

The perceived value of labor savings is reduced when the majority of your restaurant’s margin is eaten away by rent, not labor.

Thanks, landlords!

But wait…

What about the bigger restaurants and groups with better deals on rent (read: higher margins)?

They could absorb a slightly higher payments processing fee. Good for us.

We faced yet another problem.

These big groups do so much sales volume across all of their locations that they often benefit from huge volume discounts offered by their payments processors.

For their standard offline payments (where you just hand the server your credit card), they may enjoy rates as low as 1.6%.

When assessing our online product, they understandably compared our high payments fee to their offline status quo.

The huge difference in fees carried an optical sticker shock which overpowered any discussion about the value they would derive from using our app.

_{Note: Restaurants commonly pay huge commissions (upwards of 30%) to take online payments for delivery services (Uber Eats, DoorDash, etc). The value prop of a delivery platform is customer discovery and a new revenue stream. The value prop of dine-in ordering and payments is more of the same revenue stream without the customer discovery. Completely different willingness to pay.}

I could go on, but I think you’re picking up what I’m putting down.

No matter how you slice it, the pricing environment in Hong Kong is ugly.

🎓 Lessons learned?

Our pricing diligence was not rigorous enough, plain and simple.

Prospects told us 3.6% was palatable, and we ran with it.

When we built the product and came back ready to sign a deal, folks changed their tune pretty quickly.

We didn’t get anyone to sign up to that number in advance. Big mistake.

Pre-selling is the most effective form of business validation.

---

🥵 That was a lot.

Now you know what I mean when I say the odds didn’t look good.

The upshot is this:

Say we solved any 2 of these problems: the small market, capital intensive growth, or pricing environment.

The business was still unlikely to succeed due to the remaining 3rd problem alone.

We solved none of them.

And for that reason, I’m out.

6 big takeaways from working on Chowtime!

There are bunch of common things you will learn by starting any business: the importance opportunity selection, market size, cheaply pre-validating your business, yadda yadda.

I touched on some of these already.

But every business comes with its own set of lessons, unique to your experience.

Here are 6 things burned into my brain by my experience with Chowtime!

🧠 The importance of similar use cases across customers

It’s much easier to sell a product that doesn’t need much modification for many people to use it.

Make it once, sell it a lot.

If your product, like ours, requires you to make it once, sell it a few times, but then modify it, sell it a few more times, and so on… scaling will become expensive, fast.

This reduces the leverage that you would otherwise get from a great product business.

🧠 Find customers with the ability to pay

Low margin customers are hard, even if your solution increases their margin.

How are they supposed to buy new things when they’re worried about keeping the lights on?

It’s a tougher sell from the get go.

A loose Rule of Thumb: low margin businesses tend to be that way for structural reasons. If there was a way to meaningfully increase the margin of a market as a whole, people have likely figured it out already.

Plus, it’s easier to sell something that makes people more money rather than saves it.

If you’re selling to businesses, seek markets with higher margin customers.

If you’re selling to people, find people who can afford your thing.

🧠 Find customers who aren’t constantly pitched perceived similar products

Restaurants are operationally complex beasts.

There are problems and inefficiencies that can be addressed with technology everywhere.

From back-of-house, accounting, and inventory management, to food delivery, customer discovery, and marketing.

Everyone and their mother is pitching restaurants a software product.

Here’s a fun infographic of the restaurant tech ecosystem:

Takeaway:

This was not an uncommon response I received when pitching new business:

🧠 The risks of being “scrappy” up front

If I had a nickel for every time someone told me to “be scrappy”…

Founders, you can relate to this.

“Speed to market! Cut every corner you can to get fast feedback and iterate!”

Yeah I get it, it’s important to get a product to market fast and cheaply, but people seem to blindly follow this like dogma.

There’s a balance that’s not easy to strike, but do not forget that technical debt is real and will come back to bite you.

In one instance, a speedy and cost-driven decision forced us delay launching with a large customer for 2 months to fix an issue that prevented us from supporting their venue.

This consumed time and money, and hurt our GMV numbers.

On the flip side, we were meticulous and patient when building our POS integration.

It took a long time, but when we launched it, it was virtually bugless.

A hastily built integration would have killed our business on the spot.

🧠 Hunger can cloud your judgement

This was my first business, and I was so hungry to make it work. As a result, I was not as objective as I should have been early on in the journey.

A lot of my mistakes could have been avoided had I been emotionless. Hopefully that was evident from this post.

Success in business requires cold objectivity, every time.

And finally…

🧠 Do not start a technology business if the founding team cannot write software. Period.

I won’t beat this point to death.

The defense may point to many instances in which successful companies with non-technical founders financed their product from day one.

This is what we call an iceberg fallacy.

Sure, it’s happened, but it probably won’t happen to you.

---

If you made it this far, thank you.

I hope you found this post interesting or useful.

To close out with an explanation of the tagline, I’d have made more money selling ice cream on a beach.

Onward.

Thanks to Sarah, Julian, and Noah for reading a draft of this post.