Smart Menu Recommendations for a Mini Program: How a Two-Person Team Delivered in 7 Working Days

Preface

Independent developer Kobayashi took on a gig: adding a "smart menu recommendation" feature to the mini program of a chain light-food brand (12 stores). The client's requirement was simple — when users open the mini program, they should no longer see a fixed list of menu items, but rather "guess what you want to eat." The budget was tight and the deadline was two weeks.

This case study documents how Kobayashi's team (2 people) delivered in 7 working days, and why this architecture choice made subsequent maintenance nearly "zero-cost." If you're an independent developer or small team taking on custom projects, you can take this approach and run with it directly.

The Business Pain: Why Menu Recommendations Never Worked

Before the handover, the client's mini program already had a "bestsellers list," but the data was mediocre: menu click conversion had been stuck in single digits for a long time. The pain points concentrated in three areas:

1. One-size-fits-all. Everyone saw the same bestsellers list — fat-loss users saw fried chicken, dinner users saw salads. Severe mismatches.
2. Hard cold start. New users had no behavioral data, so traditional collaborative filtering failed outright, falling back to a fixed list.
3. Maintenance black hole. The client had previously hired an outsourcer to build a rule-based tag recommendation system ("spice preference," "time-of-day weighting"). Three months after launch, the rules had ballooned to over two hundred. After the outsourcer bailed, no one dared touch it, and recommendation accuracy actually ended up worse than the bestsellers list.

For Kobayashi's team, there was a fourth pain point: the deadline. Building a recommendation system from scratch in two weeks — if they had to integrate multiple model providers and manage each one's SDK and API keys, integration testing and auth debugging alone would eat up half the time.

Architecture Design: Lightweight Three Layers + Unified AI Gateway

The final architecture deliberately kept things minimal, with just three layers:

Layer 1: Feature Collection (mini program client + lightweight backend)

Only three types of signals are collected — nothing more:

• Explicit: 3 multiple-choice questions on first entry (taste preferences, dietary restrictions, scenario: solo dining / group meal / fat loss)
• Implicit: categories and price bands clicked, added to cart, and ordered in the past 30 days
• Context: current time of day, store, weather (weather significantly influences light-food vs. hot-food choices)

Layer 2: Recommendation Service (one cloud function does it all)

The core idea is "rule-based pre-filtering + LLM re-ranking":

1. Use simple rules to filter the full menu down to 30–50 candidates (exclude dietary restrictions, match time of day and price band);
2. Assemble a user profile summary + candidate menu list (with prices, tags, gross margins) into a prompt, and hand it to the LLM for re-ranking and recommendation-reason generation;
3. Return the Top 10, with each dish accompanied by a personalized recommendation line ("It's afternoon tea time — this low-calorie yogurt bowl is perfect for you").

Layer 3: Unified AI Gateway

All model calls go through a single gateway, so the backend maintains only one Base URL and one Key. This was the key to compressing the project timeline to 7 days — details below.

Key Implementation Steps and Core Code

Process checklist (actual schedule):

• [ ] Day 1: Feature field definitions; integrate tracking with the client's mini program
• [ ] Day 2: Rule-based pre-filtering logic (pure code, unit-testable)
• [ ] Day 3: Prompt template design + gateway integration
• [ ] Day 4: Re-ranking result parsing, failure fallback (fall back to bestsellers list on LLM timeout)
• [ ] Day 5: A/B switches and per-store configuration
• [ ] Day 6–7: Integration testing, load testing, canary release

Core re-ranking call (Node.js, sanitized and simplified):

const CANDIDATES = await ruleFilter(userCtx); // Rule pre-filter: 30~50 candidates

const prompt = `你是餐饮推荐专家。基于用户画像为候选菜品排序，返回JSON。
用户画像：${JSON.stringify({
  口味: userCtx.taste,
  忌口: userCtx.taboo,
  场景: userCtx.scene,
  历史偏好: userCtx.recentCats,   // 近30天品类偏好
  当前时段: userCtx.timeSlot,
  天气: userCtx.weather,
})}
候选菜品（id/名称/标签/价格/毛利率）：
${CANDIDATES.map(c => `${c.id}|${c.name}|${c.tags}|${c.price}|${c.margin}`).join('\n')}
要求：返回10个，格式 {"list":[{"id":"...","reason":"20字内推荐理由"}]}，兼顾用户偏好与毛利。`;

const res = await fetch(`${GATEWAY_URL}/v1/chat/completions`, {
  method: 'POST',
  headers: { Authorization: `Bearer ${GATEWAY_KEY}` },
  body: JSON.stringify({
    model: MODEL_NAME,        // 网关路由，切换模型只改这一处
    messages: [{ role: 'user', content: prompt }],
    response_format: { type: 'json_object' },
    timeout_ms: 3000,
  }),
});
// 解析失败或超时 → 降级返回热销榜，保证小程序永远有菜单可展示

Note two engineering details: write the fallback path first — when the LLM is unavailable, fall back to the bestsellers list, because recommendations are an enhancement, not a dependency; include gross margin in the prompt, so recommendations balance user experience against the client's revenue — this point made the client extremely satisfied at acceptance.

Why a Unified AI Gateway Saves Real Money

Let's do the maintenance math. If you connect directly to three model providers, you need: three SDKs, management and rotation of three keys, three sets of rate-limiting/retry logic, and three billing reconciliations. Based on Kobayashi's team's past experience, each model upgrade or API change took an average of 1–2 days of manual adaptation; with 5–8 such changes per year, that's over a full week of pure maintenance work.

After the unified gateway:

• One Key, one interface for all models — integration went from an estimated 2 days down to half a day;
• Switching models (e.g., from a large model to a cheaper mid-tier one for re-ranking) requires changing just one string — during cost-sensitive periods they cut per-call costs by about 60%;
• Timeouts, retries, and multi-key rotation are handled uniformly at the gateway, so the backend code no longer has retry logic scattered everywhere;
• Call logs are centralized and searchable — when the client asks "why is this recommendation off," the original request can be replayed within minutes.

The total investment in this project was about 14 person-days. Compared to the client's previous rule-based recommendation system (outsourced for about 80,000 RMB and left unmaintained after 3 months), this delivery cost less than half, and the estimated ongoing maintenance went from the outsourcing era's "we don't dare estimate" to about 2 person-days/month — that's money saved at the architecture level.

After Launch

Two weeks of canary-release comparison data (from the client's own tracking, unprocessed by our side): stores with recommendations enabled had higher menu click conversion than the control stores using only the bestsellers list, with the biggest gains among new users (the cold-start population) — because the profile questions + LLM gave new users a menu that "felt understood" from the very first open.

Even more valuable for Kobayashi's team: this "rule pre-filtering + LLM re-ranking + unified gateway" template was later reused for a bubble tea shop's set-meal recommendations and a fresh grocery mini program's pairing recommendations. Each time, only the feature fields and prompt needed changing — new project delivery cycles stabilized at under 5 days.

For Small Teams Also Doing AI Implementation

Recommendation systems sound like something reserved for big tech, but once you outsource the "algorithms" to an LLM and consolidate the "engineering" into a gateway, even a two-person team can pull it off. If your project also needs to integrate multiple model providers and is being slowed down by key management and API adaptation, try a unified AI API gateway — register to get a unified access key, and save your time for what's truly differentiated: https://api.thistoken.ai/register

---

Ready to try it yourself? Sign up at https://api.thistoken.ai/register to get your API key and start building.