How Scribi is built.

Hand-coded foundations

Scribi Writer’s Studio began as a passion project years before AI-assisted development tools existed. Every core system — the editor engine, the project architecture, the data models, the sync layer — was designed and written by hand. That foundation still runs underneath everything you see today.

When Anthropic released Claude Code, I adopted it as a development partner. It accelerates the pace at which a one-person team can ship features, write tests, and iterate on design. But the architecture, the decisions, and the accountability remain mine.

What “vibe coding” is, and why this isn’t that

“Vibe coding” is a term for a recent trend where developers prompt an AI to generate an entire application, then ship the output with little or no review. The results have been predictably bad. In just the short time this practice has been widespread, vibe-coded applications have been responsible for:

• API endpoints left completely open — no authentication, no authorization, no rate limiting — allowing anyone on the internet to read, write, or delete data.
• User credentials, personal information, and payment details exposed to third parties through missing access controls and improperly configured databases.
• Secrets and API keys hardcoded into client-side code, visible to anyone who opens their browser’s developer tools.
• No input validation, enabling injection attacks, cross-site scripting, and data corruption.

These are not edge cases. They are the natural consequence of shipping code that nobody actually read. That is not how PlotFoundry works.

How I actually use Claude Code

Claude Code is a powerful tool, and like any powerful tool, the quality of the result depends on the person using it. Here is what my development process looks like:

• I review all code. Every function, every endpoint, every security rule — I read it, understand it, and verify it before it ships. Claude Code writes code faster than I could alone, but nothing goes to production without my review.
• I design the architecture. Claude Code does not decide how the application is structured, how data flows between services, or where security boundaries live. Those decisions are mine, informed by years of building this software.
• I scan for security issues regularly. I audit endpoints, review Firestore security rules, test authorization flows, and verify that access controls work as intended. This is ongoing, not a one-time checkbox.
• I manage the servers and APIs personally. Backend services, Cloud Functions, database configuration, deployment pipelines — I maintain direct control over every layer of the infrastructure that connects your desktop application to our backend.

The result is software built at the pace of a much larger team, with the attentiveness and accountability of a single developer who cares deeply about getting it right.

The PlotFoundry platform

The website you’re reading right now is a React single-page application built with Vite, running entirely on Google Cloud services. The backend uses Firebase Authentication, Cloud Firestore for the database, Cloud Storage for file hosting, and Cloud Functions for server-side logic. Firebase Hosting serves the static build.

This stack was chosen deliberately. PlotFoundry is niche software — it serves novelists and indie authors, not millions of concurrent users. Firebase’s managed infrastructure scales automatically within that range without requiring me to babysit servers, which is exactly the right tradeoff for a one-person operation. The platform is stable, responsive, and cost-effective at its current scale.

That said, the architecture isn’t painted into a corner. If future expansions of the platform — reader-facing features, for example — demand more specific scaling infrastructure like Firestore sharding, dedicated compute, or a different backend entirely, the service boundaries are clean enough to accommodate that. I build for what the product needs today while keeping the door open for what it might need tomorrow.

Scribi Writer’s Studio under the hood

The desktop application is an Electron-wrapped app with a Nuxt server running internally and Vue powering the UI layer. That might sound like an unusual choice, so here’s why.

The Nuxt server acts as an internal security and communication layer. As Scribi rolls out API connections, user-to-user features, and cloud sync, the server mediates all of that traffic while Electron’s main process stays isolated — protecting system-level access from anything happening on the network side. The server also continues running in the background when Scribi’s main application window is closed, which enables features like the MCP (Model Context Protocol) server. That means AI assistants on your machine — like the Claude desktop app — can interact with your Scribi data without the app needing to be open on your desktop, and Scribi’s own built-in AI assistant works through that same toolset natively, using an OpenRouter or OpenAI API key you provide. There’s no generally open port in the MCP layer — it’s only available locally. Future developments in desktop AI tooling may eventually allow tunneling from a phone or browser, but that’s not currently configured, and I’ll be keeping pace with those plugin ecosystems as they mature. The UI is built with Nuxt UI 4, which keeps the interface stable, flexible, and attractive without requiring a massive custom component library.

For local data, Scribi uses PostgreSQL — the very same database engine that powers its cloud. A relational database was always the plan; the querying power is essential to how Scribi organizes projects, manuscripts, and research. Postgres is fast, battle-tested, and remarkably versatile, handling everything from simple lookups to deep relational queries with ease and scaling cleanly from a quiet desktop install all the way up to demanding cloud workloads. Where other writing software has to keep large datasets loaded in memory, Scribi queries only what it needs at any given moment.

