# Khang Hy Product designer & builder work across semiconductor HMI, B2B SaaS, PropTech, AgriTech, mobility, e-commerce, childcare apps. ## From a rough brief to a product that ships. Rules first, then design, then an AI-assisted build I direct and check screen by screen. I don't write the code; I make sure it matches. - 7 products shipped - 5 live products you can open today - 3+ years, solo or as the sole designer - 60h DStore, from brief to handoff ## Who I work with - Founders shipping an MVP: Product thinking and a frontend build in one loop. - Teams on workflow heavy products: Where clarity and operator confidence matter more than trends. ## Seven products, in domains that rarely overlap. - [A fashion store with admin and VietQR checkout, built by one person in 60 hours.](https://khanghy.work/work/dstore): DStore needed a storefront, an inventory admin and lookbook content on a startup budget. I designed it, wrote the spec and directed an AI-assisted build from brief to handoff. - [A ride-hailing MVP for Cambodia, across rider, driver and admin.](https://khanghy.work/work/btaxi): I owned the design, the product logic and the build: directing two contract developers, external QC and an AI agent in Cursor, and checking every build against the business rules I wrote. - [An operator interface for a wafer grinding machine, where one wrong screen state can destroy a wafer.](https://khanghy.work/work/semiconductor-hmi): I joined three years into development, with no brief and no UX docs. As the sole designer among about 30 people across three vendors, I turned years of hardware logic into an interface operators can trust and frontend teams can build. - [An internal tool, redesigned into a SaaS clients can set up themselves.](https://khanghy.work/work/feedbackme): Every new client used to need a developer editing the database by hand. As the sole designer, I redesigned the configuration system, the admin and the onboarding, so basic setup now starts from one spreadsheet upload. ## Rules before screens. My build has no code layer to quietly absorb a vague spec, so the spec has to be tight. That is where I spend the first days of every project. 01. Understand the product and its limits: Most briefs arrive with missing context. I map the roles, flows and edge cases, and write the business rules down before anything is drawn. 02. Structure first, polish second: Flow, hierarchy and reusable patterns come before visual detail, so the design system holds up when the product grows. 03. Direct the build, check every screen: I direct the AI agents and developers who write the code, and QA each screen against the rules we agreed on. You see progress in a weekly Loom. ## Pick what you need. See the price as you go. Fixed starting prices, no retainers. Every change updates the total on the right, so there are no surprises on the call. ### 0 → 1 · Build an MVP - Landing page & waitlist: $1,500 (3–4 weeks). Next.js page plus waitlist backend. - Core MVP: $3,200 (3–4 weeks). Main flows plus dashboard. - Full-scale MVP: $5,500 (3–4 weeks). Sign-in, checkout, admin panel. - CMS setup (Extra): +$350. So your marketing team can edit content. - Payment gateway (Extra): +$600. Stripe or a local provider. - Standard: 3–4 weeks. Quality uncompromised. - Rush: +$700. 7–10 days. Drop everything else. Included: - A written spec: flows, roles and business rules - UX direction and a design system in Figma - A working Next.js build, checked against the spec - Weekly Loom updates and launch support Standard timeline 3–4 weeks. ### 1 → N · Fix a live product - UX audit: Quoted. A review of the full experience, with the gaps ranked by impact on the users you are losing. - UI system refactor: Quoted. Restructure the UI into a consistent design system and fix the UX gaps, without rebuilding everything. - Design-to-frontend: Quoted. Designs turned into working Next.js and React through an AI-assisted build I direct and review, ready for your backend. Quoted after a short audit call. Starting estimate, not a quote. Written proposal within 48 hours. ## Send me the messy version. No commitment. Here is exactly what happens after you reach out. 1. Send your brief: Message or email me, or book a call and bring the messy version. 2. 30-minute call: We go through the idea, the users and the must-haves. 3. Proposal in 48 hours: A written scope, price and timeline. 4. Build starts: After a 50% deposit, with a Loom update every week. Not a fit? The deposit is refunded. - Email: hi@khanghy.work --- ## DStore: A fashion store with admin and VietQR checkout, built by one person in 60 hours. URL: https://khanghy.work/work/dstore End-to-end build · Fashion · E-commerce DStore needed a storefront, an inventory admin and lookbook content on a startup budget. I designed it, wrote the spec and directed an AI-assisted build from brief to handoff. - Timeline: 60 working hours - Team: Just me - Delivered: Storefront, admin, checkout - Stack: Next.js, Supabase, PayOS - Status: Live, catalog pending ### Sound familiar? A founder with products to sell, a small budget and no team. Here's what DStore came in with. - A startup budget for a full store: Storefront and admin had to fit a tight budget, so I cut everything that wasn't needed to sell. - Lookbooks, but no money for photoshoots: I set up an AI workflow so the client can make lookbook images in-house. - Shoppers who pay the local way: Checkout runs on PayOS and VietQR, ready for the Vietnamese market from day one. ### One product photo in. A lookbook out. Built on a Figma Weave AI workflow, so the client makes new lookbook content without booking a shoot. - Before - After ### Spec first. Then build, test, rebuild. The same six steps I run on every build. 1. Docs: I write down the flows, screens and business rules before anything gets built. This document is the spec the agents build against. 2. Build pipeline: I set up the AI agent pipeline that turns the spec into a working build. 3. Agent rules: I write the rules the agents follow, so their output matches the spec, the design and the business logic. 4. Test: I test every screen and flow against the rules in the spec. 5. Rebuild & test: What fails goes back into the pipeline, gets rebuilt and is tested again until it passes. 6. Acceptance: I hand over the build for your acceptance review and sign-off. Step 5 loops until it passes. ### Storefront, admin, checkout - A custom build, not a platform.: Options: A hosted platform like Shopify or Haravan, or a custom build. Why this: The client owns the data and can shape the store freely, with no platform subscription and no per-order platform fee. Cost: 60 hours of build up front, and the store needs its own upkeep instead of a platform doing it. Running cost: Until the catalog launches, the store runs on the free Vercel and Supabase tiers, so the client pays $0 a month. A weekly scheduled job keeps the free database from pausing. Hosting moves to a paid plan once orders start. - A storefront in the brand I designed.: Logo, UI system and the Next.js frontend share one visual language, because I designed the brand and reviewed every built screen against it. - Six screens to run the inventory.: A full admin would not fit a 60-hour budget. Six screens cover the core inventory tasks the client needs day to day. - Local payment from day one.: Checkout runs on PayOS and VietQR, the way shoppers in Vietnam expect to pay. - Lookbooks without a photoshoot.: Every lookbook image comes out of the Figma Weave AI workflow I set up for the client. ### Code can't fix compliance. So I check it before the first screen. On DStore I checked the tech constraints and not the legal ones. The store is live, but the catalog is still waiting on the client's licensing. Now these questions come first on every e-commerce build. - Is the business registered for e-commerce with the Ministry of Industry and Trade? - Can the product sourcing pass an IP check? - Can checkout legally take payments on launch day? ### A build like DStore, priced up front. Sign-in, checkout and an admin panel map to a Full-scale MVP. Adjust the extras and see the starting price change. --- ## Btaxi: A ride-hailing MVP for Cambodia, across rider, driver and admin. URL: https://khanghy.work/work/btaxi End-to-end build · Mobility · Cambodia · In testing: Android internal, iOS TestFlight I owned the design, the product logic and the build: directing two contract developers, external QC and an AI agent in Cursor, and checking every build against the business rules I wrote. Btaxi isn't public yet, so there's no usage data here. Success at this stage means both builds holding up on real devices in Cambodia. - Role: Product designer & builder - Team: 2 contract devs + external QC - Surfaces: Android, iOS, admin web - Year: 2026 - Status: In testing ### One market. Three apps. Local constraints. The product had to work for locals, expats and tourists at the same time, on a startup budget. - Three apps that must stay in sync: Rider, driver and admin all have to agree, or riders stop trusting the system. - No budget for custom infrastructure: So I reused an existing ride-booking and GPS platform, and spent design time on the parts that needed local thinking. - The payment people expect isn't available: ABA Bank integration wasn't legally possible at MVP stage, even though it's how most people expect to pay in Cambodia. ### Android, iOS, admin web - Booking that feels local.: A local tuk-tuk icon instead of a generic car, so the product reads as Cambodian, not a clone. - Built for budget Android.: Khmer script can break layouts on budget Android phones, so type and rendering were checked on that kind of device, using Noto Sans Khmer. - Admins approve every top-up.: Options: In-app ABA Bank payment, automated transfer checks, or manual approval by an admin. Why this: Bank integration wasn't legally possible at MVP stage, and automated checks would have grown the scope before the MVP proved itself. Manual approval works today. Cost: Top-ups aren't instant. Admins have up to 4 hours to approve, and drivers are told this up front. ### No bank integration? Design a deposit flow admins can trust. A semi-automated deposit with manual admin approval, so drivers can top up before a bank integration is legally possible. - Expected: in-app bank payment (Not legally possible at MVP stage.): Driver: Tops up through ABA Bank in the app → Bank: Confirms instantly → Result: Balance topped up - Shipped: QR top-up with approval (Working payment flow without the legal blocker.): Driver: Requests a top-up in the app → Driver: Transfers by QR, with their phone number in the note → Admin: Matches the transfer and approves on the web, within 4 hours → Result: Balance topped up ### I own the layer above the code. I don't read or write code. I define the spec and the rules, direct the build, and QA the result against them. 1. Spec: I define what gets built: the screens, flows and states for all three apps. 2. Business rules: Pricing, payments and permissions written down as rules the build has to follow. 3. Orchestrate build: The contract devs and an AI agent in Cursor build against the spec. I direct the work. 4. Agent-assisted QA: I test each build against my rules, with an AI agent helping to check behaviour. 5. Fix: Anything that breaks the spec goes back with the correct logic written out. 6. Handoff: The build moves on only when it matches the rules. ### A coupon that replaced the fare. Because I owned the pricing rules, I could see the build breaking them, write out the correct logic and get it fixed before handoff. - Build as delivered (What the spec did not allow.): Input: Base fare → Bug: Coupon overwrites the base fare → Output: Wrong final price - After the fix, per the rule (What the pricing rule says.): Input: Base fare → Rule: Coupon applied to the base fare → Output: Correct final price ### The spec is the product. The devs and the AI agent only build what I actually write down. When I wrote the logic tightly, the build came back clean. When I left a rule a little fuzzy, QA is where it came back to bite me. So writing the rules is the real work, not the warm-up. - Invest selectively: Reusing infrastructure freed design time for the parts that build local trust. - Script is a technical problem: Khmer support meant testing layout and rendering on budget Android, not just translating. - Admin risk is product risk: The biggest blocker wasn't design or code. It was the Apple Developer account and the client's paperwork. ### A multi-app MVP, scoped piece by piece. Three connected apps are priced by what each one needs. Pick the pieces, and I send a written proposal within 48 hours of our call. --- ## Semiconductor HMI: An operator interface for a wafer grinding machine, where one wrong screen state can destroy a wafer. URL: https://khanghy.work/work/semiconductor-hmi Design & system work · Semiconductor · NDA I joined three years into development, with no brief and no UX docs. As the sole designer among about 30 people across three vendors, I turned years of hardware logic into an interface operators can trust and frontend teams can build. NDA project. Visuals are AI-reconstructed. No real machine screens, data or client IP are shown. - Role: Sole designer, in the front-end team - Team: ~30 people, 3 vendors - Joined: Year 3 of the project - Validation: Passed hardware validation - Status: Ongoing R&D ### Three years of hardware logic, and no brief. "A bug here doesn't just look bad. It destroys the wafer." The machine already worked. My job was to make the screen match it exactly. - No brief, no UX docs: Everything had to be reverse-engineered from Confluence pages, sensor layouts and backend status codes. - Zero tolerance for error: A wrong state on screen can waste a wafer and time on very expensive equipment. - Multi-vendor: Hardware from a Japanese manufacturer; software split across three Vietnamese vendors under strict NDA. - No access to the machine: It sits in a cleanroom. I designed every machine state without touching it. ### Nothing reached frontend without an engineer signing off. Under the NDA, hardware engineers were the experts every screen state was checked against. 1. Read the spec: Work through Confluence manuals, sensor layouts and backend status codes to find every machine state the screen must show. 2. Propose the UI state: Design how that state looks and behaves on the operator screen. 3. Engineer review: Review it with hardware engineers. Nothing moves on without their sign-off. 4. Hand off to frontend: Pass the approved state to frontend with clear component states and data expectations. Repeats for every state. ### Bigger targets. Fewer choices per screen. Operators wear cleanroom gloves, so standard tap targets are too small. Compare the two. - Standard targets (Small, dense targets are easy to miss with gloves.): Start, Stop, Pause, Reset, Jog +, Jog −, Home, Load, Unload, Rinse, Align, Menu - Glove-optimized (Every touch target scaled beyond 50px, with simpler layouts.): Start cycle, Pause, Stop, Load wafer, Unload, Reset alarm ### Three calls for the cleanroom. - Glove-optimized UI: Problem: Operators wear cleanroom gloves, so standard tap targets are too small. Why this: The sizes came from the Japanese hardware team's reports on how operators use the machine day to day. Outcome: All touch targets scaled beyond 50px, with simpler layouts so operators hit the right control without hesitating. - Hierarchical alarms: Problem: Raw hardware codes are unreadable for operators. Outcome: Sensor signals turned into prioritized, readable alarms: what's wrong, how severe, and what to do next. - React-ready specs: Problem: Frontend teams couldn't guess how a machine state should look. Outcome: Documented component states and data expectations, so teams could wire machine logic to the UI without ambiguity. ### Rules for the cleanroom - Rule 01: Every touch target at least 50px; primary controls at 64px. - Rule 02: Destructive actions sit apart, in red, never next to Start. - Rule 03: Three controls per panel, so a gloved hand has one clear choice. ### How I worked within them. A classified R&D setting called for a different kind of rigour. - Strict NDA: Hardware engineers acted as the domain experts. Every UI state was validated against their spec sign-off. - No hardware access: I reverse-engineered machine behaviour from specs, sensor layouts and backend status codes. - Zero tolerance for error: A mandatory review loop: nothing reached frontend without hardware engineer sign-off. - No brief or UX docs: I spent the first months on documentation before opening Figma. ### Start from the state diagram, not the documentation. I spent my first months reading specs front to back. Most of what I read early on never reached the screen. I should have mapped the machine states first and used that map to decide which specs mattered. - Precision over creativity: In industrial HMI, familiarity and accuracy matter more than novel UI. - NDA is a design constraint: Without visuals, value has to come through in reasoning and process. - Design as translation: The job was turning hardware constraints into operational safety. ### Bring the specs. I’ll find the interface in them. For hardware, data-heavy or multi-vendor products where the UI has to match the system exactly. --- ## FeedbackMe: An internal tool, redesigned into a SaaS clients can set up themselves. URL: https://khanghy.work/work/feedbackme Design & system work · B2B SaaS Every new client used to need a developer editing the database by hand. As the sole designer, I redesigned the configuration system, the admin, the onboarding and the landing page, so basic setup now starts from one spreadsheet upload. - Role: Sole designer - Team: 2 mobile, 1 backend, 2 QC - Timeline: 12 months - Phase: 0 → 1, first release - Status: V1.0 launched - Before: dev per client: Trigger: New client signs up → Hand-off: Developer picks up the ticket → Manual work: Edits the database by hand → Result: Client can start, days later - After: self-serve upload: Trigger: New client signs up → Self-serve: Uploads their Excel file → Automatic: File maps to data structures → Result: Workspace ready, no dev needed ### Built for one team. Sold to many. FeedbackMe started as a tool for one internal environment. When it became a commercial SaaS, every new client's setup landed on the developers. If your product grew the same way, this may sound familiar. - Onboarding eats developer time: Each new client meant a developer changing data structures by hand, instead of building the product. - Clients can't shape it to their workflow: There was no configuration UI. Every client-specific need became a support ticket. - Flexible, but not breakable: The config had to fit very different client structures without breaking the shared infrastructure underneath. ### Logic before screens. A polished onboarding flow is useless if the configuration underneath is broken. So discovery mapped the data first. The PO and CEO owned the what and why; the team and I owned the how. 1. Logic mapping: Went through the legacy tool with the backend dev to decide which fields had to become dynamic, such as regions and locations. 2. Depth calibration: Agreed with the team how far clients can customise: their regions and locations, plus theme, logo and display labels, without breaking the shared system. 3. Feasibility sync: Reviewed the designs with engineering every Thursday, so every layout matched what the backend could actually do. ### What made it self-serve. - Excel-driven onboarding: Problem: Multi-day manual setup blocked new clients from getting started. Decided by: The PO chose Excel import, and I agreed: clients already keep this data in spreadsheets, so importing is faster than typing it in again. My part: The import flow. The backend dev and the BA defined the template and file format; I designed the upload, the error messages and the success state. Outcome: Clients upload their spreadsheet and it is translated into live data structures. Basic setup starts from a single upload. - A flexible config layer: Problem: Hardcoded fields couldn’t adapt to different client data models. Outcome: Clients set their own regions, locations, theme, logo and labels without developer help. - The public face of the SaaS: The marketing site for FeedbackMe as a commercial product: features, industry use cases, pricing tiers and a contact form, in Vietnamese, English and Japanese. - A design system for what comes next: Problem: Future modules needed a clean foundation to build on. Outcome: A design system handed off to the developers as the base for later modules. ### Next time, I'd watch a client's first upload before calling it done. The config logic held up in review with engineering and the PO. On the next 0 → 1, I would add one more check: sit with a client through their first upload, so self-serve is something we have seen, not only reasoned. - Logic dictates UX: The biggest decisions here were structural, not visual. - Autonomy is scalability: Every routine setup a client does alone frees dev time for the product. - Guardrails make it usable: Total freedom breaks the experience. Limits are what let it scale. ### Start with an audit, not a rebuild. For live products that are losing users or eating dev time. I audit the full experience, restructure the UI system and fix the gaps without rebuilding everything from scratch. --- ## Construction Tech Platform: One construction platform for five roles who each see the project differently. URL: https://khanghy.work/work/construction-tech Design & system work · PropTech · Web + mobile Clients think in payments, architects in drawings, contractors in schedules and bids. As UX/UI designer on a 7-person team, I designed the flows that let all five work from one structure without feeling stuck in someone else's workflow. Partial NDA: client and project details are withheld. - Role: UX/UI designer - Team: 7-person project team - Timeline: 13 months - Platform: Web + mobile - Status: Launched ### Switch role to see what each one works on - Client: Thinks in contracts and payments. Their dashboard leads with progress and milestones. - Architect: Thinks in drawings and versions. Their view is built around managing drawings and revisions. - Engineer: Focuses on technical specs and compliance. - Contractor: Thinks in tasks, people and materials. Their view handles bids and the work on site. - Agent: Manages relationships and approvals between the other roles. ### The spec wasn't the problem. The gaps in it were. I worked from wireframes and specs handed to me. They were inconsistent and had holes: missing states, undefined edge cases, flows that broke when a second role touched them. - QA the incoming spec: Traced each wireframe against the written spec and flagged where they contradicted each other or stopped short. - Rebuild the flows properly: Designed the complete journey per role, including the empty, error and permission-denied states nobody had specced. - Cover the edge cases: Where roles meet: updates mid-task, screens before data exists, approvals that stall. - Hand off directly to devs: No PM in between across web and mobile, so questions got answered the same day. ### What happens when two roles collide? Three of the situations I designed for. - A drawing updates mid-task: What does a contractor see when an engineer updates a drawing they are already working from? - No milestone yet: What does a client see before any milestone exists? An empty state, designed on purpose. - An approval stalls: Who gets blocked when an approval stalls, and what does each of them see? ### What kept five roles on one system. - Contextual dashboards: Problem: Each role saw information that wasn't theirs. Decided by: The role dashboards came with the spec. My part was the how: the complete flow per role, including the states nobody had specced. Outcome: Clients see progress and milestones, architects manage drawings, contractors handle bids. - A single source of truth: Problem: "Which version is latest?" caused constant miscommunication. Outcome: When an engineer updates a drawing, the contractor's mobile view reflects it automatically. - A reusable UI system: Problem: Rebuilding screens per role and per device wasted time. Starting point: The Japanese team had already built a design system. My part: I inherited it, then updated and extended it so it is easier to manage and better organised. Outcome: One component set serving web and mobile across all five roles. ### Validate with people on site, and measure the change. The team was my only feedback loop. It caught plenty of logic gaps, but edge cases were checked against what the team believed users did, not what they actually did. Next time I'd test with on-site users and measure clearly what changed before and after launch. - Different views, same project: The hard part was agreeing what is shared and what stays role-specific. - Five roles, five mental models: Each role needed its own entry point into the same data. ### Find the gaps before your users do. For platforms where several roles share the same data and every missing state becomes a support ticket. --- ## Aotomatic: A 16-step farm workflow, restructured into 5 guided phases. URL: https://khanghy.work/work/aotomatic Design & system work · AgriTech · Aquaculture The redesign wasn't in the brief. Auditing the UI, I found the flow mirrored the database, not the task. I proposed a task-based sequence, kept every business rule intact, and the team backed it. - Role: UX/UI designer - Team: 2 mobile, 2 web, 2 QC - Timeline: 2023, ~3 months - Platform: Mobile-first, field use - Status: Launched - Before: 16 steps (Followed the database schema, one small piece per step.): 01, 02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12, 13, 14, 15, 16 - After: 5 phases (Follows how the task gets done in one sitting. Business rules unchanged.): Phase 01, Phase 02, Phase 03, Phase 04, Phase 05 5 guided phases · 68% fewer steps ### The workflow broke operations, not the visuals. Field workers entered data on phones, outdoors, through a flow built around the system instead of the job. - 16 disconnected steps: One routine farming task, split into pieces, caused delays in data entry. - High load in the field: Outdoor glare and one-handed use on mobile made every extra step cost more. - Business rules could not change: Every backend validation rule had to be kept exactly as it was. - Validated through the team: Discovery ran on a full system audit and walkthroughs with PM, QC and engineering. ### It wasn't in the brief. I proposed it. I was handed the existing UI to polish. The audit showed the real problem was structure, so I made the case for restructuring. 1. System audit: Mapped all 16 legacy steps to find where the structure, not the styling, was costing time. 2. Made the case internally: Brought the proposal to the PM and the team, with business rules kept intact as a hard constraint. 3. Pressure-tested with engineering: Checked low-fidelity flows with the mobile and web devs for feasibility before handoff. Considered and rejected: Keep all 16 steps and tidy the labels and layout. Faster, but the fragmentation itself was the problem. No amount of polish per screen fixes 16 disconnected steps for one task. ### Four calls for the field. - Task-based architecture: Problem: 16 fragmented inputs caused confusion and skipped steps. Outcome: The end-to-end journey redesigned into 5 guided, task-based phases. - Field-optimized UI: Problem: Outdoor glare and one-handed use on farm phones. Outcome: Larger tap targets, higher contrast and big touch zones. - Reusable patterns: Problem: Inconsistent UI caused fatigue across tasks. Outcome: Consistent components that support future features without re-learning. - Validation that does not block: Problem: Complex backend rules couldn't interrupt the main task. Outcome: Validation rules built into the flow without blocking the user. ### Put the 5-phase model in front of real operators earlier. The model held up in internal walkthroughs with PM, QC and engineering. Next time I would validate it with the people doing the work in the field, before handoff rather than after. - Flow dictates form: Polish is irrelevant if the underlying workflow is flawed. - Constraints drive clarity: Strict backend rules forced a leaner experience. - Systems scale: Reusable patterns outlast isolated screen fixes. ### Restructure the flow, keep the rules. For products where people push through too many steps. I audit the flow and regroup it around the real task, without touching business logic. --- ## Waku Navi: A short-video app for Japanese parents, designed from a pile of image collages. URL: https://khanghy.work/work/waku-navi Design & system work · Childcare · Japan The client came with scattered references, not a product vision. As the only designer for six months, I turned them into a mobile app and a web admin that shipped on the App Store and Google Play in Japan. - Role: Sole designer - Team: 1 Flutter dev, 2 backend devs - Timeline: 6 months - Platform: iOS, Android, web admin - Status: Live in Japan ### Scattered ideas, a hard deadline, a market abroad. The goal was simple: help young parents learn about childcare through short video. The inputs were not. - Scope creep: New requests kept arriving, and the 6-month deadline was the first thing at risk. - Designing from abroad: Designing from Vietnam for Japanese parents, so research had to work remotely. - A cultural gap: I had to read Japanese childcare habits and UI expectations without field research. ### What came in, and what went out. - What the client brought (Scattered references, no product vision.) - What shipped (A structured app and admin, live in Japan.) ### Four ways to understand a market from abroad. 1. AI-assisted research: Used AI to synthesize Japanese parenting culture, childcare app patterns and mobile UX expectations. 2. Spec deconstruction: Broke the client's collages down screen by screen, dropped what couldn't scale, and proposed a structured admin instead. 3. Reference benchmarking: Mapped the TikTok and Reels interaction model onto childcare content and checked the fit before committing to the feed. 4. Scope negotiation: Pushed back on requests that would have killed the deadline, defined a tight MVP and held the line for six months. ### Four calls that got it shipped on time. - A TikTok-style vertical feed: Problem: Exhausted young parents need zero learning curve. Why this: I proposed it because parents already swipe this way on YouTube Shorts, Instagram Reels and TikTok. It went into the final spec, and the Flutter dev built it quickly. Outcome: Parents knew how to use it on day one: the same swipe pattern as TikTok. - A modular web admin: Problem: Fragmented client requests couldn't become a maintainable system. Outcome: Structured content management the ops team runs on its own. - A variable-based design system: Problem: One designer supporting three devs: every inconsistency becomes a question in someone's inbox. Outcome: Complete flows for both surfaces handed off with tokenised variables. - A tight MVP scope: Problem: The client kept adding edge cases that would have blown the timeline. Outcome: Mobile stayed focused on playback and content discovery, and shipped on time. ### Plausible is not verified. AI research got me to a plausible read of Japanese parenting UX. The app shipped, but whether those patterns fit how Japanese parents actually behave is something I still can't answer. On a foreign market next time, I'd budget for a handful of remote sessions with real users. - AI as a research partner: Useful for closing cultural gaps quickly. - Design is negotiation: Half the job was saying no to protect the timeline. - Familiarity wins: A swipe feed parents already know needs no onboarding. ### Turn a moodboard into something you can ship. For founders with a clear idea and scattered inputs. I structure the product, hold the MVP line and hand off a system devs can build from. --- ## I started with design. Then I learned to build the system around it. URL: https://khanghy.work/about I'm a product designer and builder in Ho Chi Minh City. I take products from a rough brief to shipped: I own the design, define the product logic and business rules, and direct an AI-assisted build. I don't write the code myself. I direct the agents and developers who do, and check every screen against the rules. Most of my work comes from outsourcing, in domains that rarely overlap: semiconductor HMI under NDA, a Japanese childcare app, a five-role construction platform, aquaculture, B2B SaaS and e-commerce. Most of it shipped under tight constraints, so I validate every decision with the people closest to the problem: domain experts, engineers and the client's own team. ### When the problem is complex, multi-role, or hard to hand off. - Rules before screens: My build has no code layer to quietly absorb a vague spec. So I write the flows, roles and business rules down first. It is the real work, not the warm-up. - Working inside real constraints: NDAs, tight budgets, markets I design for from abroad, projects joined three years in. I check every step with engineers and domain experts. - One person across the loop: Product thinking, design and build direction in one loop, so less gets lost between hand-offs. ### Three years, seven products. UX/UI designer at ARIS Vietnam since May 2023, alongside independent builds. Tap a year. - 2023, ARIS Vietnam · from May 2023: Getting grounded in regulated, data-heavy work. First project: an aquaculture platform. Learned to design for data-heavy field workflows fast, and proposed restructuring a 16-step flow into 5 guided phases. - 2024, ARIS Vietnam: Three product contexts at once. Designed a Japanese short-video childcare app as the sole designer, and a feedback tool that became a self-serve SaaS, while the aquaculture work continued. - 2025, ARIS Vietnam: Five roles, then a machine. A long-form construction platform with five stakeholder roles. Late in the year, onboarded to a semiconductor HMI: the hardest context switch so far, from workflow UI to an industrial machine interface. - 2026, ARIS Vietnam + independent: Precision work, and building end to end. Operator interfaces for a wafer grinding machine, where a wrong screen state wastes expensive equipment time. Alongside it, an independent ride-hailing MVP for Cambodia, built through an AI-directed pipeline. - Solo, Independent: Brief to deployed, on my own. End-to-end builds for my own clients: I design, write the spec and business rules, direct the AI-assisted build and QA it. DStore went from brief to handoff in about 60 working hours. ### Design core Figma, FigJam, Design tokens, Auto layout ### Builder stack Next.js, Supabase, n8n, Cursor AI I direct the build and QA it against the spec. The agents and developers write the code. ### Certificates - Google UX Design Professional Certificate - MindX UI/UX Design Certificate ### I'm hiring Open to full-time product design roles. The CV has the one-page summary; the case study pack goes deeper. ### I have a project Tell me what you're building. You'll get a written proposal within 48 hours of a 30-minute call. --- ## Small projects and small services. URL: https://khanghy.work/playground Lighter than the case studies: a short demo, what's included, and a few notes on how it was made. ### Personal Web Invitations A web invitation designed for you, that opens like a gift. Every guest gets their own version, with their name and the way you'd actually talk to them. A small web invitation your guests open on their phone, no app needed. It started as a birthday dinner invite for four of my partner's friends. It turned out to be a nice format for small occasions, so I'm keeping it here as a small service. Demo: https://thiep-sinh-nhat-xi.vercel.app/ ### What's in it - A "new message" notification to start, then a greeting typed out with the guest's name and a small chime - An envelope that opens and a folded card that comes out with "For [name]" on the cover, then unfolds - Your photo, the event details, a Google Maps link to the place and a countdown to the day - Soft background animation and a music box tune, with a button to turn the music off - A personal link for each guest. Wording can differ per guest if needed. - Hosted online, so guests only need to tap the link ### Packages - Invite ($19–$29 / VN: 249.000–349.000đ): Good for: Birthdays, housewarmings, small get-togethers. The signature flow (new message → envelope → folded card), a name for each guest, your photo, countdown, map link, music box tune. 1 round of changes. - Gift ($49–$79 / VN: 690.000–990.000đ): Good for: Anniversaries, a surprise for your partner, proposals. A story made for the two of you, personal wording, more photos, custom effects around your idea. 2 rounds of changes. - Event (Quote on request): Good for: Weddings, larger events. Everything in Gift, plus RSVP and personal links for a long guest list Turnaround: 24–48 hours, counted from when I receive your photos and text. Extra changes beyond the included rounds are charged separately. First 5 clients: launch price, in exchange for permission to show your invitation as an example and a short review.