DEV Community: kai belmo

AI Can Generate a SaaS Prototype. Building the Product Still Takes Months.

kai belmo — Tue, 21 Jul 2026 22:38:25 +0000

You’ve probably seen posts that make building a SaaS with AI sound almost effortless:

Give Claude one prompt, wait a few hours, and launch.

That wasn’t my experience.

I used Claude and other AI coding tools while building Infill, and they absolutely helped. I wrote code faster, found bugs sooner, and avoided a lot of repetitive work.

But the product still took me more than three months to build.

The reason is simple: generating code was never the hardest part.

The First Version Was Easy

Getting an early demo working did not take long.

Infill is a browser extension that helps users fill repetitive forms. The basic idea sounds straightforward:

Read the fields on the page.
Match them with information from the user’s profile.
Fill the form.

An AI model can help build that prototype quickly.

The problems start when you ask what happens outside the happy path.

Websites use strange labels. Some forms are split across multiple pages. Some fields already contain data. Others are hidden, disabled, sensitive, or designed to catch bots.

Then there are the questions that have nothing to do with generating another component:

What information should be filled automatically?
What should always require user approval?
Where should profile data be stored?
What happens when the AI makes the wrong match?
How much will every form submission cost?

Those decisions became most of the work.

Calling an AI Model for Everything Was a Bad Idea

My first instinct was to let an LLM handle all the field matching.

It looked good in a demo: send the form fields to the model, receive the mappings, and fill the page.

But that approach would become expensive very quickly.

Every form would create another API request. Larger forms would use more tokens. More users would mean higher bills and more latency.

There was also a bigger privacy problem.

To let the model handle everything, I would need to send form fields and parts of the user’s profile to an external AI provider. Depending on the form, that data could include names, addresses, phone numbers, employment history, financial details, or other sensitive information.

In other words, I would be exposing far more user data than necessary just to fill a form.

The product might work, but the economics and privacy model would not.

So I changed the architecture.

Infill now tries deterministic matching first. Common fields can be matched locally without an AI call. AI is only an optional fallback for cases where the normal rules are not enough.

This is less exciting than saying the whole product is powered by an autonomous agent.

It is also faster, cheaper, more private, and easier to reason about.

I Still Write the Important Code Myself

I do not hand the entire codebase to an AI agent and accept whatever it generates.

For the important parts, I still write the code myself.

That includes architectural boundaries, design patterns, data flow, privacy rules, sensitive-field handling, and the parts that could become expensive or dangerous if they are implemented badly.

AI can suggest five different abstractions in a few seconds. It cannot know which one will still make sense six months later.

It can generate a service, a hook, or a repository pattern. It does not understand the trade-offs of adding another layer to the system unless I give it that context.

For routine work, AI is great. I use it for scaffolding, repetitive code, tests, refactoring suggestions, and exploring alternatives.

But for decisions that shape the product, I slow down.

I draw the boundaries. I choose the patterns. I review how data moves through the system. I decide what must stay local, what can be optional, and what should never be automated.

The more sensitive the code is, the less comfortable I am treating AI output as a finished answer.

A generated function can look clean and still leak data, create an expensive API path, hide a race condition, or introduce a pattern that makes the codebase harder to maintain.

AI can write code quickly.

I still have to decide whether that code deserves to exist.

AI Made Me Faster, Not Finished

AI coding agents were useful throughout the project.

They helped me explore approaches, generate tests, refactor code, and understand browser-extension issues faster than I could have on my own.

But they didn’t decide the product architecture for me.

They didn’t know which trade-offs mattered most. They didn’t know how much risk I was comfortable with, what users would trust, or what my API budget could support.

And when the generated code was technically correct but wrong for the product, I still had to notice.

That is the part I think gets lost in the “one-prompt SaaS” conversation.

AI can help you reach a prototype surprisingly quickly.

Turning that prototype into something reliable, private, maintainable, and affordable still takes real engineering.

I’m not saying AI coding agents are overhyped. I use them every day.

I just don’t think “AI built my SaaS” is the full story.

A more honest version is:

AI helped me build faster, but I still had to build the product.

You can check out Infill here:

Website: https://useinfill.com
Source code: https://github.com/KaiBelmo/infill

Debugging with AI: Stop Feeding It Files, Start Feeding It Snapshots

kai belmo — Mon, 08 Jun 2026 20:17:10 +0000

AI coding agents are great at reading and understanding code. But debugging? That’s rarely just a code reading problem.

Most bugs surface because something at runtime didn’t behave: a request payload arrived in an unexpected shape, a condition took the wrong branch, a store dropped a field, or a queue handler mangled the data.

When that happens, the AI defaults to what it knows best (scanning files, Handlers, services, types, tests, helpers) It builds a theory from static text. Sometimes that works, but it’s slow, token-heavy, and noisy. The model is forced to infer runtime truth from source code alone, and it often gets it wrong.

What if you could give the AI a clean, structured snapshot of the exact values that mattered?

The AI agent skill that makes debugging less guessy

