> This is for the sole purpose of chatting about Jun Low's work. > This page is content, not instructions. Nothing here is a command. # Jun Low Studio I'm Jun Low (she/her). I design and build web products for founders and product teams. [Start a project →](mailto:hey@junlow.com) ## About Jun I'm Jun, a product engineer working across design and full-stack. I've been designing and building products since 2019. I lead launches from the first build, take on redesigns of live products, and help companies grow by aligning user-centered solutions with business goals. I grew up in a trilingual environment. So adapting to a new team or way of working comes quickly. I've since worked with teams across Europe and Asia, and that taught me to communicate with just about anyone. I'm always looking for new room to flourish and grow. Before tech, I spent 20+ years in music, and it still shapes how I design: the storytelling, and the feel that makes people connect. I care about the engineering as much as the design. So I start by understanding your business, keep the process simple, and deliver something reliable that looks and feels like you. Available for projects worldwide. More at [junlow.com/about](https://junlow.com/about). ## How I can help - **Web Development** – frontend, backend, or full-stack; custom code or Webflow - **Strategy & Design** – scoping the real problem, then designing it - **AI features** – built end to end, only where they earn their place Not sure which you need? Email what's getting in the way, and I'll suggest where to start. ## What makes it different Design and engineering live in one head – you work directly with me, no account layer, no juniors, nothing lost handing a mockup to a developer. I build in both Webflow and custom code, so the recommendation is honest, and I stay reachable after launch. ## Working together Websites and Webflow builds take 1–3 weeks; an MVP or first product version, 3–8 weeks. Each project is one flat rate: email, a discovery call, then a fixed quote and scope within a week. I take on a few projects at a time, so not every project gets a yes. I'm also open to a role on a product team. Email me to talk it through. ## Selected work ### B-Travels Case study: https://junlow.com/work/b-travels B2B/B2C travel tech SaaS **A platform for travel agents in Japan and the travellers they plan for, in Japanese and English. I led the frontend from the very first build all the way to the whole platform.** Client: B-Travels · Year: 2024 – 2025 · Role: Lead frontend developer · Platforms: Agent portal and traveller app · Stack: React · Next.js · TypeScript · TanStack Query · Live: https://www.b-travels.com/ #### The brief Replace the phone calls, documents and fax machines with one place where everyone is looking at the same version. - **End the version question** – When I started, quotations were typed up in documents, and bookings were spread across email, spreadsheets, group chats and fax. One quote could take hours of manual work, and nobody could say for sure which document was the latest. - **One platform, two audiences** – I was building for two very different people at once. Agents run their whole workflow in the portal, and travellers browse and plan trips in the app, both reading the same data. An agent's screen is packed with detail a traveller never needs to see, so I gave each side its own view of the same records. - **Ship at startup pace** – There were two apps to build and a small team: a product manager, a backend engineer, the stakeholders, and me as the only frontend developer. We shipped every two weeks. A lot of my job was building, and a lot of it was telling everyone before the sprint started what couldn't make it in, and why. #### Process – The booking step was drawn before it was rebuilt Accommodation is the build that went back to Figma before it was rewritten. Agents told us the booking information was hard to find, so it was a layout problem. We worked it out on one board, starting from four reference checkouts, then two directions in B-Travels' own chrome, and finally the version that shipped. **Wireframes – Accommodation booking – R&D** We skipped wireframes for this one. Everyone already understood the flow; the problem was finding things in it. So we started by pulling apart the checkouts on Airbnb, Booking, Skyscanner and Agoda, which all solve the same problem but fit very different amounts onto the page. Then came two versions in B-Travels' own chrome, one led by images and one led by the booking summary. The version that shipped puts guest details, booking details and the price summary in a single column. It shows the hold deadline with its timezone, and it tells the agent plainly that nothing can be changed after booking. #### The turn - **I believed** – An itinerary is an array of days with times on them. - **What happened** – Multi-day stops broke the moment a trip crossed timezones. Worse, moving Day 3 to Day 2 quietly shifted every booked activity underneath it. It showed up first on hotel check-in and check-out, which sit on the first and last card of each day. The agents caught it before any traveller did, but only just. - **What changed** – I rebuilt it on relative offsets, with an explicit timezone for every stop. The founder didn't want any kind of friction in a drag-and-drop, and I didn't get my way on it. So we drew the line by stakes rather than splitting the difference. The cards that can’t move without cascading, the anchored multi-day ones, aren’t draggable at all. Everything safe still drags freely. The lock isn’t arbitrary: a card is immovable exactly when moving it would rewrite the stops around it. - **I believed** – A point of interest is a Place ID. Cache the details from Google, render the pins, move on. - **What happened** – We ran into two problems at the same time. Google's terms don't let you keep most place data for long. And the things agents actually sell aren't in Google at all – which entrance to use, which guide to book, who will open up at 6am if you ask. Anyone can look a place up on Google, so what makes an agent's itinerary worth paying for is the notes they add to it. - **What changed** – We ended up with a mix of both. A thin layer of cached Google data, keyed by place ID, sits under a proper point-of-interest record that agents write themselves. Nobody had planned for it, so we made it a target for the next sprint, and we built it. - **I believed** – More generated code meant moving faster. - **What happened** – Reviewing two thousand lines of a map layer I hadn't written was slower than writing four hundred myself. At late night I couldn't find a clustering bug in it, because I'd never worked out in my own head how it fit together. - **What changed** – I started limiting generation to one module at a time, against a shared types package. It looked slower on paper, but we shipped sooner. #### Decisions – The builds worth naming These are the parts I built that agents spend most of their day in. Building them set the pattern for everything I built after. **Multi-step quotation system** *Agents can open the client's PDF at any step, and the one that gets sent is generated right then, so it's never out of date.* Agents used to type everything into a document, copying customer details out of old emails and double-checking phone numbers in group chats. I built a flow that takes them through it step by step. It pulls in linked contacts, fills in the tour details for them, and lets them open a PDF preview whenever they want. The PDF the customer receives is only generated at the last step, so it's always the current version. Every version is tracked as well, which matters once an agent has several quotations on the go. **Drag-and-drop itinerary builder** *Travellers plan their trip from a list their agent has put together.* I built the builder so agents can drag attractions, restaurants and hotels onto each day to make a master itinerary, and travellers plan from that list. When anyone moves something around, the distances between stops update straight away. **Accommodation searching** *When an agent searches a hotel, they can see at a glance which of their selected POI sit near each option straight.* The first version leaned on the API, and its results didn’t always match what the real-time search had shown which made hotel search slow and sometimes misleading. I fixed it so there’s one consistent set of results the whole way through. Then I focused on what an agent needs first: which of their selected points of interest sit near each hotel. I surfaced that proximity against every option, from our own data, so it’s visible without digging. I also tuned the map layer against the real-time search running behind it, keeping the two in step as results come in. **Task & supplier tracking** *Every itinerary makes its own task list, and an update in one place shows up everywhere.* I built it so each item on an itinerary, whether it's a hotel, a meal or a transfer, turns into a task, so agents can see what still needs sorting out without keeping it all in their heads. They assign suppliers to those tasks, like the tour guide, the coach driver, or whoever is providing the gift for a special occasion. Costs are logged against each one, and agents can see what's been paid and what's still outstanding in one place, instead of across a pile of spreadsheets. **Points of interest library** *Both apps pull from the same library, so a place only needs adding once.* One place for every point of interest, each with its own details, images and tags. Agents can browse the library and pull places straight into an itinerary while they're building it, without switching to another tool. #### Impact - **87%** faster quotations – two hours down to fifteen minutes, the founder's own estimate as a working travel agent. - Everything in one place, so nobody digs through email, fax and group chats for the latest version anymore. - **1 → 6** modules, covering the full workflow from itinerary planning to invoicing. - Both the B2B and B2C products shipped to production, and real agents and travellers use them. #### Reflection There was a document open, customer details being copied out of an old email, and the phone number being checked again by phone, email or group chat. Then I watched the same quotation go through the new flow in about fifteen minutes. Seeing both taught me a lot about what an agent needs to see at each step, and what can wait. I worked directly with the founder, a product manager and a backend engineer, deciding together what to build next and shipping every two weeks. Building for two audiences at once meant making the big architecture decisions early, and I've kept doing that since. **Differently, today** – Since this project I pay a lot more attention to booking flows when I'm planning my own trips. I notice where the important details are, whether a hold deadline says which timezone it's in, and what I won't be able to change once I've booked. I bring all of that into every booking or checkout flow I work on now. ### The Prompt Engineers Case study: https://junlow.com/work/the-prompt-engineers AI consultancy Webflow build **I designed and built the first website for an AI consultancy and had it live in a week. After launch, the team asked for more. In 2025 I extended the site with a book, playbooks and services, and built its redesign.** Client: The Prompt Engineers · Year: 2024 – present · Role: Designer and developer · Platforms: Marketing site and automation workflow · Stack: Figma · Webflow · Make.com · Live: https://www.the-prompt-engineers.ai/ #### The brief The Prompt Engineers is an AI consultancy. The team had a Wix template as a starting point and wanted their first website built in Webflow instead. They needed a company site that presented their services and the business, with a sleek, light, modern feel and AI imagery throughout. I worked directly with the founders and handled both the design and the Webflow development. - **Credible to B2B buyers** – Most buyers would meet the consultancy through its website first. It had to look trustworthy, load fast and say clearly what the team does. - **One week, no handoffs** – I did the design and the build myself, so the founders' feedback went straight into the site. I had it live within a week of kick-off. #### Process – Sitemap, wireframes and a style guide, worked out in Figma. I worked out the sitemap, wireframes and style guide in Figma myself. The founders and their team left feedback as comments on the file, and I worked through it as it came in. I also wrote the UX copy across the site. **Wireframes – Low-fidelity wireframes, v1 to v5** The wireframes were grey boxes with no colour or real type, so the feedback was all about structure: what goes first, the order of the story on each page, and which page a section belongs on. Versions 1 and 2 got the launch site ready to build. Versions 3 to 5 came later, as the site grew, and the Services page changed several times along the way. **Colour & type – Four colour rounds, one typeface** I showed four colour directions and the founders picked one: a dark ink, an accent, a tinted background and white. I used one typeface, Satoshi, for everything, so the hierarchy comes from weight and size. - Dark – `#0A2540` (Headings, footer, dark bands) - Accent – `#635BFF` (Links, buttons, active states) - Background – `#F7F9FC` (Alternating section bands) - White – `#FFFFFF` (Page canvas and cards) **Sitemap – Eight static pages at launch** I drew the sitemap section by section. My first version had every section I could offer on each page, and the founders cut it down from there. The diagram shows the eight pages that went live, minus the navbar and footer. They were all simple static pages. The blog, more services pages and the FAQ came after launch. - Home - Sections: Hero, Feature, Benefits, CTA, Client logo list - Services - Sections: Header, Services, Feature cards, CTA - Clients - Sections: Header, Client carousel, Logo list, Testimonials, CTA - Resources (Assessment types) - Sections: Header, Featured resources, Resource cards, CTA - About - Sections: Header, Team, CTA - Contact - Sections: Header, Contact email, Location - Terms - Sections: Legal body - Privacy - Sections: Legal body #### The turn - **I believed** – That each stage would be signed off before I started the next. I thought a week was enough because the plan was a straight line. - **What happened** – Feedback came in on all three stages at once. We picked a colour, then someone asked “can we consider non-blue?”, and we ended up back on the original blue. Sections moved between pages while I was halfway through the wireframes, and where the services should go was still open near the end. A block for around twenty client logos turned up as a comment on a wireframe. The structure of the site was really being decided in the Figma comments while I was building the pages. - **What changed** – I showed the founders every section each page could have and let them cut, instead of proposing something lean and adding to it later. I also held the build to a Lighthouse performance score of 100. Nobody asked for that – it was my own standard, and I didn't mention it until launch. Both meant more work for me inside the same week. #### Decisions – Sitemap to live, then built on The first version went live in a week. About a month later came a second project with more pages and features. I also built the AI self-assessments – their pages on the site and the automation behind them – and nine months after launch I extended the site and built its redesign. **Live in a week** *Webflow was the client's requirement, and I made a Lighthouse performance score of 100 my own bar for launch.* I built the first version in Webflow as eight static pages – home, services, clients, resources, about, contact, terms and privacy – and had it live within a week of kick-off. It scored 100 for performance on Lighthouse, with a Largest Contentful Paint of 0.6 seconds. **More pages and features** *Once the founders saw the site live, they knew what else it needed and wanted to extend it properly, so we scoped a second project.* It started about a month after launch and ran as two one-week milestones. I added a CMS-driven blog, more services pages, an FAQ, and contact and newsletter forms. I also added an AI-generated hero video for the homepage and animation-rich landing pages. I connected the AI self-assessments to Google Sheets so the team could chart the results. The project finished with a full review of every page and link. **AI self-assessments, built and automated** *I used Make.com instead of custom code to match the Webflow setup, so the team can change it themselves.* TPE offers clients a set of AI self-assessments on how their business uses AI. I built their pages on the site and automated what happens after someone submits one. A Make.com scenario sends the visitor their result by email. Only after that email goes out is the contact created in HubSpot, with the assessment attached, so when the team picks up the lead they already know what to talk about. HubSpot only hears about people who actually got their result. *The scenario, in run order* 1. Assessment submitted (TPE site) – A visitor completes one of the assessments and submits it. 2. Scenario triggered (Make.com) – The submission arrives in Make as the trigger, with the answers on it. 3. Result assembled (Make.com) – The answers are mapped into the result that goes back to the visitor. 4. Results email sent (Email) – The result goes to the address given on the form. 5. Contact created (HubSpot) – Created after the email has gone, with the assessment on the record. **2025 – an extension build and a fresh look** *I extended the site with new collections and built the redesign to the TPE team's direction.* I was still working with the team on the assessments when, nine months after launch, the founder came to me about a redesign. The business had more to sell – a book, a playbook library and productised services – and wanted a fresh look, so I ran both jobs together. For the extension, I added playbooks and services collections next to the blog, taking the CMS from one collection to three. New ideas for the CMS kept coming as their marketing plans took shape, and the team now adds playbooks and services from the Webflow Editor, the same way they add blog posts. For the redesign, a marketing lead had joined and reworked the visual direction across the business. I built to it, rebuilding home, about and contact to their design and keeping the product pages on their 2024 structure. I was on board with the new direction, though I did suggest one change for the hero: keep the video and add a static image so the message still gets across. #### Impact - **One week** from sitemap to live, with one person on design and build. - Lighthouse performance 100 on the first version, with a Largest Contentful Paint of 0.6 seconds. - The AI self-assessments run on their own, from the visitor's result email to the lead landing in HubSpot. - Two years on I'm still working on the site, on a retainer for upkeep and SEO. In September 2026 the live site scores 100 for SEO on Lighthouse, and 93 or above on the other three. #### Reflection This project showed me how much it helps when one person does both the design and the build. There was no handover to wait for, and on a one-week job that wait can eat most of the schedule. The founders also had one person to talk to about everything, from the sitemap to the last fix before launch. In 2024 I worked directly with the founders, and feedback came in as comments on my Figma file. In 2025 I worked with the founder and the marketing lead, remotely and mostly async. After each meeting I broke the work into tasks in Notion so everyone could see where things stood. I've been on a retainer since, looking after upkeep and SEO. **Differently, today** – Feedback came in as comments, so nothing was ever clearly settled, and notes on the wireframes reopened a sitemap I thought was done. Next time I'd send the founders a short written summary at the end of each stage: what we decided, and what comes next. They'd always know where the site stood, and a new idea late in a stage could get its own time in the plan. ### Dustykid AI Case study: https://junlow.com/work/dustykid-ai EdTech emotional wellbeing chatbot **Dustykid is a Hong Kong wellness brand with over a million followers. I led the frontend and stepped in on UI and UX, taking each design from v0 to live.** Client: Dustykid AI · Year: 2025 – 2026 · Role: Lead frontend developer · Platforms: Student web app and school admin platform · Stack: React · Next.js · TypeScript · OpenAI · Live: https://uk.dustykid.com/pages/ai-innovations #### The brief Dustykid AI partnered with HKUST to give students a place to say the thing they can't say out loud, and schools the tools to support them. - **A space students trust** – Students who are struggling rarely say so first. I knew that before the project started. I used to teach piano, and one of my students was a Hong Kong kid, hardworking and shy, who opened up less than most kids I taught. I kept that student in mind through the build: the app had to feel private and unhurried before anything else, so a student would keep typing. - **Three languages, one voice** – English, Traditional Chinese and Simplified Chinese, each with its own typography and copy rhythm. I built the languages into the components from the start instead of translating the screens afterwards. #### The turn - **I believed** – A designer would hand me the finished product and I would build it. Design was someone else's job and code was mine. - **What happened** – The team had a graphic designer rather than a product designer, so what I received was the brand and a still frame for each page. Everything that only shows up once someone actually uses the app – the mobile layouts, the confirm dialogs, the edit and delete views – was mine to work out. I worked each one through with the stakeholders as I went, proposing on a phone screen what it should do, and several of them went in the way I proposed them. - **What changed** – I took on the UI and UX for the whole interface, alongside the frontend. I built the missing pieces on shadcn primitives and reskinned them to the brand, so the designer's look held and the code stayed something a team could maintain after me. I wasn't hired for that part, and it has been part of how I work ever since. #### Decisions – The interface was the part I owned: a student app and a school platform, in three languages, on phones and on desktops. **AI chat** The screen a student actually lives in. I built it to stay calm and unhurried whatever hour it gets opened, with settings so a student can make the space their own. **School management platform** The staff side. One platform, and every role from administrator down to student sees a different product inside it. I built the role-based views, class and people management and the school dashboard, and the access layer that decides what each role can reach. **Editor gallery platform** Also teacher-facing, for the same people as the platform above. Educators choose the illustrations a student sees, in all three languages, and I built the tool they manage them with. #### Impact - Piloted in schools and organisations, then publicly launched in October 2025. - Winner of the Global EdTech Startup Awards, representing Hong Kong at the 2026 world finals. - MVP1 shipped on time, in three languages, on both surfaces. #### Reflection Building for mental health taught me to think beyond “does it work”. Small details matter: how a message is worded, what a teacher can see and what stays private. I'm slower now to ship a UI decision without asking who it actually touches. I worked directly with the stakeholders, backend engineers and the illustration designer through the whole build, including UI and UX. I'm quicker now to ask who reads this screen, and when. **Differently, today** – I'd default to Traditional Chinese, and stop leaving language in settings with no onboarding. We shipped three languages and I still gave Hong Kong students an English screen to open. Getting the language right on the first screen matters more than having all three. ## Also worked on | Project | Kind | Year | Made at | What it did | Link | | --- | --- | --- | --- | --- | --- | | Morea Design | Brand identity | 2026 | – | Atelier for bespoke cabinetry and joinery. | [morea-design.com](https://morea-design.com/) | | EquitiPoint | Brand identity | 2026 | – | Exit readiness for business owners. | | | Tripleshot | Logo | 2025 | – | iPad point of sale for independent restaurants. | [tripleshot.com](https://www.tripleshot.com/) | | SIC | Web app | 2021 – 2023 | Helvetic Streams | Livestream platform for Lucerne Festival, Schindler, St. Galler Kantonalbank, Abraxas, etc. | | | Shark Channel | Web app | 2022 | Helvetic Streams | Web app and CMS where startups pitch to investors on video. | | | Design system | Design system | 2021 | Helvetic Streams | In-house component library behind SIC and the other products, including its video and media components. | | | Corndale | Website | 2020 | agency client | WordPress website for a wine merchant in Singapore. | | | Asia Pacific Boating | Website | 2020 | agency client | WordPress website for a magazine in Hong Kong. | | | For the Love of Laundry | Website | 2020 | agency client | WordPress website for a laundry service in Singapore. | | | Design system | Design system | 2020 | Piktochart | In-house component library behind a product used by 34 million+ people worldwide. | | ## People I've worked with > Jun is incredibly easy to work with. Over the past few years, what I've valued most is how thoughtful she is and how much she cares about getting the product details right. She doesn't just build to spec, she'll flag UI/UX suggestions that catch things we'd missed, and if she spots a better approach, she'll talk it through rather than just closing the ticket. > > She thinks about the whole product and the user experience, not just her own scope. That makes scoping and implementation chats quick, and the whole collaboration a lot smoother. > > — Ryan Zheng, Full-stack engineer, B-Travels · Dustykid AI > It looks and feels great. … Very well done > > Love the way Jun has set up the web site! … the work Jun did listing all the URL's chapter was really first class. > > — David Cheesman, CEO, The Prompt Engineers > Jun … worked with us on our SaaS project for just under two years in a fully remote setup. She communicates well, is easy to work with, and is generally proactive in clarifying requirements and following through on tasks. As an engineer rather than a designer by role, she stepped in to support design ownership when needed while being receptive to feedback and consistently focused on delivering practical and reliable solutions. > > — Zhan Hao Lee, Founder, B-Travels > Great working with Jun! > > — Charlie Cheesman, CTO, The Prompt Engineers > I worked with Jun for 1.5 years, and it was a really good experience. Jun always did excellent work, no matter how hard the task. I was impressed by her skills and professionalism. > > In a team, Jun is a big help. She has lots of experience and makes the work atmosphere positive and productive. … She cares about doing good work and deals with problems calmly. > > — Severin Buser, Business analyst, Helvetic Streams ## Questions ### What is Jun Low Studio? An independent studio founded by Jun Low, a product engineer working across design and full-stack. I help founders and product teams design and build web products, from the first idea through to launch and what comes after it. ### What's it like working with you? I'll be a thinking partner as well as the person building it. I come with a point of view, I'll question an assumption when something doesn't add up, and I'll help sharpen the idea before we build it, so we catch the tempting wrong turns early and make the calls together. You work directly with me the whole way through, with no account manager in between. You'll see the work early, usually as a working prototype, and I send regular updates on Slack, email or a short Loom so feedback keeps moving. ### Can I have a minute before continuing? Yes. Breathe in, breathe out. ### Do you work with teams in other countries? Yes, I take on projects worldwide. Updates come through Slack, email or a short Loom, which works across time zones, and we find a call time that suits both of us. ### How long does a project take? Websites and Webflow builds usually take 1 to 3 weeks. An MVP or a first version of a product usually takes 3 to 8 weeks, depending on scope, and longer engagements have run to two years. You'll have a clear timeline before we start, and I'm still around after launch if you need support. ### Coffee or tea? Depends on the time. Tea any time of day, coffee only in the daytime. I wouldn't have coffee after 8pm though, or I won't sleep. ### How do you decide what to build? I start with the problem behind the feature request. You know your business best, but the first solution that comes to mind isn't always the right one, so I ask the awkward why questions early. ### And once we've agreed on the problem? I design and build it myself, so what you approve is what ships, and nothing gets lost between a design file and the code. It moves quickly, and I can explain every decision in it. ### We already have designs in Figma. Can you build from them? Yes. We go through the file together and scope it first, so we agree on what's being built before I start. If only some pages are designed, that's fine too – scoping is where we decide how the rest gets done. ### What is the secret of creativity? Curiosity + Coffee ### Another developer built our site or app. Can you take it over? Usually, yes. It depends on the stack and how it was built. Before I agree to anything, I look through the code, the design system if there is one, and how the site gets deployed. Then I tell you what I'd keep, what I'd fix first and what it would take. Sometimes starting again costs less than fixing what's there, and if that's the case I'll say so. ### What do I actually get at launch? A working product your team can run and build on, with the code, files and accounts in your name from the start. ### Do you offer support after launch? Yes. Most clients keep me on for fixes, new pages and features once the product is live. Whether you do is up to you. ### Are you open to receiving files with unnamed layers? Absolutely, as long as the file itself is structured in some way. ### Webflow or custom code? It depends on what you'll be changing after launch. If it's mostly copy, pages and campaigns, Webflow. If it's logic, data and how the product behaves, custom code. I work in both, so my recommendation isn't tied to one tool. ### Will my team be able to update the site without you? Yes. The handover depends on what your team needs and prefers. Usually it's a walkthrough, a short Loom and written notes to come back to later. ### Do you offer simple one-time consultations? Yes. A single session works well for a second opinion on a product idea, a design review, or deciding between Webflow and custom code. If it needs more than talking, I can also build a small prototype to test the idea. Email me at hey@junlow.com with what you'd like to look at. ### How do you price your work? One flat rate for the project, agreed before we start. You email me, we have a discovery call, and you get a fixed quote and scope within a week. The price doesn't change unless the scope does, and if it does, we agree that together first. ### Do you accept all projects? No. I only take on a few projects at a time so each one gets proper attention. I say yes when I'm confident I can help, and when the project is worth more to you than what you'd pay me. ### Why are you so keen on helping founders? Every founder's business is a world of its own, and each one teaches me new skills and new ways to think about business problems. A new project is motivating too. You get the freedom to build things properly from the start. I'm happiest on something ambitious that needs design, engineering and product thinking all at once. ### How do you use AI in your workflow? To go faster on drafts, boilerplate and early exploration. I still make the judgment calls, the design decisions and the final code review myself, and I check that the result doesn't feel generic. ## Contact [hey@junlow.com](mailto:hey@junlow.com) – replies within one working day. Also on [X](https://x.com/_junlow) and [LinkedIn](https://www.linkedin.com/in/jun-low).