Vibe Coders SG #3, Designing with AI, without the slop 🔥

Pico cam is a tiny instant camera for iPhone that turns the Dynamic Island into a tiny hidden Polaroid camera. Pulling down the Dynamic Island expands it into a full retro camera interface — complete with shake-to-develop, filters, and a physical-feeling dial, all modeled on classic Polaroid cameras.

Soon, a product designer, loves cameras and wanted to channel that joy into design — obsessing over every sound and haptic (filter dial, zoom, flash, settings) rather than just shipping a functional camera app.

• A tiny, constrained UI space (the Dynamic Island) can become a surprisingly rich, joyful interaction if enough craft goes into it.
• Nostalgia-driven design (Polaroid mechanics) can resonate even with users — like kids at the exhibition — who've never touched a physical camera.
• Sound design can come from anywhere: a plastic comb recorded on Voice Memos became the dial sound.
• Pixel-perfect device-specific alignment work (matching every iPhone notch/Dynamic Island size since the iPhone 11) is invisible craft that makes an app feel "real."

Dojojojo is a gamified fitness app where workouts feed a pet, a card collection, and auto battles. Described as Tamagotchi meets Duolingo for healthy living. Users grow and evolve a pixel companion by logging steps, nutrition, and workouts, with mini-games like a computer-vision push-up checker that verifies joint positions for correct form.

The husband-and-wife team wanted to make fitness tracking feel like play rather than a chore, pairing a evolving pixel-companion loop with real health logging. The app is built in Flutter (with original illustration from artists), and the team leaned on AI coding tools and design references to create a delightful fitness app

