The Tools to Build SaaS Solo: My Full CyberSygn Stack

Most SaaS stacks are bloated with tools that just sounded impressive. Here is the small one I actually ship with, every day, alone.

Pick the wrong tools to build SaaS and you end up spending more time managing your stack than building the product, which is a lesson I learned the slow and expensive way. CyberSygn now runs on a deliberately small set of tools, and every single one earns its place by being something I genuinely open and use rather than something that merely looked impressive on a conference slide. Over the first year I swapped out several pieces as the real constraints made themselves known, and what survived is lean by design instead of by accident. In this post you will get the complete CyberSygn stack broken into runtime, payments, and frontend, along with the honest reason each piece made the cut. If you are building a solo SaaS and want a map you can actually copy, this is it.

Runtime and storage: one platform that costs almost nothing

Start with where the code actually lives, because that one decision shapes almost everything downstream. CyberSygn runs on Cloudflare Workers. The code executes at the edge, close to the user, deploys in seconds, and at the volume I handle it costs almost nothing. For short-term state I use Cloudflare KV, a simple key-value store. You can picture it as a fast notepad the application reads from and writes to constantly. For the heavy files, meaning the signed PDFs and audit certificates, I use R2. That is long-term blob storage, which just describes big files that need to sit somewhere safe for years. The metrics dashboard runs on Analytics Engine, so even my reporting stays inside the same family of tools. The key choice underneath all of this is that everything lives inside the Cloudflare ecosystem. That gives me one platform, one bill, and one place to operate. As a solo founder, that single-vendor simplicity is worth far more than squeezing out a theoretically perfect component for each job, and it forms the backbone of a clean Cloudflare Workers stack. One more point is worth making about cost, because people assume a real product demands a fat server bill when it genuinely does not. Workers bills by actual use, so a quiet hour costs nothing while a busy hour costs only cents. That pricing model is precisely what lets one person run a full e-signature service without a single machine to patch or reboot, and it shapes every other choice in my list of tools to build SaaS.

Payments and email: the two systems you cannot get wrong

Two parts of any SaaS simply have to work, namely taking money and sending mail, so I refuse to improvise anywhere near either one. For billing I use Stripe, which handles both the monthly Solo subscription and the higher-volume Studio plan, while the Stripe Customer Portal lets customers manage their own plan so I never have to touch a billing change by hand. For email I use Resend, which sends every transactional message the product produces, from the signing-flow emails to the welcome drip to the monthly owner report. Deliverability is the part most founders quietly skip and then come to regret, so I set up DKIM, SPF, and DMARC from the very start, three email security records that prove your mail is genuinely from you and keep it landing in the inbox rather than the spam folder. Resend handles the difficult mechanics of actually getting mail delivered, which means I do not have to babysit it, and for an indie SaaS stack that kind of boring reliability is exactly what you want. The broader lesson here is really about knowing where to be cheap and where not to be. I am perfectly happy to hand-write a frontend to save money, but I am not willing to roll my own billing or run my own mail server, because money and email are the two systems where a small bug turns directly into a lost customer or a missed payment. Those areas get paid, trusted tools, and everything else gets the lean treatment.

Frontend and dev tools to build SaaS without a framework

Here is the choice that tends to surprise people, which is that the frontend uses no framework at all. The marketing site, the dashboard, and the signing flow are written by hand in plain HTML, CSS, and JavaScript, which means there is nothing to update on a schedule, no build step waiting to break, and no framework churn to chase every six months. For the PDFs I rely on pdf-lib to generate and flatten documents and pdf.js to render them in the browser, and when my detection logic needs a vision fallback it calls Anthropic Claude Sonnet 4.5 to handle the harder cases. The shipping setup is just as plain, because GitHub holds the source, GitHub Actions runs the tests on every push, and Wrangler pushes the deploy, and that really is the whole pipeline. When you are building solo SaaS tools, boring is genuinely a feature rather than a compromise, because every fancy choice is one more thing you alone have to maintain at two in the morning, while plain tools let you spend your hours on the product instead of the plumbing. One rule sits behind all of these tools to build SaaS solo, which is that every piece must be something I can hold entirely in my head. If I cannot explain what a tool does and why it is there, it does not belong in the stack, because a framework I only half understand is really a future outage I will not be able to debug. So I keep the list short on purpose and add a new tool only when the pain of not having it has become real and repeated, never simply because it looks clever.