FINEBook a systems review

Work / BUQQ

B2B restaurant reservation platform for Southeast Asia, taken from idea to live product

End to end product ownership: research, brand, build, legal and go to market, alone.

RoleProduct owner: research, brand, build, legal, go to market
TimelineOngoing development
StatusLive, ongoing development
StackNext.js, TypeScript, Drizzle ORM
Livebuqq.online →

The situation

Restaurant reservation infrastructure in Southeast Asia is fragmented. Venues rely on phone calls and messaging apps to manage bookings, and the reservation platforms that do exist were built for other markets — priced on commission per cover, not built for how venues here actually communicate with guests and staff.

What I did

I built the whole thing: market and competitor research, the business model, the brand and logo, the product specification, the build itself, the legal framework, technical SEO, and the content and go to market pipeline. Buqq is the answer to whether I can take a product from an idea to something live in the market, on my own.

A GUEST BOOKS WITHOUT AN ACCOUNT, THREE CHECKS DECIDE WHETHER THEY CAN, AND EVERY FAILURE IS A SPECIFIC ANSWER RATHER THAN AN ERROR.

The booking rules are only visible in three places

The flow decides whether a booking can be taken and, when it cannot, which specific answer the guest gets. None of that reaches the guest as a flow, so it surfaces as three screens: the times the venue can actually offer, the reason a check failed, and the confirmation the guest sees once it passes.

FIG. 02 · WHAT THE FLOW PRODUCES3 OF 6 STEPS SHOWN
01
GUEST · SLOT PICKERPHONE
Buqq guest slot picker on a phone, showing available booking times with one time slot selected.
EXPAND ⤢
02
GUEST · CHECK FAILEDDESKTOP
Buqq check-failed screen on desktop, showing the reason a booking slot could not be held and returning the guest to pick a new time.
EXPAND ⤢
03
GUEST · CONFIRMEDPHONE
Buqq booking-confirmed screen on a phone, showing the confirmed reservation details.
EXPAND ⤢
01 · SLOTS OFFEREDTimes the venue cannot seat are absent rather than greyed out, so there is nothing to try and fail at.
02 · CHECK FAILEDA failed check answers with its own reason instead of a generic error, and sends the guest back to pick a time that works.
03 · BOOKING CONFIRMEDConfirmation is issued on the write. The notifications that follow cannot hold it up or take it back.

FIG. 02 — THE THREE CHECKS SEEN FROM THE DINER'S SIDE: WHAT IS OFFERED, WHAT IS REFUSED, WHAT IS CONFIRMED.

Key decisions and tradeoffs

Four decisions that shaped the product, the alternative in each case, and what the choice cost.

Decision 01COMMERCIAL

A flat monthly fee instead of commission per booking, with accounts restricted to businesses

ALTERNATIVEopen Buqq to consumer diners as account holders too, and take a cut of each reservation — the more familiar reservation-platform shape (OpenTable, Resy).WHY NOTa commission model puts Buqq's incentives at odds with the venue's on their busiest nights, and a consumer marketplace (diner accounts, reviews, loyalty) changes who Buqq is liable to and how disputes get resolved. Diners still book on Buqq — as guests, no account required — but only restaurants sign up, pay, and hold data. The Terms of Service require anyone opening a Vendor account to represent that they're acting as a business, not a consumer, which keeps the legal and trust surface small enough for one person to stand behind.COSTno marketplace network effects from diner accounts (no saved diner profiles, no reviews, no loyalty layer yet), and every restaurant sign-up has to hold up as a genuine business rather than simply completing a form.
Decision 02DISCOVERABILITY

Moving pricing data server side in Next.js

ALTERNATIVErender pricing client side, which is the default and the faster thing to build.WHY NOTcrawlers and AI assistants reading the site could not see the pricing at all, at exactly the moment buyer research is shifting toward AI assisted vendor comparison.COSTmore of the page has to be rendered on the server rather than left to the client, which was extra upfront work for a page that would not otherwise have needed it.
Decision 03RISK

An AI blog pipeline that stops at a Telegram approval gate, rather than publishing automatically

ALTERNATIVElet Claude generate and publish articles end to end, which scales fastest.WHY NOTunreviewed content published under Buqq's name is a reputational risk with no upside proportionate to the time saved. A Vercel cron job picks the next queued topic, Claude drafts the full structured article (dek, key takeaways, body, FAQs, table of contents), and a Telegram message goes out for review — I reply `approve` or `reject` from my phone, and only an approval publishes it.COSTpublishing throughput is capped by how much I can personally review, which is slower than full automation, but it is the trade I would make again.
Decision 04SUPPORT

No support ticketing system or chatbot — a direct email line instead

ALTERNATIVEbuild a support chatbot or ticketing/escalation workflow, which is what SaaS products this size are expected to have.WHY NOTat current scale, a chatbot or ticket queue would be theatre — extra infrastructure standing between a merchant's problem and the one person who can actually fix it. A paying business asking for help gets a reply from me, not a bot with an escalation path.COSTevery support email is on me personally with no tier of triage underneath it, and that doesn't scale past a certain number of accounts — but it's honest about the size of the operation today, and merchants get a real answer faster because of it.

Current status

Live and in the market, with ongoing development.

Stack and timeline

Buqq runs on Next.js (App Router) with TypeScript, Drizzle ORM over a Supabase-hosted PostgreSQL database, and Playwright for end-to-end testing. Polar handles billing and subscription checkout, Resend sends transactional email, the Anthropic API drafts blog content for human approval, and the Telegram Bot API delivers booking alerts to merchants and signup alerts to me — all gated behind a Telegram approval step for anything AI-generated, rather than running unattended. Hosted on Vercel, pinned to the Singapore region for database latency.

Next.jsTypeScriptDrizzle ORMSupabase (PostgreSQL)PolarResendAnthropic APITelegram Bot APIPlaywright
Next case — 03Dog Park ExplorerRead →

Have a system that half works and nobody wants to touch?

A systems review puts the situation, the cost and the options in writing.

Book a systems reviewOr send a direct message →