A few months ago, I was helping a friend set up her freelance business. She needed a privacy policy for her website, a way to generate invoices, and QR codes for her business cards. Simple stuff.
What wasn't simple was the experience of actually getting these things done.
Every "free" privacy policy generator wanted her email before showing results. Every invoice tool required creating an account. Every QR code site was plastered with ads and upsells. And the kicker? Most of these tools were sending her data to some server she'd never heard of.
I'm a web developer. I knew I could build something better. So I did.
ToolKit.dev is a collection of free business tools that run entirely in your browser. No accounts. No server-side processing. No data collection. Your information never leaves your machine.
Here's how I built it, why I made the technical choices I did, and how I'm turning it into a sustainable business without compromising on privacy.
The Tools
Right now, ToolKit.dev has three core tools:
1. Privacy Policy Generator
You answer a few questions about your website — what data you collect, whether you use cookies, if you serve users in the EU or California — and it generates a GDPR and CCPA compliant privacy policy. No lawyer required for basic coverage.
2. Invoice PDF Generator
Fill in your business details, add line items, set tax rates and discounts, and download a professional PDF invoice. It handles multiple currencies, calculates totals automatically, and produces clean, print-ready documents.
3. QR Code Generator
Generate QR codes for URLs, WiFi passwords, vCards, email addresses, and more. Customize colors and sizes. Download as PNG. All generated client-side.
Every tool works the same way: you interact with it in the browser, everything is processed locally with JavaScript, and the output is yours. I never see it.
The Tech Stack (And Why It's Boring on Purpose)
Here's the part that might surprise some developers: there's no React. No Next.js. No Tailwind. No build step. No node_modules folder with 847 packages.
The entire site is static HTML, CSS, and vanilla JavaScript, hosted on Cloudflare Pages.
Why vanilla JS?
Because these tools don't need a framework. A privacy policy generator is fundamentally a form that produces text output. An invoice generator is a form that produces a PDF. A QR code generator takes input and renders an image.
React's virtual DOM diffing doesn't help here. Server-side rendering doesn't help here. A 200KB JavaScript bundle to hydrate a form doesn't help here.
What helps is:
- Fast page loads. The entire site loads in under a second on a 3G connection. No waiting for JS bundles to download and parse.
- Zero dependencies to maintain. No Dependabot PRs. No breaking changes from upstream. No supply chain attacks.
- Easy to understand. Any developer can read the source and know exactly what's happening. There's no framework magic to trace through.
For PDF generation, I use a lightweight client-side library. For QR codes, same approach — a small, focused library that runs in the browser. That's it. The rest is hand-written HTML, CSS, and JS.
Why Cloudflare Pages?
Three reasons:
- It's free. For a static site, Cloudflare Pages costs literally nothing. Unlimited bandwidth. Unlimited requests. Free SSL.
- It's fast. Cloudflare's edge network means the site loads quickly everywhere in the world.
- It's simple. Push to a Git branch, site deploys automatically. No CI/CD to configure, no Docker containers to manage, no servers to patch.
The total hosting cost for ToolKit.dev is $0/month.
Why Client-Side Processing Matters
This is the hill I'll die on.
When you use a typical "free" online tool — a PDF converter, an image resizer, a document generator — your files get uploaded to someone's server. That server processes your data and sends the result back.
What happens to your data on that server? Usually, the privacy policy says something like "we may retain uploaded files for up to 24 hours for quality assurance purposes." Sometimes they're more honest: "we may use uploaded content to improve our services" (read: train models).
For business tools, this is a real problem:
- Privacy policies contain details about your business practices. You probably don't want those sitting on a random server.
- Invoices contain your name, address, bank details, client information, and financial data. This is sensitive information.
- QR codes might encode WiFi passwords, private URLs, or contact details.
With ToolKit.dev, none of this is an issue. The tools run JavaScript in your browser tab. Your data exists in browser memory while you're using the tool and disappears when you close the tab. There's no server to hack, no database to breach, no logs to subpoena.
I don't have access to your data because your data never reaches me. That's not a policy — it's architecture.
Building the Privacy Policy Generator
Let me walk through how one of these tools works under the hood, because I think it illustrates the approach well.
The privacy policy generator presents a multi-step form. Each step asks about a different aspect of your site: what personal data you collect, whether you use cookies or analytics, whether you process payments, whether you serve EU or California residents, etc.
As you fill in the form, JavaScript builds up a configuration object. When you hit "Generate," a function takes that object and constructs the privacy policy text, section by section.
Each section is conditionally included based on your answers. If you don't collect email addresses, there's no section about email data processing. If you don't serve EU users, the GDPR sections are omitted. The result is a policy that's relevant to your actual business, not a generic template bloated with irrelevant clauses.
The generated policy is rendered as formatted HTML that you can copy, or you can download it. The entire process happens in one browser tab, in one session, with zero network requests after the initial page load.
Is this a replacement for hiring a lawyer? No. But for a freelancer putting up their first website, it's infinitely better than having no privacy policy at all — or copying one from another site (which is both legally questionable and often inaccurate).
The Business Model
Here's the part where I explain how this makes money without selling user data or plastering the site with ads.
The tools are free. Completely free, no catches. They'll stay free.
Revenue comes from two sources:
1. Digital Products
I sell practical resources for freelancers and small business owners:
- The Cold Email Playbook — 50 proven email templates organized by scenario (cold outreach, follow-ups, negotiation, etc.), with explanations of why each template works. $9.
- The Freelancer Business Kit — proposal templates, contract templates, invoice layouts, email scripts, pricing frameworks, and onboarding checklists. Everything you need to run the business side of freelancing. $19.
- The Legal Templates Pack — Terms of Service, DMCA Policy, Cookie Policy, Refund Policy, and Acceptable Use Policy templates with customization guides. $14.99.
These products are sold through Payhip, so purchases are handled entirely off-site. No payment processing on my end, no storing credit card numbers, no PCI compliance headaches.
2. Content Marketing / SEO
The site has a growing content hub with articles targeting keywords that freelancers and small business owners search for. Articles like guides on GDPR compliance, invoicing best practices, and how to get freelance clients.
These articles drive organic traffic to the tools, and the tools drive awareness of the digital products. It's a flywheel: content brings traffic, tools provide value and build trust, products monetize the audience that finds value in the free tools.
No ads. No affiliate links masquerading as recommendations. No dark patterns.
Lessons Learned
Start with the simplest thing that works. I could have spent months building a full-stack app with user accounts, saved documents, collaboration features, and a subscription model. Instead, I shipped three static tools in a fraction of the time. They work. People use them. I can always add complexity later.
Boring technology is a feature. Using vanilla HTML/CSS/JS means I spend my time building tools, not fighting tooling. No webpack configs to debug. No hydration mismatches to track down. No "works in dev, breaks in prod" surprises.
Privacy as architecture beats privacy as policy. Any company can write a privacy policy that says "we respect your privacy." Very few companies architect their products so that user data literally cannot be accessed by the company. The latter is a much stronger value proposition.
Free tools are the best marketing. Every person who generates a privacy policy or creates an invoice is a person who now associates ToolKit.dev with "that site that helped me for free." Some percentage of those people will need a cold email template or a freelancer contract, and they'll remember where they got help before.
What's Next
I'm planning to add more tools based on what freelancers and small business owners actually need. A contract generator is high on the list. So is a proposal template builder and a simple business name generator.
I'm also expanding the content hub with more in-depth guides. The goal is to be the go-to resource for solo operators who want practical tools and advice without the enterprise bloat or the upsell pressure.
If you want to check it out, the site is live at https://toolkit-dev.pages.dev/. Every tool is free. No signup required. Your data stays in your browser.
If you're a developer thinking about building something similar, my advice is: start simple, ship fast, and optimize for trust. The web has enough bloated SaaS apps. Sometimes people just need a tool that works.
Have questions about the tech stack or the business model? Drop them in the comments — happy to go deeper on anything.
Top comments (0)