Running the same engine on the desktop and in the cloud is a deliberate decision. Your local data and its cloud mirror share an identical structure, which gives us perfect 1:1 cloud syncing with no lossy translation between two different systems. It also lays the groundwork for capabilities planned down the road — vector embeddings and semantic search, both inside Scribi and across Readerling — that will eventually let readers discover books and authors in more intuitive ways than ever before.

A couple of other pieces worth mentioning. Semantic search is on the roadmap rather than shipped today, and when it lands the plan is to run embeddings through a local engine — generating vectors right on your machine, so you won’t need an internet connection and won’t pay for tokens. At the scale Scribi would generate embeddings, sending that work to a cloud endpoint would be expensive for the end user, so keeping it local is the right call. In the meantime, Scribi runs LanguageTool locally as a server process for grammar and style checking; it ships with a minimal, locally packaged JRE that keeps its memory footprint light.

Security in depth

PlotFoundry employs multiple layers of protection to keep your data safe:

• Authorization gating: Every API endpoint verifies identity and permissions. Unauthenticated requests are rejected. Endpoints that handle sensitive operations require email verification, valid tokens, and role checks.
• Data validation: All user input is validated both client-side and server-side. Firestore security rules enforce strict access controls at the database level — the client is never trusted as the sole authority.
• Rate limiting: API endpoints are rate-limited to prevent abuse, brute-force attacks, and automated scraping.
• Content sanitization: User-generated content is sanitized before storage and again before rendering to prevent cross-site scripting and injection attacks.
• No secrets on the client: API keys, signing keys, and service credentials live exclusively on the server. The only configuration exposed to the browser is the public Firebase config required for authentication.
• Encryption & data isolation: All data is encrypted in transit (TLS) and at rest. Cloud-synced content is protected by row-level security, so each account’s data is only ever accessible to that account — there is no path around it. Every write to the cloud is mediated and validated by our own server layer, so the client has no SQL injection vector to exploit.
• Template integrity: Scribi templates (.scrib files) are cryptographically signed and validated on both import and export to prevent tampering or injection of malicious content.

For a full description of how we handle your data, see our Privacy Policy.

Why this matters for desktop software

Web applications run in a browser sandbox — they have limited access to your system. Desktop applications are different. An Electron-based app like Scribi runs with direct access to your filesystem, your hardware, and potentially sensitive data stored in system-level secure channels: saved passwords, biometric data, authentication tokens, and more. That’s true of any Electron app, or any native desktop application for that matter.

When you install Scribi from PlotFoundry, you’re getting software whose backend connections are gated and authenticated, whose API is broken into specialized areas of concern, and whose code has been reviewed and tested by the person who wrote it. When you download a “free” knockoff or a cracked copy from an unknown source, you have no such guarantees. That software could be doing anything with the system-level access that a desktop application inherently has — scraping credentials, exfiltrating personal files, or opening a persistent backdoor to your machine.

I want to be straightforward about this: I don’t invest in hardening the client-side application against reverse engineering. Someone motivated enough can look at how Scribi works, take screenshots, and prompt an AI to build a lookalike. They can unbundle the macOS build and read the source code if they really want to. But that copy won’t authenticate with PlotFoundry’s servers, it won’t receive updates, and it won’t come with any of the backend services, security infrastructure, or ongoing development that make Scribi what it is. More importantly, if someone else is distributing that build, you have no idea what they’ve added to it.

For more on what this means for you as a user and what to do if cost is a barrier, see the About page.

Your part in the equation

No platform can fully protect an account whose password has been compromised. Like any service, the security of your account also depends on you:

• Use a strong, unique password that you don’t reuse across other services.
• Keep your email account secure — it’s the recovery path for your Plot Foundry account.
• Don’t share your license key or login credentials with others.

If you do your part, I’ll do mine. That’s the deal.

Why I’m telling you this

Most companies don’t disclose their development tools. I’m choosing to because I think authors deserve to know how the software they trust with their work is built. AI-assisted development is genuinely useful — it lets me build and maintain a platform that would otherwise require a full team. But “AI-assisted” is not the same as “AI-generated and shipped without oversight.”

Every feature, every security measure, and every line of code on this platform has a human being behind it who understands what it does and why it’s there. That human is me, and I take that responsibility seriously.

If you have questions about how PlotFoundry is built or how your data is protected, I’m always reachable by email at brian@plotfoundry.com.