William Arthur founded Camelot Web Tools in June 2026 while studying business at Western Governors University, and launched the product at camelotwebtools.com as a solo, self-funded effort. The premise is straightforward: freelancers and small businesses juggle a long list of unglamorous but necessary documents and calculations — proposals, statements of work, invoices, time tracking, tax estimates, cash-flow projections — and most of them either pay for several separate subscription tools to cover it, or do it manually in spreadsheets. Camelot Web Tools bundles a reported 79 individual tools across four categories — client work, finance and billing, business operations, and developer utilities — into a single browser-based suite, with a free tier and paid plans layered on top.

The actual technical differentiator, not just the tool count

The more interesting detail isn’t the breadth of the tool list — plenty of “business toolkit” products exist — it’s the processing model. Camelot Web Tools runs entirely client-side, executing in the browser via WebAssembly and JavaScript rather than sending data to a server. The product’s own description is specific about what that means in practice: “zero network transmission of client files, invoices, or financial records.” For the exact category of documents this tool handles — client proposals, invoices, financial statements — that’s a real, meaningful privacy claim, not a marketing flourish: a freelancer’s financial and client data never leaves their own device to be processed at all, as opposed to being processed remotely and merely encrypted in transit. Building an entire multi-tool suite this way is also a genuinely harder engineering choice than a standard server-backed SaaS product, since every calculation and document generator has to run correctly inside the browser itself.

What building it has actually involved

Arthur describes the work so far in fairly unglamorous, accurate terms: preparing the product for public use, setting up pricing and license delivery, handling deployment, and iterating on usability and reliability — the real, less visible work of getting a self-funded product from a working build to something strangers can actually sign up for and trust with their invoices. He’s doing this while enrolled in a business program at WGU, which puts Camelot Web Tools in a specific and fairly common category of founder story: someone building a real, technically substantial product part-time, without outside funding, while still formally studying the business side of what they’re doing.

The honest state of the business right now

Camelot Web Tools is pre-revenue, and Arthur doesn’t frame it otherwise — by his own account, the current challenge isn’t building more features, it’s reaching the freelancers and small businesses who’d actually use this and figuring out what makes them come back. That’s the standard, difficult distribution problem every bootstrapped, pre-marketing-budget product runs into after the build is done: a genuinely useful, well-architected tool with effectively no audience yet is still an unproven business, whatever the engineering underneath it looks like.

The local-first architecture here is a real, checkable technical claim rather than a vague pitch, and it’s worth watching whether a privacy-first positioning is enough to help an unfunded, one-person toolkit find its early users in a category full of larger, server-based competitors.

Camelot Web Tools is live at camelotwebtools.com.