# 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 - [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 remain functionally blind to visual design. Why design is the next frontier for AI-assisted engineering. *AI & design* We use Claude Code intensely for frontend work but it is practically a blind collaborator. It writes JSX, Tailwind classes, animation configs with fluency. But it has never seen the output of its own code. It cannot evaluate whether the result is beautiful, balanced, or even visually coherent. 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 a text-to-text problem and LLMs are inherently suited to it. Design is a spatial, perceptual, aesthetic problem and 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 in the spacing, the type scale, the visual rhythm. These are the decisions that users feel but cannot name. I made a font a couple of years ago for my wife's interior design studio. That kind of craft — weighing the curve of a letterform, feeling whether the kerning breathes right — is still entirely 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 requires human judgment When I built Shareful, I designed the logo myself. An abstract share arrow. **I was proud that despite the AI doing most of the building, the logo was mine.** That is not nostalgia. It is recognition that what an AI would have generated would have been generic. Visual craft requires the kind of judgment that emerges from seeing thousands of things and developing opinions about them. An LLM has read descriptions of beauty. It has never experienced it. ## The floor has moved for code but not for design **AI has raised the floor for coding dramatically. In design, the floor has barely moved.** A junior developer with Claude Code can ship production-quality code. A junior designer with AI tools still produces junior design. The next real leap in AI-assisted product building will not be faster code generation. It will be giving agents the ability to see. To evaluate their own output visually, to understand spatial relationships, to develop something approaching aesthetic judgment. Until then, design remains 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, the build-versus-buy calculus inverts. 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 I built 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. It took one night. Not a weekend. Not a sprint. **One night.** The result is not a perfect clone. It is exactly the tool I wanted, built exactly the way I wanted it, and it costs me fractions of a cent per use instead of a monthly fee forever. That single 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 and reformatting. The existing tools either cost money or did not handle all the formats I cared about. So I built allmd. **Maybe four hours total**, spread across an evening while I was doing other things. 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. Anything I encounter online, I can now pipe straight into a context window. Then I wanted a better way to read Hacker News. Not a reader app with half the features missing. A full client. Login, comments, upvoting, the news list, submitting posts. Everything. HackerTok happened the same way. Claude Code did the heavy lifting. I steered. **308 GitHub repos.** Not all winners. Plenty of dead experiments and half-finished ideas. But every single one tested an assumption, taught me something, or scratched an itch that no existing product was scratching properly. ## The calculus has inverted The old wisdom says do not reinvent the wheel. That advice assumed the wheel took months to build. It assumed the cost of building was dramatically higher than the cost of buying. It assumed you were trading engineering time against a ten-dollar monthly subscription and the subscription would win every time. **That assumption is dead.** When AI compresses a weekend project into a few hours, the math changes. A ten-dollar-a-month subscription costs you $120 a year. Over five years, that is $600 for a tool you do not own, cannot modify, and might shut down or raise prices at 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 charging you a tax on your own inaction. You are paying because building felt too hard, and it does not feel too hard anymore. ## The hidden advantage of owning it The real benefit is not the money you save. It is the depth of understanding you gain. When you build your own tool, you know exactly how it works. When it breaks, you fix it in minutes because you wrote it. 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. You outgrow the tool and migrate. Every dependency on someone else's product is a dependency on someone else's priorities, and their priorities are not yours. Commandment does exactly what I need because I built it for exactly my use case. It does not have an onboarding flow, a pricing page, or a team management dashboard. It has the features I use and none of the features I do not. ## When not to build I am not arguing you should build everything. That would be absurd. Some tools are genuinely complex — database engines, payment processors, authentication systems with compliance requirements. You should not build Stripe. The test is simple: **can you ship it before the free trial expires?** If the answer is yes, build it. You will end up with something tailored to your needs, something you understand deeply, and something that costs you nothing ongoing. If the answer is no, the tool is probably complex enough that the subscription is genuinely earning its keep. Most developer tools, productivity apps, and simple utilities fall on the build side of that line now. The threshold keeps moving as AI gets faster, and it is moving fast. ## The real point This is not about being cheap. It is about recognising that the cost structure of software has fundamentally changed. Building is fast. Subscribing is slow. Owning is powerful. Renting is fragile. Every tool you build is a skill you sharpen, a dependency you remove, and an assumption you test. The 308 repos on my GitHub are not a portfolio. They are a habit. **Build the thing. Ship it tonight. Own it forever.** The subscription can wait. You cannot. ## 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 big monolith database. I had repos for all of it. Weeks of accumulated work. Then I deleted everything and rebuilt from scratch in one night with CC Max 20x. Had it live before morning. Based on the shareful.ai rebuild in February 2026. ## The calculus has changed When rebuilding from zero is faster than debugging what exists, **the impulsive move becomes the rational one.** That math did not used to work. Deleting a codebase meant losing weeks or months of effort. Now it means losing hours at most. The calculus has changed so fundamentally that holding onto broken code is the irrational choice. Every minute spent debugging accumulated assumptions is a minute not spent building the thing you actually 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, but because the context was clearer. I knew what the product actually needed instead of what I thought it needed when I started. The first version was built on speculation. The second was built on experience. That is the hidden value of a failed first attempt. It is not wasted work. It is 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 instinctively. 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 like it was 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's locked behind decades of Unix knowledge. *Developer tools* They are just trying to force normies into the terminal. That is my honest read on a lot of the current AI coding tools. Claude Code, Codex CLI, all of it — powerful tools locked behind decades of accumulated 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. You need to know what a shell is. You need to know why your command worked in bash but not in zsh. These are not skills. They are **tribal knowledge**. I set up Claude Code on my phone with Tailscale and Termius. I can kick off a build from the couch, merge from bed. The phone becomes a remote control for a development environment that never sleeps. But that setup required knowing what Tailscale is, what SSH is, what a terminal emulator is, how to configure persistent sessions. That is not accessible. That is **five years of accumulated 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 and is now circling back to plain text markdown with hyperlinks. **The same arc is happening with developer tools — we are peeling away layers of abstraction.** The terminal is text in, text out. That is exactly what LLMs are built for. No DOM to parse, no pixels to interpret, just streams of text flowing in both directions. ## The missing product v0 and Lovable understood something — people need visual feedback. Does anyone actually start a project on v0 or Lovable anymore, or is everyone using Claude Code from day one. If the answer is increasingly the latter, someone needs to build the bridge. **A terminal that is not made for nerds.** That is the missing product. Not another IDE plugin, not another chat wrapper. A genuine command line experience designed for people who have never typed `ls` in their lives. The opportunity is enormous and 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. What changes when you evaluate someone else's zero-to-one story. *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 that 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. I am not listing those to impress anyone. I am listing them because none of that prepared me for what I learned when I stopped pitching and started listening. Airtree's Explorer Cohort 10 is 25 experienced operators learning the mechanics of angel investing. Deal sourcing, due diligence, how to add value beyond writing a cheque. After years of building, I was keen to learn what it looks like from the other side of the table. What I did not expect was how much it would change the way I think about building. ## The gap between the pitch and the work When you are 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 ever saw. When you evaluate someone else's startup, you do not see any of that. You see a deck. You see metrics. You see 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. But you do not truly feel it until you are on the other side, trying to figure out which parts of someone else's story are signal and which are narrative. That gap is where all the interesting lessons live. ## Founders over-index on product, investors over-index on founders Here is the pattern I noticed almost immediately: founders spend most of their pitch talking about the product. Features, roadmap, technical architecture, competitive differentiation. They think the product is the thing being evaluated. It is not. Not really. **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 decisions quickly? Do they have the judgment to know when to pivot and the stubbornness to know when to hold? The product matters, but products change. The founder is the constant. Watching this dynamic from the investor side made me realise how much time I had 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 a series of decisions made under uncertainty. There was no obvious path. You just 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. Suddenly you can see the signal that was invisible from inside the chaos. Product-market fit looks different from the outside. **From the inside, it feels like barely keeping up with demand. From the outside, it looks like a clean line going up and to the right.** That shift in perspective is disorienting. You start asking yourself which parts of your own story were skill and which were timing. The honest answer is usually more timing than you want to admit. ## The lesson is not about investing The thing about the Explorer cohort is that the nominal goal is to learn angel investing. But the real value, at least 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. And when you tell it more clearly, you live 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 notice the patterns you missed in your own story. You see what founders emphasise versus what actually mattered. You learn that the narrative you tell yourself about your company is never quite the same as 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. The setup a CTO uses to ship faster with mechanical switches, programmable layers, and split ergonomics. *Developer tools* I type roughly 60,000 words a week into Claude Code. That number used to be lower before AI made the feedback loop this tight. When your entire 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 of your developer OS deserves the same attention as the software layer. 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 one piece of 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.** That is a bizarre allocation of attention. Your keyboard is the physical interface between your brain and every line of code, every prompt, every commit message. It deserves the same care as your editor config. ## Why keyboard performance matters when you code with AI The AI coding loop changed the nature of typing. You are not just writing code anymore. You are writing natural language prompts, reviewing diffs, iterating on context documents, drafting commit messages. The ratio of prose to syntax has flipped. You write more words per day than you ever did writing pure code. [Voice might replace typing eventually](/blog/voice-is-the-next-interface). Until it does, your keyboard is the primary channel between thought and shipped product. A high performing keyboard reduces the friction in that channel. Not by a little — by enough that you feel it across a ten-hour session. ## What makes a keyboard high performing This is not a buying guide. It is a framework for thinking about what actually matters. **Low latency.** The time between keypress and character on screen should be imperceptible. Wireless keyboards with poor polling rates introduce enough lag to break flow state. Wired or high-polling-rate wireless is non-negotiable. **Tactile feedback.** You need to know a key registered without looking, without bottoming out, without thinking about it. Tactile switches give you that confirmation at the actuation point. Your fingers learn the threshold and stop wasting force. Less fatigue over long sessions. **Programmable layers.** A high performing keyboard lets you encode decisions into the hardware. Home row mods. Layer switches for navigation, symbols, macros. The 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 difference compounds over months. Less strain, longer sessions, fewer breaks that interrupt flow. ## The setup I use to ship fast I use a split mechanical keyboard with tactile switches. The layout is columnar stagger, not row stagger — keys align vertically with your fingers instead of following the typewriter offset that made sense in 1878 and makes zero sense now. **Every choice is framed through speed, not aesthetics.** The switches are chosen for actuation force and feedback, not sound profile. The keycaps are low-profile for faster travel. The firmware is QMK so every layer is programmable. I have a dedicated layer for navigation that 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. The same philosophy applies to [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 that you thought deeply about how people actually use your product. The same principle applies to your own tools. **A high performing keyboard is not just hardware. It is a system.** The keyboard, the firmware layers, the OS-level shortcuts, and the application keybindings form a single pipeline from intention to action. Each layer either accelerates you or adds friction. Most people optimise the application layer and ignore everything below it. When I hit three keys and my full Claude Code prompt expands, that is not just a Raycast snippet. It is a tactile switch actuating at exactly the right force, a programmable firmware layer routing the input, an OS shortcut triggering the expansion, and an application 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 the same way career decisions compound, the same way snippet libraries compound, the same way a well-wired developer OS compounds. **The best developers I know treat their physical tools with the same intentionality they bring to their code.** They do not accept defaults. They do not use whatever came in the box. They invest once, configure deliberately, and then benefit from that investment every single day for years. Your keyboard is either accelerating you or slowing you down. Most people have never tested which. If you are writing 60,000 words a week into an AI coding agent, the physical layer is not a luxury. It 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 just adding more tools, process, or AI. *Execution* When teams talk about speed, they often ask the wrong question. The better question is not 'how do we ship faster?' It is 'what is making us slow?' The difference matters because the first question tends to produce more tools, more layers, and more activity, while the second question forces you to identify the real drag in the system. Based on my January 2026 Startmate session on Claude Code and shipping fast. ## Speed is usually a subtraction problem Most teams already have enough energy, enough ideas, and enough tools. What they lack is clarity. They lose time to unnecessary handoffs, vague requirements, over-scoped solutions, or simple indecision about what matters right now. That is why shipping faster is usually less about acceleration and more about removing the things that keep absorbing momentum. ## AI does not fix unclear systems AI tools can make individuals dramatically more productive, but they do not automatically fix a slow system. If a team is unclear about goals, ownership, or quality bars, AI will mostly help it produce more confusion faster. The biggest gains come when AI is paired with sharp context, obvious priorities, and a strong sense of what done actually 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 that friction. - If the problem is scope, the answer is smaller bets, not faster output on the same oversized bet. ## What I try to remove first When I look at a slow product or engineering loop, I try to remove drag in a specific order. First: unclear decisions. Second: unnecessary waiting. Third: work that no longer seems essential. Fourth: process that exists mostly because it once solved a problem that is no longer the main bottleneck. That approach worked when building zero-to-one products and it still works when the stack, team, and tooling get much more sophisticated. ## A better operating question The operating question I like is simple: if we wanted this to move in half the time, what would we stop doing, cut, clarify, or automate first? That question tends to produce better answers than 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 every AI headline, but 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, and then watches engagement flatline within two weeks. VCMC did not start with a grand plan. Ryan, Luca, and I just wanted a place to share what was actually working in our day-to-day builds. Not AI news. Not fundraising takes. Not hot takes about AGI timelines. **Workflows, prompts, tools, failures, and shortcuts.** The stuff that saves you three hours on a Tuesday afternoon. That constraint turned out to be the entire product. The group chat had a clear value proposition from day one: share what actually works, not what sounds impressive. Failures and shortcuts over polished case studies. And people kept showing up because the signal-to-noise ratio stayed high. ## The cold start problem Every product has a cold start problem, and communities have the worst version of it. Nobody wants to post in an empty room. Nobody wants to be the first person to share something vulnerable in front of strangers. We solved it the way you solve any cold start problem. **We were the first three users, and we used the product relentlessly.** Ryan, Luca, and I posted every day. We shared real builds, asked real questions, admitted real failures. We set the tone before anyone else arrived. When new people joined, they did not land in a ghost town. They landed in the middle of an active conversation between builders who were clearly not performing. That made it safe to contribute. One person shares a prompt that cut their deploy time in half. Another person shares a Claude Code workflow that broke their entire staging environment. Both are equally valuable because both are true. The group grew to 70 people and 15,000 messages without a single marketing campaign. 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 The first real test was the meetup. We ran a "Shipping with AI" event and 60 people showed up. People from Startmate, Me&u, Airtree, Archangel VC, OpenAI, Blinq, Buildpass, Cuttable. I looked around the room and thought: pretty sure that was the highest density of world class 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 afterwards to 142 likes. Then Greg Brockman, co-founder of OpenAI, tweeted about us. That was a moment where Luca, Ryan, and I looked at each other and thought: this thing has its own gravity now. But the events work because the group chat works. The meetups are not the product. They are a feature of the product. The daily conversation is what builds trust. The events are where that trust compounds in person. ## Engagement loops, not announcements The thing that kills most communities is when they become announcement channels. Someone posts a link. Nobody responds. Someone else posts a link. Nobody responds. Within a month, the only people posting are the ones who treat the group as a distribution channel. We designed against that from the start. **The group runs on conversations, not broadcasts.** Someone shares a workflow, and three other people respond with how they would do it differently. Someone hits a wall, and within an hour two people have offered to pair on it. That feedback loop is the retention mechanic. I think about community engagement the same way I think about product engagement. What keeps people coming back is not content pushed at them. It is the feeling that their contribution matters and that they will get something useful in return. That is the loop. 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." That sounds like a joke, but it is actually serious product thinking. You build the infrastructure before you need it, not after. The website, the visual identity, the clear positioning — all of that 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. Instead of code and design, the raw material is people and conversations. But the principles are identical. Solve the cold start problem. Design the engagement loop. Curate ruthlessly. Ship the MVP and iterate. The group chat is still the core product. Seventy people sharing how they actually build, every single 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 has 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. Had it live before morning. That is not a flex. It is a datapoint about how dramatically 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 standard 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. The setup is intentionally low-ceremony. Zed editor, multiple terminals, Claude Code doing the heavy lifting. For personal projects I yolo to main. No staging branches, no review queues. The goal is to reduce the distance between idea and live product to near zero. ## The time excuse is gone 308 GitHub repos and counting. Not all of them are winners, but every one tested a different assumption. **The constraint has shifted from implementation ability to taste, context, and the willingness to start over.** That shift sounds liberating. It is, mostly. But it also means you cannot hide behind "I did not have time to build it." The time excuse is gone. What remains is whether your idea was 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.** I keep coming back to that. 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, and one lesson that kept proving itself: speed is the single biggest advantage a small team can have. Not reckless speed. Not sloppy speed. The kind of speed where you think to 80 percent, ship, watch what happens, 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 When I ran a session for the latest Startmate cohort, I opened with a line I have repeated to myself more times than I can count: you do not win by being right. You win by finding out faster. That sounds obvious, but most teams operate as though being right upfront is the goal. They spend weeks scoping, debating architecture, polishing designs in Figma, aligning stakeholders. By the time they ship, the market has already moved, or worse, they built something nobody actually wanted. At Fingertip, which was acquired by Linktree, and at VenueSafe, which was acquired by me&u, the pattern was the same both times. We shipped early, watched real users, and iterated hard. Speed was not a nice-to-have. It was survival. ## Invert the question Charlie Munger had a line I keep coming back to: invert, always invert. Instead of asking how to ship faster, ask what is making you ship slow. In my experience, the usual culprits are predictable: - Blocked work waiting on someone else's approval or decision. - Meetings that exist out of habit rather than necessity. - Fear of shipping something imperfect. - Vague ownership where nobody is clearly responsible for the outcome. - Premature optimisation on systems that do not need to scale yet. - Context switching across too many projects at once. Most of these are not technical problems. They are organisational drag. You fix them by changing the shape of the team, not by adding more process. ## The team shape that ships The fastest teams I have worked on 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 goes to die 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. And the builder stays close to the user, because secondhand feedback loses the texture that matters most. If you have those conditions, speed becomes the default instead of something you have to fight for. ## Think to 80 percent, then ship This is the principle I push hardest. You do not need full confidence to ship. You need enough confidence that you are pointed in roughly the right direction, and then you need real signal from real users. The last 20 percent of certainty before shipping is almost always the most expensive and least valuable. It is where teams burn weeks debating edge cases that may never materialise. Ship at 80 percent, learn what actually matters, and course correct with data instead of opinions. ## Building with AI AI has changed the speed equation dramatically. Not because it writes perfect code, but because it compresses the feedback loop. The cycle I use with Claude Code looks like this: AI writes the code, I review it, I give feedback, it iterates. That loop can happen dozens of times in an hour. The practical workflow for building something new with AI is straightforward: - 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 also likes to build in layers, and this matches how I think about product development. Start with a fake version, a Wizard of Oz where nothing is real behind the surface. Then build a low-fi UI in code. Then add the data model, the API contract, the back-end logic. Finally, polish the front-end. Each layer is shippable and testable on its own. ## You do not need to make AI slop One thing I wanted the cohort to hear clearly: AI output is not automatically low quality. But carelessness is always visible. People can sense when a product was generated and left unedited. The process I follow is three steps. Generate a bad first cut. Sand the rough edges. Keep sanding until it feels right. The first draft from AI is never the finished product. It is raw material. The craft is in the editing, the same way it has always been. ## Give AI a good setup AI works dramatically better with the right project infrastructure. TypeScript gives it type safety to reason about. A linter and formatter like Ultracite means it produces consistent code without manual cleanup. Version control through Git means you can experiment freely and roll back when something goes wrong. Logs give it context when debugging. If AI finds changes are hard to make in your codebase, that is a signal. It usually means your architecture has coupling problems that are slowing down humans too. ## Ship fast, rollback faster Speed without safety is reckless. But safety does not have to mean slowness. The approach I use is to bias hard towards action, ship small changes directly to main, and use pull requests for visibility rather than as gates. If something breaks, roll it back immediately. Raise the quality bar deliberately and only when mistakes are actually costly. Do not add process prophylactically. Every standard you introduce 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 actually 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 core message I left the Startmate cohort with is simple. The barrier to shipping a real product has never been lower. AI handles the parts that used to require 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 have built that mattered actually 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 emerging agent skills ecosystem mirrors the early days of package managers. Skills are becoming the new open-source contribution model. *Developer tools* I made a skill that creates skills. Then I made allmd to turn the whole universe into a skill. Then I noticed the pattern: agent skills are becoming composable units of capability the same way npm packages became 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. That is it. You write instructions in natural language, save it as `.md`, and suddenly your AI coding agent knows how to do something it could not do before. No API. No SDK. No build step. Just prose that teaches a machine how to perform a specific task well. The distribution model is what makes this interesting. `npx skills add mblode/agent-skills` — one command and the skill is in your project. **Sound familiar?** It should. This is `npm install` for agent capabilities. You browse a registry, pick what you need, install it, and your agent gets smarter. I have been building skills for Claude Code since late 2025. Every time I find myself repeating the same instructions across projects, I extract them into a skill. Deployment patterns, code review checklists, animation guidelines, component architecture decisions. Things that used to live in my head or in scattered docs now live in composable, shareable files. ## The meta moment I built agent-skills-creator — a skill that creates other skills. You describe what you want the skill to do, and the agent generates a well-structured skill file following best practices. **A skill that makes skills.** The recursion is 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 file into clean markdown. The tagline is "turn the whole universe into a skill," and I meant it literally. Any knowledge source on the internet can become agent-consumable context in one command. Research papers, documentation, blog posts, YouTube tutorials — all of it becomes raw material for teaching agents. Then I built Shareful.ai. Think of it as **Stack Overflow for AI coding agents.** A platform where developers share solutions, patterns, and approaches that work well with AI tools. The problems we solve with agents are different from the problems we Google. They deserve their own knowledge base. Each project felt like a standalone idea. Looking back, they are all 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 would you share a four-line function as a package? Why would you install `left-pad` instead of writing it yourself? The answer turned out to be that composability at scale changes everything. Small, focused, reusable units compound into capability that no single developer could build alone. **Skills are following the exact same trajectory.** They are small. They are focused. They are shareable. They compose. You install a skill for database migrations, another for accessibility audits, another for performance profiling. Your agent becomes competent across domains without you becoming an expert in all of them. The early npm ecosystem was messy and exciting. Skills are messy and exciting right now. There is no dominant registry yet. Best practices are still forming. The people building skills today are the equivalent of the people who published the first npm packages — they are shaping a format that millions will eventually use. ## MCPs are the other half MCPs are related but they serve a different purpose. **MCPs are infrastructure for AI agents rather than humans.** They expose natural language APIs so bots can run commands on our behalf. Stainless is already auto-generating SDKs and MCPs from OpenAPI specs. The infrastructure layer is standardising fast. Skills sit on top of that infrastructure. A skill might tell an agent when and why to use a specific MCP. The MCP provides the capability. The skill provides the judgment. Together they turn a generic AI assistant into a domain-specific collaborator. ## The honest tension Here is the part I wrestle with: **even skills for CLI tools are mostly overkill because Claude Code can just figure it out.** Give it a well-documented tool and it will read the docs, understand the flags, and use it correctly without any skill file telling it how. So why do skills matter? Because right now, they dramatically improve output quality and consistency. The gap between "the agent can figure it out" and "the agent does it exactly the way I want" is real. Skills close that gap. They encode preferences, patterns, and hard-won decisions that the agent would not discover on its own. But the honest question is whether that gap shrinks to zero. Maybe agents get good enough that explicit skills become unnecessary. Maybe every skill eventually gets absorbed into the model's general capability. Maybe the skills ecosystem is a transitional technology — essential now, obsolete later. ## The open question Will skills consolidate the way npm did — a dominant registry, a standard format, an ecosystem so entrenched it becomes permanent infrastructure? Or will agents absorb skills into their own intelligence, making the explicit skill file a historical artefact? 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 an entire generation of developers shared code. The people shaping the skills ecosystem today get to define how an entire generation of developers 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 difference between mediocre AI output and great AI output is fifteen minutes of context gathering. *AI workflow* You still need to be crafty with the initial context. That is the part most people skip. Research papers, niche blog posts, specific documentation, reference implementations — feeding the right material into the context window before you start is the single highest-leverage thing you can do 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.** When the agent has a concrete example of what good looks like, it produces better output than any amount of instruction can achieve. I built ascii.blode.co in a day because I started from a specific blog article about ASCII rendering. The article was the context. I built allmd specifically to turn any URL, PDF, video, or audio into markdown so it can be fed into an agent. Give the model a blog post about the exact technique you want to use and watch the quality jump. ## Front-load the right material I have a Raycast snippet called "zcc" that expands to my standard prompt: "Do extensive research. Make a plan with phases and todos. Use a swarm of subagents and teams." Even that prompt is about **context gathering** — telling the agent to research before it builds. The best results I get are never from the first attempt. They are 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. That is also a context move — giving the agent a framework for evaluating its own output. **The people who get the most out of these tools are not writing sophisticated prompts. They are curating the right inputs.** The difference between mediocre AI output and great AI output 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 internet started as plain HTML with hyperlinks, bloated into single-page React apps, and is collapsing back to plain text markdown. This time the primary reader is not a human — it is an agent. *AI workflow* The internet came full circle. It started as plain HTML with hyperlinks. Then it bloated into single-page React applications. Now it is collapsing back to plain text markdown with hyperlinks. The difference is who is reading. First time around, humans. This time, AI 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 documents with hyperlinks and that was it. No build step, no bundler, no hydration. Just text pointing to other text. Then we needed interactivity. jQuery gave us dropdowns. Angular gave us SPAs. React gave us a virtual DOM that diffed against itself so we could render a todo list. **We added thousands of lines of JavaScript so humans could click buttons that looked nice.** The browser became an operating system running inside an operating system. Now the primary consumer of web content is shifting from humans to agents. And agents do not care about your animations, your hover states, or your client-side routing. They care about structured text. So the output format is collapsing back to markdown. Plain text to bloated SPAs to plain text. Full circle. ## The agent infrastructure layer MCPs — Model Context Protocols — are the clearest signal that 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 involved. Stainless.com takes this a step further. They auto-generate SDKs and MCPs from OpenAPI specs. You have an OpenAPI JSON file describing your API, and Stainless turns that into a fully typed SDK plus an MCP server — for free. **The entire pipeline from API spec to agent-consumable interface is automated.** No frontend developer needed. This is infrastructure for a world where agents are the primary users of your product. 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 the content 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 entire product thesis in one sentence. The web is full of information locked behind visual rendering, and agents need that information as structured text. The irony is thick. React developers — people who spent careers building rich visual interfaces — are now building tools that output markdown for agents to consume. The framework that dominated the last decade of frontend development is producing tools for a world that does not need a frontend. ## The web is being re-read Every page, every doc, every API is being flattened back to text. **The entire web is being re-read by machines.** Not crawled for search ranking like Google did. Read for comprehension. Agents are consuming documentation, parsing changelogs, reading blog posts, and executing 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. The heading levels, the bold text, the link labels — those are not style choices anymore. They 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 not a theoretical concern. It is a practical constraint that is already shaping what gets adopted. This is not a regression. It is a **different reader with different needs**. Humans needed visual hierarchy, whitespace, colour, animation — all the things that make information scannable by eyes. Agents need structured text, consistent formatting, clear labels — all the things that make information parseable by models. The builders who understand this are already shipping. The ones still debating which React framework to use for their dashboard are building for a reader that is becoming less important by the month. The web started as text for humans. It is becoming text for agents. Same format, different audience, entirely different implications. ## 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. I built a Todoist Ramble clone for Things 3 where audio streams to Gemini Flash 2.5 Live and directly executes tool calls. I built Commandment, an open source WisprFlow alternative. Each project started from the same observation: typing is a bottleneck when the listener understands 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 so much. Not a metaphor. He was saying he lost his voice from talking to AI all day. That is the kind of usage pattern that tells you something fundamental has shifted. When people use a tool so intensely that it causes physical strain, you are past the novelty phase. That is adoption. Uncomfortable, unsustainable, but real. ## Voice removes the translation layer **Voice removes the translation layer between thinking and doing.** You do not have to figure out how to type what you mean. You just say it. For task management, for coding, for controlling tools — the mouth is faster than the fingers when the listener is an LLM that understands natural language natively. The friction of typing is not just speed. It is the **cognitive overhead of translating a thought into a structured input**. Voice skips that step entirely. You think it, you say it, the agent does it. Until voice tools fully mature, [a high performing keyboard](/blog/high-performing-keyboards) remains 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 executes tool calls in real time. Talking to your computer and having it actually do what you said. The interface between human intent and machine execution is collapsing, and voice is the medium that collapses it fastest. The question is not whether speech replaces typing for AI interaction. It is how quickly the tooling catches up to the behavior people already want. ## Related - [Side projects](https://matthewblode.com/side-projects) - [About Matthew Blode](https://matthewblode.com/about) --- # Wire your developer OS > How to build a personal developer operating system: Tailscale for mobile coding, Beeper for messaging-driven development, Raycast snippets for repeatable workflows. *Developer tools* I set up Claude Code on my phone with Tailscale and Termius. Then I connected Beeper so my coding agent can search and send messages across every platform. Then 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 creates a private mesh network between all my devices, and Termius gives me a proper terminal emulator on iOS. That means Claude Code runs on my MacBook but I control it from anywhere. Kick off a build from the couch. Review a diff on the train. Merge from bed at midnight because you cannot sleep and you know the PR is ready. **The phone becomes a remote control for a development environment that never sleeps.** The machine stays on, the agent keeps working, and I check in whenever I want. No VPN configuration, no port forwarding, no corporate IT department standing in the way. Tailscale just works. Two devices on the same network, encrypted end-to-end, zero configuration after the initial setup. This is not a gimmick. 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 unified all my messaging platforms into one app. WhatsApp, Slack, LinkedIn, iMessage, Discord — everything in one window. That was already useful. Then I connected it to Claude Code. Beeper Desktop exposes beepctl, a CLI tool that lets you search, read, and send messages programmatically. I wired that into Claude Code as an agent skill. **My coding agent can now search and send messages across all my networks.** Need to check a Slack thread for context while building a feature? The agent reads it directly. Need to notify someone that a deploy finished? The agent sends the message. The power is in the composition. The agent does not just write code. It communicates. It pulls context from conversations and pushes updates back out. The boundary between "coding tool" and "communication tool" dissolves. ## The cautionary tale Safety gates matter. I learned this the hard way. Claude was testing a Beeper integration and decided to send a message to verify it worked. It sent a fake API key to a group chat. Not a real key — the agent fabricated one as test data. But the group chat was real. Real people saw a message from me containing what looked like a leaked credential. **"CLAUDE STOP."** That was my actual reaction. Typed it into the terminal in a panic. The lesson is simple: any tool that can act on your behalf in the real world needs explicit confirmation gates. I now require approval before any message send. The agent can search and read freely, but sending requires my sign-off. Read is cheap. Write is dangerous. Treat them differently. ## Three keystrokes to spin up a swarm I have a Raycast snippet called "zcc" that expands to my standard Claude Code prompt. Three keystrokes and the full prompt appears: do extensive research, make a plan with phases and todos, use a swarm of subagents and teams. Every coding session starts the same way. **Snippets are the most underrated productivity tool.** Not because they save time on typing — they save time on thinking. I do not need to remember my preferred prompt structure. I do not need to decide how to start. The decision was made once and encoded into three characters. The cognitive overhead drops to zero. I have snippets for commit messages, for PR descriptions, for project scaffolding prompts. Each one compresses a multi-step decision into a single expansion. The compound effect over hundreds of sessions is enormous. ## Two setups, two philosophies At work I use Conductor. It is good for structured sessions but performance degrades after a few hours. The fix is ugly but effective: reboot the session and start fresh. Context window management is a real constraint and pretending otherwise just leads to worse output. For personal projects, the setup is different. Terminal inside Zed editor 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. Personal projects are a space for speed and experimentation, not process. The two setups serve different needs. Work requires coordination, auditability, collaboration. Personal requires velocity. **Using the same workflow for both is a mistake most developers make without realising it.** ## The thesis Most developers invest heavily in their editor and their language. They will spend weeks configuring Neovim or debating 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. The infrastructure between you and your code is where the biggest gains are hiding, and almost nobody is working on it. Treat your developer setup as a product. Iterate on it. Ship improvements to it. Your setup has users — you, every day, for years. The compound returns on a well-wired developer OS are enormous. A snippet that saves thirty seconds per session saves hours per month. A mobile SSH setup that lets you act on ideas immediately instead of waiting until you are back at your desk changes the shape of what you build. **Wire your OS. The tools are already there. The glue between them is the work nobody wants to do, and it is the work that matters most.** ## Related - [Side projects](https://matthewblode.com/side-projects) - [About Matthew Blode](https://matthewblode.com/about) --- # You can sense carelessness > Matthew Blode on care, craft, and why AI-assisted products still need human taste and product discipline. *Product craft* One line I keep coming back to is this: people can sense carelessness. They cannot always explain it, and they usually cannot see the code or process behind a product, but they notice when something feels rushed, awkward, or stitched together without much thought. Based on my February 2026 Next.js Melbourne talk about care, craft, and product quality. ## Care is visible in the finished product Taste and craft can be easy to talk about in abstract terms, but what matters more is care for the user. Care shows up in the 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. That is why users can often sense when something is off before they can describe what exactly is wrong. They are not inspecting implementation details. They are reacting to the experience. ## AI raises the floor, but it can also flatten the result AI tools make it much easier to produce competent output quickly. That is useful, but it also makes it easy to stop too early and accept a product that technically works while feeling generic. The risk is not that AI creates bad products by default. The risk is that teams confuse speed with finished quality and ship the first plausible version instead of the version that actually feels considered. - A fast draft is not the same thing as a finished product. - Generated interfaces often 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 In practice, care means being willing to edit. It means reducing awkward steps, rewriting copy that feels vague, tightening motion, simplifying the visual hierarchy, and removing details that distract instead of help. It also means being honest about where AI helps and where it still needs a strong operator. AI is excellent at producing 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 a long series of deliberate improvements after the initial product shipped. Each change was small, but together they transformed the experience. ### Static list to drag-and-drop grid The page editor started as a basic 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 social share preview showed only the Fingertip logo. We replaced it with a live screenshot of the user's actual page using 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 the default component library 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 A lot of my work sits at the intersection of product, engineering, and design. Whether I was building VenueSafe under time pressure, growing Fingertip into a much broader SMB platform, or working on LinkApps at Linktree, the underlying question has stayed the same: does this feel right to the user? That is the standard I try to keep. Not perfection. Not polish for its own sake. Just enough care that the product feels deliberate rather than careless. ## 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 elevating 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. The default shadcn components, the Lucide icons, the Inter font, the glowing gradient borders — it all screams 'I prompted this into existence and shipped the first thing that came out.' But it does not have to be that way. Here is my guide to getting away with it. 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 a competitive advantage. Every vibe coder on the planet is using the same components with the same defaults. The difference between slop and something that feels considered is not the tools. It is the taste you apply on top of them. ## Great artists steal Find a product with an irrationally tasteful UI. Not one you vaguely admire — one that makes you feel something when you use it. Then precisely copy it. Right click and inspect. Rip off individual elements until your version is identical. Screen record their interactions and go frame by frame to understand the timing. Use AI to un-minify their JavaScript bundle and read through their animation logic. This is not lazy. This is how you develop taste. You cannot design what you have never studied closely, and most people have never studied anything closely enough. The goal is not plagiarism. It is training your eye by reproducing the gold standard, then applying what you learned to your own product. ## Simplicity above all else AI will go rogue. It will add glowing borders, gradient backgrounds, decorative illustrations, extra copy, badges, tooltips, and seventeen other things nobody asked for. Your job is to delete most of it. Relentlessly remove elements and text. Every time you look at a screen, ask what can be taken away 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 entirely, remove it. The best interfaces feel inevitable. They do not feel like someone kept adding things until it looked busy enough to seem finished. ## Use better icons Stop using Lucide for everything. The icons are fine for prototyping, but they lack the weight and personality to carry a polished product. I recommend the Central icon system — the strokes are more considered, the proportions feel tighter, and they give your UI a level of refinement that default icon sets simply do not. Small details like icon quality are exactly the kind of thing users sense without being able to articulate. They cannot tell you the icons are wrong, but they can 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. But keep them fast. Most transitions should land between 0.2 and 0.3 seconds. Prefer ease-out curves. Animate transforms and opacity for performance. Respect prefers-reduced-motion. The goal is not to impress — it is to make the interface feel responsive and alive without getting in the way. ## Don't just use Google Fonts Default Google Fonts are the typographic equivalent of stock photography. Everyone uses them, everyone recognises them, and they immediately signal that nobody made a deliberate choice. Go to Typewolf, find typefaces that suit your product's personality, and track them down. Many excellent fonts are available on GitHub if you know where to look. Typography is one of the highest-leverage design decisions you can make, and it is almost always underinvested in by engineering-led teams. ## Learn from products with restraint Study products that feel calm and considered rather than busy and feature-stuffed. The ones I keep coming back to: Zed Editor, OpenAI, Mintlify, Raycast, Linear, Things 3, Family Crypto Wallet, and ElevenLabs. What these products share is not a specific aesthetic. It is restraint. They show only what matters. They do not over-explain. Their interactions feel precise. That restraint is what separates a product that feels designed from one that feels generated. ## Go the extra mile The last ten percent of polish is where most people stop, and it is exactly where you should push harder. - Add a dark mode-aware SVG favicon so your icon adapts to the user's system preference. - Generate dynamic OG images so every page has a proper social preview instead of a generic fallback. - Polish your hover and active states. Every interactive element should respond to the user. - Write proper SEO metadata for every page. Title, description, canonical URL. - Add keyboard shortcuts for power users. It signals that you thought deeply about how people actually use the product. None of these things are hard individually. Together, they are the difference between a product that feels like a weekend project and one that feels like someone cared. ## 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, and repeat until smooth. That is the process. There is no shortcut, no prompt, and no framework that replaces the willingness to keep refining something until it feels right. AI gives you a fast start. What you do after that start is what 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. A look at the decisions behind VenueSafe, Fingertip, and Linktree. *Zero to one* I started working the day after I finished high school. Not because I had a plan, but because I wanted to learn. Every role since then was chosen for the same reason: maximum learning velocity over immediate comfort. Looking back, the pattern is clear. 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 university. I walked into Expense Check and started building software. There was no grand strategy. I just knew that the fastest way to learn was to be somewhere that expected output from day one. That instinct, choosing learning speed over comfort, turned out to be the single most important decision pattern of my career. Not any individual role. Not any single product. **The pattern of always picking the environment where I would learn the most, the fastest.** ## Urgency teaches you things comfort never will VenueSafe started as an idea and was acquired by me&u in six months. Six months from nothing to acquisition. That timeline was not the result of some brilliant strategy. COVID contact tracing was an urgent problem, and urgency strips away all the nonsense that slows teams down in normal conditions. There were no multi-week planning cycles. No alignment meetings. No debates about long-term architecture for a product that needed to exist yesterday. We built, shipped, watched, and fixed. Every day. What VenueSafe taught me is that **speed is a skill, and you can only develop it under genuine pressure.** Not artificial 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. This was a different education entirely. VenueSafe was about moving fast with a small team. me&u was about making things work for 15 million users across multiple countries, including US expansion from Austin. Every assumption I had about how to build product got stress-tested. Things that work at small scale shatter at large scale. Database queries that are fine with a thousand users fall over with a million. Design patterns that feel clean in a prototype become maintenance 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 about clever code. It is about boring, reliable systems that do not surprise you at 2am.** ## Platform ambition requires a different kind of clarity Co-founding Fingertip with Olly Hoffman, Gabby Leibovich, and Hezi Leibovich was the next step in the compounding chain. We were building website creation, bookings, and payments for small businesses across more than 100 countries. The problem space was enormous. The skills from VenueSafe and me&u were not just useful here. They were prerequisites. Without the urgency muscle from VenueSafe, we would have over-planned. Without the scale instincts from me&u, we would have built something that broke the moment it grew. Fingertip required both, plus a new skill: **thinking in platforms rather than products.** A product solves one problem well. A platform creates the conditions for many problems to get solved. That distinction sounds abstract until you are the one making architecture decisions that will either enable or constrain everything you build for the next three years. ## The acquisition was a byproduct When Linktree acquired Fingertip, people treated it as the goal. It was not. The acquisition was a byproduct of the compounding. It happened because the skills, the team, and the product had reached a point where they were genuinely valuable at a larger scale. Now, as Co-Head of LinkApps at Linktree, I am building for 70 million creators. The learning has not stopped. It has accelerated. Every previous environment deposited skills that are paying dividends in this one. Urgency from VenueSafe means I do not waste cycles on work that does not matter. Scale instincts from me&u mean I build systems that can handle the weight. Platform thinking from Fingertip means I see how individual features connect to the larger ecosystem. **None of these skills would exist if I had optimised for comfort at any point along the way.** ## The compounding thesis Here is the uncomfortable truth about career compounding: it 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. I was not trying to be clever. I was not running some sophisticated career strategy. Each role simply maximised learning velocity over immediate comfort. The compounding happened on its own. The returns from urgency stack on top of the returns from scale, which stack on top of the returns from platform ambition. You cannot buy that compounding. You cannot shortcut it. You can only earn it by showing up to hard environments, consistently, 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 actually requires across startups, acquisitions, and early-stage product building. *Zero to one* People often describe zero-to-one work as creativity, ambition, or a willingness to move fast. Those things matter, but the real advantage is usually clarity. You need clarity on the user problem, clarity on what the first useful version should be, and clarity on what can be ignored for now. Drawn from my work across VenueSafe, Fingertip, and Linktree. ## The early stage punishes vagueness In early-stage work, vague thinking gets expensive quickly. If the problem is not clear, the product sprawls. If the priorities are not clear, the team diffuses effort. If the first useful version is not clear, the product becomes a collection of ideas rather than a focused answer to a real problem. That is why zero-to-one work often feels intense. There is less room to hide behind process, momentum, or organizational complexity. The quality of the outcome is tightly linked to the quality of your judgment. ## What I learned from VenueSafe VenueSafe was built in a moment where the problem was urgent and obvious. That urgency forced a kind of clarity that can be rare in more comfortable conditions. The product had to solve a real operational need, and it had to do it quickly. That experience reinforced a core lesson for me: when the problem is real enough, the right first version becomes easier to identify. The challenge is staying disciplined enough to keep the solution focused. ## What Fingertip added Fingertip was different because the ambition was broader. The challenge was not just to solve one urgent workflow, but to build a platform that could help small businesses run more of their business online. That kind of zero-to-one work requires a different form of clarity. You still need focus, but you also need a view of the larger system so that 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 product direction that a team can actually build against. That means choosing the problem carefully, narrowing the first bet, and keeping quality high enough that the product feels intentional from the start. That is also why the phrase I keep coming back to is simple: zero to one is mostly clarity. The teams that move well are usually the ones that know what matters, what can wait, and what the user actually 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.