• Reference collection (Mobbin, Dribbble, Design Spells) plus a "watch" skill that studies video for micro-animations helps close the gap AI-generated UI usually has around motion/interaction detail.
• Markdown-based guardrails (locking in brand color, text-box style, and Apple's Human Interface Guidelines) let the team stop repeating instructions and keep design consistent across sessions.
• Generating multiple variants (three, specifically) from the same prompt gives room to mix-and-match the best parts rather than accepting a single AI output.
• Code-quality guardrails (cognitive complexity/cyclomatic analysis, pixel-accurate visual diffing) in CI/CD keep AI-assisted code from degrading over time.

Meng explains that as coding agents like Codex can build full iOS apps from a single prompt, the differentiator left for humans is "taste" — craftsmanship in prompting, tool choice, and creative direction.

He also demonstrated building a live survey-style iOS app in SwiftUI via Codex + an iOS-focused plugin, and also discusses DreamCut, a Mac app he built for himself to record and edit his own video content.

Meng used to teach SwiftUI line-by-line, where students could only prototype small experiences and rarely shipped to the App Store.

Now that agentic tools can generate working apps from a prompt, he wanted to answer: if the agent can do the technical work, what's actually left for humans to contribute?

His answer — taste — reframes what's worth teaching and practicing now.

• The barrier to building an app has dropped to: a Mac, an agent (Codex), and the ability to prompt well — no deep technical background required.
• "Taste" — knowing which prompts, skills, and libraries to reach for, and when — becomes the actual craft once code generation itself is commoditized.
• Building tools for your own workflow (like DreamCut) can be more effective than assembling several off-the-shelf tools, and can scale to a real audience (videos made with it reaching hundreds of thousands to millions of views).
• Counterintuitively, leaning fully into AI tooling pushed the speaker to be more human — going outside, showing his face, talking to people — rather than replacing that need.

A talk on why an app can be "great" and still "not feel right" — and how Apple's new design system (of which liquid glass is only one part) is meant to fix that.

Jia Chen walks through eight design principles that landed this year, then zeroes in on familiarity: concentricity, the content-vs-controls layer split, and when to use each of the three glass materials so an app feels at home on the device.

Jia Chen kept hearing the same unhelpful critique — "this is great, but it doesn't feel right" — and people couldn't say what that meant. He wanted language for it. After a night of community demos, he shifted from community-building to the new platform work: not liquid glass as a skin, but how hardware and software are supposed to blend into one experience.

• "Doesn't feel right" is a real failure mode, and Apple's eight principles (purpose, responsibility, flexibility, craft, agency, familiarity, simplicity, delight) give you words for it.
• Liquid glass is the familiar name, but it's a subset. The design system is about blending hardware and software — if you only chase the glass, you miss the foundation.
• Concentricity is why Settings, Clock, and iMessage feel like one family: tab bars nest into corners, radii match the device, interactions lift into the controls layer. Your app should not suddenly "show them off."
• Native controls give you the material, the motion, and accessibility for free. Custom glass is a last resort, not a flex.
• Delight and craft (Pico cam's details, the personality in vibe-coded projects) are named as first-class principles, not extras.

A custom-built multi-agent orchestration system by Yu Xuan (Mobbin) for coordinating AI coding agents on his own projects, rather than using off-the-shelf tools. He demos it alongside two things built with it: Joodle, an iOS journaling app with doodle drawing, and an experimental web-based "mind palace" / life graph that maps personal taste.

Existing agent orchestration tools didn't give him what he wanted: the ability to pause and steer agents, see a plan before building starts, choose which parts to hand off vs. stay hands-on for, save cost by matching model tier to task, and — most importantly — a system that learns from its own mistakes over time and improves.

• Splits "roles" (permanent — skills, permissions, knowledge, one job done well) from "agents" (disposable — spun up per session, shut down after, but feeding lessons back into the persistent role/memory layer).
• Agent performance degrades past roughly half a context window, so breaking tasks into smaller pieces handed off between agents keeps quality consistent.
• A chat-first "butler" layer lets the human manage/delegate without needing to code, while gates control what gets automated vs. reviewed by a person.
• Interactive HTML plan mode (with prototypes you can manipulate before code is written) and a verification/checklist report close the loop between planning, building, and review.
• The self-updating loop — the system proposing fixes to itself and restarting on approval — is a concrete example of self-improving automation most current tools don't offer.
• The "mind palace" shows AI-assisted taste-building: linking disparate personal interests (music, objects, film) into a graph, then having AI surface new recommendations from the pattern of links.

Jiak Simi is Kimberley's Singapore food app — a personal palate compass. It learns how you actually eat, then answers jiak simi? (what to eat?) with places that fit you, not what is trending or paid.

Kimberley got tired of answering the same daily question with the same few spots. Most food apps show nearby, popular, or advertised. She wanted taste: a map of your palate that gets sharper every meal. Built as a solo founder, with AI on the heavy lifting so time could go into craft and hyperlocal detail.

• Jiak Simi's design is uniquely local — hawkers, halal, walking time, Singlish.
• Leveraging AI to build helps non-engineer like Kimberley spend more time on craftmanship and refining taste.
• Palate as a compass is a more powerful recommendations engine than typical food apps that rely on reviews

Two small personal-use apps built by Edmund: (1) an AI usage-limit tracker, originally built for an OpenAI build week in July, that monitors subscription/plan limits and connects to a home Linux server over Tailscale, plus a home-screen widget; and (2) a reminder board — a simple sticky-note-style app synced across phone and Mac, inspired by an app called Mono, with MCP support so AI agents can also post reminders.

The usage tracker exists because plan/subscription limits reset on a schedule he wanted visibility into on the go (e.g., checking on the train), and to get notified the moment a limit resets so he knows it's time to build again. The reminder board exists for a much more personal reason: he admits to forgetting homework and doomscrolling more than doing it, so he wanted reminders to surface exactly where he's already looking — his phone's home screen.

• Small, single-purpose personal tools (a widget, a sticky note board) can solve real daily friction without needing to be full products.
• Connecting a personal app to your own infrastructure (home Linux server via Tailscale) is a lightweight way to get remote access without cloud hosting.
• Building for your own admitted bad habits (doomscrolling over homework) is a legitimate and relatable design brief.
• Wiring MCP into a simple reminder app turns a static sticky-note tool into something AI agents can proactively write to — a small but concrete example of agents acting on personal infrastructure.

A panel Q&A following the individual project presentations, where builders reflected on lessons from vibe coding their apps and fielded audience questions on scoping, cross-platform development, competition from big incumbents, and maintaining code without a technical background.

Opening question: If people remember one thing from your talk, what should it be?

• Think from first principles — AI makes it easy to build fast, but speed without clear intent creates unnecessary baggage. Prioritize knowing exactly where you're going before you start.
• Be patient with yourself — especially without a coding background. Take one thing, make it good, then slowly add more. There's no rush.
• Just keep building — the barrier is low and mistakes aren't punished. When you're stuck, AI is what makes you free to keep going.
• Craft things with intention — intentionality is what separates an idea from an actual product.
• Focus on the one feature that matters — it's tempting to prompt for ten features, but pick the one that makes the difference and hold it to a high bar; AI will happily produce subpar work if you let it.
• Distribution is the most important thing — Meng shared building five apps over two years, one hitting $100K MRR before dropping 50% in a month. His answer to "AI could replace you in a month": stop being shy on camera, be more human, and own distribution.

Q: How do you know when something is "done" instead of second-guessing yourself? (from Guru, a data scientist)

Ship as soon as possible. Stop overthinking — post it on Twitter/LinkedIn and let real reception tell you if it's ready, rather than deciding "done" in isolation.

Q: How does building for iOS/Swift differ from web or Android?

Kimberley (no coding background, ships to both platforms): uses React Native as a single source of truth so updates go out to both Android and iOS at once.

Yu Xuan: leans into the Apple ecosystem to cut his own workload — his doodle app uses iCloud alone, avoiding the need for a database or auth (unless building something social). Web requires more infrastructure thinking (backend, auth, data safety) than iOS, and he prefers SwiftUI's declarative style over TypeScript for web UI work.

Q: What if a large incumbent just copies your app?

Meng noted he's living this now, competing against well-funded AI app builders (Lovable, valued at $5–13B, and Codex). His response: lean into distribution, talk to real people, solve locally-felt problems, open-source parts of his work, and offer a lifetime deal — something VC-backed competitors structurally won't do since they depend on subscriptions.

Another panelist pointed to speed as the edge: shipping every other day based on constant beta feedback, versus the many approval/design layers a large company needs before reaching the same user need.

Q: As a non-technical founder, how do you maintain code and fix bugs after shipping? (from Agnes)

Pit AI tools against each other — have Claude and Codex review one another's work. Even without being able to read the codebase yourself, this lets you catch gaps and get a second opinion on quality before trusting a change.

Recurring themes across answers:

• Speed is cheap now; judgment about what to build and when it's good enough is the actual bottleneck.
• Distribution, personal presence, and real-world feedback loops are repeatedly framed as the durable moat against both AI commoditization and well-funded competitors.
• Cross-platform and maintenance questions were answered with "reduce your own surface area" (React Native as single source of truth, iCloud instead of custom backend, AI-vs-AI review) rather than mastering every layer personally.