I built a SaaS stack just to give away the product for free (Here is what I learned)

I built a SaaS stack just to give away the product for free (Here is what I learned)

Most people build a SaaS to make money. I built one because I wanted to understand how the plumbing works.

It all started with a frustrating school assignment. I had to turn in a project and include polished screenshots of my code. The standard way to do this involves copying your code, opening a website, pasting it, downloading the image, and repeating that loop for 20+ different files. It felt like a massive waste of time, so I decided to automate it.

I ended up creating SyntaxShot—a CLI tool that turns your code into clean, syntax-highlighted images directly from your terminal.

But instead of just keeping it as a local script, I decided to go all the way. I built a landing page, set up user documentation, and integrated a full Stripe billing system with a Pro tier—even though my free tier is so capable that I honestly don't expect anyone to pay for it.

Here are my main takeaways from shipping a real dev tool from scratch:

1. Heavy native dependencies are a DX nightmare Initially, looking at code-to-image tools, many rely on heavy native graphic libraries. If you've ever tried to install a Node package that requires compiling Cairo, GTK, or specific Windows Build Tools locally, you know how easily it breaks.

The fix: I built the rendering pipeline using Vite, React, Shiki (for exact syntax highlighting), and @napi-rs/canvas.

The result: @napi-rs/canvas ships with prebuilt binaries for Windows, macOS, and Linux. It just works instantly out of the box with zero native compilation pain.

1. Recursive file structures require care When I added the directory scanning feature (running syntaxshot ./src), the first naive attempt just dumped every single image into a flat folder. If you had index.js in three different subdirectories, they would overwrite each other.

I had to rewrite the algorithm to map and mirror the exact subfolder structure into the output directory, ensuring file names never conflict.

I also learned the hard way that you need a strict exclusion list. Nobody wants screenshots of their node_modules, lockfiles, or .env configurations cluttering their space.

1. Shipping > Perfection (and the role of AI) I'll be completely transparent: I used AI heavily to help me move fast, unblock logic, and bootstrap the boilerplate code. But my rule was strict: never copy-paste blindly. I forced myself to review, break down, and understand exactly what every function was doing. Using AI as a collaborative peer allowed me to focus on the big picture: architectural choices, deployment, and user experience.

Why go through the trouble of a Pro tier?
SyntaxShot has a Pro tier that unlocks folder scanning, SVG exports, and extra themes. But honestly? The Free tier gives you everything you need for individual file captures.

I didn't build this to get rich. I built it to learn how to hook up a Stripe payment gateway, manage API validation caching (the tool caches licenses locally for 7 days to allow offline usage), and structure production-ready code.

The tool is completely live and open for testing. I’m looking for real, raw feedback. If you think the implementation is messy or want to roast my architecture, please go ahead in the comments—I'm here to learn!

Check the site: https://syntaxshot.dev

Run it: npm i syntaxshot-cli