1. A security audit for your vibe-coded app, before real users' data goes in

    A security audit for a vibe-coded app checks what a demo never shows: keys in the app's code, who can see and change each record, logins, and whether the server checks every request. I go through your Lovable, Replit or Bolt app and send you a written list of what's exposed, in order of risk, and what fixing it involves.

  2. Taking over an app your last developer left

    A new developer can take over an app the last developer left. First get access to everything the app runs on, then the developer reads the code and checks what works, then finishes what's missing. I've taken over and finished projects mid-build several times.

  3. Finding out why your web app is slow

    A slow web app is usually slow in a few specific places: too many or slow database queries, inefficient processing, large data, or no caching, so the same work is repeated on every request. Measure first to find those places, then fix them, and measure again.

  4. Why your AI-built app keeps breaking, and how to steady it

    If every change you ask Lovable, Replit, Bolt or another AI tool for breaks something else, the AI is changing code it can't fully see, and nothing checks the result. I steady apps like this: find what works, put automatic checks around the main features, and fix what's broken.

  5. Why your vibe-coded prototype loses its data

    A vibe-coded prototype usually loses its data because it keeps the data in the browser, on one device. Clear the browser, switch to your phone, or ask a colleague to look, and it isn't there. The fix is a real database behind a server, with logins.

  6. Adding payments and subscriptions to your app

    Add payments and subscriptions with a payment provider such as Stripe: it takes the card details and charges them, and tells your app's server when a payment succeeds, fails or a subscription ends. The server then switches features on or off. Your app never stores card details.

  7. What multi-tenancy is, and when your app needs it

    Multi-tenancy means one app serves many customer organizations while keeping each one's data separate, so none of it leaks to another. Your app needs it as soon as you sell it to more than one business: every record belongs to a customer, and the server checks it on every request.

  8. Making your website multilingual

    A multilingual website gives each language its own addresses, such as /fr for French, with a language switcher, translated page titles and descriptions, and tags that tell Google which pages are translations of each other. The translations can come from people, from AI, or both.

  9. How much it costs to build a small business website

    The cost to build a small business website depends on how many pages it has, whether you'll edit it yourself, whether it's in more than one language, and what forms and connections it needs. I don't publish prices: I look at what you need first, then quote. Running it afterwards costs little.

  10. A website you can edit yourself without breaking it

    You can have a website you update yourself without breaking it. I build sites with a CMS where you change the words, photos and articles through simple forms, while the design stays fixed. My preferred CMS is Sveltia CMS. Every change is kept, and a change that would break a page never goes live.

  11. Moving your website off Wix, Squarespace or WordPress to a faster, cheaper site

    You can move your website off Wix, Squarespace or WordPress without losing its pages or its place on Google. I rebuild it as a fast site with no plugins to keep updating and far less for anyone to hack, keep every page's address or redirect it, and give you a CMS so you can still change it yourself.

  12. A daily report from your business data, by email

    A daily report can be built from your own systems and emailed to you: a scheduled job pulls the numbers, compares them with the week before, and sends one short email. Nobody has to log in to five dashboards to see how the business is going.

  13. Connecting your CRM to your website so listings update themselves

    Connect your CRM to your website through the CRM's API: a scheduled job reads the listings every day, copies the photos, and rebuilds the website's pages. New and changed listings appear without anyone copying them across by hand.

  14. Translating your website and content automatically into another language

    Your website, listings and other content can be translated automatically, but not by just running them through AI: on its own, AI gets industry words wrong in ways that change what a page promises. I build automatic translation with a rulebook for your industry's terms and a second AI that checks every translation.

  15. AI automation examples for small businesses

    Examples of automations for small businesses: listings pulled from a CRM onto the website every day, the same listings translated into another language automatically, a full mailbox moved into cheaper storage, and a daily report emailed from the business's own data.

  16. How much it costs to run AI in your app

    AI in an app costs money every time it's used: the model provider charges for the text each request sends and receives. The cost depends on how much text each request carries, which model answers, and how often it runs. I measure the cost per request first, then choose the model and the calls to match.

  17. AI hallucination: why your AI makes things up, and how to cut it down

    AI hallucination is when an AI model gives a confident answer that isn't true. It happens when the model doesn't have the facts in front of it, sees a document in pieces, is asked for something that isn't there, or has no example of a good answer. Giving it sources, a way to say 'not found' and a worked example cuts most of it.

  18. How to get an AI chatbot that answers from your company's documents

    If your team answers the same questions every day and the answers are already in your documents, an AI chatbot can answer them instead. I build chatbots that answer from your company's documents, show where each answer came from, and say 'not found' rather than guess. Nothing needs training.

  19. How to know if your AI feature gives the right answers

    You know an AI feature gives the right answers by testing it against a set of real questions with checked answers, and scoring every change against that set. That also lets you keep improving it: try a change, score it, and keep it only if the answers got better.

  20. Getting your app onto the App Store and Google Play

    To publish an app on the App Store and Google Play you need an Apple developer account, a Google Play developer account, a store listing with screenshots and a privacy policy, and an app that passes each store's review. The app can be published under your company's accounts or under mine; either way I do the builds, submissions and review.

  21. How much it costs to build an iPhone and Android app

    The cost of an iPhone and Android app depends on what's behind the screens, whether it's one codebase or two, the store setup, and who owns the accounts and hosting. I don't publish prices: I look at your idea or prototype first, then quote.

  22. App Store app or web app: build both with React Native

    If people will use your app on their phones, build it as an iPhone and Android app in React Native. The same code also runs in the browser, so the web app comes almost for free. A web app on its own only makes sense when nobody needs it on a phone.

  23. Turning your Lovable, Replit or Bolt app into an iPhone and Android app

    A Lovable, Replit or Bolt prototype can become a real iPhone and Android app on the App Store and Google Play. It's rebuilt as one app that runs on iPhone, Android and the web, on a proper backend, with the prototype as the specification.

  24. How much it costs to turn a vibe-coded prototype into a real app

    The cost of turning a vibe-coded prototype into a real app depends on what it needs that the prototype doesn't have, how the AI built it, whether it goes on phones, and who hosts it. I don't publish prices: I look at each app first, then quote.

  25. When to hire a developer for your Lovable, Replit or Bolt app

    Keep building with Lovable, Replit or Bolt while you're still working out what the app should do. Hire a developer when real people's data is about to go in, when each new prompt breaks something else, or when the app needs logins, payments or things that happen while nobody has it open.

  26. Turning a vibe-coded prototype into an app with logins and a backend

    To turn a vibe-coded prototype into an app with logins and a backend, put your own API between the app and a real database, add sign-in, password reset and an admin screen, and keep secrets on the server. What that involves, and what the prototype is worth.

  27. Security review of an AI-built Supabase app

    A security review of an AI-built Supabase app checks whether the frontend talks straight to the database with a Supabase key, whether every API endpoint is secured, and whether business rules run on the server. Why it matters, and what the fix involves.

  28. A developer in Australia to fix your vibe-coded app

    I'm a Sydney developer who fixes vibe-coded apps: I check them for security and data problems first, then rebuild them properly, using your prototype as the specification.

  29. Making a Lovable, Replit or Bolt app production ready

    To make a Lovable, Replit or Bolt app production ready, add real logins and permissions, keep secrets on a server, use a proper database with backups, and add error reporting and repeatable deploys. The full list, and the order I work in.

  30. My first RAG, part 2: I built generation. One endpoint sang. The other lied about people needing the bathroom.

    Week two of the RAG project — added /summarize and /answer on top of retrieval. /summarize was the surprise hit. /answer had a polite refusal problem and then a stranger one. Notes from the workbench.

  31. My first RAG

    From zero Python service experience and zero RAG knowledge to a working YouTube transcript retrieval pipeline. The mental shifts, the decisions, and the gotchas that surprised me.

  32. If you came from Jekyll or Gatsby, you want a git-based CMS

    Why a git-based CMS is the natural successor to Jekyll or Gatsby — your content stays as markdown in the repo, the editor just sits on top. Plus what I found running Decap and Sveltia side-by-side.

  33. Migrating from Next.js to Astro

    Three years after migrating to Next.js, I migrated off it. Why I left, what the move to Astro looked like, and the numbers from this site's rebuild.

  34. Next js - Is it getting just too hard to use?

    Since Next.js 13 went all in on server components, it has been getting harder to use for anything that needs integration: a CMS, static site rendering, internationalization.

  35. Migrating from Gatsby to Next.js

    Reflections from leaving Gatsby for Next.js in early 2023 — what worked, what didn't, and what the migration actually cost.