# Matthew Blode — Full corpus > Melbourne-based product leader and engineer on the AI team at Linktree, co-founder of Fingertip and VenueSafe, Forbes 30 Under 30. This document is the complete public content of matthewblode.com in one file, intended for long-context agent ingestion. --- # About Matthew Blode > Melbourne-based product leader and engineer on the AI team at Linktree, co-founder of Fingertip and VenueSafe, Forbes 30 Under 30. AI team at Linktree. Co-founder of Fingertip and VenueSafe. Forbes 30 Under 30. Melbourne-based product leader and engineer. ## Quick facts - **6 months** — VenueSafe went from idea to acquisition by me&u in six months. - **15M+ users** — Helped scale me&u's mobile ordering platform to 15M+ users globally after VenueSafe was acquired. - **100+ countries** — Fingertip supported small businesses globally before its acquisition by Linktree. - **Zero to one** — My specialty is building the early product, engineering, and AI systems that get new ventures moving. Two startups, two exits. I am a Melbourne-based product leader and engineer focused on going zero to one. I co-founded VenueSafe during COVID and took it from idea to acquisition by me&u (formerly Mr Yum) in six months. I stayed on for two years, helped scale me&u to 15M+ users globally, and supported the US expansion from Austin, Texas. After that I co-founded Fingertip with Olly Hoffman and the founders of Catch and Menulog. We scaled to tens of thousands of small businesses across 100+ countries before Fingertip was acquired by Linktree. Today I'm on the AI team at Linktree, building AI-powered experiences for creators and small businesses. ## Experience ### 2025 - Present — Linktree *AI Team* · [Linktree](https://linktr.ee) Building AI-powered experiences for creators on the AI team. - Building AI agents and product experiences for 70M+ Linktree users. ### 2023 - 2025 — Fingertip *Co-founder & CTO* · [Fingertip](https://fingertip.com) Co-founded Fingertip with Olly Hoffman, Gabby Leibovich, and Hezi Leibovich to help small businesses run more of their business online. - Scaled to tens of thousands of small businesses across 100+ countries. - Built product and engineering across website creation, bookings, payments, and invoicing. - Fingertip was acquired by Linktree in 2025. ### 2022 - 2023 — me&u *Senior Software Engineer* · [me&u](https://www.meandu.com/) Joined me&u (formerly Mr Yum) after the VenueSafe acquisition and helped scale the platform to 15M+ users globally. - Helped scale me&u's platform to 15M+ users. - Moved to Austin, Texas to support US market expansion. ### 2020 - 2021 — VenueSafe *Co-founder & CTO* · [VenueSafe](https://venuesafe.netlify.app/) Built a COVID contact tracing platform for Australian venues and hospitality businesses. - Went from idea to acquisition by me&u in six months. - Built and shipped the product during the peak urgency of COVID operations. ### 2019 - 2020 — Light Creative *Front-end Web Developer* · [Light Creative](https://www.lightcreative.com.au) Built React frontends for enterprise clients across e-commerce and corporate platforms. - Delivered fast, responsive interfaces for high-traffic web applications. ### 2016 - 2019 — S. Group *Web Developer* · [S. Group](http://www.sgroup.com.au) Built websites and web applications for corporate clients across marketing and internal tools. - Shipped projects across multiple concurrent client engagements. ## Community & advisory ### Startmate *Accelerator Mentor* · [Startmate](https://www.startmate.com.au) Mentoring startups in Australia's leading accelerator and supporting the next generation of founders. ### OpenAI *Codex Ambassador* · [OpenAI](https://openai.com) Supporting local developer communities through community sessions, feedback, and hands-on learnings. ### Airtree *Explorer* · [Airtree](https://www.airtree.vc) Part of Airtree's operator community connecting experienced builders with early-stage founders. ### VCMC *Co-founder* · [VCMC](https://vcmc.ai) Co-founded the Vibe Coding Micro Community with Luca Bonelli and Ryan Hendler to bring AI-native builders together. ## FAQ ### What does Matthew Blode do? Matthew is on the AI team at Linktree, working across product and frontend to build AI-powered creator experiences. ### What has Matthew Blode built? He co-founded VenueSafe during COVID and took it from idea to acquisition by me&u in six months. He then helped scale me&u to 15M+ users globally. After that, he co-founded Fingertip with the founders of Catch and Menulog, scaling to tens of thousands of small businesses across 100+ countries before Fingertip was acquired by Linktree. ### Is Matthew Blode available for speaking or mentoring? Yes. Matthew speaks at meetups, panels, and builder events on topics like zero-to-one product building, AI-assisted engineering, and shipping fast. He also mentors through Startmate and co-founded VCMC, a builder community in Melbourne. ### Where can I find Matthew Blode online? You can find Matthew on LinkedIn, GitHub, X, Raycast, CodePen, and on this site where he publishes his projects and resume. - [LinkedIn](https://www.linkedin.com/in/matthewblode/) - [GitHub](https://github.com/mblode) - [X](https://x.com/mattblode) - [Raycast](https://www.raycast.com/mblode) - [CodePen](https://codepen.io/mblode) - [projects](https://matthewblode.com/all) - [resume](https://matthewblode.com/resume.pdf) --- # Speaking & talks > Talks and sessions by Matthew Blode on zero-to-one product building, AI-assisted engineering, and shipping fast. ## Topics - Zero-to-one product building - AI-assisted engineering - Product taste and craft - Startup execution speed - Developer tooling - Community-led learning ## Talks ### You can sense carelessness *Next.js Melbourne meetup* · February 2026 · BuildPass, Melbourne Users notice when you cut corners — even if they never see the code. This talk unpacks why product taste matters and how the details you think are invisible still shape how a product feels. - Explored why the details users never consciously notice still shape how a product feels. - Presented to ~50 developers and product builders at the Next.js Melbourne meetup. - Slide deck shared publicly after the event. - [Slides / link](https://nextjs-preso.blode.co) - [Event page](https://luma.com/t5jle3hj) ### Ship fast or die *Startmate mentor session* · January 2026 · Melbourne Built for the latest Startmate cohort. A working session on Claude Code workflows, the real sources of drag in early-stage teams, and when slowing down is the fastest move. - Delivered as part of a new mentorship with Startmate. - Covered Claude Code, velocity killers, and when to slow down to speed up. - Slide deck published publicly after the session. - [Slides / link](https://app.chroniclehq.com/share/8460b971-930c-4f97-b0bb-7f6e1b683693/561d15f0-33df-446a-b89b-b36438ad31fb/intro) ### You don't have to make AI slop *Melbourne builder meetup* · January 2026 · Melbourne AI tools make it easy to ship faster. They also make it easy to ship worse. This talk covers the specific habits that keep the quality bar high when you’re building with AI every day. - Explored the gap between using AI tools and producing AI-quality output. - Shared specific habits for keeping the bar high when shipping with AI. - Slides published publicly after the session. - [Slides / link](https://app.chroniclehq.com/share/dbb62bb8-d1bb-4ee4-b24e-77c900a2ca31/0ac5a633-f636-410a-85b0-ba02540e3e94/intro) ### Building at different scales *The Outlook panel* · July 2025 · Melbourne What changes when you go from a three-person startup to Atlassian scale? A panel with Tarra van Amerongen and Trudi Boatwright on how execution methods shift while the core mission stays constant. - Joined Tarra van Amerongen and Trudi Boatwright for the panel. - Explored how execution methods shift with company scale while the core mission stays constant. - [Video](https://www.linkedin.com/posts/matthewblode_want-to-know-what-customers-want-tarra-activity-7363744098853273601-2l43?utm_source=share&utm_medium=member_ios&rcm=ACoAABPvOgMBrrRnmj7eHPWPIcoGwwpj2HiQRKg) --- # Press & mentions > Public features, awards, and third-party mentions of Matthew Blode. ## Recognition - [Meet the Aussies on the 2025 Forbes 30 Under 30 Asia list](https://www.forbes.com.au/news/30-under-30/meet-the-aussies-on-the-2025-forbes-30-under-30-asia-list/) — *Forbes Australia*. Recognition tied to the 2025 Forbes 30 Under 30 Asia list. - [Matthew Blode](https://pauseawards.com/winners/matthew-blode/) — *Pause Awards*. Public winner profile describing Matthew as CTO and co-founder of Fingertip. ## Features - [Fingertip](https://www.forbes.com/profile/fingertip/) — *Forbes*. Forbes company profile for Fingertip, describing the business co-founded by Matthew Blode and Oliver Hoffman. - [Matthew Blode - One Page Website Award](https://onepagelove.com/matthew-blode) — *One Page Love*. Feature page for Matthew Blode's one-page portfolio site. --- # The Blode Stack > Software Matthew Blode has built — design foundations, developer tools, and platform tools. ## 1. Design foundations A typeface, icon set, and component library that work together. Keeps your UI consistent out of the box. - [Glide](https://glide.blode.co) — Variable font family crafted for UI. · [GitHub](https://github.com/mblode/glide) - [Blode Icons](https://icons.blode.co) — 3,000+ beautiful icons. Lucide compatible. · [GitHub](https://github.com/mblode/blode-icons) - [Blode UI](https://ui.blode.co) — The shadcn/ui registry with good taste. · [GitHub](https://github.com/mblode/blode-ui) - [Style Capture](https://style-capture.blode.co) — Point at any UI. Let your agent rebuild it. · [GitHub](https://github.com/mblode/style-capture) ## 2. Developer tools Tools and agents for coding, converting content, and testing changes. - [Agent Skills](https://github.com/mblode/agent-skills) — All I know about building products, turned into agent skills. - [AllMD](https://allmd.blode.co) — Turn the whole universe into markdown. · [GitHub](https://github.com/mblode/allmd) - [Commandment](https://commandment.blode.co) — Voice to text, instantly. Just press a shortcut and speak. BYO OpenAI API key. · [GitHub](https://github.com/mblode/commandment) - [DiffHub](https://diffhub.blode.co) — Local diff viewer for cmux. · [GitHub](https://github.com/mblode/diffhub) - [Rubber Duck](https://rubber-duck.blode.co) — Voice coding agent. Talk through code to understand the problem. · [GitHub](https://github.com/mblode/rubber-duck) ## 3. Platform tools Shared infrastructure so you don't have to build it yourself. - [Blode.md](https://blode.md) — Documentation platform. Write markdown, get a published docs site. · [GitHub](https://github.com/mblode/blodemd) - [Strata Sync](https://stratasync.dev) — Apps that just work. Inspired by Linear's sync engine. Open-source. Total tools: 11. --- # All projects > A reverse-chronological list of every project Matthew Blode has built — products, open source, side projects, client work, and presentations. ## 2026 - [Agent Skills](https://github.com/mblode/agent-skills) — *Open source*. A minimal set of agent skills for high-quality UI and frontend work - [AllMD](https://allmd.blode.co) — *Open source*. Convert web pages, YouTube videos, PDFs, Google Docs, and more to markdown - [ASCII](https://ascii.blode.co) — *Side project*. ASCII art generator - [Blode Icons](https://icons.blode.co) — *Open source*. Icon library for design engineers - [Blode UI](https://ui.blode.co) — *Open source*. UI component library for design engineers - [Blode.md](https://blode.md) — *Open source*. Documentation framework for the whole stack - [DiffHub](https://github.com/mblode/diffhub) — *Open source*. Local git diff viewer - [Done Bear](https://donebear.com) — *Product*. Calm, local-first task manager for focused people and teams - [HackerTok](https://hackertok.blode.co) — *Side project*. TikTok-style recommendation system for Hacker News - [Reel](https://reel.blode.co) — *Open source*. Turn browser feedback recordings into structured artifacts for coding agents - [Rubber Duck](https://github.com/mblode/rubber-duck) — *Open source*. Open-source voice coding companion for macOS - [Shareful.ai](https://shareful.ai) — *Product*. Share and discover coding solutions - [Ship fast or die](https://app.chroniclehq.com/share/8460b971-930c-4f97-b0bb-7f6e1b683693/561d15f0-33df-446a-b89b-b36438ad31fb/intro) — *Presentation*. If AI writes the code, how come you're still moving slowly? - [Spotlight Testing](https://github.com/mblode/spotlight-testing) — *Open source*. See your code changes in a running dev server instantly - [Strata Sync](https://stratasync.dev) — *Open source*. Sync that works offline - [Style Capture](https://style-capture.blode.co) — *Side project*. Capture CSS from any website element and convert to Tailwind classes - [You can sense carelessness](https://nextjs-preso.blode.co) — *Presentation*. Behind-the-scenes of Fingertip's product engineering - [You don't have to make AI slop](https://app.chroniclehq.com/share/dbb62bb8-d1bb-4ee4-b24e-77c900a2ca31/0ac5a633-f636-410a-85b0-ba02540e3e94/intro) — *Presentation*. Building quality products with AI tools ## 2025 - [Beautiful QR Code](https://beautiful-qr-code.blode.co) — *Side project*. Generate beautiful, customizable QR codes in JavaScript - [Blue Noise Dither](https://blue-noise.blode.co) — *Side project*. Blue noise dithering visualizer - [Brighter](https://github.com/mblode/brighter) — *Open source*. macOS brightness utility - [Claude Code Search](https://www.npmjs.com/package/claude-code-search) — *Open source*. Search through your Claude Code conversation history - [Colour Mixer](https://color-mixer.blode.co) — *Side project*. Pigment-based colour mixing playground - [Days Off Git](https://days-off-git.blode.co) — *Side project*. Inspect and visualize GitHub commit patterns - [Dither Asteroids](https://dither.blode.co) — *Side project*. Asteroids game with blue noise dithering - [DnD Grid](https://dnd-grid.com) — *Open source*. Draggable and resizable grid layout for React - [Linktree](https://linktr.ee) — *Product*. Link-in-bio platform for creators - [Matt's Experiments](https://experiments.blode.co) — *Side project*. A collection of UI experiments - [Moon Simulator](https://moon.blode.co) — *Side project*. Interactive moon phase simulator - [New Portfolio Site](https://matthewblode.com) — *Side project*. Personal portfolio redesign - [Nicebreak](https://nicebreak.blode.co) — *Product*. AI ice breakers for Google Meet - [QRUX](https://qrux.app) — *Product*. Create and manage QR codes - [React Vello](https://react-vello.blode.co) — *Open source*. Blazing fast React renderer powered by Vello - [Resumai](https://resumai.studio) — *Product*. AI-powered resume editor - [VCMC](https://vcmc.ai) — *Product*. Vibe Coding Micro Community ## 2024 - [Raycast CyberChef](https://github.com/mblode/raycast-cyberchef) — *Open source*. CyberChef operations in Raycast - [Touchwood Cabinetry](https://touchwood.com.au) — *Client*. Award-winning custom kitchens and cabinetry ## 2023 - [Blue Noise TypeScript](https://github.com/mblode/blue-noise-typescript) — *Open source*. Blue noise dithering algorithm in TypeScript - [Fingertip.com](https://fingertip.com) — *Exit*. AI-powered platform helping SMBs run their entire business ## 2022 - [Raycast Google Search](https://github.com/mblode/raycast-google-search) — *Open source*. Google search extension for Raycast - [Raycast Quick Event](https://github.com/mblode/raycast-quick-event) — *Open source*. Create calendar events with natural language in Raycast ## 2021 - [Blue Noise Rust](https://github.com/mblode/blue-noise-rust) — *Open source*. Black and white image dithering using blue noise - [me&u](https://meandu.com) — *Product*. Mobile ordering platform for hospitality ## 2020 - [Egg Freezing](https://eggfreezing.org.au) — *Client*. Fertility preservation decision-making resource - [Fertility Choices](https://fertilitychoices.com.au) — *Client*. Fertility preservation guidance for cancer patients - [Light Creative](https://lightcreative.com.au) — *Client*. Strategic brand storytelling and design agency - [PANDA](https://www.panda.org.au) — *Client*. Mental health support for expecting and new parents - [VenueSafe](https://venuesafe.netlify.app/) — *Exit*. COVID contact tracing platform serving 1M+ Australians ## 2019 - [Bishops](https://bishops.com.au) — *Client*. Launceston barristers and solicitors - [Blue Derby](https://www.ridebluederby.com.au) — *Client*. Tasmania's mountain bike trails destination - [Change Overnight](https://changeovernight.co) — *Client*. Charitable hotel in Launceston, Tasmania - [Crunchlab](http://crunchlab.com.au) — *Client*. Cloud-based accounting automation for businesses - [Freedom Centre](https://freedomcenter.in) — *Client*. Education and job skills programs in India - [Hacker News Client](https://hn.matthewblode.com) — *Side project*. Hacker News web app built with React and Redux - [Michael Christofas](https://michaelchristofas.com.au) — *Design*. Corporate, events, and portraiture photographer - [Nectaar](https://nectaar.com.au) — *Client*. Melbourne residential and commercial interior design - [OPERA](https://opera.eclc.org.au) — *Client*. Community program combating ageism - [Plastex](https://www.plastexmatting.com) — *Client*. Industrial and commercial matting manufacturer - [Rae & Partners](https://raepartners.com.au) — *Client*. Tasmanian full-service law firm - [TRAM](https://tram.org.au) — *Client*. University of Melbourne research impact accelerator - [VSCode Pretty Formatter](https://marketplace.visualstudio.com/items?itemName=mblode.pretty-formatter) — *Open source*. VS Code extension to format files using Pretty Diff - [VSCode Zotero](https://marketplace.visualstudio.com/items?itemName=mblode.zotero) — *Open source*. Zotero Better BibTeX citations for VS Code ## 2018 - [Anstie Constructions](https://www.anstieconstructions.com.au) — *Client*. Tasmanian commercial and institutional builder - [Arise Acres](https://web.archive.org/web/20250416043844/https://ariseacres.com.au/) — *Client*. Property development website - [Creative Brimbank](https://creativebrimbank.com.au) — *Client*. Arts and cultural programs for Brimbank community - [Deus Ex Machina](https://shop.au.deuscustoms.com) — *Client*. Motorcycle and surf culture lifestyle brand - [Heathdale Christian College](https://www.heathdale.vic.edu.au) — *Client*. Christian school from Kinder to Year 12 - [IPD Consulting](https://ipdconsulting.com.au) — *Client*. Tasmanian engineering and project management consulting - [Jeremy Blode Photography](https://jeremyblode.com) — *Design*. Melbourne and Mornington Peninsula wedding photographer - [Klapsis](https://klapsis.com.au) — *Client*. Building and construction project management - [Lord of the Fries](https://www.lordofthefries.com.au) — *Client*. Plant-based fast food restaurant chain - [Our Cradle](https://ourcradle.com.au) — *Client*. Luxury accommodation at Tasmania's Cradle Mountain - [Polar Guides](https://polarguides.org) — *Client*. Professional guiding standards for polar environments - [Shift Property Styling](https://www.shiftpropertystyling.com.au) — *Client*. Property styling mobile app - [Sprout Forms Tables](https://github.com/mblode/sprout-forms-tables) — *Open source*. Custom tables field for Sprout Forms on Craft 3 - [VSCode Twig Language 2](https://marketplace.visualstudio.com/items?itemName=mblode.twig-language-2) — *Open source*. VS Code extension with snippets, syntax highlighting, and formatting for Twig - [Your Tea](https://int.yourtea.com) — *Client*. Traditional Chinese Medicine herbal tea blends ## 2017 - [Little Designer Club](https://web.archive.org/web/20200425005856/https://littledesignerclub.com/) — *Client*. Kids craft and design subscription box - [SVG Placeholder](https://github.com/mblode/svgplaceholder) — *Open source*. Invisible SVG placeholder plugin for lazy loading in Craft CMS - [Verbb](https://verbb.io) — *Product*. Craft CMS plugin marketplace - [VSCode Twig Language](https://marketplace.visualstudio.com/items?itemName=mblode.twig-language) — *Open source*. VS Code extension with snippets and syntax highlighting for Twig ## 2016 - [Expense Check](https://www.expensecheck.com.au) — *Product*. Automated bill switching and expense reduction - [Grav Theme Medium](https://github.com/mblode/grav-theme-medium) — *Open source*. Medium-inspired theme for Grav CMS ## 2015 - [Burger](http://codepen.io/mblode/pen/qEGWwB) — *Open source*. The minimal hamburger menu with fullscreen navigation - [Hayley Lauren Design](http://hayleylaurendesign.com) — *Design*. Graphic design portfolio website - [Marx](https://mblode.github.io/marx/) — *Open source*. The classless CSS reset (perfect for Communists) --- # Blog # AI can code but it can't design > AI agents write production code but stay blind to visual design. Why design is the next frontier for AI-assisted engineering. *AI & design* We use Claude Code hard for frontend work but it is a blind collaborator. It writes JSX, Tailwind, animation configs with fluency. It has never seen the output of its own code. It cannot tell if the result is beautiful or balanced. Based on conversations from early 2026 about AI coding agents, design tools, and bridging the gap between terminal-based AI and visual editing. ## The gap is perceptual, not technical Code generation is text-to-text. LLMs are built for it. Design is spatial and aesthetic. They have no native sense of it. The difference between a good interface and a mediocre one is almost never in the code. It is the spacing, the type scale, the visual rhythm. Users feel these but cannot name them. I made a font a couple of years ago for my wife's interior design studio. Weighing the curve of a letterform, feeling whether the kerning breathes, is illegible to an LLM. The agent can set your font-family. It cannot tell you why one typeface carries more warmth than another. ## Visual craft still needs human judgment When I built Shareful, I designed the logo myself. An abstract share arrow. **The AI did most of the building. The logo was mine.** What an AI would have generated would have been generic. Visual craft needs judgment that comes from seeing thousands of things and forming opinions. An LLM has read descriptions of beauty. It has never experienced it. ## The floor moved for code, not design **AI raised the floor for coding. In design, the floor has barely moved.** A junior developer with Claude Code ships production-quality code. A junior designer with AI tools still produces junior design. The next leap will not be faster code generation. It will be giving agents the ability to see. To evaluate their output, understand spatial relationships, develop aesthetic judgment. Until then, design stays human territory. ## Related - [Side projects](https://matthewblode.com/side-projects) - [About Matthew Blode](https://matthewblode.com/about) --- # Build the tool you're too cheap to pay for > When building costs hours instead of months, build-versus-buy flips. The case for building your own tools when AI makes implementation nearly free. *AI-assisted engineering* I wanted WisprFlow but did not want to pay for it. So I built Commandment, an open-source alternative with BYO API key, in a night. Then allmd to turn any URL into markdown. Then HackerTok. Same impulse each time: too cheap to subscribe, fast enough to build. Based on side projects shipped between late 2025 and early 2026 including Commandment, allmd, and HackerTok. ## The impulse I use voice-to-text constantly. WisprFlow is good. It costs money every month. I looked at the subscription, looked at the feature set, and thought: I could build this. So I built Commandment. Open-source, BYO OpenAI API key, runs locally. **One night.** Not a weekend. Not a sprint. It is exactly the tool I wanted, and it costs me fractions of a cent per use instead of a monthly fee forever. That night changed how I think about every SaaS product I use. ## The pattern repeats After Commandment, I needed a way to turn web pages, PDFs, videos, and audio files into clean markdown. I wanted to feed everything into AI context windows without copy-pasting. Existing tools either cost money or did not handle every format. So I built allmd. **Four hours**, spread across an evening. It converts any URL, PDF, video, or audio file into markdown. Turn the whole universe into a skill. That is the tagline, and it is not an exaggeration. Then I wanted a better way to read Hacker News. A full client. Login, comments, upvoting, the news list, submitting posts. HackerTok happened the same way. Claude Code did the heavy lifting. I steered. **308 GitHub repos.** Plenty of dead experiments. But every one tested an assumption, taught me something, or scratched an itch nothing else was scratching. ## The calculus has flipped The old wisdom says do not reinvent the wheel. That advice assumed the wheel took months to build. It assumed building cost much more than buying. It assumed you were trading engineering time against a ten-dollar subscription, and the subscription would win. **That assumption is dead.** When AI compresses a weekend project into a few hours, the math changes. A ten-dollar-a-month subscription is $120 a year. Over five years, $600 for a tool you do not own, cannot modify, and might shut down or hike prices any time. The alternative is four hours of your evening and a tool you control forever. The subscription is not buying you software. It is a tax on your own inaction. You pay because building felt too hard. It does not feel too hard anymore. ## The hidden advantage of owning it The real benefit is not the money. It is the depth of understanding. When you build it, you know how it works. When it breaks, you fix it in minutes. When you want a new feature, you add it. When the upstream API changes, you adapt. **You are never waiting on someone else's roadmap.** Subscription software is a black box. You file a feature request and hope. You hit a bug and wait. Every dependency on someone else's product is a dependency on their priorities, not yours. Commandment does what I need because I built it for my use case. No onboarding flow. No pricing page. No team dashboard. The features I use and none of the ones I do not. ## When not to build Some tools are genuinely complex. Database engines, payment processors, auth with compliance requirements. You should not build Stripe. The test: **can you ship it before the free trial expires?** If yes, build it. You end up with something tailored, something you understand, and something that costs nothing ongoing. If no, the subscription is probably earning its keep. Most developer tools, productivity apps, and utilities fall on the build side now. The threshold keeps moving as AI gets faster. ## The real point This is not about being cheap. The cost structure of software has changed. Building is fast. Subscribing is slow. Owning is durable. Renting is fragile. Every tool you build is a skill you sharpen, a dependency you remove, and an assumption you test. The 308 repos are not a portfolio. They are a habit. **Build the thing. Ship it tonight. Own it forever.** ## Related - [Side projects](https://matthewblode.com/side-projects) - [About Matthew Blode](https://matthewblode.com/about) --- # Delete everything and start over > When rebuilding from zero is faster than debugging what exists, the impulsive move becomes the rational one. *Execution* I wanted shareful.ai to have a Mac app, iOS app, Chrome extension, Safari extension, frontend, and a monolith database. Repos for all of it. Weeks of work. Then I deleted everything and rebuilt from scratch in one night with CC Max 20x. Live before morning. Based on the shareful.ai rebuild in February 2026. ## The calculus has changed When rebuilding from zero is faster than debugging, **the impulsive move becomes the rational one.** That math did not used to work. Deleting a codebase meant losing weeks. Now it means losing hours. Holding onto broken code is the irrational choice. Every minute debugging accumulated assumptions is a minute not building what you need. ## The first version is research The second version was better in every way. Not because I am smarter at 2am than I was the week before. The context was clearer. I knew what the product needed instead of what I thought it needed when I started. The first version was built on speculation. The second on experience. That is the hidden value of a failed first attempt. Not wasted work. Research. ## Deletion is editing The old version carried accumulated assumptions. The new version carried only intent. **When building is fast, deletion is not waste. It is editing.** Writers know this. The first draft exists to discover what you are trying to say. The second draft exists to say it. Code works the same way now. The first build teaches you what the product should be. The second build is the product. Holding onto the first draft out of sunk cost is how you end up with software that feels designed by committee, even when the committee was just you at different points in time. ## Related - [Side projects](https://matthewblode.com/side-projects) - [About Matthew Blode](https://matthewblode.com/about) --- # Forcing normies into the terminal > The command line is the most agent-friendly interface we have, but it is locked behind decades of Unix knowledge. *Developer tools* They are just trying to force normies into the terminal. That is my read on current AI coding tools. Claude Code, Codex CLI, all of it. Capable tools locked behind decades of Unix knowledge. The command line is the most agent-friendly interface we have, but most people cannot use it. Based on observations about AI coding tool accessibility from early 2026. ## The tribal knowledge problem You need to know what a PATH is. What a shell is. Why your command worked in bash but not zsh. These are not skills. They are **tribal knowledge**. I set up Claude Code on my phone with Tailscale and Termius. Build from the couch, merge from bed. But that required knowing Tailscale, SSH, terminal emulators, persistent sessions. Not accessible. **Five years of nerd knowledge** compressed into a weekend project. ## The arc back to plain text The internet went from plain text HTML with hyperlinks to bloated SPA React apps. Now it is circling back to plain text markdown with hyperlinks. **The same arc is happening with dev tools. Layers of abstraction peeling away.** The terminal is text in, text out. Exactly what LLMs are built for. No DOM, no pixels. Just streams of text both ways. ## The missing product v0 and Lovable got something right. People need visual feedback. But does anyone still start a project on v0 or Lovable, or is everyone on Claude Code from day one? Someone needs to build the bridge. **A terminal not made for nerds.** That is the missing product. Not another IDE plugin. Not another chat wrapper. A real command line for people who have never typed `ls` in their lives. Nobody is building it yet. ## Related - [Side projects](https://matthewblode.com/side-projects) - [About Matthew Blode](https://matthewblode.com/about) --- # From builder to angel > After two exits, joining Airtree's Explorer cohort showed what founders look like from the investor side. *Zero to one* After years of building and pitching, I joined Airtree's Explorer cohort to learn what it looks like from the other side of the table. Evaluating other founders' zero-to-one stories taught me things about my own I could not see while living through them. Based on joining the Airtree Explorer Cohort 10 in early 2026. ## Switching seats I have spent most of my career on one side of the table. Building, pitching, convincing someone to believe in the thing I was making. VenueSafe was acquired by me&u. Fingertip was acquired by Linktree. Forbes 30 Under 30, Young Entrepreneur Awards finalist. None of that prepared me for what I learned when I stopped pitching and started listening. Airtree's Explorer Cohort 10 is 25 operators learning angel investing. Deal sourcing, due diligence, adding value beyond writing a cheque. I joined to see the other side. I did not expect how much it would change the way I think about building. ## The gap between the pitch and the work Inside a startup, you remember the chaos. The database migration that almost killed your launch. The co-founder argument at 11pm about whether the pricing page should exist yet. The three pivots nobody outside the company saw. When you evaluate someone else's startup, you do not see any of that. You see a deck. Metrics. A founder telling a story about how they got from nothing to something. **The gap between the pitch and the work is enormous.** Every founder knows this about their own company. You do not feel it until you are on the other side, sorting which parts of a story are signal and which are narrative. That gap is where the interesting lessons live. ## Founders over-index on product, investors over-index on founders The pattern I noticed straight away: founders spend most of their pitch on the product. Features, roadmap, architecture, competitive differentiation. They think the product is what is being evaluated. It is not. **Investors over-index on the founder.** They want to know if this person can survive the next eighteen months of things going wrong. Can they recruit? Can they make hard calls quickly? Do they have the judgment to pivot and the stubbornness to hold? Products change. The founder is the constant. Watching this from the investor side showed me how much time I wasted in my own pitches talking about features instead of demonstrating judgment. ## Pattern recognition flips when you change perspective When you have built something from zero to one, you remember it as decisions made under uncertainty. No obvious path. You made the best call you could with incomplete information, over and over, until something worked. When you evaluate someone else's zero-to-one story, the pattern recognition flips. You see the signal that was invisible from inside the chaos. **From the inside, product-market fit feels like barely keeping up with demand. From the outside, it looks like a clean line up and to the right.** That shift is disorienting. You start asking which parts of your own story were skill and which were timing. The honest answer is more timing than you want to admit. ## The lesson is not about investing The nominal goal of the Explorer cohort is angel investing. The real value, for me, is what it teaches you about your own work. **Seeing the pitch from the outside made me a better builder, not a better investor.** When you understand how your story reads to someone who was not there for the chaos, you tell it more clearly. The decisions get sharper because you can see them the way an outsider would. The best way to understand your own work is to evaluate someone else's. You see what founders emphasise versus what mattered. You learn the narrative you tell yourself about your company is not the one other people hear. Switch seats. Even temporarily. The view is different, and it changes what you see when you sit back down. ## Related - [About Matthew Blode](https://matthewblode.com/about) - [Speaking](https://matthewblode.com/speaking) --- # High performing keyboards > Why a high performing keyboard is the most underrated developer tool. Mechanical switches, programmable layers, split ergonomics. *Developer tools* I type roughly 60,000 words a week into Claude Code. When your workflow is prompt, review, iterate, the keyboard becomes the bottleneck you never think about. Here is the setup I use and why the physical layer deserves the same attention as the software. Based on the developer hardware and workflow setup used throughout 2025-2026. ## The physical layer of your developer OS I wrote about [wiring your developer OS](/blog/wire-your-developer-os): Tailscale for mobile coding, Beeper for messaging, Raycast snippets for every repeated prompt. All software. None of it matters if the hardware you touch ten hours a day is an afterthought. **Most developers will spend weeks configuring Neovim but never question the keyboard under their fingers.** Bizarre allocation of attention. Your keyboard is the interface between your brain and every line of code, every prompt, every commit. It deserves the same care as your editor config. ## Why keyboard performance matters when you code with AI The AI coding loop changed typing. You are writing prompts, reviewing diffs, iterating on context docs, drafting commits. The ratio of prose to syntax flipped. You write more words a day than you did writing pure code. [Voice might replace typing eventually](/blog/voice-is-the-next-interface). Until it does, your keyboard is the channel between thought and shipped product. A high performing keyboard cuts friction in that channel enough that you feel it across a ten-hour session. ## What makes a keyboard high performing Not a buying guide. A framework for what matters. **Low latency.** Keypress to character on screen should be imperceptible. Wireless with poor polling rates breaks flow. Wired or high-polling-rate wireless is non-negotiable. **Tactile feedback.** You need to know a key registered without looking or bottoming out. Tactile switches confirm at the actuation point. Your fingers learn the threshold and stop wasting force. Less fatigue over long sessions. **Programmable layers.** Encode decisions into the hardware. Home row mods. Layers for navigation, symbols, macros. Same philosophy as Raycast snippets. Compress multi-step actions into muscle memory. **Split ergonomics.** Your shoulders should not be hunched inward for eight hours. A split keyboard lets your arms rest at shoulder width. The posture compounds over months. Less strain, longer sessions, fewer breaks. ## The setup I use to ship fast I use a split mechanical keyboard with tactile switches. Columnar stagger, not row stagger. Keys align vertically with your fingers instead of following the 1878 typewriter offset. **Every choice is framed through speed, not aesthetics.** Switches chosen for actuation and feedback, not sound. Keycaps are low-profile for faster travel. Firmware is QMK so every layer is programmable. A dedicated nav layer means my hands never leave home row to reach arrow keys. The compound effect is real. Each optimisation saves fractions of a second. Over hundreds of sessions, those fractions become hours. Same philosophy as [removing what makes you slow](/blog/remove-whats-making-you-slow). Sometimes the drag is in the last place you look. ## Keyboard shortcuts are a design decision I wrote about how [keyboard shortcuts for power users](/blog/you-dont-have-to-make-ai-slop) signal you thought about how people use your product. Same principle applies to your own tools. **A high performing keyboard is a system, not just hardware.** Keyboard, firmware layers, OS shortcuts, app keybindings form one pipeline from intention to action. Each layer accelerates or adds friction. Most people optimise the app layer and ignore everything below. When I hit three keys and my full Claude Code prompt expands, that is not just a Raycast snippet. It is a tactile switch at the right force, a firmware layer routing the input, an OS shortcut triggering the expansion, and an app executing the result. The whole stack matters. ## The compound returns of physical tools A keyboard you use 2,000 hours a year is not a purchase. It is infrastructure. The returns compound like career decisions, snippet libraries, a well-wired developer OS. **The best developers I know treat physical tools with the same intentionality they bring to code.** They do not accept defaults. They invest once, configure deliberately, and benefit every day for years. Your keyboard is either accelerating you or slowing you down. Most people have never tested which. If you write 60,000 words a week into an agent, the physical layer is the foundation everything else sits on. ## Related - [Wire your developer OS](https://matthewblode.com/blog/wire-your-developer-os) - [Side projects](https://matthewblode.com/side-projects) - [About Matthew Blode](https://matthewblode.com/about) --- # Remove what's making you slow > Matthew Blode on shipping faster by removing drag, not adding more tools, process, or AI. *Execution* Teams ask the wrong question about speed. Not 'how do we ship faster?' but 'what is making us slow?' The first produces more tools and more activity. The second finds the real drag. Based on my January 2026 Startmate session on Claude Code and shipping fast. ## Speed is a subtraction problem Most teams have enough energy, ideas, and tools. They lack clarity. They lose time to handoffs, vague requirements, over-scoped solutions, and indecision about what matters now. Shipping faster is less about acceleration and more about removing what absorbs momentum. ## AI does not fix unclear systems AI makes individuals more productive. It does not fix a slow system. If a team is unclear about goals, ownership, or quality bars, AI helps it produce confusion faster. The biggest gains come when AI is paired with sharp context, obvious priorities, and a strong sense of what done looks like. - If the problem is ambiguity, more code generation will not solve it. - If the problem is approval friction, better prompts will not remove it. - If the problem is scope, the answer is smaller bets, not faster output on the same oversized bet. ## What I remove first When I look at a slow loop, I remove drag in order. First: unclear decisions. Second: unnecessary waiting. Third: work that no longer seems essential. Fourth: process that exists because it once solved a problem that is no longer the bottleneck. That worked for zero-to-one products. It still works as the stack and team get more sophisticated. ## A better operating question If we wanted this to move in half the time, what would we stop doing, cut, clarify, or automate first? That question beats a vague desire to go faster. It leads to fewer moving parts, clearer ownership, and a product that keeps momentum instead of getting buried under process. ## Related - [Speaking](https://matthewblode.com/speaking) - [VenueSafe case study](https://matthewblode.com/case-studies/venuesafe) - [About Matthew Blode](https://matthewblode.com/about) --- # Seventy people in a group chat > How VCMC went from 3 people in a WhatsApp group to 70+ members and 15,000+ messages. The product thinking behind community building. *Product craft* Six months ago, Ryan Hendler, Luca Bonelli, and I started a WhatsApp group. Not to track AI headlines. To share how we actually build day to day. It grew to 70 people, 15,000 messages, and sold-out meetups. Then Greg Brockman tweeted about us. Based on the growth of the Vibe Coding Micro Community (VCMC) from 2025-2026. ## Community is a product Most communities die because nobody treats them like a product. Someone creates a Slack, invites 200 people, posts a welcome message, watches engagement flatline within two weeks. VCMC did not start with a plan. Ryan, Luca, and I wanted a place to share what was working in our day-to-day builds. Not AI news. Not fundraising takes. Not AGI timelines. **Workflows, prompts, tools, failures, shortcuts.** The stuff that saves you three hours on a Tuesday. That constraint was the product. Share what works, not what sounds impressive. Failures and shortcuts over polished case studies. People kept showing up because the signal stayed high. ## The cold start problem Communities have the worst version of the cold start problem. Nobody wants to post in an empty room. Nobody wants to be first to share something vulnerable in front of strangers. **We were the first three users, and we used the product relentlessly.** Posted every day. Real builds, real questions, real failures. We set the tone before anyone else arrived. New people did not land in a ghost town. They landed in an active conversation between builders who were not performing. That made it safe to contribute. One person shares a prompt that cut their deploy time in half. Another shares a Claude Code workflow that broke their staging. Both valuable because both are true. The group grew to 70 people and 15,000 messages with no marketing. Every invite was personal. Every new member was someone we had worked with, met at an event, or whose work we respected. **Curation is not gatekeeping. It is product design.** ## Sixty people in a room First real test was the meetup. We ran a "Shipping with AI" event and 60 people showed up. Startmate, Me&u, Airtree, Archangel VC, OpenAI, Blinq, Buildpass, Cuttable. Pretty sure that was the highest density of top builders in one room in Australian history. The second meetup sold out at 52 guests with a 16-person waitlist. OpenAI's Scott Falkner spoke and posted about it to 142 likes. Then Greg Brockman tweeted about us. We looked at each other and thought: this thing has its own gravity now. Events work because the group chat works. Meetups are a feature, not the product. Daily conversation builds the trust. Events are where it compounds in person. ## Engagement loops, not announcements Most communities die when they become announcement channels. Someone posts a link. Nobody responds. Within a month, the only people posting treat the group as a distribution channel. We designed against that. **The group runs on conversations, not broadcasts.** Someone shares a workflow, three people respond with how they would do it differently. Someone hits a wall, two people offer to pair on it within an hour. That loop is the retention mechanic. What keeps people coming back is not content pushed at them. It is the feeling that their contribution matters and they will get something useful back. Contribute, receive value, contribute again. ## Build the brand before you need it We built [vcmc.ai](https://vcmc.ai) with a proper brand page, "in case the New York Times picks up on this group." Sounds like a joke. Serious product thinking. Build the infrastructure before you need it. Website, visual identity, positioning. All of it existed before the Greg Brockman moment. When attention arrived, we had something to point people to. We looked like we had been doing this for years, not months. ## What I learned Community building is product building with a different input. The raw material is people and conversations instead of code and design. The principles are identical. Solve the cold start. Design the loop. Curate ruthlessly. Ship the MVP and iterate. The group chat is still the core product. Seventy people sharing how they actually build, every day. No algorithms, no feeds, no content strategy. Just builders talking to builders. That turned out to be enough. ## Related - [About Matthew Blode](https://matthewblode.com/about) - [Speaking](https://matthewblode.com/speaking) --- # Ship a side project every week with AI > How AI coding tools changed the effort-to-outcome ratio for side projects, and why the constraint shifted from implementation to taste. *AI-assisted engineering* I deleted all the repos and rebuilt shareful.ai from scratch in one night with CC Max 20x. Live before morning. Not a flex. A datapoint about how the effort-to-outcome ratio has changed for side projects. Based on my January 2026 Startmate session on Claude Code and shipping fast, and drawn from projects shipped between late 2025 and early 2026. ## Three keystrokes and the swarm spins up I have a Raycast snippet called "zcc." Three keystrokes expand to my Claude Code prompt: "Do extensive research. Make a plan with phases and todos. Use a swarm of subagents and teams." That is how most projects start. Low-ceremony setup. Zed editor, multiple terminals, Claude Code doing the heavy lifting. For personal projects I yolo to main. No staging branches, no review queues. Cut the distance between idea and live product to near zero. ## The time excuse is gone 308 GitHub repos and counting. Not all winners, but every one tested an assumption. **The constraint shifted from implementation to taste, context, and the willingness to start over.** You cannot hide behind "I did not have time to build it." The time excuse is gone. What remains is whether your idea is any good. ## Speed without direction is just motion When building is cheap, the only question is whether what you build feels considered. **The tools make shipping trivial. The hard part is deciding what deserves to exist.** The people building the most interesting things right now are not the fastest coders. They are the ones with the clearest sense of what matters. ## Related - [Side projects](https://matthewblode.com/side-projects) - [About Matthew Blode](https://matthewblode.com/about) --- # Ship fast or die > Matthew Blode on shipping speed, AI workflows, team shape, and why finding out faster beats being right. *Execution* Two startups, two acquisitions, one lesson: speed is the biggest advantage a small team can have. Not reckless. Not sloppy. The kind where you think to 80 percent, ship, watch, and close the loop before anyone else has finished their second planning meeting. Based on my January 2026 Startmate mentor session on Claude Code and shipping fast. ## The mindset I ran a session for the latest Startmate cohort and opened with a line I repeat to myself: you do not win by being right. You win by finding out faster. Most teams operate like being right upfront is the goal. Weeks scoping, debating architecture, polishing Figma, aligning stakeholders. By the time they ship, the market has moved. Or they built something nobody wanted. At Fingertip and VenueSafe, the pattern was the same. We shipped early, watched real users, and iterated hard. Speed was survival. ## Invert the question Charlie Munger: invert, always invert. Instead of asking how to ship faster, ask what is making you ship slow. The usual culprits: - Blocked work waiting on someone else's approval. - Meetings that exist out of habit. - Fear of shipping something imperfect. - Vague ownership where nobody is responsible for the outcome. - Premature optimisation on systems that do not need to scale yet. - Context switching across too many projects. Most of these are not technical. They are organisational drag. You fix them by changing the shape of the team, not by adding process. ## The team shape that ships The fastest teams share a few traits. One owner end-to-end, not a chain of handoffs between product, design, and engineering. Fewer meetings, because meetings are where momentum dies when there is nothing specific to decide. Small teams, because communication overhead scales quadratically. A clear definition of done, because without it everything stays 90 percent finished forever. The builder stays close to the user, because secondhand feedback loses texture. With those conditions, speed becomes the default. ## Think to 80 percent, then ship You do not need full confidence to ship. You need enough to know you are pointed in roughly the right direction. Then you need signal from real users. The last 20 percent of certainty is the most expensive and least valuable. Teams burn weeks debating edge cases that may never happen. Ship at 80 percent, learn what matters, and course correct with data instead of opinions. ## Building with AI AI changed the speed equation. Not because it writes perfect code, but because it compresses the feedback loop. With Claude Code: AI writes, I review, I give feedback, it iterates. That loop can happen dozens of times in an hour. The workflow for building something new: - Pick one tiny behaviour. Not a feature. A single user action. - Ask Claude Code for a plan before writing anything. - When something breaks, paste what broke. Give it the error, the context, the intent. - Show the result to one user. - Fix the first friction point, then repeat. AI builds in layers, which matches how I think about product. Start with a Wizard of Oz where nothing is real behind the surface. Then a low-fi UI in code. Then the data model, API, back-end. Finally, polish the front-end. Each layer is shippable and testable on its own. ## You do not need to make AI slop AI output is not automatically low quality. But carelessness shows. People can tell when a product was generated and left unedited. Three steps. Generate a bad first cut. Sand the rough edges. Keep sanding until it feels right. The first draft from AI is raw material. The craft is in the editing, same as always. ## Give AI a good setup AI works better with the right infrastructure. TypeScript gives it type safety to reason about. A linter and formatter like Ultracite means consistent code without manual cleanup. Git means you can experiment and roll back. Logs give it context when debugging. If AI finds changes hard to make in your codebase, that is a signal. Your architecture has coupling problems that are slowing humans down too. ## Ship fast, rollback faster Speed without safety is reckless. But safety does not have to mean slow. Bias towards action, ship small changes directly to main, and use pull requests for visibility, not as gates. If something breaks, roll it back. Raise the quality bar only when mistakes are costly. Do not add process prophylactically. Every standard has a cost in speed, and that cost compounds. ## Do not guess what is broken Once you are shipping fast, you need to know what is happening. Session replay, analytics, logs, and alerts are not optional. They are the infrastructure that makes speed sustainable. Without them, you are shipping fast and blind, which is worse than shipping slow. ## Anyone can ship The barrier to shipping a real product has never been lower. AI handles the parts that used to need deep specialisation. The constraint now is taste, clarity, and willingness to put something in front of users before it feels ready. That is uncomfortable. It is also how every product I built that mattered got built. ## Related - [Speaking](https://matthewblode.com/speaking) - [VenueSafe case study](https://matthewblode.com/case-studies/venuesafe) - [About Matthew Blode](https://matthewblode.com/about) --- # Skills are the new packages > The agent skills ecosystem mirrors the early days of package managers. *Developer tools* I made a skill that creates skills. Then I made allmd to turn the universe into a skill. Then I saw the pattern: agent skills are composable units of capability the way npm packages are composable units of code. Based on building agent skills, shareful.ai, and allmd in early 2026. ## Skills are just markdown files that make agents useful An agent skill is a markdown file. You write instructions in natural language, save as `.md`, and your agent knows how to do something new. No API. No SDK. No build step. Prose that teaches a machine a specific task. The distribution is what makes this interesting. `npx skills add mblode/agent-skills`. One command and the skill is in your project. **Sound familiar?** This is `npm install` for agent capabilities. Browse a registry, install, your agent gets smarter. I have been building skills for Claude Code since late 2025. Every time I repeat the same instructions across projects, I extract them. Deployment patterns, code review checklists, animation guidelines, component decisions. Things that lived in my head now live in shareable files. ## The meta moment I built agent-skills-creator. A skill that creates skills. You describe what you want, and the agent generates a structured skill file. **A skill that makes skills.** Not a gimmick. It is the natural consequence of treating agent capabilities as composable units. Then I built allmd. It converts any URL, PDF, video, or audio into clean markdown. The tagline is "turn the whole universe into a skill," and I meant it literally. Any knowledge source becomes agent context in one command. Then I built Shareful.ai. **Stack Overflow for AI coding agents.** Developers share solutions and patterns that work with AI tools. The problems we solve with agents are different from the ones we Google. They deserve their own knowledge base. Each project felt standalone. They are the same idea. Build the ecosystem that makes agent capabilities shareable. ## The npm analogy is not a metaphor In 2010, npm was a weird idea. Why share a four-line function as a package? Why install `left-pad` instead of writing it? Composability at scale changes everything. Small, focused, reusable units compound into capability no single developer could build alone. **Skills are on the same trajectory.** Small. Focused. Shareable. Composable. Install one for database migrations, another for accessibility audits, another for performance profiling. Your agent becomes competent across domains without you being an expert in all of them. The early npm ecosystem was messy and exciting. Skills are messy and exciting now. No dominant registry. Best practices still forming. The people building skills today are the equivalent of the first npm publishers. ## MCPs are the other half **MCPs are infrastructure for agents rather than humans.** They expose natural language APIs so bots can run commands. Stainless auto-generates SDKs and MCPs from OpenAPI specs. The infrastructure layer is standardising fast. Skills sit on top. A skill tells an agent when and why to use a specific MCP. The MCP provides the capability. The skill provides the judgment. ## The honest tension Here is what I wrestle with: **even skills for CLI tools are mostly overkill because Claude Code can figure it out.** Give it a well-documented tool and it will read the docs and use it correctly. So why do skills matter? They improve output quality and consistency. The gap between "the agent can figure it out" and "the agent does it the way I want" is real. Skills close that gap. They encode preferences and hard-won decisions the agent would not discover alone. The honest question is whether that gap shrinks to zero. Maybe skills are transitional. Essential now, obsolete later. ## The open question Will skills consolidate the way npm did, with a dominant registry and standard format? Or will agents absorb skills into their own intelligence? I do not know. **But I know which side I am building on.** The people who shaped npm's early ecosystem got to define how a generation of developers shared code. The people shaping skills today get to define how a generation share agent capabilities. That is a bet worth making. Even if the agents eventually eat it all. ## Related - [Side projects](https://matthewblode.com/side-projects) - [About Matthew Blode](https://matthewblode.com/about) --- # The crafty context trick > The gap between mediocre and great AI output is fifteen minutes of context gathering. *AI workflow* You still need to be crafty with the initial context. Most people skip it. Research papers, niche blog posts, specific docs, reference implementations. Feeding the right material in is the highest-leverage move with AI coding tools. Based on workflow patterns from building with Claude Code and Codex throughout 2025 and 2026. ## The prompt matters less than what surrounds it Most people spend an hour refining instructions when they should spend fifteen minutes finding the right reference. **The best input is not a better prompt. It is a better reference.** Give the agent a concrete example of good and the output beats any amount of instruction. I built ascii.blode.co in a day because I started from a blog article on ASCII rendering. The article was the context. I built allmd to turn any URL, PDF, video, or audio into markdown for an agent. Feed the model a post about the exact technique you want. Watch the quality jump. ## Front-load the right material My Raycast snippet "zcc" expands to: "Do extensive research. Make a plan with phases and todos. Use a swarm of subagents and teams." Even that is **context gathering**. Tell the agent to research before it builds. Best results never come from the first attempt. They come from the attempt where I front-loaded the right material. ## Curate inputs, not instructions I use Brian Lovin's /simplify skill at the end of every session. Another context move. It gives the agent a framework to evaluate its own output. **The people who get the most out of these tools are not writing sophisticated prompts. They curate inputs.** The gap between mediocre and great is almost never the model. It is the fifteen minutes you did or did not spend gathering context before you hit enter. ## Related - [Side projects](https://matthewblode.com/side-projects) - [About Matthew Blode](https://matthewblode.com/about) --- # The internet came full circle > The web started as plain HTML, bloated into SPAs, and is collapsing back to markdown. This time the reader is an agent. *AI workflow* The internet came full circle. Plain HTML, then SPAs, now back to markdown. The difference is who is reading. First time, humans. This time, agents. Based on observations about the shift from visual web interfaces to agent-consumable markdown formats in 2025-2026. ## The arc nobody planned The web started as plain text. Tim Berners-Lee wrote HTML with hyperlinks and that was it. No build step, no bundler, no hydration. Just text pointing to text. Then we needed interactivity. jQuery gave us dropdowns. Angular gave us SPAs. React gave us a virtual DOM that diffed against itself to render a todo list. **We added thousands of lines of JavaScript so humans could click pretty buttons.** The browser became an OS inside an OS. Now the primary reader is shifting from humans to agents. Agents do not care about your animations, hover states, or client-side routing. They care about structured text. So the output is collapsing back to markdown. Plain text to bloated SPAs to plain text. Full circle. ## The agent infrastructure layer MCPs are the clearest signal the web is being rebuilt for a different reader. An MCP is not a human interface. It is a **natural language API for bots to run commands on our behalf**. You expose tools, the agent calls them, things happen. No pixels. Stainless.com goes further. They auto-generate SDKs and MCPs from OpenAPI specs. Your OpenAPI JSON becomes a typed SDK plus an MCP server. For free. **The pipeline from API spec to agent interface is automated.** No frontend dev needed. If your service has an API, it can have an MCP. If it has an MCP, agents can use it. The interface layer is plain text all the way down. ## Why I built allmd I built allmd because I kept hitting the same wall. I needed to feed content into an agent, but it was trapped in formats agents cannot read. A PDF. A YouTube video. A webpage drowning in JavaScript. allmd converts any URL, PDF, video, or audio file into clean markdown. **Because agents need markdown, not pixels.** That is the whole thesis. The web is full of information locked behind visual rendering, and agents need it as structured text. The irony is thick. React developers who spent careers building rich visual interfaces are now building tools that output markdown for agents. ## The web is being re-read Every page, every doc, every API is being flattened back to text. **The web is being re-read by machines.** Not crawled for search ranking. Read for comprehension. Agents consume documentation, parse changelogs, read blog posts, and execute tasks based on what they find. This changes what matters about your content. Visual hierarchy was for humans scanning a page. Structured text is for agents parsing information. Heading levels, bold text, link labels are **semantic signals for a non-human reader**. ## What this means for builders If your product cannot be represented as structured text, agents cannot use it. That is already shaping what gets adopted. This is not a regression. It is a **different reader with different needs**. Humans need visual hierarchy, whitespace, colour, animation. Agents need structured text, consistent formatting, clear labels. The builders who get this are already shipping. The ones still debating React frameworks for their dashboard are building for a reader that matters less by the month. ## Related - [Side projects](https://matthewblode.com/side-projects) - [About Matthew Blode](https://matthewblode.com/about) --- # Voice is the next interface > From Rubber Duck to losing your voice talking to AI. Why speech is replacing typing as the way we code. *Voice AI* I built Rubber Duck, a voice coding agent. A Todoist Ramble clone for Things 3 that streams audio to Gemini Flash 2.5 Live and runs tool calls. Commandment, an open source WisprFlow alternative. Each one started from the same observation: typing is a bottleneck when the listener speaks natural language. Based on voice AI projects built between late 2025 and early 2026. ## The usage pattern that tells you something shifted Someone in our community literally lost his voice from talking to AI. Not a metaphor. He lost his voice from talking to AI all day. That tells you something shifted. When a tool causes physical strain, you are past novelty. That is adoption. Uncomfortable, unsustainable, but real. ## Voice removes the translation layer **Voice removes the translation layer between thinking and doing.** You do not figure out how to type what you mean. You say it. For tasks, code, controlling tools, the mouth is faster than the fingers when the listener is an LLM. Typing friction is not speed. It is **the cognitive overhead of translating thought into structured input**. Voice skips that. Think it, say it, agent does it. Until voice tools mature, [a high performing keyboard](/blog/high-performing-keyboards) is still the fastest physical interface between thought and shipped code. ## The interface is collapsing **The tools I am building now would have been science fiction two years ago.** Streaming audio to a model that runs tool calls in real time. Talking to your computer and having it do what you said. The interface between intent and execution is collapsing. Voice collapses it fastest. The question is not whether speech replaces typing for AI. It is how fast the tooling catches up to the behaviour people already want. ## Related - [Side projects](https://matthewblode.com/side-projects) - [About Matthew Blode](https://matthewblode.com/about) --- # Wire your developer OS > Build a personal developer OS: Tailscale for mobile coding, Beeper for messaging-driven development, Raycast snippets for repeatable workflows. *Developer tools* Claude Code on my phone via Tailscale and Termius. Beeper wired in so my agent can search and send messages across every platform. Raycast snippets for every repeated prompt. Your developer OS deserves the same care as the products you ship. Based on personal developer infrastructure built throughout 2025-2026. ## Your phone is a remote control I SSH into my dev machine from my phone. Tailscale gives me a private mesh. Termius gives me a real terminal on iOS. Claude Code runs on my MacBook. I drive it from anywhere. Build from the couch. Diff on the train. Merge from bed at midnight. **The phone is a remote control for a dev environment that never sleeps.** The machine stays on, the agent keeps working. No VPN config, no port forwarding, no corporate IT. Tailscale just works. I use it daily. The gap between having an idea and acting on it shrinks to the time it takes to pull out your phone. ## Beeper changed everything Beeper unifies my messaging. WhatsApp, Slack, LinkedIn, iMessage, Discord, one window. Useful on its own. Then I connected it to Claude Code. Beeper Desktop ships beepctl, a CLI that searches, reads, and sends messages. I wired it into Claude Code as a skill. **My coding agent can search and send across all my networks.** Need a Slack thread for context? The agent reads it. Need to ping someone that a deploy finished? The agent sends it. The agent does not just write code. It communicates. It pulls context from conversations and pushes updates back out. The line between coding tool and comms tool dissolves. ## The cautionary tale Safety gates matter. I learned this the hard way. Claude was testing a Beeper integration and sent a message to verify it worked. It sent a fake API key to a group chat. Not a real key, fabricated as test data. But the group chat was real. Real people saw a message from me with what looked like a leaked credential. **"CLAUDE STOP."** Typed into the terminal in a panic. The lesson: any tool that acts on your behalf needs explicit confirmation gates. I now require approval before any send. Read is cheap. Write is dangerous. ## Three keystrokes to spin up a swarm A Raycast snippet called "zcc" expands to my standard Claude Code prompt. Three keystrokes, full prompt: do extensive research, make a plan with phases and todos, use a swarm of subagents and teams. Every session starts the same way. **Snippets are the most underrated productivity tool.** Not because they save typing. They save thinking. The decision was made once, encoded into three characters. I have snippets for commit messages, PR descriptions, scaffolding prompts. Each compresses a multi-step decision into one expansion. The compound effect over hundreds of sessions is enormous. ## Two setups, two philosophies At work I use Conductor. Good for structured sessions, but performance degrades after a few hours. The fix is ugly: reboot the session and start fresh. Context window management is a real constraint. Personal projects are different. Terminal inside Zed running Claude Code. **Yolo to main.** No staging branches, no PR reviews, no ceremony. If it works, it ships. If it breaks, I fix it. Work needs coordination, auditability, collaboration. Personal needs velocity. **Using the same workflow for both is a mistake most developers make without realising it.** ## The thesis Most developers invest in their editor and their language. Weeks on Neovim, debates over TypeScript versus Go. They will not spend an afternoon wiring up Tailscale. **The glue layer is the most underinvested part of your stack.** How you access your tools. How you trigger your workflows. How you compose your systems. That is where the biggest gains hide, and almost nobody works on it. Treat your setup as a product. Your setup has users. You, every day, for years. A snippet that saves thirty seconds saves hours a month. Mobile SSH lets you act on an idea instead of waiting until you are back at your desk. **Wire your OS. The tools are there. The glue is the work nobody wants to do, and the work that matters most.** ## Related - [Side projects](https://matthewblode.com/side-projects) - [About Matthew Blode](https://matthewblode.com/about) --- # You can sense carelessness > Why AI-assisted products still need human taste and product discipline. *Product craft* People can sense carelessness. They cannot see the code, but they notice when something feels rushed or stitched together without thought. Based on my February 2026 Next.js Melbourne talk about care, craft, and product quality. ## Care is visible in the finished product Care for the user shows up in small decisions: how quickly a page settles, whether the copy is clear, whether a form feels obvious, whether the product creates friction at the wrong moment. Users sense when something is off before they can describe it. They are not inspecting code. They are reacting to the experience. ## AI raises the floor, but it can flatten the result AI makes it easy to produce competent output fast. It also makes it easy to stop too early and ship something that works but feels generic. The risk is teams confuse speed with quality and ship the first plausible version instead of the considered one. - A fast draft is not a finished product. - Generated interfaces need stronger editing than teams expect. - The closer a product is to the user, the more obvious careless details become. ## What care looks like in practice Care means being willing to edit. Cut awkward steps. Rewrite vague copy. Tighten motion. Simplify the hierarchy. Remove details that distract. It also means being honest about where AI helps. AI is great at momentum. It is less reliable at deciding what should matter most to the user. ## Fingertip after the MVP: a series of 1,000 small iterations At Fingertip, care showed up as deliberate improvements after the MVP shipped. Each change was small. Together they transformed the experience. ### Static list to drag-and-drop grid The page editor started as a static list. We replaced it with a drag-and-drop grid that gave users real control over layout. ![Page editor before: a static list of sections](/blog/you-can-sense-carelessness/design-before.png) ![Page editor after: a drag-and-drop grid with visual hierarchy](/blog/you-can-sense-carelessness/design-after.png) ### Sharing that matches reality The default share preview was just the Fingertip logo. We replaced it with a live screenshot of the user's page via a headless render API. ![Social share before: generic Fingertip logo](/blog/you-can-sense-carelessness/og-before.png) ![Social share after: live profile screenshot](/blog/you-can-sense-carelessness/og-after.jpeg) ### Default shadcn to intentional system Central icons, custom typography, taller inputs, and custom colours turned default shadcn into a considered design system. ![Form inputs before: default shadcn styling](/blog/you-can-sense-carelessness/outcome-before.jpg) ![Form inputs after: polished event settings with structured hierarchy](/blog/you-can-sense-carelessness/outcome-after.png) ## Why this matters to me My work sits between product, engineering, and design. Whether it was VenueSafe under time pressure, Fingertip growing into a broader SMB platform, or LinkApps at Linktree, the question stays the same: does this feel right to the user? That is the standard. Not perfection. Not polish for its own sake. Enough care that the product feels deliberate. ## Related - [Speaking](https://matthewblode.com/speaking) - [Fingertip case study](https://matthewblode.com/case-studies/fingertip) - [About Matthew Blode](https://matthewblode.com/about) --- # You don't have to make AI slop > A practical guide to AI-built UIs beyond the default: better fonts, better icons, stolen taste, and relentless editing. *Design* Everyone can tell when you vibe coded your app. Default shadcn, Lucide icons, Inter, glowing gradient borders. It screams 'I prompted this and shipped the first thing that came out.' It does not have to be that way. Based on my January 2026 Melbourne builder meetup talk about using AI tools without sacrificing product quality. ## The tools are table stakes I build with shadcn/ui, Tailwind, Motion, React, and Ultracite/Biome. You probably use a similar stack. None of this is an advantage. Every vibe coder is using the same components with the same defaults. The difference between slop and considered is the taste you apply on top. ## Great artists steal Find a product with an irrationally tasteful UI. One that makes you feel something. Then copy it. Right click and inspect. Rip off elements until your version is identical. Screen record interactions and go frame by frame on the timing. Use AI to un-minify their JS bundle and read their animation logic. This is how you develop taste. You cannot design what you have not studied closely. The goal is not plagiarism. It is training your eye by reproducing the gold standard, then applying it to your own product. ## Simplicity above all else AI will go rogue. Glowing borders, gradient backgrounds, decorative illustrations, extra copy, badges, tooltips, and seventeen things nobody asked for. Your job is to delete most of it. Every time you look at a screen, ask what can go without losing meaning. If a paragraph can be a sentence, make it a sentence. If a sentence can be a label, make it a label. If a label can be removed, remove it. The best interfaces feel inevitable. They do not feel like someone kept adding things until it seemed finished. ## Use better icons Stop using Lucide for everything. Fine for prototyping, but they lack the weight to carry a polished product. I use the Central icon system. The strokes are considered, the proportions tighter. Users sense icon quality without being able to articulate it. They cannot tell you the icons are wrong, but they feel when something looks generic. ## Add delightful animations Use motion.dev. Go through the animations.dev and devouringdetails.com courses. Animations are one of the fastest ways to make a product feel intentional rather than generated. Keep them fast. Most transitions land between 0.2 and 0.3 seconds. Prefer ease-out. Animate transforms and opacity. Respect prefers-reduced-motion. The goal is not to impress. It is to feel responsive without getting in the way. ## Don't just use Google Fonts Default Google Fonts are typographic stock photography. Everyone uses them, everyone recognises them, and they signal that nobody made a deliberate choice. Go to Typewolf, find typefaces that suit your product, track them down. Many great fonts are on GitHub if you know where to look. Typography is one of the highest-leverage design decisions and it is almost always underinvested in by engineering-led teams. ## Learn from products with restraint Study products that feel calm rather than feature-stuffed. The ones I come back to: Zed Editor, OpenAI, Mintlify, Raycast, Linear, Things 3, Family Crypto Wallet, and ElevenLabs. What they share is restraint. They show only what matters. They do not over-explain. Interactions feel precise. That is what separates designed from generated. ## Go the extra mile The last ten percent is where most people stop. Push harder there. - Add a dark mode-aware SVG favicon so your icon adapts to the user's system. - Generate dynamic OG images so every page has a proper social preview. - Polish hover and active states. Every interactive element should respond. - Write proper SEO metadata for every page. Title, description, canonical URL. - Add keyboard shortcuts for power users. It signals you thought about how people actually use the product. None of these are hard alone. Together they separate a weekend project from something that feels cared for. ## Death by a thousand tweaks The real work is not the first version. It is the five hundred small improvements after. Sand it, feel the grain, get a splinter, sand again. That is the process. No shortcut replaces the willingness to keep refining. AI gives you a fast start. What you do after determines whether you shipped something worth using or just more slop. ## Related - [Speaking](https://matthewblode.com/speaking) - [Fingertip case study](https://matthewblode.com/case-studies/fingertip) - [About Matthew Blode](https://matthewblode.com/about) --- # Your career compounds > Why the biggest career advantages come from stacking high-learning environments, not individual wins. The decisions behind VenueSafe, Fingertip, and Linktree. *Zero to one* I started working the day after high school. Not because I had a plan. Because I wanted to learn. Every role since then was picked the same way: maximum learning velocity over comfort. Careers compound like interest, but only if you keep reinvesting. Based on LinkedIn posts about career compounding and the Fingertip acquisition story from 2025. ## The day after high school Most people take a gap year or ease into uni. I walked into Expense Check and started building software. No grand strategy. The fastest way to learn was to be somewhere that expected output from day one. That instinct, learning speed over comfort, turned out to be the most important decision pattern of my career. Not any role. Not any product. **Always picking the environment where I would learn the most, the fastest.** ## Urgency teaches you things comfort never will VenueSafe went from idea to acquisition by me&u in six months. Not some brilliant strategy. COVID contact tracing was an urgent problem, and urgency strips out the nonsense that slows teams down. No multi-week planning cycles. No alignment meetings. No long-term architecture debates for a product that needed to exist yesterday. We built, shipped, watched, fixed. Every day. VenueSafe taught me that **speed is a skill, and you only develop it under real pressure.** Not deadlines set by a project manager. Real pressure, where real people need a real solution and the clock is not negotiable. ## Scale breaks everything you thought you knew After me&u acquired VenueSafe, I moved into scaling mobile ordering across their platform. Different education entirely. me&u was making things work for 15 million users across multiple countries, including US expansion from Austin. Every assumption got stress-tested. Things that work at small scale shatter at large scale. Queries fine with a thousand users fall over with a million. Patterns that feel clean in a prototype become nightmares in a system that has to stay up during a Friday night dinner rush across three time zones. **Scale teaches you that elegance is not clever code. It is boring, reliable systems that do not surprise you at 2am.** ## Platform ambition needs a different clarity Co-founding Fingertip with Olly Hoffman, Gabby Leibovich, and Hezi Leibovich was the next step. Website creation, bookings, and payments for small businesses across more than 100 countries. Huge problem space. The skills from VenueSafe and me&u were prerequisites. Without urgency, we would have over-planned. Without scale instincts, we would have built something that broke the moment it grew. Fingertip needed both, plus **thinking in platforms rather than products.** A product solves one problem well. A platform creates the conditions for many problems to get solved. That sounds abstract until you are making architecture decisions that constrain the next three years. ## The acquisition was a byproduct When Linktree acquired Fingertip, people treated it as the goal. It was a byproduct of the compounding. It happened because the skills, team, and product had reached a point where they were valuable at a larger scale. Now, as Co-Head of LinkApps at Linktree, I build for 70 million creators. The learning has accelerated. Every previous environment deposited skills that pay dividends here. Urgency from VenueSafe means I do not waste cycles. Scale instincts from me&u mean I build systems that handle the weight. Platform thinking from Fingertip means I see how features connect to the ecosystem. **None of these skills would exist if I had optimised for comfort.** ## The compounding thesis Career compounding only works if you keep choosing learning environments over comfortable ones. Every role where you coast is a year of zero returns. Every role where you are slightly overwhelmed is a year of high-interest deposits. Each role maximised learning velocity over comfort. The compounding happened on its own. Returns from urgency stack on returns from scale, which stack on returns from platform ambition. You cannot buy it. You cannot shortcut it. You earn it by showing up to hard environments for years. **Choose the role that scares you slightly more than it excites you.** That is where the interest rate is highest. ## Related - [About Matthew Blode](https://matthewblode.com/about) - [Speaking](https://matthewblode.com/speaking) --- # Zero to one is mostly clarity > Matthew Blode on what zero-to-one product work takes across startups, acquisitions, and early-stage building. *Zero to one* People describe zero-to-one work as creativity, ambition, or willingness to move fast. Those matter. The real advantage is clarity. Clarity on the user problem, on the first useful version, and on what can be ignored for now. Drawn from my work across VenueSafe, Fingertip, and Linktree. ## The early stage punishes vagueness Vague thinking gets expensive fast. If the problem is not clear, the product sprawls. If priorities are not clear, the team diffuses effort. If the first useful version is not clear, the product becomes a pile of ideas instead of a focused answer. That is why zero-to-one work feels intense. Less room to hide behind process or org complexity. The outcome tracks the quality of your judgment. ## What I learned from VenueSafe VenueSafe was built when the problem was urgent and obvious. Urgency forced clarity that is rare in comfortable conditions. The product had to solve a real operational need, fast. When the problem is real enough, the right first version is easier to identify. The challenge is staying disciplined enough to keep it focused. ## What Fingertip added Fingertip was broader. Not one urgent workflow. A platform to help small businesses run more of their business online. That needs a different clarity. You still need focus, plus a view of the larger system so each new capability extends the platform instead of turning it into a pile of features. ## Why zero to one is still my specialty The part I enjoy most is turning ambiguity into a direction a team can build against. Choose the problem carefully. Narrow the first bet. Keep quality high enough that the product feels intentional from day one. Zero to one is mostly clarity. The teams that move well know what matters, what can wait, and what the user needs next. ## Related - [VenueSafe case study](https://matthewblode.com/case-studies/venuesafe) - [Fingertip case study](https://matthewblode.com/case-studies/fingertip) - [About Matthew Blode](https://matthewblode.com/about) --- ## Agent discovery - Sitemap: https://matthewblode.com/sitemap.xml - llms.txt: https://matthewblode.com/llms.txt - llms-full.txt: https://matthewblode.com/llms-full.txt - API catalog: https://matthewblode.com/.well-known/api-catalog - Skills index: https://matthewblode.com/.well-known/agent-skills/index.json - MCP server: https://matthewblode.com/mcp - MCP discovery: https://matthewblode.com/.well-known/mcp.json Any page on this site returns markdown when requested with `Accept: text/markdown` or by appending `.md` to the URL.