That’s exactly why I built the snaplog skill.
Instead of asking your assistant to guess where the bug lives, the skill teaches it a tiny, repeatable workflow:

Describe the bug: “Actor, trigger, expected state, observed state.”
The AI identifies the likely boundary: For example, request input, branch decision, state transition, persistence write, or error path.
The AI adds one or two temporary snaplog.injectLog() calls: Only the variables that matter.
You reproduce the bug.
snaplog writes local structured logs: Usually under .debug/debug.log for Node.
The AI reads the snapshots and reasons from runtime facts: It no longer has to infer everything from static source code.
The temporary instrumentation gets removed.

This saves tokens because the AI gets a compact runtime artifact instead of repeatedly searching broad code paths.

Under the hood: the library that makes it work

The skill itself is small on purpose. It works through a focused npm package: @kaibelmo/snaplog.

It’s a local-first TypeScript runtime snapshot debugger that runs in Node.js, browsers, and browser extensions. Think of it as the sweet spot between messy console.log spam and a full-blown observability platform.

Here’s what using it looks like:

import { createSnaplogClient } from "@kaibelmo/snaplog";
import { createNodeSnaplogTransport } from "@kaibelmo/snaplog/node";

const snaplog = createSnaplogClient({
  runtime: "node",
  source: "checkout/applyDiscount",
  transport: createNodeSnaplogTransport(),
  serialize: {
    redactKeys: ["token", "password"]
  }
});

snaplog.injectLog({
  cart,
  discount,
  finalTotal,
  user
});

Run your reproduction steps, and you get clean, structured logs (default path .debug/debug.log):

{
  "event": "snapshot",
  "variable": "finalTotal",
  "value": 89.99,
  "source": "checkout/applyDiscount",
  "timestamp": "..."
}

The library handles safe serialization, automatic redaction of sensitive keys, simple flow tracking, and multiple storage backends (file logs for Node, extension storage for browsers). It’s deliberately minimal, zero-dependency where possible, and gets out of your way once the bug is fixed.

Why the skill and library work better together

With the snaplog skill, the AI isn’t adding random logs. It’s placing temporary snapshots at the exact points that matter, then reading the captured values directly.

Less code scanning. Fewer guesses. Faster debugging.

Instead of making the model imagine runtime state, you give it the facts.

npx skills add KaiBelmo/snaplog

Github repo: github.com/KaiBelmo/snaplog

TypeScript: Not Always the Answer

kai belmo — Thu, 27 Jul 2023 21:03:28 +0000

JavaScript is a versatile and dynamic programming language that allows developers to build a wide range of applications. However, its dynamic nature can sometimes lead to errors and bugs that are challenging to detect during development. To address this, developers often turn to type annotations to provide clarity and ensure code correctness. Two popular approaches for adding type annotations to JavaScript code are JSDoc and TypeScript.

Understanding JSDoc

JSDoc is a comment syntax that can be used to annotate JavaScript code with type information. JSDoc annotations are not enforced by the JavaScript compiler, but they can be used by linters and IDEs to provide static type checking.
JSDoc annotations are written in the form of @tag, where the tag specifies the type or purpose of the annotated element. For example:

/**
 * @type {string}
 */
const randomestring = "42";

JSDoc also supports more complex type annotations, such as custom objects, arrays, and function signatures.

/**
 * @typedef {Object} Foo
 * @property {string} bar
 * @property {number} nda
 */

/**
 * @type {Foo[]}
 */
const randomObj = [
  { bar: "the answer to life, universe and everything", nda: 42 },
  { bar: "random string", nda: 25 }
];

/**
 * @param {Foo} obj
 * @returns {string}
 */
function randomFunction(obj) {
  return `${obj[0].bar} is ${obj[0].nda}.`;
}

Understanding TypeScript

TypeScript is JavaScript on steroids, adding optional static typing and other powerful features to the language. It allows developers to write a more strict form of JavaScript that helps write less error-prone code.

TypeScript needs to be compiled before it can be executed.

interface Foo {
  bar: string;
  nda: number;
}

const randomObj: Foo[] = [
  { bar: "the answer to life, universe and everything", nda: 42 },
  { bar: "random string", nda: 25 }
];

function randomFunction(obj: Foo): string {
  return `${obj[0].bar} is ${obj[0].nda}.`;
}

JSDoc vs. TypeScript: Choosing the Right Approach

Scenario #1 If you are using a framework like Next.js or Vue, there is always a build step. Therefore, you can ignore JSDoc and use TypeScript.
JSDoc is a favorable option over TypeScript in scenarios where faster shipping is crucial due to the absence of compilation steps. Additionally, it proves beneficial when working with third-party JavaScript libraries without TypeScript support, handling small projects or scripts, and when incrementally adding type annotations to existing JavaScript codebases instead of rewriting them in TypeScript.

useful links

Rich Harris (creator of Svelte) talks about Typescript and JSdoc.

learn recursion: the hard way

kai belmo — Wed, 10 Nov 2021 18:50:24 +0000

"To understand recursion, you must first understand recursion."
this joke is completely wrong because if you want to understand recursion you need to check this blog post.