diff --git a/src/routes/blog/post/agency-backend-standardization/+page.markdoc b/src/routes/blog/post/agency-backend-standardization/+page.markdoc
new file mode 100644
index 0000000000..b1bc06d9f1
--- /dev/null
+++ b/src/routes/blog/post/agency-backend-standardization/+page.markdoc
@@ -0,0 +1,85 @@
+---
+layout: post
+title: "How agencies standardize backend stacks across clients"
+description: Why development agencies benefit from standardizing their backend stack and how to choose a platform flexible enough to serve diverse client needs.
+date: 2024-05-03
+cover: /images/blog/agency-backend-standardization/cover.png
+timeToRead: 6
+author: aditya-oberai
+category: product
+featured: false
+unlisted: true
+---
+
+Running a development agency means context-switching constantly. One client needs an e-commerce platform, another needs a healthcare app, a third wants an internal operations tool. Each project has different requirements, but if each one also uses a different backend stack, you've built yourself an operational nightmare.
+
+The most efficient agencies solve this by standardizing. Not by forcing every project into the same shape, but by choosing a backend platform flexible enough to serve diverse client needs while being familiar enough that every developer on the team can hit the ground running.
+
+## The hidden cost of backend fragmentation
+
+When each client project uses a different backend technology, the costs compound quickly:
+
+- **Onboarding overhead.** A new developer joining the agency has to learn the stack for each active project before they can contribute. If Project A uses Firebase, Project B uses Supabase, and Project C uses a custom Rails API, that's three different mental models to maintain.
+- **Debugging across unfamiliar systems.** When something breaks in production on a project where the original developer has moved on, the team inherits a system they don't know well.
+- **No knowledge reuse.** Solutions built for one client (authentication flows, file upload handling, role-based access patterns) can't easily be reused across clients if the underlying platforms differ.
+- **Inconsistent security posture.** Different platforms have different security defaults. Standardizing means your security practices travel with your stack.
+- **Longer estimation and scoping.** When a developer scopes a new project on a familiar platform, they can estimate accurately. Unfamiliar platforms introduce risk that's hard to price.
+
+## What agencies actually need from a backend platform
+
+Agencies have a distinct set of requirements compared to product companies:
+
+- **Multi-tenancy or project isolation.** Client data must be isolated. Each project needs its own databases, storage, and access policies.
+- **Fast project setup.** Agencies bill by the hour. Spinning up a new backend environment in minutes rather than days is a real business advantage.
+- **Breadth of features.** Authentication, databases, file storage, serverless functions, and messaging in one platform means fewer vendors to manage per project.
+- **Self-hosting or data ownership options.** Enterprise and regulated clients sometimes require that their data not leave their controlled environment.
+- **Reasonable pricing at varying scale.** Agency clients range from early-stage startups to mid-market businesses. The backend platform needs to be economical at small scale and not punitive at medium scale.
+- **Good documentation and community.** Developers solve problems faster when the platform has thorough documentation and an active community.
+
+## How standardization works in practice
+
+Agencies that have standardized their backend stack typically follow a pattern:
+
+**1. Choose a platform that can grow with client projects.** The backend that works for a small client's MVP needs to also work when that client's user base grows by 10x. Platforms that charge per API call or per database record quickly become expensive at scale.
+
+**2. Build internal templates and starter kits.** Once you've standardized on a platform, build your own starting points: authentication flows, admin panel scaffolding, standard database schemas for common use cases. These internal tools pay off across every subsequent project.
+
+**3. Train the team once, benefit continuously.** Invest in getting the whole team proficient on the chosen platform. The return on that training investment compounds with every project you ship.
+
+**4. Use the platform's organizational features.** Most backend platforms offer organizations, teams, or workspaces for managing multiple projects. Use them consistently so there's a clear structure that any team member can navigate.
+
+**5. Document your patterns, not just the platform.** Your team's specific conventions (how you name collections, how you structure permissions, how you handle file uploads) should be documented alongside the platform documentation.
+
+## Evaluating a backend platform for agency use
+
+When choosing a platform to standardize on, test it against a realistic agency project:
+
+- How long does it take to spin up a new project from scratch?
+- Can you replicate a project structure for a new client without starting from zero?
+- How does it handle multiple environments (development, staging, production)?
+- Is there a CLI or API for automating project setup?
+- How are credentials and secrets managed across multiple projects?
+- Can clients get access to their own data without accessing your team's account?
+
+## Appwrite for agency teams
+
+Appwrite is an open-source developer infrastructure platform for building web, mobile, and AI apps. It includes both a backend server, providing authentication, databases, file storage, serverless functions, real-time subscriptions, and messaging, and a fully integrated hosting solution for deploying static and server-side rendered frontends. Appwrite can be fully self-hosted on any Docker-compatible infrastructure or used as a managed service through [Appwrite Cloud](https://cloud.appwrite.io).
+
+Appwrite is particularly well-suited to agency workflows:
+
+- **Project isolation**: Appwrite's project-based structure gives each client their own authentication system, database, storage, and functions within a clean, isolated boundary, while remaining manageable from a single Appwrite installation or organization.
+- **Fast project setup**: The [Appwrite CLI](https://appwrite.io/docs/tooling/command-line/installation) supports scripted project creation and configuration, making it straightforward to automate new client environment setup from a template.
+- **Full-stack coverage**: Authentication, databases, storage, functions, real-time, and messaging in one platform means fewer third-party integrations to manage per project and a consistent mental model across all client work.
+- **Self-hosting for regulated clients**: Agencies working with enterprise or compliance-sensitive clients can deploy Appwrite within those clients' own cloud accounts, satisfying data residency requirements without switching to a different backend stack.
+- **Client access controls**: Appwrite's team and membership system lets you give client stakeholders read or admin access to their own project without exposing your team's other client environments.
+
+## Start standardizing your agency's backend stack
+
+Standardization is one of the highest-leverage decisions an agency can make. The right backend platform becomes a multiplier on every developer's productivity across every client engagement.
+
+[Appwrite](https://appwrite.io) is particularly well-suited for agency use. Its project-based structure isolates each client's data, authentication, storage, and functions within a clean boundary. The [Appwrite CLI](https://appwrite.io/docs/tooling/command-line/installation) supports scripted project setup, making it straightforward to automate the creation of new client environments. Appwrite's self-hosting option means agencies working with enterprise or regulated clients can deploy within those clients' own cloud accounts when required. With authentication, databases, storage, functions, and messaging all in one platform, there's very little that a typical agency project requires that Appwrite doesn't cover.
+
+- [Appwrite Teams documentation](https://appwrite.io/docs/products/auth/teams)
+- [Appwrite CLI docs](https://appwrite.io/docs/tooling/command-line/installation)
+- [Appwrite Sites documentation](https://appwrite.io/docs/products/sites)
+- [Sign up for Appwrite Cloud](https://cloud.appwrite.io)
diff --git a/src/routes/blog/post/appwrite-vs-vercel-vs-netlify/+page.markdoc b/src/routes/blog/post/appwrite-vs-vercel-vs-netlify/+page.markdoc
new file mode 100644
index 0000000000..874417bc2b
--- /dev/null
+++ b/src/routes/blog/post/appwrite-vs-vercel-vs-netlify/+page.markdoc
@@ -0,0 +1,139 @@
+---
+layout: post
+title: "Appwrite vs Vercel vs Netlify: where does your stack live?"
+description: What Vercel and Netlify actually provide versus Appwrite's full-stack platform, and how to decide between consolidating your stack or mixing services.
+date: 2024-06-14
+cover: /images/blog/appwrite-vs-vercel-vs-netlify/cover.png
+timeToRead: 7
+author: aditya-oberai
+category: product
+featured: false
+unlisted: true
+---
+
+If you ask a developer what Vercel and Netlify do, you'll get a clear answer: they host frontend applications. Fast deployments, CDN-delivered static assets, serverless functions for edge logic. They're excellent at what they do. But they're not full-stack platforms, and treating them as the foundation of your entire stack creates architectural gaps that show up later as bugs, security incidents, or features that are much harder to build than they should have been.
+
+The key question is not which hosting platform is better. It is what each layer of your stack is actually responsible for, and whether your current setup covers the complete surface area of your application's needs.
+
+## What Vercel and Netlify are (and aren't)
+
+Vercel and Netlify are frontend deployment and hosting platforms. Their primary value is in the delivery layer:
+
+- Automatic deployments from Git
+- Global CDN distribution for static assets
+- Preview environments for every pull request
+- Serverless functions (Edge Functions, API Routes, Netlify Functions) for server-side logic
+- Build pipeline integrations for popular frontend frameworks (Next.js, Gatsby, Astro, etc.)
+
+What they are **not** is a complete backend. Specifically, they don't provide out of the box:
+
+- **A persistent database.** Serverless functions on Vercel or Netlify don't have a built-in database. You bring your own: Postgres on PlanetScale or Neon, a NoSQL database on MongoDB Atlas, or another service.
+- **User authentication.** There is no built-in user management, session handling, or OAuth integration. You bring your own: Auth0, Clerk, NextAuth, or another service.
+- **File storage.** No built-in file upload or storage system. Developers typically reach for AWS S3, Cloudflare R2, or similar.
+- **Real-time.** No native WebSocket or real-time subscription primitives.
+- **Server-side business logic with persistent state.** Serverless functions are stateless and short-lived by design.
+
+The result is that building a full application on Vercel or Netlify means stitching together multiple third-party services (one for auth, one for database, one for storage, one for email), each with its own API, SDK, billing, and maintenance burden.
+
+## What Appwrite is
+
+Appwrite is a full-stack platform. [Appwrite Sites](https://appwrite.io/docs/products/sites) handles frontend hosting and deployment, while the rest of the platform covers the complete backend: authentication, databases, file storage, serverless functions, messaging, and real-time.
+
+### Frontend hosting with Appwrite Sites
+
+Appwrite Sites handles frontend deployment with the features you'd expect from a modern hosting platform:
+
+- **Git-based deployments.** Connect a repository, select a branch, and Appwrite automatically builds and deploys on every push.
+- **Global distribution.** Sites are served across the Appwrite Network's edge locations, reducing latency worldwide.
+- **Branch and commit URLs.** Every branch and commit gets its own URL, so you can preview and share changes before activating them.
+- **Custom domains.** Attach your own domain via CNAME, ALIAS/ANAME, or nameserver delegation. TLS certificates are provisioned and managed automatically.
+- **DDoS protection and WAF.** Security infrastructure is included by default.
+- **Framework support.** Starter kits for Next.js, Nuxt, SvelteKit, Astro, Vue, TanStack Start, and more.
+- **CLI and manual deploy.** Beyond Git, you can deploy via the Appwrite CLI or by uploading a `.tar.gz` build artifact directly.
+
+### Backend services
+
+Appwrite's backend covers everything a production application needs without reaching for separate services:
+
+- **Authentication.** Email/password, OAuth2 (Google, GitHub, Apple, and 30+ other providers), phone/SMS, anonymous sessions, multi-factor authentication, and team-based access control.
+- **Databases.** A document-oriented database with collections, indexes, real-time subscriptions, and a query system with support for filtering, ordering, and pagination.
+- **File storage.** Managed file uploads with bucket-level and document-level permissions, file type restrictions, size limits, and antivirus scanning.
+- **Serverless functions.** Server-side logic with support for multiple runtimes (Node.js, Python, PHP, Ruby, Dart, Swift, Kotlin, Go, and more), triggered by HTTP requests, events, or schedules.
+- **Messaging.** Push notifications, email, and SMS messaging with support for topics and subscriber management.
+- **Real-time.** WebSocket-based subscriptions that let clients listen for changes to documents, collections, files, or any Appwrite resource.
+
+Appwrite is fully open source and can be self-hosted on any Docker-compatible infrastructure.
+
+## How Appwrite fits into your architecture
+
+Depending on your situation, there are two ways to use Appwrite.
+
+### Appwrite as your entire stack
+
+Your frontend deploys to Appwrite Sites; your backend (auth, database, storage, functions) runs in the same Appwrite project. One platform, one dashboard, one billing relationship. Your frontend and backend share the same environment variables and can be managed from a single console with no cross-platform configuration to maintain.
+
+```js
+// In a Next.js app deployed to Appwrite Sites
+import { Client, Account, Databases } from 'appwrite';
+
+const client = new Client()
+    .setEndpoint('https://<REGION>.cloud.appwrite.io/v1')
+    .setProject('<PROJECT_ID>');
+
+const account = new Account(client);
+const databases = new Databases(client);
+
+const user = await account.get();
+const posts = await databases.listDocuments('<DATABASE_ID>', '<COLLECTION_ID>');
+```
+
+### Appwrite backend with Vercel or Netlify for frontend
+
+If your frontend is already on Vercel or Netlify, or your use case benefits from their specific ecosystem (Next.js optimizations on Vercel, for example), Appwrite works cleanly as the backend layer alongside either platform.
+
+- **Vercel or Netlify** handles frontend hosting, CDN delivery, and deployment automation
+- **Appwrite** handles user authentication, data storage, file management, and backend functions
+
+Your Next.js application deployed on Vercel calls Appwrite APIs for user login, data fetching, and file uploads. Vercel does what it's good at (shipping static assets and edge functions fast); Appwrite does what it's good at (managing persistent state, users, and files securely).
+
+```js
+// In a Next.js API route deployed to Vercel
+import { Client, Account } from 'node-appwrite';
+
+const client = new Client()
+    .setEndpoint('https://<REGION>.cloud.appwrite.io/v1')
+    .setProject('<PROJECT_ID>')
+    .setSession(sessionToken);
+
+const account = new Account(client);
+const user = await account.get();
+```
+
+Both architectures are well-supported. The choice comes down to whether you want full platform consolidation or prefer to keep a specific hosting setup you're already invested in.
+
+## The backend gap problem
+
+Regardless of where your frontend lives, the more important architectural question is: what handles your backend?
+
+The risk of treating Vercel or Netlify as your complete backend (beyond their serverless function layer) is what might be called the backend gap: the growing list of things your application needs that none of your current services provide.
+
+Common manifestations:
+
+- A user can't reset their password because there's no built-in session or email integration
+- Uploaded files are accessible to any user because there's no per-user access control
+- Real-time features require polling because there's no subscription system
+- The admin needs to see all user accounts but there's no user management interface
+- An enterprise customer asks about audit logging and there's no answer
+
+Each of these is solvable, but each requires adding another service, learning another API, and maintaining another integration. Appwrite was designed to cover all of these from the start, alongside the frontend hosting layer.
+
+## Choose your stack based on backend coverage, not just frontend delivery
+
+Vercel and Netlify are excellent at frontend delivery. They're not replacements for a backend. The teams that build most efficiently are those that understand what each layer of their stack is responsible for and pick tools that cover the complete surface area of their application's needs.
+
+[Appwrite](https://appwrite.io) covers the full stack: frontend hosting with [Appwrite Sites](https://appwrite.io/docs/products/sites) and a complete backend in a single platform. If you prefer a separate hosting setup, Appwrite fills the backend layer cleanly alongside Vercel, Netlify, Cloudflare Pages, or anything else. Try [Appwrite Cloud](https://cloud.appwrite.io) for free or self-host using the [installation guide](https://appwrite.io/docs/advanced/self-hosting).
+
+- [Appwrite Sites documentation](https://appwrite.io/docs/products/sites)
+- [Appwrite Authentication docs](https://appwrite.io/docs/products/auth)
+- [Appwrite Databases docs](https://appwrite.io/docs/products/databases)
+- [Sign up for Appwrite Cloud](https://cloud.appwrite.io)
diff --git a/src/routes/blog/post/avoid-backend-overengineering/+page.markdoc b/src/routes/blog/post/avoid-backend-overengineering/+page.markdoc
new file mode 100644
index 0000000000..d31f2a9956
--- /dev/null
+++ b/src/routes/blog/post/avoid-backend-overengineering/+page.markdoc
@@ -0,0 +1,101 @@
+---
+layout: post
+title: "How to Avoid Backend Overengineering in Early-Stage Products"
+description: The patterns that lead early-stage teams to overengineer their backend and the decisions that keep systems simple while still being production-ready.
+date: 2024-08-09
+cover: /images/blog/avoid-backend-overengineering/cover.png
+timeToRead: 6
+author: aditya-oberai
+category: product
+featured: false
+unlisted: true
+---
+
+Early-stage product development has a seductive enemy: the urge to build infrastructure for a scale that doesn't exist yet. A developer building their first application feature starts thinking about microservices, event-driven architecture, distributed caching, and multi-region failover, for a product with zero users.
+
+This is backend overengineering, and it's one of the most reliable ways for a small team to burn months of development time on problems they don't actually have.
+
+## What overengineering costs
+
+The cost of overengineered backend architecture isn't just the time spent building it. The compounding costs are:
+
+- **Complexity that slows all future development.** Every new feature has to navigate a more complicated system. Debugging is harder. Onboarding new engineers is harder. Making changes is slower and riskier.
+- **Maintenance burden that grows with the system.** More services, more dependencies, more configuration means more things that can break and more time spent keeping them running.
+- **Delayed market feedback.** The longer it takes to ship something users can interact with, the longer it takes to learn whether you're building the right thing.
+- **False confidence in infrastructure.** Teams that have invested heavily in infrastructure sometimes continue building around it even when the product hypothesis isn't working, because stopping feels like admitting the infrastructure investment was wasted.
+
+## The common overengineering patterns
+
+### Premature microservices
+
+Microservices architecture has real advantages, for large teams with mature, well-understood systems where independent deployment and scaling of individual services creates meaningful value. For an early-stage product with a team of one to five people, microservices mostly add operational complexity with no corresponding benefit.
+
+A monolith or a small number of well-structured services is almost always the right architecture for an early-stage product. You can split later, when you have a concrete reason to do so.
+
+### Building for theoretical scale
+
+"We might have a million users" is not a design requirement. Actual scale requirements come from actual load data. Building distributed systems, eventual consistency patterns, and sharding strategies for load that might never materialize is engineering time that could go into the product.
+
+Design for the scale you have plus a reasonable buffer. Optimize when you have data showing you need to.
+
+### Over-abstracting too early
+
+Generic frameworks, plugin architectures, and highly abstracted database layers seem like they'll enable flexibility. In practice, they create indirection that makes the system harder to understand and change. The abstraction that seemed like it would help in six months often just makes the current six months slower.
+
+### Custom authentication
+
+Implementing authentication from scratch (session management, password hashing, brute-force protection, OAuth integrations, MFA) is a significant engineering investment that most teams don't need to make. Authentication is a solved problem. Using a backend platform that handles it correctly is not cutting corners; it's good engineering judgment.
+
+### Building admin tooling before you need it
+
+Admin panels, data dashboards, and internal tooling are genuinely useful, eventually. In the earliest stages of a product, most of these can be handled by the management interface of whatever backend platform you're using. Custom admin tooling built before there's a clear need for it is often rebuilt or abandoned as the product evolves.
+
+## What "appropriately simple" looks like
+
+An appropriately simple early-stage backend:
+
+- Uses a managed backend platform for authentication, data storage, file handling, and basic serverless functions
+- Has a clear, conventional data model that reflects actual requirements, not a speculative future model
+- Deploys to managed infrastructure with minimal operational overhead
+- Uses the smallest number of services that covers actual requirements
+- Can be understood by any engineer on the team within an hour of looking at it
+- Has enough monitoring and logging to investigate problems, but not more
+
+The test of appropriate simplicity is not "could this scale to a million users"; it's "could we add an important new feature next week without a major architectural change."
+
+## When to add complexity
+
+Complexity should be added when there's a concrete, measured reason to add it. Not when you anticipate a problem, but when you're experiencing one.
+
+The right triggers for adding backend complexity:
+- A specific performance bottleneck identified by actual profiling, not hypothetical
+- A scale requirement driven by actual traffic data
+- A compliance or security requirement with a clear business justification
+- A development velocity problem where the current architecture is genuinely blocking the team
+
+Without one of these concrete triggers, the cost of added complexity is almost always higher than the benefit.
+
+## Appwrite keeps your backend appropriately simple
+
+Appwrite is an open-source developer infrastructure platform for building web, mobile, and AI apps. It includes both a backend server, providing authentication, databases, file storage, serverless functions, real-time subscriptions, and messaging, and a fully integrated hosting solution for deploying static and server-side rendered frontends. Appwrite can be fully self-hosted on any Docker-compatible infrastructure or used as a managed service through [Appwrite Cloud](https://cloud.appwrite.io).
+
+Appwrite is built around the same "appropriately simple" philosophy described above. Rather than requiring teams to configure and connect multiple individual services, it provides a single platform with sensible defaults:
+
+- **No auth service to configure separately**: Email/password, OAuth2, phone, and MFA are built in. Brute-force protection and session expiration are enabled by default.
+- **No separate database and API layer to build**: Create collections, define your schema, and query immediately. The query system handles filtering, ordering, and pagination without custom API endpoints.
+- **No file upload infrastructure to set up**: Storage buckets with permission controls and image transformations are ready to use. No S3 policies, no upload URL generation logic.
+- **Serverless functions for the logic that needs a server**: When you need server-side processing, Appwrite Functions run without a separate server to maintain.
+- **Built-in management console**: The Appwrite Console handles the admin tooling use case out of the box for most early-stage products, eliminating one common source of premature tooling.
+
+The result is a backend that covers what you need at launch and grows with your product, without requiring you to design a distributed system before you have users.
+
+## Keep your early-stage backend boring on purpose
+
+The best thing a small team can do for their backend is make it boring as quickly as possible. Use managed services for solved problems: authentication, database, storage, functions. Keep the architecture as simple as the actual requirements allow. Add complexity only when real constraints demand it.
+
+[Appwrite](https://appwrite.io) is built around this philosophy. Instead of asking development teams to assemble and maintain multiple backend services, it provides authentication, databases, file storage, serverless functions, real-time subscriptions, and messaging in a single, unified platform. Your team writes the code that matters for your product and delegates the solved infrastructure problems to a platform that handles them correctly. Start on [Appwrite Cloud](https://cloud.appwrite.io) to get set up in minutes, or explore the [documentation](https://appwrite.io/docs) to see the full capabilities.
+
+- [Appwrite Authentication docs](https://appwrite.io/docs/products/auth)
+- [Sign up for Appwrite Cloud](https://cloud.appwrite.io)
+- [Appwrite Functions docs](https://appwrite.io/docs/products/functions)
+- [Appwrite Databases docs](https://appwrite.io/docs/products/databases)
diff --git a/src/routes/blog/post/baa-explained/+page.markdoc b/src/routes/blog/post/baa-explained/+page.markdoc
new file mode 100644
index 0000000000..20893a1e4a
--- /dev/null
+++ b/src/routes/blog/post/baa-explained/+page.markdoc
@@ -0,0 +1,97 @@
+---
+layout: post
+title: "BAA explained: what it is and when you need one"
+description: A practical guide to Business Associate Agreements for developers building healthcare apps, covering what they include, when they apply, and how to get them.
+date: 2024-03-15
+cover: /images/blog/baa-explained/cover.png
+timeToRead: 7
+author: aditya-oberai
+category: security
+featured: false
+unlisted: true
+---
+
+If you've ever built a product that touches healthcare data, you've probably heard the term "BAA" thrown around, often by a legal team, sometimes by a prospective enterprise customer, and occasionally in a sales call that suddenly got very serious. But what exactly is a Business Associate Agreement, and when does your team actually need one?
+
+This post breaks it down from a developer and technical lead perspective, so you can make informed decisions before the lawyers get involved.
+
+## What is a BAA?
+
+A Business Associate Agreement (BAA) is a legally binding contract required under the Health Insurance Portability and Accountability Act (HIPAA) in the United States. It governs how a "business associate" (any vendor or third party that handles Protected Health Information (PHI) on behalf of a covered entity) can access, use, and safeguard that information.
+
+In plain terms: if your software processes, stores, or transmits any data that could identify a patient or relate to their health, treatment, or payment, you likely need a BAA with every vendor in your stack that touches that data.
+
+Covered entities under HIPAA include health plans, healthcare clearinghouses, and healthcare providers. Business associates include anyone who works on their behalf: cloud providers, software vendors, analytics platforms, and backend-as-a-service providers.
+
+## When do you need a BAA?
+
+The short answer: whenever PHI is in scope and you're using a third-party service to handle it. Here are the most common scenarios:
+
+- **You're building a patient portal or EHR integration.** Any app that stores or transmits patient records, appointment data, diagnoses, or treatment history involves PHI.
+- **You're working with a healthcare provider as a client.** Even if your app is not itself medical software, if you're building for a clinic or hospital, their data requirements apply.
+- **You're storing user-generated health data.** Fitness apps, mental health platforms, and telehealth tools may collect health-adjacent data that qualifies as PHI.
+- **You're building a claims or billing system.** Financial data tied to health services is also PHI.
+- **Your platform processes insurance information.** Health plan identifiers, beneficiary numbers, and claims data are all covered.
+
+If none of these apply (if you're building a general SaaS product with no health-related data), you likely don't need a BAA. But the moment healthcare-related data enters your system, the requirement applies.
+
+## What a BAA actually covers
+
+A properly drafted BAA typically includes:
+
+- **Permitted uses and disclosures** of PHI by the business associate
+- **Safeguards required** to protect PHI, including administrative, physical, and technical controls
+- **Breach notification obligations** and timelines: HIPAA requires notifying affected individuals within 60 days of discovering a breach
+- **Sub-contractor requirements**: your business associates must also ensure any downstream vendors sign BAAs
+- **Data return or destruction obligations** upon contract termination
+- **Liability and indemnification** terms in the event of a breach
+
+The BAA does not, on its own, make your system HIPAA compliant. It's a contractual mechanism that formalizes responsibilities; actual compliance requires implementing the underlying security controls in your application and infrastructure.
+
+## How teams approach BAA agreements in practice
+
+**1. Audit your vendor stack early**
+
+The most common mistake is waiting until a customer asks for proof of HIPAA compliance to start reviewing vendor BAAs. Smart teams audit their infrastructure stack at the architecture stage: cloud provider, database, authentication, file storage, email and messaging, and analytics. Each of these may need a BAA.
+
+**2. Use vendors that already support BAAs**
+
+Most major cloud providers offer BAAs as part of their enterprise or business plans. AWS, Google Cloud, and Microsoft Azure all offer them. For application-layer services, it varies; some offer them freely, others only on paid plans, and some don't offer them at all. This makes vendor selection a compliance decision, not just a technical one.
+
+**3. Separate PHI from non-PHI workloads where possible**
+
+Teams often structure their architecture to minimize the surface area of PHI exposure. If only a subset of services touch protected data, fewer BAAs are required. This is both a legal and operational simplification that pays off at scale.
+
+**4. Keep a BAA register**
+
+Maintaining a document that lists every vendor with PHI access, the BAA status with each, and the review dates is basic hygiene. For small teams, a spreadsheet works. For larger organizations, dedicated compliance management tooling may be worthwhile.
+
+**5. Get BAAs in place before the sales conversation**
+
+If a prospective customer asks whether you have BAAs in place and you don't, the deal is over. Enterprise healthcare customers require documentation before onboarding, not as a post-sale formality.
+
+## Choosing a backend that supports compliance
+
+When selecting backend infrastructure for a HIPAA-relevant application, look for vendors who:
+
+- Offer formal BAA agreements (not just a compliance FAQ page)
+- Document their security controls: encryption at rest and in transit, access controls, audit logging
+- Are transparent about sub-processors, meaning other vendors they use who may also touch your data
+- Provide SOC 2 Type II reports or equivalent third-party audit documentation
+
+## Appwrite for compliance-sensitive applications
+
+Appwrite is an open-source developer infrastructure platform for building web, mobile, and AI apps. It includes both a backend server, providing authentication, databases, file storage, serverless functions, real-time subscriptions, and messaging, and a fully integrated hosting solution for deploying static and server-side rendered frontends. Appwrite can be fully self-hosted on any Docker-compatible infrastructure or used as a managed service through [Appwrite Cloud](https://cloud.appwrite.io).
+
+For teams building in compliance-sensitive environments, Appwrite's self-hosting capability is particularly relevant to the BAA question. When you self-host Appwrite within your own cloud account or on-premise infrastructure, your data never leaves your controlled environment. The primary BAA relationship becomes the underlying cloud provider where Appwrite runs, not a separate backend vendor with its own sub-processors and data handling policies.
+
+Appwrite's built-in authentication handles session management, Argon2 password hashing, and OAuth integrations. Its database and file storage operate within your own deployment boundary. Its serverless functions execute within your infrastructure perimeter. For healthcare teams that need to demonstrate control over where PHI lives and who can access it, Appwrite's self-hosting model provides a practical, auditable path forward.
+
+## Build your HIPAA-compliant backend with full data control
+
+BAAs are not a checkbox, they're a signal that your infrastructure was designed with data accountability in mind. When you self-host Appwrite within your own cloud account or on-premise infrastructure, your data never leaves your controlled environment. The primary BAA relationship becomes the underlying cloud provider where Appwrite runs, not a separate backend vendor with its own sub-processors and data handling policies. This makes the compliance conversation cleaner and the audit trail shorter.
+
+- [Appwrite HIPAA compliance](https://appwrite.io/docs/advanced/security/hipaa)
+- [Appwrite Self-Hosting guide](https://appwrite.io/docs/advanced/self-hosting)
+- [Appwrite Authentication docs](https://appwrite.io/docs/products/auth)
+- [HHS HIPAA Business Associate Guidance](https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/business-associates/index.html)
diff --git a/src/routes/blog/post/backend-platform-security-responsibilities/+page.markdoc b/src/routes/blog/post/backend-platform-security-responsibilities/+page.markdoc
new file mode 100644
index 0000000000..668f84ebce
--- /dev/null
+++ b/src/routes/blog/post/backend-platform-security-responsibilities/+page.markdoc
@@ -0,0 +1,90 @@
+---
+layout: post
+title: "Security responsibilities when using backend platforms"
+description: Understanding the shared responsibility model for security when building on backend-as-a-service platforms, and what that means for your application.
+date: 2024-04-05
+cover: /images/blog/backend-platform-security-responsibilities/cover.png
+timeToRead: 6
+author: aditya-oberai
+category: security
+featured: false
+unlisted: true
+---
+
+When you build on a backend platform (whether that's a cloud provider, a BaaS solution, or a managed database service) you're entering into what the industry calls a "shared responsibility model." The platform secures some things. You secure others. Understanding exactly where that boundary sits is one of the most important security decisions a development team makes.
+
+Get it wrong in one direction and you'll over-invest in controls the platform already handles. Get it wrong in the other and you'll ship an application with critical security gaps you didn't know existed.
+
+## What is the shared responsibility model?
+
+The shared responsibility model is a framework, originally formalized by cloud providers like AWS and Azure, that divides security duties between the infrastructure provider and the customer. At a high level:
+
+- **The platform is responsible for** securing the underlying infrastructure: physical hardware, network fabric, hypervisors, and the software that runs the managed services themselves.
+- **You are responsible for** securing what runs on top of the platform: your application code, your data, your access policies, and how you configure the platform's services.
+
+The line shifts depending on the service model. With IaaS (Infrastructure as a Service), you manage almost everything above the virtual machine. With PaaS (Platform as a Service) and SaaS-like BaaS platforms, the provider manages more, but you still own your application logic and data security.
+
+## What backend platforms typically handle
+
+When using a well-maintained backend platform, you can generally expect the provider to take responsibility for:
+
+- **Physical and network security.** Data centers, network isolation, DDoS mitigation, and hardware security are the provider's domain.
+- **Platform-level patching.** The underlying OS, database engine, and runtime environment are kept up to date by the platform.
+- **Encryption in transit.** TLS termination and secure transport between services is typically handled out of the box.
+- **Encryption at rest.** Most platforms encrypt stored data by default, though you should verify the encryption standard and key management approach.
+- **High availability and redundancy.** Uptime SLAs, failover, and backup infrastructure are generally managed by the platform.
+- **Authentication service security.** If the platform provides authentication, it should handle password hashing, brute-force protection, and secure session management internally.
+
+## What you are responsible for
+
+No matter how capable the platform, these responsibilities remain yours:
+
+- **Application-level access control.** Defining who can access what in your application is your job. Platforms provide permission primitives (RBAC, resource-level policies, team scopes), but how you configure and apply them is entirely up to you.
+- **Your own code security.** SQL injection, XSS, insecure deserialization, and other application-layer vulnerabilities are introduced by your code, not the platform's. Static analysis tools, code review practices, and secure coding standards are your responsibility.
+- **API key and secret management.** Storing API keys securely, rotating them regularly, and ensuring they're never committed to version control is a developer responsibility regardless of which platform you're using.
+- **Data you send to the platform.** The platform secures data at rest, but you control what data you send. Over-collecting sensitive data that doesn't need to be stored is a risk you create.
+- **Third-party integrations.** When your application connects to external services, the security of those connections and the data shared across them is your responsibility.
+- **User account policies.** Enforcing strong password policies, requiring multi-factor authentication, and managing account recovery flows is your team's decision, not the platform's default.
+- **Monitoring and incident response.** Platform providers may offer logging and alerting tools, but configuring those tools and responding to alerts falls to your team.
+
+## Common misconceptions that lead to security gaps
+
+**"The platform handles security."** This is the most dangerous misunderstanding. The platform handles its security. Your application security is still entirely yours.
+
+**"We don't need access control because the data isn't sensitive."** Access control is not only about protecting sensitive data; it's about ensuring application integrity. Unauthenticated users modifying or deleting data causes incidents regardless of whether that data is regulated.
+
+**"Our platform is SOC 2 certified, so we're covered."** SOC 2 certification covers the platform's own controls. It does not certify the security of what you build on top of it.
+
+**"We'll add security later."** Security controls are cheapest when built in. Authentication bypass bugs, insecure direct object references, and exposed admin endpoints discovered post-launch are expensive to fix and damaging to user trust.
+
+## Choosing a platform with clear security documentation
+
+When evaluating backend platforms, look for those that:
+
+- Publish a clear shared responsibility documentation outlining what they handle versus what you handle
+- Provide granular permission systems that let you enforce least-privilege access
+- Offer audit logging so you can track who accessed what
+- Are transparent about their own security certifications and third-party audits
+- Support security best practices by default, like Argon2 password hashing, session expiration, and rate limiting on authentication endpoints
+
+## Appwrite's security model
+
+Appwrite is an open-source developer infrastructure platform for building web, mobile, and AI apps. It includes both a backend server, providing authentication, databases, file storage, serverless functions, real-time subscriptions, and messaging, and a fully integrated hosting solution for deploying static and server-side rendered frontends. Appwrite can be fully self-hosted on any Docker-compatible infrastructure or used as a managed service through [Appwrite Cloud](https://cloud.appwrite.io).
+
+Within the shared responsibility model, Appwrite clearly defines what the platform handles versus what you handle:
+
+- **Authentication security**: Appwrite handles password hashing using Argon2, brute-force protection with configurable thresholds, secure session token management, and multi-factor authentication, all implemented correctly at the platform layer so you don't have to.
+- **Granular permissions**: Appwrite's permission system lets you define access at the database collection, document, storage bucket, and individual file level, making it practical to enforce least-privilege access across your entire data layer.
+- **Transparent codebase**: Because Appwrite is open source, you can review every line of security-relevant code. There is no need to trust vendor claims about what the platform does or doesn't do; you can verify the implementation directly.
+- **Audit visibility**: Appwrite logs resource events with timestamps and user context, giving your team the trail needed for incident response and compliance reviews.
+
+Your responsibilities remain: your application logic, your access control configuration, your API key management, and your input validation. But Appwrite handles the platform-layer security correctly so you can focus on what's uniquely yours.
+
+## Apply your application security on top of a platform you can verify
+
+No backend platform removes your responsibility for application security. But choosing a platform that handles its layer correctly, is transparent about what it does, and gives you the primitives to enforce least-privilege access makes your job significantly smaller. With Appwrite, you can verify every security-relevant decision in the open-source codebase rather than trusting vendor claims.
+
+- [Appwrite Security overview](https://appwrite.io/docs/advanced/security)
+- [Appwrite Authentication docs](https://appwrite.io/docs/products/auth)
+- [Appwrite Databases permissions](https://appwrite.io/docs/products/databases/permissions)
+- [Appwrite Audit Logs](https://appwrite.io/docs/advanced/security/audit-logs)
diff --git a/src/routes/blog/post/backend-that-scales/+page.markdoc b/src/routes/blog/post/backend-that-scales/+page.markdoc
new file mode 100644
index 0000000000..e73b9ff80f
--- /dev/null
+++ b/src/routes/blog/post/backend-that-scales/+page.markdoc
@@ -0,0 +1,100 @@
+---
+layout: post
+title: "How to Build a Backend That Scales Without Stress"
+description: The architectural decisions and platform choices that let small teams build backends that scale gracefully without managing complex infrastructure.
+date: 2024-09-06
+cover: /images/blog/backend-that-scales/cover.png
+timeToRead: 7
+author: aditya-oberai
+category: product
+featured: false
+unlisted: true
+---
+
+Scaling is the word that makes early-stage developers nervous. The fear is some version of this: we build something, it gets popular, and then it falls over because we didn't plan for scale. Then we have to rewrite everything under pressure while real users are experiencing problems.
+
+This fear is mostly misplaced, not because scaling is trivial, but because the things that cause applications to break under load are predictable, and the decisions that prevent those breakdowns are straightforward. You don't need to be a distributed systems engineer to build a backend that handles growth gracefully.
+
+## Why most scaling problems are actually architecture problems
+
+When applications fall over under load, the cause is usually one of a small set of architectural patterns:
+
+- **Database queries that are efficient at small scale but catastrophic at large scale**: full table scans, N+1 queries, missing indexes
+- **Stateful server architecture** that can't be horizontally scaled: sessions stored in server memory, local file system dependencies
+- **Synchronous processing of slow operations**: sending emails, generating PDFs, or calling external APIs in the request-response cycle
+- **No caching layer**: computing the same results repeatedly for every request
+
+None of these problems require predicting future scale to prevent. They're recognizable antipatterns that can be avoided during initial design.
+
+## The decisions that enable scaling
+
+### Design for stateless servers from the start
+
+A stateless server is one that doesn't store any local state between requests. All state (user sessions, data, files) lives in external stores: a database, a cache, or file storage. Stateless servers can be scaled horizontally by adding instances without synchronization overhead.
+
+The practical implication: don't store session data in server memory. Don't write files to the local filesystem as part of request handling. Don't use server-local caching for data that needs to be consistent across multiple instances.
+
+### Index your data access patterns
+
+Database performance at scale almost always comes down to indexing. A query that does a collection scan on a 1,000-row table takes milliseconds; the same query on a 10-million-row table without an index takes seconds or minutes.
+
+The rule of thumb: every field you query on, filter by, or sort on should have an index. Define these indexes during schema design, not after performance problems appear.
+
+### Move slow operations out of the request cycle
+
+Operations that take more than a few hundred milliseconds don't belong in the synchronous request-response cycle. Sending welcome emails, generating reports, processing uploaded files, calling third-party APIs with variable latency; these should be queued and processed asynchronously.
+
+In practice, this means using serverless functions triggered by events or message queues, rather than executing slow operations inline. The request returns quickly; the work happens in the background.
+
+### Use a managed backend to avoid infrastructure scaling work
+
+The biggest scaling simplification for small teams is using a managed backend platform whose infrastructure scales automatically. When authentication, database, and storage are managed services, you're not responsible for provisioning database replicas, configuring connection pools, or managing server capacity. The platform handles this.
+
+This doesn't mean infinite scale for free; managed platforms have their own limits and costs at high volume, but it means your team doesn't have to solve the infrastructure scaling problem while also building the product.
+
+## What to optimize early (and what not to)
+
+**Optimize early:**
+- Database schema and indexes: these are hard to change after data exists
+- Stateless server architecture: retrofitting statelessness is painful
+- Asynchronous processing for slow operations: much easier to design in than to add later
+
+**Don't optimize early:**
+- Caching layers: add these when you have measured cache miss data
+- Database sharding or replication: only relevant at scale levels most applications never reach
+- Microservices decomposition: adds operational complexity without benefit until you have a concrete need
+- CDN configuration for every asset: relevant for media-heavy applications, not for most early-stage products
+
+## Practical scaling indicators to watch
+
+Before you experience a performance problem, you want to see it coming. A few metrics worth tracking from early in an application's life:
+
+- **Database query latency**: P95 and P99, not just average
+- **API response time**: are slow requests isolated or systematic?
+- **Error rates**: are database timeouts or connection exhaustion errors appearing?
+- **Request throughput**: are there specific endpoints or time windows where load concentrates?
+
+These indicators give you enough warning to address scaling issues before they become user-facing outages.
+
+## Appwrite for scalable applications
+
+Appwrite is an open-source developer infrastructure platform for building web, mobile, and AI apps. It includes both a backend server, providing authentication, databases, file storage, serverless functions, real-time subscriptions, and messaging, and a fully integrated hosting solution for deploying static and server-side rendered frontends. Appwrite can be fully self-hosted on any Docker-compatible infrastructure or used as a managed service through [Appwrite Cloud](https://cloud.appwrite.io).
+
+Appwrite's architecture aligns with the scaling principles outlined in this post:
+
+- **Stateless by design**: Appwrite's API layer is stateless. Session state, user data, and files are all stored in external managed stores (the database and object storage layers). This means the Appwrite API can be scaled horizontally without session synchronization issues.
+- **Indexed queries**: Appwrite Databases allow you to define indexes on your collections during schema setup. The platform enforces that queries run against indexed fields, preventing the full collection scans that break performance at scale.
+- **Asynchronous functions**: Appwrite Functions are inherently asynchronous, designed for event-driven and scheduled execution. Slow operations (sending notifications, processing uploads, calling external APIs) are a natural fit for Functions rather than inline request handlers.
+- **Managed scaling on Appwrite Cloud**: Appwrite Cloud handles infrastructure scaling automatically. You're not responsible for provisioning database read replicas, scaling connection pools, or adjusting compute capacity as your user count grows.
+- **Self-hosted horizontal scaling**: If you self-host, Appwrite's Docker-based architecture supports horizontal scaling of individual services using standard container orchestration tools like Docker Swarm or Kubernetes.
+
+## Build on a platform designed to scale with your application
+
+Building a backend that scales is about avoiding known antipatterns: stateful servers, unindexed queries, synchronous slow operations. Choose infrastructure that scales without requiring you to manage it directly.
+
+[Appwrite](https://appwrite.io) is designed to support this model. Its managed database system handles indexes and query optimization at the platform level. Its serverless functions run asynchronously and scale based on invocation volume without requiring you to manage server capacity. File storage is managed independently of your compute layer. [Appwrite Cloud](https://cloud.appwrite.io) scales the infrastructure automatically; if you self-host, Appwrite's Docker-based deployment can be scaled horizontally using standard container orchestration.
+
+- [Sign up for Appwrite Cloud](https://cloud.appwrite.io)
+- [Appwrite Databases docs](https://appwrite.io/docs/products/databases)
+- [Appwrite Functions docs](https://appwrite.io/docs/products/functions)
+- [Appwrite Self-Hosting guide](https://appwrite.io/docs/advanced/self-hosting)
diff --git a/src/routes/blog/post/build-from-scratch-productivity/+page.markdoc b/src/routes/blog/post/build-from-scratch-productivity/+page.markdoc
new file mode 100644
index 0000000000..7d9a2806e2
--- /dev/null
+++ b/src/routes/blog/post/build-from-scratch-productivity/+page.markdoc
@@ -0,0 +1,89 @@
+---
+layout: post
+title: "Why Building From Scratch Is Killing Developer Productivity"
+description: The hidden costs of building custom solutions for solved problems and how to develop better judgment about when to build versus when to use existing tools.
+date: 2024-09-20
+cover: /images/blog/build-from-scratch-productivity/cover.png
+timeToRead: 6
+author: aditya-oberai
+category: product
+featured: false
+unlisted: true
+---
+
+Every developer has an internal instinct to build things. It's part of what makes software development satisfying: the ability to create something from nothing, tailored exactly to your requirements. But this instinct, when left unchecked, is one of the most reliable ways to slow a team down.
+
+"Build it from scratch" has a seductive logic: we'll have full control, it will fit our exact needs, and we won't be dependent on a third party. What it often produces is: an authentication system with undiscovered security vulnerabilities, a file upload implementation that breaks on edge cases, an email notification system that nobody fully understands, and months of engineering time spent on problems that have already been solved.
+
+## The problems with always building from scratch
+
+### Every custom solution requires ongoing maintenance
+
+When you build a custom authentication system, you're not just writing code once. You're committing to maintaining that code: fixing bugs, applying security patches, updating dependencies, supporting new use cases as the product evolves. The initial build is the smallest investment; the long tail of maintenance is where the true cost lives.
+
+This is true for every custom component: email templates, file upload handling, user management, notification systems. Each one is a maintenance burden that competes with feature development for engineering time.
+
+### Custom implementations are frequently wrong in subtle ways
+
+Authentication is the canonical example. Password hashing with a fast algorithm instead of bcrypt. Session tokens that don't expire. Password reset flows that leak information about whether an email address is registered. Missing rate limiting on login endpoints. These are mistakes that developers with years of experience continue to make because they're subtle and don't cause visible failures until they're exploited.
+
+The same pattern applies to data validation, file type checking, SQL injection protection, and dozens of other security-relevant implementation details. Every custom implementation is a custom opportunity to get these wrong.
+
+### Building from scratch defers the actual product work
+
+The goal of a software development team is to build a product that people want to use. Authentication, databases, file storage, and email sending are infrastructure problems, not product problems. The product is the unique value your application creates. Every hour spent on infrastructure is an hour not spent on that unique value.
+
+Teams that build everything from scratch consistently take longer to reach their first users, first paying customers, and meaningful feedback. Teams that use managed infrastructure for solved problems get to the product work faster.
+
+### Custom solutions become knowledge silos
+
+When a senior developer builds a custom authentication system, they understand it. When that developer moves on, the team inherits a system with limited documentation, no external community knowledge base, and quirks that took the original developer months to discover. Custom solutions create knowledge silos that become organizational liabilities.
+
+## When building from scratch is the right call
+
+Not everything should be off-the-shelf. Building from scratch is worth the investment when:
+
+- **The problem is genuinely your core differentiation.** If your unique value is in the thing you're building, the engineering investment is justified.
+- **Existing solutions genuinely don't fit.** Some domains have unusual requirements that existing tools don't handle well. This is less common than developers assume, but it does happen.
+- **You have specific compliance or customization requirements that managed solutions can't meet.** Though it's worth verifying this assumption rather than assuming it; many modern platforms are more flexible than their documentation suggests.
+- **You have the engineering capacity to maintain it properly.** Building something you can't maintain is building a future problem.
+
+The honest assessment most teams need to make: for how many of their current custom solutions does any of the above actually apply?
+
+## A better decision framework
+
+Before building anything from scratch, ask:
+
+1. **Is this problem solved?** Does a managed service, library, or platform already handle this correctly and reliably?
+2. **What's the maintenance cost?** If we build this, who maintains it, and what happens when they leave or are busy?
+3. **What's the security risk?** Are there known failure modes for custom implementations of this component?
+4. **What's the opportunity cost?** What product work doesn't happen because we're spending time on this?
+5. **What do we gain from custom?** Is the control, flexibility, or cost savings from building custom actually material?
+
+If there's a good existing solution, the maintenance cost is significant, there are security risks in custom implementations, the opportunity cost is real, and the gain from custom is marginal; you should use the existing solution.
+
+## Appwrite: the backend you stop building from scratch
+
+Appwrite is an open-source developer infrastructure platform for building web, mobile, and AI apps. It includes both a backend server, providing authentication, databases, file storage, serverless functions, real-time subscriptions, and messaging, and a fully integrated hosting solution for deploying static and server-side rendered frontends. Appwrite can be fully self-hosted on any Docker-compatible infrastructure or used as a managed service through [Appwrite Cloud](https://cloud.appwrite.io).
+
+Appwrite directly replaces the categories of infrastructure that teams most commonly rebuild from scratch unnecessarily:
+
+- **Authentication**: Email/password with Argon2 hashing, 30+ OAuth providers, phone/SMS, anonymous sessions, MFA, password history, dictionary checks, and brute-force protection, implemented correctly and maintained by the Appwrite team, not yours.
+- **Database with API**: Create collections, define schema and indexes, and query immediately. No custom API layer to build or maintain.
+- **File storage**: Managed uploads with per-user access controls, image transformations, and antivirus scanning. No S3 configuration, no upload URL generation, no access control middleware.
+- **Background functions**: Serverless functions triggered by HTTP, events, or schedules, covering the asynchronous processing that most applications need without a custom job queue.
+- **Real-time**: WebSocket subscriptions that let your UI react to data changes, without building a real-time server.
+- **Messaging**: Push notifications, email, and SMS sending through a unified API with topic-based subscriber management.
+
+The code your team writes is the unique business logic that makes your application worth using. Appwrite handles the infrastructure layer that every application needs but none should be building from scratch.
+
+## Stop rebuilding infrastructure and start shipping product
+
+The discipline of knowing what not to build is as important as the ability to build. The developers and teams who ship the most are not the ones who build the most infrastructure. They build exactly the infrastructure they need to build, and use everything else from tools that already exist.
+
+[Appwrite](https://appwrite.io) is built around this philosophy: a single platform that handles authentication, databases, file storage, serverless functions, real-time subscriptions, and messaging. Development time goes toward what makes your application unique. Try [Appwrite Cloud](https://cloud.appwrite.io) for free or review the [documentation](https://appwrite.io/docs) to see how much backend infrastructure you can stop building from scratch.
+
+- [Appwrite Storage docs](https://appwrite.io/docs/products/storage)
+- [Sign up for Appwrite Cloud](https://cloud.appwrite.io)
+- [Appwrite Authentication docs](https://appwrite.io/docs/products/auth)
+- [Appwrite Functions docs](https://appwrite.io/docs/products/functions)
diff --git a/src/routes/blog/post/build-internal-tools-quickly/+page.markdoc b/src/routes/blog/post/build-internal-tools-quickly/+page.markdoc
new file mode 100644
index 0000000000..00ff771427
--- /dev/null
+++ b/src/routes/blog/post/build-internal-tools-quickly/+page.markdoc
@@ -0,0 +1,142 @@
+---
+layout: post
+title: "How to Build Internal Tools Quickly: Admin Panels"
+description: A practical guide to building admin panels and operations dashboards quickly using Appwrite as the backend, without sacrificing security or reliability.
+date: 2024-09-13
+cover: /images/blog/build-internal-tools-quickly/cover.png
+timeToRead: 7
+author: aditya-oberai
+category: tutorial
+featured: false
+unlisted: true
+---
+
+Internal tools (admin panels, operations dashboards, data management interfaces, support tooling) are some of the most frequently built and least glamorous software a team ships. They almost always require the same components: a list of records, filters and search, the ability to view and edit individual records, role-based access for different staff members, and some actions that trigger backend operations.
+
+The challenge is that "quickly" and "correctly" are often in tension. Quick internal tools are often insecure (shared credentials, no access logging) or fragile (one developer's laptop away from going down). The right approach builds internal tools that are genuinely fast to build and production-ready at the same time.
+
+## What most internal tools actually need
+
+Before choosing an approach, it's worth being specific about the requirements:
+
+- **Authentication with role differentiation.** Admins, support agents, and read-only analysts should have different levels of access. A single shared login is a security problem.
+- **CRUD operations on application data.** View, create, edit, and delete records from the application's databases.
+- **File access.** View or download files that users have uploaded.
+- **Action triggers.** Send a notification, reset a user's account, approve a pending record. These are operations that go beyond simple data editing.
+- **Audit trail.** Who did what, and when.
+- **Simple deployment.** The tool needs to run reliably without its own complex infrastructure.
+
+## Approach 1: Use the Appwrite Console directly
+
+For many internal use cases, the [Appwrite Console](https://appwrite.io/docs/tooling/console) covers the requirement without any additional development. Appwrite's console provides:
+
+- A visual database browser with the ability to view, create, edit, and delete documents
+- User management: view user accounts, create accounts, manage sessions, edit labels
+- File storage browsing: view and download files in any storage bucket
+- Function execution logs and manual invocation
+- Real-time event logs
+
+Access to the Appwrite Console is controlled by team membership. You can add support staff or operations team members with appropriate permission levels without giving them access to the codebase or deployment infrastructure.
+
+For teams using Appwrite, "build an admin panel" sometimes means "set up the right team access in the Appwrite Console," saving days of development time.
+
+## Approach 2: Build a custom admin UI on the Appwrite API
+
+When the Console's generic interface doesn't meet your needs (you want domain-specific workflows, custom views, or an interface accessible to non-technical staff), building a lightweight custom UI on top of the Appwrite API is straightforward.
+
+The key advantage of building on Appwrite is that you're not also building the backend. Authentication, data storage, and access control are already there. You're building a UI layer.
+
+Here's a minimal admin panel example that lists users and their associated data:
+
+```js
+import { Client, Users, Databases, Query } from 'node-appwrite';
+
+const client = new Client()
+    .setEndpoint('https://<REGION>.cloud.appwrite.io/v1')
+    .setProject('<PROJECT_ID>')
+    .setKey('<API_KEY>');
+
+const users = new Users(client);
+const databases = new Databases(client);
+
+// List users with pagination
+async function getUsers(page = 0) {
+    return await users.list(
+        [],          // queries
+        25,          // limit
+        page * 25    // offset
+    );
+}
+
+// Get a user's associated records
+async function getUserOrders(userId) {
+    return await databases.listDocuments(
+        '<DATABASE_ID>',
+        'orders',
+        [
+            Query.equal('userId', userId),
+            Query.orderDesc('$createdAt'),
+            Query.limit(50)
+        ]
+    );
+}
+```
+
+For the front end, a component library like shadcn/ui or Mantine provides the table, form, and filter components that make admin panels feel professional without substantial CSS work.
+
+## Approach 3: Use a low-code builder on top of Appwrite's API
+
+For teams that want an even faster path to a functional admin interface, tools like Appsmith, Budibase, or Retool can connect to Appwrite's REST API and build interfaces with drag-and-drop components. This approach trades flexibility for speed; you'll hit the low-code tool's limits eventually, but for standard CRUD interfaces, it can produce something useful in hours.
+
+## Security considerations that matter for internal tools
+
+Internal tools are often less secure than customer-facing applications, because the assumption is that only trusted people use them. This assumption is worth questioning:
+
+- **Each user should have their own login.** Shared credentials make it impossible to audit who did what.
+- **Role-based access is not optional.** A support agent doesn't need the ability to delete database collections. Apply least-privilege to internal tool access.
+- **API keys used by the admin panel should have limited scope.** Don't use a master API key for admin panel requests if a more limited key works.
+- **Log significant actions.** When someone deletes a record, resets a user's password, or triggers a backend action from the admin panel, that should appear in an audit log.
+
+## Triggering backend actions from the admin panel
+
+Some internal tool operations go beyond data editing; they need to trigger backend logic. Appwrite Functions are well-suited for this:
+
+```js
+import { Client, Functions } from 'node-appwrite';
+
+const functions = new Functions(client);
+
+// Trigger a function that sends a password reset email to a user
+const execution = await functions.createExecution(
+    '<FUNCTION_ID>',
+    JSON.stringify({ userId: '<USER_ID>', action: 'password_reset' }),
+    false,     // async
+    '/',       // path
+    'POST'     // method
+);
+```
+
+This pattern keeps privileged operations as server-side Functions with their own access policies, rather than exposing them as direct database operations from the admin panel.
+
+## Appwrite for internal tools
+
+Appwrite is an open-source developer infrastructure platform for building web, mobile, and AI apps. It includes both a backend server, providing authentication, databases, file storage, serverless functions, real-time subscriptions, and messaging, and a fully integrated hosting solution for deploying static and server-side rendered frontends. Appwrite can be fully self-hosted on any Docker-compatible infrastructure or used as a managed service through [Appwrite Cloud](https://cloud.appwrite.io).
+
+Appwrite is particularly well-suited to internal tool development because it solves the recurring backend requirements that every internal tool shares:
+
+- **Built-in console**: The [Appwrite Console](https://appwrite.io/docs/tooling/console) provides a fully functional interface for browsing databases, managing user accounts, viewing files, and monitoring function executions, covering many internal tool requirements without any custom development.
+- **Teams and roles**: Appwrite's teams and membership system gives different staff members appropriate access levels. Support agents, operations staff, and administrators can each have their own login with scoped permissions. No shared credentials.
+- **Rich query API**: Filter, sort, and paginate records across any collection using Appwrite's query system. Building a filtered view of production data for operations staff is a frontend exercise, not a backend one.
+- **Serverless functions for privileged actions**: Sensitive operations that shouldn't be exposed as direct database writes (bulk updates, account resets, notification sends) are implemented as Appwrite Functions with their own API key and access scope.
+- **Audit logging**: Appwrite logs events with user and timestamp context, giving you the audit trail that enterprise clients and internal compliance teams require.
+
+## Build internal tools that are fast, secure, and maintainable
+
+Internal tools are worth building quickly. They pay back in operational efficiency and team capability. The mistake is treating them as throwaway tools that don't need proper authentication and access control. Building on a managed backend platform means you get both speed and correctness without having to choose.
+
+[Appwrite](https://appwrite.io) provides the foundation for internal tools that work: authentication with team-based access, a database with a rich query system, file storage, and serverless functions for backend operations. The [Appwrite Console](https://appwrite.io/docs/tooling/console) handles many internal tool needs directly. When you need a custom interface, the Appwrite SDKs give you a clean, well-documented API to build on.
+
+- [Sign up for Appwrite Cloud](https://cloud.appwrite.io)
+- [Appwrite Users API docs](https://appwrite.io/docs/products/auth/manage-users)
+- [Appwrite Functions docs](https://appwrite.io/docs/products/functions)
+- [Appwrite Databases docs](https://appwrite.io/docs/products/databases)
diff --git a/src/routes/blog/post/client-dashboards-internal-tools/+page.markdoc b/src/routes/blog/post/client-dashboards-internal-tools/+page.markdoc
new file mode 100644
index 0000000000..8dac459f9c
--- /dev/null
+++ b/src/routes/blog/post/client-dashboards-internal-tools/+page.markdoc
@@ -0,0 +1,103 @@
+---
+layout: post
+title: "Building client dashboards and internal tools faster"
+description: How to ship admin panels, dashboards, and internal tools quickly for clients without rebuilding the same backend infrastructure from scratch each time.
+date: 2024-05-10
+cover: /images/blog/client-dashboards-internal-tools/cover.png
+timeToRead: 6
+author: aditya-oberai
+category: product
+featured: false
+unlisted: true
+---
+
+Every developer who has worked with clients has shipped at least one admin panel, operations dashboard, or internal management tool. These projects share a common characteristic: they're rarely glamorous, but they're almost always urgent. A client needs to manage their user base. An ops team needs to review uploaded documents. A support team needs to search orders.
+
+The problem is that the backend work underlying these tools (authentication with role-based access, database queries, file retrieval) is substantial, and it often has to be rebuilt nearly from scratch for each new project.
+
+## Why internal tools are harder than they look
+
+Internal tools appear simple from the outside. A table of records, a few forms, maybe some charts. But the backend requirements are real:
+
+- **Authentication with role-based access.** The tool needs to distinguish between a read-only analyst and an admin who can delete records. That requires a proper permission system, not just a shared password.
+- **Secure data access.** The tool is often reading from production data. Security controls need to be real, not approximate.
+- **File handling.** Many internal tools need to display, download, or upload documents and media. File storage with access controls is a full problem on its own.
+- **Audit trails.** Enterprise clients often need to know who viewed or modified what, and when.
+- **Reliability.** Internal tools that go down affect real operations. They need to be deployed properly, not just running on a local server.
+
+The result is that a "simple dashboard" can easily require a week of backend work before the front end even starts.
+
+## The approaches teams use
+
+### Build everything custom
+
+The most common approach for agencies and freelancers: build a backend API from scratch for each project. Maximum flexibility, maximum time. For highly specialized tools with complex business logic, this is sometimes the right call. For a straightforward data management interface, it's usually overkill.
+
+### Use a low-code builder
+
+Tools like Retool, Appsmith, or Budibase let teams build internal tools on top of existing data sources with drag-and-drop components. These work well when the tool is simple and the data source is already set up. They struggle when you need custom logic, when the client wants a specific UI, or when the tool needs to be embedded into another application.
+
+### Use a backend platform with a built-in management console
+
+Backend platforms like Appwrite come with their own console, a fully functional web interface for managing all your application's data, users, files, and settings. For many internal tools, configuring the right collections, permissions, and views in the platform console is all the "internal tool" a team actually needs.
+
+For cases where a custom UI is required, the platform provides the API layer, authentication, and data storage, so the developer only has to build the front end.
+
+## What makes a backend platform good for internal tool development
+
+- **A built-in console with meaningful functionality.** Viewing, filtering, editing, and deleting records from a GUI without writing code.
+- **Role-based access control.** Granular permissions so different users see and can do different things.
+- **Real-time capabilities.** Dashboards that show live data without polling hacks.
+- **File storage with access controls.** Managed file storage where you can restrict who can view or download which files.
+- **Serverless functions.** For business logic that needs to run on the server (sending emails, transforming data, triggering integrations) without maintaining a separate service.
+- **Good REST and SDK support.** So the front-end developer can query data, create records, and trigger actions with minimal boilerplate.
+
+## Building a user management dashboard with Appwrite
+
+Appwrite's console already handles a significant portion of what agencies need for client-facing admin tools. For the cases where you need a custom interface, the Appwrite SDK makes it straightforward to build on top of:
+
+```js
+import { Client, Databases, Query } from 'appwrite';
+
+const client = new Client()
+    .setEndpoint('https://<REGION>.cloud.appwrite.io/v1')
+    .setProject('<PROJECT_ID>');
+
+const databases = new Databases(client);
+
+// Fetch users with pending status for review
+const result = await databases.listDocuments(
+    '<DATABASE_ID>',
+    '<COLLECTION_ID>',
+    [
+        Query.equal('status', 'pending'),
+        Query.orderDesc('$createdAt'),
+        Query.limit(25)
+    ]
+);
+```
+
+Combined with Appwrite's built-in authentication and team-based permissions, you can give the client's operations team their own login to a custom dashboard that only shows them the data they're authorized to see, without building an authentication system from scratch.
+
+## Appwrite as the backend for client dashboards
+
+Appwrite is an open-source developer infrastructure platform for building web, mobile, and AI apps. It includes both a backend server, providing authentication, databases, file storage, serverless functions, real-time subscriptions, and messaging, and a fully integrated hosting solution for deploying static and server-side rendered frontends. Appwrite can be fully self-hosted on any Docker-compatible infrastructure or used as a managed service through [Appwrite Cloud](https://cloud.appwrite.io).
+
+For client dashboard and internal tool work, Appwrite covers the entire backend layer in one integration:
+
+- **Built-in console**: The [Appwrite Console](https://appwrite.io/docs/tooling/console) provides a fully functional interface for browsing, editing, and managing data, users, and files, meeting many internal tool requirements without any custom development.
+- **Authentication with team roles**: Appwrite's teams and memberships system lets you give different client staff members appropriate access levels to their project data, with no shared passwords or custom role logic to build.
+- **Real-time subscriptions**: Dashboards can reflect live data updates using Appwrite's built-in WebSocket subscriptions. No polling required.
+- **File storage with permissions**: Managed file storage where access is controlled per user or team, making document review and approval workflows straightforward to implement.
+- **Serverless functions**: Backend actions triggered from the dashboard (sending notifications, updating records in bulk, integrating with third-party services) can be implemented as Appwrite Functions without maintaining a separate server.
+
+## Reduce per-client backend work with a shared platform foundation
+
+Internal tools don't have to be slow to build. The key is separating the logic that needs to be custom from the infrastructure that can be handled by a platform. Authentication, data storage, file handling, and access control are solved problems. You should not be rebuilding them for every client engagement.
+
+[Appwrite](https://appwrite.io) gives you all of these as a unified platform. Its console handles a large portion of the administrative interface needs directly. When you need a custom front end, the Appwrite SDKs for JavaScript, Flutter, iOS, Android, and multiple server-side languages let you build on top of a solid foundation without starting from zero.
+
+- [Appwrite Databases docs](https://appwrite.io/docs/products/databases)
+- [Appwrite Authentication docs](https://appwrite.io/docs/products/auth)
+- [Appwrite Console documentation](https://appwrite.io/docs/tooling/console)
+- [Sign up for Appwrite Cloud](https://cloud.appwrite.io)
diff --git a/src/routes/blog/post/cloudinary-vs-appwrite-storage/+page.markdoc b/src/routes/blog/post/cloudinary-vs-appwrite-storage/+page.markdoc
new file mode 100644
index 0000000000..218d0b8990
--- /dev/null
+++ b/src/routes/blog/post/cloudinary-vs-appwrite-storage/+page.markdoc
@@ -0,0 +1,101 @@
+---
+layout: post
+title: "Cloudinary vs Appwrite Storage: trade-offs in image handling"
+description: A technical comparison of Cloudinary and Appwrite Storage, covering image transformation capabilities, pricing models, and data ownership implications.
+date: 2024-06-07
+cover: /images/blog/cloudinary-vs-appwrite-storage/cover.png
+timeToRead: 7
+author: aditya-oberai
+category: product
+featured: false
+unlisted: true
+---
+
+Image and file handling is one of those backend concerns that starts simple (upload a photo, store it somewhere, serve it to users) and quickly becomes nuanced. Resize for mobile. Generate thumbnails. Serve optimized formats like WebP. Apply transformations on the fly. Restrict access to certain users. Handle uploads of 50MB videos.
+
+Two tools come up frequently in this space: Cloudinary, a dedicated digital asset management and transformation platform, and Appwrite Storage, the file management component of the Appwrite backend platform. They solve overlapping problems but with different priorities. This post breaks down the trade-offs.
+
+## What Cloudinary does well
+
+Cloudinary is purpose-built for media transformation and delivery. Its strengths are significant:
+
+- **Deep image and video transformation API.** Cloudinary's transformation URL syntax is powerful. Resize, crop, rotate, adjust quality, convert formats, apply AI-powered smart cropping, add overlays and watermarks, all via URL parameters or SDK calls.
+- **Global CDN delivery.** Cloudinary operates its own CDN with points of presence worldwide. Transformed images are cached and served close to end users automatically.
+- **AI-powered features.** Background removal, auto-tagging, smart cropping that focuses on faces or focal points, generative fill: these are Cloudinary features that go beyond what most storage services offer.
+- **Media management dashboard.** Cloudinary provides a web interface for browsing, organizing, searching, and managing digital assets.
+- **Wide format support.** SVG, GIF, video (including streaming), 3D formats. Cloudinary handles a broad range of media types.
+
+If your application is primarily a media-heavy platform (a social network, a photography app, an e-commerce site with complex product imagery needs), Cloudinary's transformation capabilities are genuinely impressive.
+
+## Where Cloudinary creates trade-offs
+
+**Pricing at scale.** Cloudinary's pricing is based on credits, a unit that accounts for storage, transformations, and bandwidth. At low volume, the free tier covers many use cases. At moderate to high volume, costs can escalate quickly, particularly when multiple transformations are applied to many assets. Teams that haven't modeled their usage carefully have been surprised by bills.
+
+**Vendor lock-in.** When your image URLs include Cloudinary transformation parameters, your media pipeline is tightly coupled to Cloudinary's infrastructure. Migrating away means regenerating all your media assets and updating URLs throughout your application.
+
+**Data ownership complexity.** Your assets are stored in Cloudinary's infrastructure. While you have control over your account, the data is in their cloud, subject to their infrastructure decisions, pricing changes, and service continuity.
+
+**Limited to media.** Cloudinary handles images and videos. It doesn't give you user authentication, a database, serverless functions, or the other backend primitives that most applications also need.
+
+## What Appwrite Storage offers
+
+Appwrite Storage is a file management service that's part of the broader Appwrite backend platform. It approaches file handling differently:
+
+- **General-purpose file storage.** Store any file type: documents, images, videos, binaries, PDFs. This is broader than a pure media platform.
+- **Access control at the file and bucket level.** Appwrite's permission system lets you specify exactly which users or teams can read, create, update, or delete files in a given storage bucket. This is important for applications where different users should only access their own files.
+- **Image transformations via URL parameters.** Appwrite Storage supports on-the-fly image transformations through query parameters (resize by width/height, crop, and format conversion). The transformation feature set is more limited than Cloudinary's but covers the most common use cases.
+- **Antivirus scanning.** Appwrite can integrate with ClamAV to scan uploaded files for malware, which is important for applications that accept user uploads.
+- **Input validation.** You can configure each storage bucket with allowed file types, minimum and maximum file sizes, and other constraints that are enforced server-side.
+- **Self-hostable.** The entire Appwrite platform, including Storage, can be run on your own infrastructure. Your files stay in your cloud account or your own servers.
+
+## Comparing the two directly
+
+| Capability | Cloudinary | Appwrite Storage |
+|---|---|---|
+| Image transformations | Extensive (resize, crop, AI features, video) | Basic to moderate (resize, crop, format) |
+| Video processing | Yes, including streaming | Basic support |
+| CDN delivery | Built-in global CDN | Requires configuration with your CDN provider |
+| Access control | API key and folder-level | Granular user and team permissions |
+| Self-hosting | No | Yes |
+| Data ownership | Vendor's cloud | Your infrastructure (self-hosted) |
+| Pricing model | Credit-based, per transformation | Per storage volume and requests |
+| Part of a full backend platform | No | Yes |
+| Antivirus scanning | No | Yes (with ClamAV) |
+
+## Choosing between them
+
+**Choose Cloudinary if:**
+- Your application is heavily media-focused and requires advanced transformations (smart cropping, AI features, video streaming)
+- You need a global CDN for media delivery without additional configuration
+- Your team will primarily work with image and video assets, and the specialized tooling is worth the cost
+
+**Choose Appwrite Storage if:**
+- You need general-purpose file storage alongside authentication, databases, and other backend services
+- Access control at the per-user or per-team level is important for your use case
+- Data ownership and the option to self-host are requirements
+- Your image transformation needs are moderate (resize, crop, format conversion)
+- You want predictable pricing that doesn't fluctuate based on transformation volume
+
+For many applications, the right answer is Appwrite Storage for most files and user documents, combined with a CDN layer you control for performance-sensitive media delivery.
+
+## Appwrite Storage in depth
+
+Appwrite is an open-source developer infrastructure platform for building web, mobile, and AI apps. It includes both a backend server, providing authentication, databases, file storage, serverless functions, real-time subscriptions, and messaging, and a fully integrated hosting solution for deploying static and server-side rendered frontends. Appwrite can be fully self-hosted on any Docker-compatible infrastructure or used as a managed service through [Appwrite Cloud](https://cloud.appwrite.io).
+
+Appwrite Storage is the file management component of the Appwrite platform. Unlike standalone storage or CDN services, it's designed to work in conjunction with Appwrite's authentication and database layers:
+
+- **Permission-aware storage**: Because Appwrite Storage knows about your authenticated users and teams, you can restrict file access to specific users without building a separate access control layer. A file uploaded by User A is not accessible to User B unless you explicitly configure that permission.
+- **Image transformations via `getFilePreview`**: On-the-fly image resizing, cropping (with gravity control), quality adjustment, format conversion (JPEG, PNG, WebP, AVIF, HEIC), border radius, opacity, and rotation, all via URL parameters or SDK calls.
+- **Antivirus scanning**: Integration with ClamAV to automatically scan uploaded files for malware before they're stored, important for any application that accepts user-generated file uploads.
+- **Bucket-level configuration**: File type allowlists, maximum file size limits, and encryption settings are configured per bucket, not per upload.
+- **Self-hosting**: Appwrite Storage runs entirely within your own infrastructure when self-hosted, meaning files never leave your controlled environment. This is relevant for compliance and data ownership requirements.
+
+## Choose file storage based on access control needs, not just transformation depth
+
+Both tools are good at what they're designed for. The trade-offs are about fit, not quality. A social platform with complex image manipulation needs is a different use case than a SaaS application that stores user-uploaded PDFs and profile photos.
+
+[Appwrite Storage](https://appwrite.io/docs/products/storage) is available as part of [Appwrite Cloud](https://cloud.appwrite.io) or via self-hosting. It integrates naturally with Appwrite's authentication and database systems, making it straightforward to enforce per-user file access without building the access control logic yourself.
+
+- [Appwrite Storage documentation](https://appwrite.io/docs/products/storage)
+- [Appwrite Image Transformations](https://appwrite.io/docs/products/storage/images)
+- [Sign up for Appwrite Cloud](https://cloud.appwrite.io)
diff --git a/src/routes/blog/post/compliant-architectures/+page.markdoc b/src/routes/blog/post/compliant-architectures/+page.markdoc
new file mode 100644
index 0000000000..1fc8d08778
--- /dev/null
+++ b/src/routes/blog/post/compliant-architectures/+page.markdoc
@@ -0,0 +1,85 @@
+---
+layout: post
+title: "Designing compliant architectures without slowing your team"
+description: How to build compliance into your backend architecture from the start without creating bottlenecks or blocking your team from shipping faster.
+date: 2024-03-22
+cover: /images/blog/compliant-architectures/cover.png
+timeToRead: 7
+author: aditya-oberai
+category: security
+featured: false
+unlisted: true
+---
+
+Compliance has a reputation for slowing teams down. Ask any developer who has shipped a feature only to have it blocked by a security review, or watched a launch get delayed because a legal team needed time to assess data handling practices. The frustration is understandable, but in most cases, it's not compliance that's slow. It's retrofitting compliance onto a system that wasn't designed with it in mind.
+
+The good news is that building for compliance from the start doesn't have to mean building slowly. With the right architectural decisions made early, teams can move fast and stay compliant at the same time.
+
+## Why compliance-by-design matters
+
+Tacking compliance onto an existing system is expensive. When data flows are already established, storage decisions have been made, and access controls are loosely defined, auditing and remediating those systems can take months. Worse, it often requires breaking changes that affect production systems.
+
+By contrast, building with compliance in mind from the beginning means:
+
+- **Lower total cost.** Security controls built in are always cheaper than security controls retrofitted.
+- **Faster audits.** When your architecture is documented and your controls are already implemented, audit processes move in days instead of weeks.
+- **Fewer blockers.** Engineers don't have to stop and redesign systems when enterprise customers or regulators ask compliance questions.
+- **Credibility with enterprise buyers.** For teams selling into regulated industries (healthcare, finance, government), demonstrating compliance posture is a prerequisite for getting into procurement conversations.
+
+## Key architectural decisions that affect compliance
+
+### Data classification and separation
+
+Not all data is equal from a compliance perspective. PHI (Protected Health Information) under HIPAA, personal data under GDPR, and cardholder data under PCI DSS each carry different requirements. Designing your system to classify and separate these types of data early simplifies the controls you need to apply.
+
+A practical approach: treat sensitive data as its own domain within your architecture. Separate databases, separate services, and separate access policies for regulated data. This limits the blast radius of any breach and makes it easier to apply appropriate controls without over-engineering the rest of your system.
+
+### Access control by design
+
+Role-based access control (RBAC) and attribute-based access control (ABAC) should be designed at the system level, not added as an afterthought. Compliance frameworks like HIPAA and SOC 2 require demonstrating that only authorized users can access sensitive resources.
+
+Define your permission model early: who can read what, who can write what, and under what conditions. Document it. Implement it at the service layer, not just the UI layer.
+
+### Encryption at rest and in transit
+
+This should be non-negotiable for any system handling regulated data. TLS for all data in transit, AES-256 or equivalent encryption for data at rest. Most modern cloud providers and backend platforms handle this by default, but verify it explicitly for every service in your stack.
+
+### Audit logging
+
+Regulatory frameworks require audit trails: who accessed what, when, from where, and what they did with it. Build logging into your authentication and data access layers from the start. Logs should be immutable, timestamped, and retained for the period required by the relevant regulation (typically 6 years under HIPAA).
+
+### Data residency and sovereignty
+
+GDPR and many other regional regulations restrict where personal data can be stored and processed. If you're serving users in the EU, you may need to ensure data stays within EU infrastructure. Design for this before you've already stored millions of user records in a single region.
+
+## Compliance and development velocity: making them coexist
+
+The key tension is between moving fast and building correctly. Here are patterns that help reconcile the two:
+
+- **Use infrastructure-as-code.** When your compliance controls are defined in code (network policies, access rules, encryption configurations), they can be reviewed, versioned, and replicated. This eliminates the manual configuration drift that causes audit failures.
+- **Automate compliance checks in CI/CD.** Static analysis tools, secrets scanning, and dependency vulnerability checks can be run automatically on every pull request. Catching issues before they reach production is faster than remediating them after.
+- **Pick backend services that handle compliance controls for you.** Not every team has the bandwidth to implement authentication security, password policies, session management, and audit logging from scratch. Managed backend services that implement these correctly by default reduce your compliance surface area significantly.
+- **Document as you build.** Architecture decision records (ADRs) and data flow diagrams maintained alongside your code are invaluable during audits. Writing them while the decisions are fresh takes minutes; reconstructing them later takes days.
+
+## Appwrite for compliant architectures
+
+Appwrite is an open-source developer infrastructure platform for building web, mobile, and AI apps. It includes both a backend server, providing authentication, databases, file storage, serverless functions, real-time subscriptions, and messaging, and a fully integrated hosting solution for deploying static and server-side rendered frontends. Appwrite can be fully self-hosted on any Docker-compatible infrastructure or used as a managed service through [Appwrite Cloud](https://cloud.appwrite.io).
+
+Appwrite addresses several compliance-by-design concerns at the platform level, reducing what your team needs to build and maintain:
+
+- **Access control**: Appwrite's permission system lets you define read, create, update, and delete permissions per resource (at the collection, document, bucket, or file level), making least-privilege access something you configure rather than build.
+- **Audit logging**: Appwrite maintains event logs for resource access and modifications, providing the visibility that compliance frameworks like HIPAA and SOC 2 require.
+- **Encryption**: Data is encrypted at rest and in transit by default, meeting the baseline encryption requirements of most compliance frameworks.
+- **Data residency**: Appwrite can be deployed within a specific cloud region or on-premise, putting data location entirely under your control.
+- **Self-hosting**: Because Appwrite is open source and self-hostable, your data can stay entirely within your own infrastructure, eliminating a class of third-party data handling concerns before they arise.
+
+## Embed compliance in your architecture before the first audit
+
+Compliance doesn't have to be a speed bump. When it's embedded in your architecture rather than imposed on top of it, it becomes a competitive advantage: a signal to enterprise customers that your team builds trustworthy systems.
+
+[Appwrite](https://appwrite.io) is an open-source developer infrastructure platform that provides built-in authentication, databases, file storage, serverless functions, web hosting, and more, with security controls built in from the ground up. Its permission system, session management, password policies, and support for self-hosting make it a practical choice for teams building in regulated environments. Whether you're running Appwrite on your own infrastructure or using [Appwrite Cloud](https://cloud.appwrite.io), the platform gives you the controls you need to build compliantly without building everything yourself.
+
+- [Sign up for Appwrite Cloud](https://cloud.appwrite.io)
+- [Appwrite Authentication docs](https://appwrite.io/docs/products/auth)
+- [Appwrite Self-Hosting guide](https://appwrite.io/docs/advanced/self-hosting)
+- [Appwrite Security overview](https://appwrite.io/docs/advanced/security)
diff --git a/src/routes/blog/post/developer-compliance-thinking/+page.markdoc b/src/routes/blog/post/developer-compliance-thinking/+page.markdoc
new file mode 100644
index 0000000000..f6b9d363fa
--- /dev/null
+++ b/src/routes/blog/post/developer-compliance-thinking/+page.markdoc
@@ -0,0 +1,102 @@
+---
+layout: post
+title: "Developer-first thinking about compliance requirements"
+description: A developer-first guide to understanding compliance requirements, identifying what applies to your application, and making informed architecture decisions.
+date: 2024-04-12
+cover: /images/blog/developer-compliance-thinking/cover.png
+timeToRead: 6
+author: aditya-oberai
+category: security
+featured: false
+unlisted: true
+---
+
+Compliance conversations usually happen in one of two ways. Either a legal or compliance officer drops a list of requirements in a developer's lap and asks for sign-off, or a developer gets two days before a customer call to figure out if the product is GDPR compliant. Neither scenario produces good outcomes.
+
+The developers who navigate compliance well think about it early, from a technical perspective, before the legal team is in the room. Developing that habit starts with understanding the frameworks that are most likely to apply to your application.
+
+## Why developers should think about compliance first
+
+Legal teams interpret compliance requirements. Developers implement them. The gap between "our data handling must comply with GDPR" and "here's how we configure our database, API, and third-party integrations to accomplish that" is entirely a technical problem.
+
+By the time a developer understands what a compliance requirement actually means in code, they've already made architectural decisions that may need to be unwound. Getting a working mental model of the common frameworks before those decisions are made saves significant rework.
+
+## The frameworks that matter most for most developers
+
+### GDPR (General Data Protection Regulation)
+
+Applicable if you're processing personal data of EU residents, regardless of where your company is based. The core developer-relevant requirements are:
+
+- **Lawful basis for processing**: you need a documented legal reason to process each category of data you collect
+- **Data minimization**: collect only what you actually need
+- **Right to erasure**: users can request deletion of their data, and your system must be able to fulfill that request across all stores
+- **Data portability**: users can request their data in a machine-readable format
+- **Breach notification**: data breaches must be reported to the relevant supervisory authority within 72 hours
+
+In practice, GDPR compliance touches your user registration flow, your data model, your third-party integrations, your logging and analytics setup, and your support processes.
+
+### HIPAA (Health Insurance Portability and Accountability Act)
+
+Applicable if you're processing Protected Health Information (PHI) in the United States. The core technical requirements, known as the Security Rule, cover:
+
+- **Access controls**: unique user identification, emergency access procedures, automatic logoff, and encryption
+- **Audit controls**: hardware, software, and procedural mechanisms to examine access and activity
+- **Integrity controls**: mechanisms to ensure PHI is not improperly altered or destroyed
+- **Transmission security**: encryption and integrity controls for PHI transmitted over networks
+
+HIPAA compliance requires a comprehensive risk analysis of your system, documented policies and procedures, and Business Associate Agreements with every vendor that touches PHI.
+
+### PCI DSS (Payment Card Industry Data Security Standard)
+
+Applicable if you store, process, or transmit cardholder data. The most developer-relevant guidance: don't store raw cardholder data if you can avoid it. Use a PCI-compliant payment processor (like Stripe or Braintree) and let them handle the cardholder data. Your PCI scope shrinks dramatically when cardholder data never touches your own systems.
+
+If you do store cardholder data, PCI DSS requires network segmentation, encryption, access controls, regular security testing, and annual assessments.
+
+### SOC 2 (Service Organization Control 2)
+
+Not a legal requirement but increasingly a commercial one. Enterprise buyers (especially in the US) often require vendors to have SOC 2 Type II certification before signing contracts. SOC 2 covers five Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy.
+
+Getting SOC 2 certified requires documented controls across your engineering, security, and operations practices. It's a significant process but increasingly table stakes for selling to enterprise customers.
+
+## Questions developers should be able to answer before the legal review
+
+Before bringing compliance questions to legal, a developer should be able to clearly answer:
+
+- What categories of personal or sensitive data does the application collect and store?
+- Where does that data live? What cloud regions, what databases, what third-party services?
+- Who has access to it, and how is that access controlled?
+- How is the data encrypted at rest and in transit?
+- What happens when a user requests their data be deleted?
+- What logging and audit trails exist?
+- What third-party services does the application send user data to?
+
+Having answers to these questions makes the legal review faster and more productive. Legal teams can interpret requirements; they can't reverse-engineer your database schema.
+
+## Practical steps for developer-led compliance thinking
+
+- **Build a data map early.** A simple diagram or spreadsheet that lists every data type your application processes, where it's stored, who accesses it, and what third parties receive it. This is the foundation of almost every compliance framework's requirements.
+- **Read the relevant frameworks directly.** GDPR, HIPAA, and PCI DSS all have published guidance that is more readable than it sounds. Understanding the intent behind requirements helps you make better implementation decisions than following a checklist mechanically.
+- **Pick backend tools with compliance-relevant features.** Authentication systems with built-in MFA, audit logging, password policies, and data deletion support reduce the amount of compliance-relevant code you write yourself.
+- **Document architectural decisions as you make them.** A brief explanation of why you chose a particular storage approach, what access controls are in place, and how data is protected is invaluable during audits.
+
+## Appwrite for compliance-ready applications
+
+Appwrite is an open-source developer infrastructure platform for building web, mobile, and AI apps. It includes both a backend server, providing authentication, databases, file storage, serverless functions, real-time subscriptions, and messaging, and a fully integrated hosting solution for deploying static and server-side rendered frontends. Appwrite can be fully self-hosted on any Docker-compatible infrastructure or used as a managed service through [Appwrite Cloud](https://cloud.appwrite.io).
+
+For developers thinking through compliance requirements before engaging legal, Appwrite provides a concrete foundation that maps directly to common framework requirements:
+
+- **GDPR**: Appwrite supports user data deletion at the account level, granular data access permissions per resource, and self-hosting for full data residency control, directly addressing GDPR's right to erasure and data minimization requirements.
+- **HIPAA**: Appwrite's self-hosting option allows deployment within your own compliant infrastructure, keeping PHI within your controlled environment. Its authentication system, session management, and audit logging map to HIPAA's Security Rule technical safeguards.
+- **SOC 2**: Appwrite's permission system, audit logging, and encryption at rest and in transit provide a documented, implementable foundation for SOC 2's security and availability criteria.
+- **Answering the hard questions**: When an auditor asks "who has access to this data and how is it controlled?", Appwrite's explicit permission model gives you a concrete, reviewable answer rather than custom code that needs to be explained from scratch.
+
+## Map your compliance requirements to your architecture before the legal review
+
+Compliance doesn't have to be a surprise. Developers who understand the frameworks that apply to their application make better technical decisions and have more productive conversations with legal teams, security reviewers, and enterprise customers.
+
+[Appwrite](https://appwrite.io) is an open-source backend platform built with security and privacy controls as first-class features. Its support for self-hosting, built-in GDPR-relevant features like data deletion, granular permissions, and comprehensive audit logging make it a practical foundation for applications with real compliance requirements. Explore the [Appwrite compliance documentation](https://appwrite.io/docs/advanced/security#compliance) to see how its features map to the security controls your compliance framework requires.
+
+- [Appwrite GDPR compliance](https://appwrite.io/docs/advanced/security/gdpr)
+- [Appwrite Authentication docs](https://appwrite.io/docs/products/auth)
+- [GDPR official text](https://gdpr-info.eu/)
+- [HHS HIPAA Security Rule](https://www.hhs.gov/hipaa/for-professionals/security/index.html)
diff --git a/src/routes/blog/post/easiest-file-uploads/+page.markdoc b/src/routes/blog/post/easiest-file-uploads/+page.markdoc
new file mode 100644
index 0000000000..9c207a5f2d
--- /dev/null
+++ b/src/routes/blog/post/easiest-file-uploads/+page.markdoc
@@ -0,0 +1,167 @@
+---
+layout: post
+title: "The Easiest Way to Add File Uploads to Your App"
+description: A practical guide to implementing file uploads in your application using Appwrite Storage, covering setup, upload, access control, and image transformations.
+date: 2024-08-16
+cover: /images/blog/easiest-file-uploads/cover.png
+timeToRead: 6
+author: aditya-oberai
+category: tutorial
+featured: false
+unlisted: true
+---
+
+Adding file uploads to an application is one of those features that looks simple until you're actually doing it. Choose a storage provider, configure permissions, generate upload URLs, handle chunking for large files, serve files with proper content types, restrict access to authorized users, and avoid storing sensitive files publicly. Each of these is a real problem that needs a real solution.
+
+This post walks through the fastest path from "we need file uploads" to "file uploads are working in production" using Appwrite Storage.
+
+## What is Appwrite?
+
+Appwrite is an open-source developer infrastructure platform for building web, mobile, and AI apps. It includes both a backend server, providing authentication, databases, file storage, serverless functions, real-time subscriptions, and messaging, and a fully integrated hosting solution for deploying static and server-side rendered frontends. Appwrite can be fully self-hosted on any Docker-compatible infrastructure or used as a managed service through [Appwrite Cloud](https://cloud.appwrite.io).
+
+Appwrite Storage is the file management component of the Appwrite platform. It handles the infrastructure concerns of file uploads (chunking large files automatically, enforcing file type and size validation, managing per-user access controls, performing on-the-fly image transformations, and integrating antivirus scanning) so that adding file uploads to your application is a configuration and SDK task rather than a backend engineering project.
+
+## What you'll need
+
+- An [Appwrite Cloud](https://cloud.appwrite.io) account or a self-hosted Appwrite instance
+- The Appwrite SDK for your platform (we'll use JavaScript/Web in this guide)
+
+## Setting up a storage bucket
+
+In Appwrite, files are organized into buckets. Each bucket has its own permission settings, file type restrictions, and size limits. Think of a bucket as a folder with configurable access control.
+
+To create a bucket:
+
+1. Open your Appwrite console and navigate to **Storage**
+2. Click **Create bucket**
+3. Give it a name (e.g., "profile-photos")
+4. Set the maximum file size and allowed file extensions appropriate for your use case
+5. Configure the permissions. For user-specific files, you'll typically want users to be able to create files and read their own files
+
+You can also create buckets programmatically using the Appwrite Server SDK:
+
+```js
+import { Client, Storage } from 'node-appwrite';
+
+const client = new Client()
+    .setEndpoint('https://<REGION>.cloud.appwrite.io/v1')
+    .setProject('<PROJECT_ID>')
+    .setKey('<API_KEY>');
+
+const storage = new Storage(client);
+
+const bucket = await storage.createBucket(
+    'profile-photos',         // Bucket ID
+    'Profile Photos',         // Name
+    [
+        Permission.read(Role.user('<USER_ID>')),
+        Permission.create(Role.user('<USER_ID>')),
+        Permission.update(Role.user('<USER_ID>')),
+        Permission.delete(Role.user('<USER_ID>'))
+    ],
+    false,                    // fileSecurity
+    true,                     // enabled
+    10000000,                 // maximumFileSize (10MB)
+    ['jpg', 'jpeg', 'png', 'gif', 'webp'] // allowedFileExtensions
+);
+```
+
+## Uploading a file from the browser
+
+With the bucket created, file uploads from the browser use the Appwrite Web SDK:
+
+```js
+import { Client, Storage, ID } from 'appwrite';
+
+const client = new Client()
+    .setEndpoint('https://<REGION>.cloud.appwrite.io/v1')
+    .setProject('<PROJECT_ID>');
+
+const storage = new Storage(client);
+
+async function uploadFile(file) {
+    const response = await storage.createFile(
+        'profile-photos',    // Bucket ID
+        ID.unique(),         // File ID. Let Appwrite generate one
+        file                 // The File object from an <input type="file">
+    );
+    return response.$id;     // Store this ID to retrieve the file later
+}
+
+// Connect to a file input
+document.getElementById('file-input').addEventListener('change', async (event) => {
+    const file = event.target.files[0];
+    if (file) {
+        const fileId = await uploadFile(file);
+        console.log('Uploaded file ID:', fileId);
+    }
+});
+```
+
+The `createFile` method handles chunking for large files automatically. Files up to 5GB are supported with automatic chunked upload handling built into the SDK.
+
+## Retrieving and displaying files
+
+Once uploaded, you can get a file's URL for display using the `getFileView` method:
+
+```js
+const fileUrl = storage.getFileView('profile-photos', fileId);
+// Use fileUrl as the src of an img tag or href for download links
+```
+
+For images, Appwrite Storage supports on-the-fly transformations via URL parameters. You can request a resized version of an image without modifying the original:
+
+```js
+// Get a 200x200 thumbnail of a profile photo
+const thumbnailUrl = storage.getFilePreview(
+    'profile-photos',
+    fileId,
+    200,   // width
+    200,   // height
+    'center', // gravity
+    100    // quality (0-100)
+);
+```
+
+## Restricting file access
+
+Appwrite's permission system controls who can read, create, update, and delete files. Permissions can be set at the bucket level (applying to all files in the bucket) or at the individual file level.
+
+For user-owned files, set `fileSecurity` to `true` on the bucket and pass per-file permissions when creating the file:
+
+```js
+import { Permission, Role, ID } from 'appwrite';
+
+const response = await storage.createFile(
+    'user-documents',
+    ID.unique(),
+    file,
+    [
+        Permission.read(Role.user(currentUserId)),
+        Permission.delete(Role.user(currentUserId))
+    ]
+);
+```
+
+With this configuration, only the user who uploaded the file can view or delete it. Other authenticated users won't be able to access it. Unauthenticated requests will receive a 401 response.
+
+## Handling file deletions
+
+Deleting a file is straightforward:
+
+```js
+await storage.deleteFile('profile-photos', fileId);
+```
+
+For applications that need to clean up orphaned files (files whose associated database records have been deleted), Appwrite Functions can be used to trigger file deletions on database document delete events.
+
+## Implement production-ready file uploads in hours, not days
+
+File uploads don't have to be a week of backend work. Appwrite Storage handles the infrastructure: chunked uploads, access control, image transformations, file validation. You write the feature, not the plumbing.
+
+To go further with [Appwrite Storage](https://appwrite.io/docs/products/storage), explore the documentation for advanced topics like bucket encryption settings, antivirus scanning configuration, and integrating uploads with Appwrite Functions for post-upload processing.
+
+- [Appwrite Storage documentation](https://appwrite.io/docs/products/storage)
+- [Appwrite Web SDK docs](https://appwrite.io/docs/sdks)
+- [Appwrite Functions docs](https://appwrite.io/docs/products/functions)
+- [Sign up for Appwrite Cloud](https://cloud.appwrite.io)
diff --git a/src/routes/blog/post/evaluate-backend-tools-no-lock-in/+page.markdoc b/src/routes/blog/post/evaluate-backend-tools-no-lock-in/+page.markdoc
new file mode 100644
index 0000000000..e8a4e715cb
--- /dev/null
+++ b/src/routes/blog/post/evaluate-backend-tools-no-lock-in/+page.markdoc
@@ -0,0 +1,122 @@
+---
+layout: post
+title: "How to evaluate backend tools without locking yourself in"
+description: A practical framework for evaluating backend platforms and services in a way that minimizes lock-in and preserves your team's ability to change direction.
+date: 2024-07-19
+cover: /images/blog/evaluate-backend-tools-no-lock-in/cover.png
+timeToRead: 6
+author: aditya-oberai
+category: product
+featured: false
+unlisted: true
+---
+
+Every backend technology decision creates some amount of lock-in. The question is never "how do I avoid lock-in entirely"; it's "which dependencies are worth taking, and how do I minimize the cost of the ones I take?"
+
+Developers who've been through a painful migration know the feeling: a decision made early in a project, when the team was small and the requirements were unclear, becomes a constraint years later when the application has grown, the team has changed, and the requirements have evolved in ways nobody anticipated.
+
+Evaluating backend tools with the migration cost in mind from the start is the best way to avoid that trap.
+
+## What lock-in actually means in practice
+
+Lock-in is not binary. There are degrees:
+
+- **Deep lock-in:** Your data model, business logic, and application code are tightly coupled to a specific platform's proprietary APIs and abstractions. Migrating requires rewriting significant portions of the application.
+- **Moderate lock-in:** Your application uses a platform's SDKs and APIs, but the underlying data is in a portable format and the business logic is relatively decoupled. Migration is work but is tractable.
+- **Shallow lock-in:** The platform provides commodity infrastructure. Migrating means updating configuration and credentials. Your application code barely changes.
+
+Most decisions fall somewhere in the middle. The goal is to be thoughtful about which kinds of lock-in you're accepting and why.
+
+## The evaluation framework
+
+### 1. Data portability
+
+The most important lock-in question: how easy is it to get your data out?
+
+Ask:
+- Is data stored in a standard format (JSON, CSV, Parquet, SQL dump)?
+- Is there a documented export process?
+- Can you export data without contacting the vendor?
+- If the service shut down tomorrow, could you recover your data in a usable form?
+
+Platforms that store your data in proprietary formats or require vendor assistance to export are high lock-in. Platforms that use standard data formats with straightforward export are low lock-in.
+
+### 2. API standardization
+
+Custom proprietary APIs create higher switching costs than standard ones.
+
+Ask:
+- Does the platform use standard protocols (REST, GraphQL, WebSocket)?
+- Are the data query patterns platform-specific, or could a similar query be run against a standard database?
+- If you replaced this service with a different one, how much of your application code would need to change?
+
+### 3. Open source and self-hosting
+
+Open-source platforms with self-hosting support offer a specific kind of insurance: even if the vendor's managed cloud service changes pricing, changes terms, or shuts down, the software continues to exist and can be operated independently.
+
+Ask:
+- Is the platform open source? Under what license?
+- Can you self-host if needed?
+- If the vendor's cloud service goes away, can you continue operating the software?
+
+### 4. Feature isolation
+
+The more of your application's functionality is built around a single platform's specific features, the higher the switching cost. Evaluate how deeply any given platform's unique abstractions penetrate your application code.
+
+Ask:
+- Are you using platform-specific real-time APIs that have no direct equivalent elsewhere?
+- Are your security rules written in a proprietary syntax?
+- Is your authentication model tied to vendor-specific tokens or session formats?
+
+### 5. The migration path from the alternative
+
+Before committing to a platform, spend an hour thinking about the migration path away from it. Not because you plan to migrate, but because understanding the migration cost clarifies what you're actually signing up for.
+
+Ask:
+- What would it take to move your data to another database?
+- What would it take to switch authentication providers?
+- What would it take to move your file storage to another service?
+
+If the answers are "a few hours of configuration changes," that's acceptable lock-in. If the answers are "three months of engineering and significant downtime risk," that's worth factoring into your decision.
+
+### 6. Pricing predictability
+
+Unexpected cost increases are a form of lock-in. If a platform's pricing changes significantly after you've built your application around it, the cost to migrate may exceed the cost to absorb the price increase.
+
+Ask:
+- Is the pricing model predictable as scale grows?
+- Have there been significant pricing changes in the platform's history?
+- At what usage level would this platform become expensive relative to alternatives?
+
+## Applying this framework to backend platforms
+
+| Criterion | High lock-in signals | Low lock-in signals |
+|---|---|---|
+| Data portability | Proprietary format, no export tool | Standard formats, self-service export |
+| API design | Proprietary SDK required | Standard REST/GraphQL, multiple SDKs |
+| Open source | Closed source, cloud-only | Open source, self-hostable |
+| Feature dependencies | Proprietary security rules, custom query language | Standard query patterns, interchangeable features |
+| Pricing | Variable per-operation pricing | Predictable compute/storage pricing |
+
+## Appwrite and the lock-in question
+
+Appwrite is an open-source developer infrastructure platform for building web, mobile, and AI apps. It includes both a backend server, providing authentication, databases, file storage, serverless functions, real-time subscriptions, and messaging, and a fully integrated hosting solution for deploying static and server-side rendered frontends. Appwrite can be fully self-hosted on any Docker-compatible infrastructure or used as a managed service through [Appwrite Cloud](https://cloud.appwrite.io).
+
+Scoring Appwrite against the evaluation framework above:
+
+- **Data portability**: Appwrite stores data in standard JSON document format. Data can be exported without contacting the vendor, and the format is immediately usable in other systems.
+- **API design**: Appwrite exposes a standard REST API alongside native SDKs. The query patterns are well-documented and map to standard database concepts. Replacing Appwrite with another service would require updating your data access calls, but not rewriting your application's business logic.
+- **Open source and self-hosting**: Appwrite is Apache 2.0 licensed and fully self-hostable. If Appwrite Cloud ceased to exist, you could operate the same software on your own infrastructure without any code changes.
+- **Feature isolation**: Appwrite's APIs follow standard conventions. Its authentication tokens are standard JWTs. Its database queries use a documented query syntax. The level of proprietary abstraction is low compared to platforms like Firebase.
+- **Pricing**: Appwrite Cloud prices on compute and storage. Self-hosted Appwrite has only infrastructure costs. Neither model involves per-operation billing that scales unpredictably with data access patterns.
+
+## Evaluate lock-in trade-offs before you're deep in a migration
+
+Evaluating backend tools with lock-in in mind doesn't mean being paralyzed or avoiding decisions. It means being clear-eyed about the dependencies you're taking on and choosing platforms where the lock-in trade-offs are reasonable given your situation.
+
+[Appwrite](https://appwrite.io) is designed to minimize these concerns: it's open source (Apache 2.0 licensed), fully self-hostable, uses standard REST APIs alongside native SDKs, stores data in portable formats, and offers a managed cloud service ([Appwrite Cloud](https://cloud.appwrite.io)) that can be migrated to self-hosted without code changes. It's a deliberate choice for teams that want a capable backend platform without accepting deep vendor lock-in.
+
+- [Appwrite Self-Hosting docs](https://appwrite.io/docs/advanced/self-hosting)
+- [Appwrite Databases docs](https://appwrite.io/docs/products/databases)
+- [Appwrite Authentication docs](https://appwrite.io/docs/products/auth)
+- [Sign up for Appwrite Cloud](https://cloud.appwrite.io)
diff --git a/src/routes/blog/post/firebase-vs-open-source-tradeoffs/+page.markdoc b/src/routes/blog/post/firebase-vs-open-source-tradeoffs/+page.markdoc
new file mode 100644
index 0000000000..2ff4419e55
--- /dev/null
+++ b/src/routes/blog/post/firebase-vs-open-source-tradeoffs/+page.markdoc
@@ -0,0 +1,99 @@
+---
+layout: post
+title: "Firebase vs open source: the trade-offs developers miss"
+description: An honest look at the trade-offs developers make when choosing Firebase: vendor lock-in, pricing at scale, and data ownership versus open-source alternatives.
+date: 2024-07-12
+cover: /images/blog/firebase-vs-open-source-tradeoffs/cover.png
+timeToRead: 7
+author: aditya-oberai
+category: product
+featured: false
+unlisted: true
+---
+
+Firebase is often the first backend platform developers reach for. The documentation is good, the quickstart experience is fast, and the combination of real-time database, authentication, and hosting in one place made it genuinely novel when it launched. Millions of applications are built on it, and for many use cases it continues to be a reasonable choice.
+
+But Firebase involves trade-offs that aren't obvious at the start, and they become more significant as applications grow. Understanding what those trade-offs actually are lets developers make informed decisions rather than discovering the costs later.
+
+## What Firebase does well
+
+It's worth being clear about Firebase's genuine strengths before cataloguing its limitations:
+
+- **Fast to get started.** The Firebase console and SDK documentation make it possible to have authentication, a database, and hosting working in under an hour.
+- **Google infrastructure.** Firebase runs on Google Cloud, which provides global scale and reliability that few organizations could replicate.
+- **Real-time by default.** Firestore's real-time listeners are a well-designed abstraction that simplifies building collaborative and live-updating applications.
+- **Generous free tier.** The Spark (free) plan covers enough usage for early-stage applications and small side projects to run indefinitely.
+- **Broad ecosystem.** Firebase integrates natively with other Google Cloud services, and there's a large community of Firebase developers.
+
+## The trade-offs
+
+### Vendor lock-in
+
+Firebase's APIs, data models, and SDKs are proprietary. Firestore's document model, security rules syntax, real-time listener API, and authentication tokens are all Firebase-specific. There is no standard interface that other databases or auth systems use.
+
+When you build deeply on Firebase, you're not building on transferable infrastructure; you're building on Firebase. Migrating away means rewriting your data access layer, your security rules, your authentication flow, and potentially your data model. For applications that have been in production for years, this migration can be a multi-month engineering project.
+
+This isn't unique to Firebase (most managed platforms involve some lock-in), but the depth of Firebase's proprietary abstractions makes it more pronounced than some alternatives.
+
+### Pricing at scale
+
+Firebase's pricing model charges per document read, write, and delete, plus for storage and bandwidth. The Spark (free) plan is limited; the Blaze (pay-as-you-go) plan charges incrementally.
+
+The problem developers encounter is that Firebase's pricing is difficult to predict when data access patterns are complex. A real-time listener on a collection that receives frequent updates can generate many more document reads than expected. Denormalized data models (which Firebase's NoSQL approach sometimes encourages) can multiply read counts.
+
+Teams that move quickly and don't model their usage have received Firebase bills that were multiples of what they anticipated. This is not unique to Firebase (all cloud services have this problem), but Firebase's pricing model is particularly sensitive to data access pattern choices made during development.
+
+### Data ownership and Google's history of product discontinuation
+
+Firebase data lives in Google's infrastructure. Google has a documented history of discontinuing products: Google Reader, Google+, Inbox, Google Stadia, and many others. While Firebase is clearly a core part of Google's developer platform and an unlikely discontinuation target, the risk is not zero, and teams that have built critical infrastructure on discontinued Google products have paid the migration cost.
+
+More practically: your Firebase data is not portable in the way that a Postgres database export is portable. Exporting Firestore data requires writing export scripts, and the exported format is Google's proprietary format.
+
+### Limited to Firebase's feature set
+
+Firebase provides authentication, Firestore, the Realtime Database, Cloud Storage, Cloud Functions, Hosting, and a few other services. When you need something outside that set (a specific messaging system, a custom authentication provider, a specialized storage feature), you're either adding another Google Cloud service (increasing complexity) or adding a third-party service (adding another vendor).
+
+### Self-hosting is not possible
+
+Firebase is a fully managed, cloud-only platform. You cannot self-host Firebase in your own infrastructure. For teams with data residency requirements, enterprise customers who need on-premise deployment, or applications in regulated industries, this is a hard constraint.
+
+## What open-source alternatives offer
+
+Open-source backend platforms like Appwrite address these trade-offs differently:
+
+- **Portable data and APIs.** Open-source platforms use standard data formats and well-documented APIs. Migrating your data or switching deployment environments doesn't require rewriting your application.
+- **Self-hostable.** Your data stays in your infrastructure, in the regions you choose.
+- **Predictable pricing.** Infrastructure costs (compute and storage) are well-understood and competitive. There are no per-document pricing surprises.
+- **Full customizability.** Open-source platforms can be modified, extended, and integrated with internal infrastructure in ways that closed-source platforms cannot.
+- **No Google dependency.** Your application's backend isn't subject to a single vendor's product decisions.
+
+## Appwrite as a Firebase alternative
+
+Appwrite is an open-source developer infrastructure platform for building web, mobile, and AI apps. It includes both a backend server, providing authentication, databases, file storage, serverless functions, real-time subscriptions, and messaging, and a fully integrated hosting solution for deploying static and server-side rendered frontends. Appwrite can be fully self-hosted on any Docker-compatible infrastructure or used as a managed service through [Appwrite Cloud](https://cloud.appwrite.io).
+
+Appwrite directly addresses each of the Firebase trade-offs outlined above:
+
+- **Lock-in**: Appwrite uses standard REST APIs and open-source SDKs. Its Apache 2.0 license and self-hosting support mean you're never dependent on a single vendor's pricing or product decisions.
+- **Pricing**: Appwrite Cloud pricing is based on compute and storage, not per-document operations. Self-hosted Appwrite has only infrastructure costs. Neither model produces per-query billing surprises.
+- **Data ownership**: Self-hosted Appwrite stores data in your own infrastructure. Even on Appwrite Cloud, the data model is standard and exportable. There is no Google-owned infrastructure between you and your data.
+- **Feature breadth**: Appwrite provides authentication (email, OAuth2 with 30+ providers, phone, anonymous, MFA), a document database with real-time subscriptions, file storage with permissions and antivirus scanning, serverless functions, and messaging, covering the same surface area as Firebase's main services.
+- **Self-hosting**: Appwrite can be deployed on any Docker-compatible infrastructure, including your own servers, your cloud account, or an on-premise environment. This is a hard requirement for many enterprise and compliance use cases that Firebase simply cannot satisfy.
+
+## Who should still consider Firebase
+
+Firebase remains a strong choice for:
+
+- **Rapid prototyping and MVPs.** The speed of Firebase's developer experience is genuinely useful when the goal is validating an idea, not building production infrastructure.
+- **Applications that stay small.** If your application has modest scale and your data access patterns are well-controlled, Firebase's pricing can be quite reasonable.
+- **Teams already deeply invested in Google Cloud.** If your team has expertise in Google Cloud and Firebase, the ecosystem integration value is real.
+
+## Switch from Firebase before lock-in compounds into a migration project
+
+Choosing Firebase is not a mistake. It's a trade-off: lock-in for developer experience, pricing variability for managed scale, and Google's platform choices for infrastructure quality. Whether those trade-offs are worth it depends on your specific situation.
+
+[Appwrite](https://appwrite.io) is a Firebase alternative that's open source, self-hostable, and actively developed. It provides authentication with 30+ OAuth providers, a document-oriented database with real-time subscriptions, file storage with permission controls, serverless functions, and messaging. Start on [Appwrite Cloud](https://cloud.appwrite.io) for a managed experience, or self-host when your requirements demand it.
+
+- [Appwrite Authentication docs](https://appwrite.io/docs/products/auth)
+- [Appwrite Databases docs](https://appwrite.io/docs/products/databases)
+- [Appwrite Self-Hosting guide](https://appwrite.io/docs/advanced/self-hosting)
+- [Sign up for Appwrite Cloud](https://cloud.appwrite.io)
diff --git a/src/routes/blog/post/indie-hackers-shipping-faster/+page.markdoc b/src/routes/blog/post/indie-hackers-shipping-faster/+page.markdoc
new file mode 100644
index 0000000000..b7f52edf53
--- /dev/null
+++ b/src/routes/blog/post/indie-hackers-shipping-faster/+page.markdoc
@@ -0,0 +1,88 @@
+---
+layout: post
+title: "How Indie Hackers Are Shipping Apps Faster Than Ever"
+description: The tools, habits, and shipping decisions that let solo developers and small teams get production-ready applications in front of users in days, not months.
+date: 2024-08-02
+cover: /images/blog/indie-hackers-shipping-faster/cover.png
+timeToRead: 6
+author: aditya-oberai
+category: product
+featured: false
+unlisted: true
+---
+
+Something has shifted in the past few years in independent software development. Solo developers and two-person teams are shipping products that used to require a 10-person engineering team. They're launching in weeks instead of months, getting to first paying customer faster than ever, and doing it without burning out on infrastructure work.
+
+This isn't magic; it's the compounding effect of a set of practical decisions about what to build, what to buy, and what to skip entirely.
+
+## The leverage shift
+
+The historical bottleneck for indie developers wasn't ideas; it was implementation time. Building a web application from scratch meant setting up a server, configuring a database, implementing authentication, building an API, and writing all of that before touching the actual thing that made the product interesting.
+
+Modern tooling has changed this. The infrastructure layer (auth, storage, database, APIs) is now largely solved by managed platforms. The frontend layer is solved by component libraries, design systems, and framework conventions. What remains for the developer to build is the unique logic that differentiates their product. Everything else can be assembled from available tools.
+
+The developers shipping fastest have internalized this. They're not proud of writing their own authentication system; they're proud of how quickly they shipped something people use.
+
+## The tools that show up in every fast indie stack
+
+### Frontend frameworks that handle the boring parts
+
+React, Next.js, SvelteKit, Nuxt: modern meta-frameworks handle routing, server-side rendering, API routes, and deployment with minimal configuration. Combined with component libraries like shadcn/ui, Radix, or Tailwind UI, a developer can build a polished, responsive interface in a fraction of the time it would have taken five years ago.
+
+### Backend platforms instead of custom APIs
+
+Building a custom backend API is the single biggest time sink in a new application build. Indie developers who ship fast make a different choice: they use a backend platform that provides authentication, database, file storage, and serverless functions out of the box.
+
+This single decision (using a backend platform instead of building a custom API) saves days of work on almost every project.
+
+### AI-assisted development
+
+GitHub Copilot, Cursor, and other AI coding tools have become genuine productivity multipliers for experienced developers. They're not replacing judgment, but they're dramatically reducing the time it takes to implement patterns you already understand.
+
+### Managed deployment and hosting
+
+Vercel, Railway, Fly.io, and similar platforms have made deployment a solved problem. Push to GitHub, deployment happens automatically. No server management, no nginx configuration, no SSL certificate renewal.
+
+## The habits that matter as much as the tools
+
+**Scope aggressively.** The indie developers who ship fastest have a ruthless relationship with scope. Every feature that doesn't directly validate the core value proposition gets cut from v1. The goal is to learn whether anyone wants the product, not to build the complete vision first.
+
+**Decide once about architecture.** Endless evaluation of technology options is time not spent building. The developers who ship fast make architectural decisions quickly (often using whatever they know best) and then stop second-guessing them until there's a reason to revisit.
+
+**Launch before it feels ready.** Shipping before the product feels complete is uncomfortable but valuable. Users find the important bugs. Real usage reveals the important missing features. Private polish never builds the feedback loop that makes products better.
+
+**Reuse patterns ruthlessly.** Every time you solve a problem (file upload handling, email notification logic, subscription billing), document the pattern and reuse it. Indie developers who have shipped multiple products have a personal library of solutions that reduces the marginal cost of each new project.
+
+## Appwrite for indie developers
+
+Appwrite is an open-source developer infrastructure platform for building web, mobile, and AI apps. It includes both a backend server, providing authentication, databases, file storage, serverless functions, real-time subscriptions, and messaging, and a fully integrated hosting solution for deploying static and server-side rendered frontends. Appwrite can be fully self-hosted on any Docker-compatible infrastructure or used as a managed service through [Appwrite Cloud](https://cloud.appwrite.io).
+
+For indie developers and small teams, Appwrite's value proposition is direct: one platform replaces the collection of individual backend services that would otherwise each need their own account, API key, billing setup, and learning curve.
+
+- **Authentication with 30+ OAuth providers**: Google, GitHub, Apple, Discord, and many more, configured in minutes, with no custom OAuth implementation required.
+- **Document database**: Create collections, define your schema, and start querying immediately. Real-time subscriptions let your UI react to data changes without polling.
+- **File storage**: Upload, serve, and transform images. Restrict access to specific users. No S3 configuration required.
+- **Serverless functions**: Server-side logic in Node.js, Python, Go, and more, triggered by HTTP, events, or schedules, without managing a separate server.
+- **Free tier on Appwrite Cloud**: Sufficient for most indie projects at launch, with predictable costs as scale grows.
+
+The result: the infrastructure layer is behind you in hours, not days, leaving the time for what actually makes your product worth using.
+
+## What the fastest builders have in common
+
+Across the indie hacker community (on Twitter, on Indie Hackers, in product-focused Discords), the developers who ship most consistently share a few traits:
+
+- They're not trying to build perfect infrastructure; they're trying to test ideas
+- They've made peace with using managed services instead of building everything
+- They have strong opinions about their personal stack and don't reevaluate it every project
+- They ship publicly and use the feedback to decide what to build next
+
+## Use a backend platform to eliminate the infrastructure bottleneck
+
+Shipping fast is a skill, but it's also a set of choices. The choice to use a backend platform instead of a custom API, a component library instead of custom CSS, and a managed deployment service instead of a custom server configuration: each of these is a compound decision that multiplies across every hour spent building.
+
+[Appwrite](https://appwrite.io) covers authentication with 30+ OAuth providers, a document-oriented database, file storage, serverless functions, and messaging in one integration. [Appwrite Cloud](https://cloud.appwrite.io) has a free tier sufficient for most early-stage applications, and SDK support for web, mobile, and server environments means you're not rewriting backend logic for different clients.
+
+- [Appwrite Documentation](https://appwrite.io/docs)
+- [Sign up for Appwrite Cloud](https://cloud.appwrite.io)
+- [Appwrite Authentication docs](https://appwrite.io/docs/products/auth)
+- [Appwrite Functions docs](https://appwrite.io/docs/products/functions)
diff --git a/src/routes/blog/post/open-source-baas-alternatives/+page.markdoc b/src/routes/blog/post/open-source-baas-alternatives/+page.markdoc
new file mode 100644
index 0000000000..1b22f04bc1
--- /dev/null
+++ b/src/routes/blog/post/open-source-baas-alternatives/+page.markdoc
@@ -0,0 +1,80 @@
+---
+layout: post
+title: "Open-source alternatives to proprietary BaaS tools"
+description: A look at the open-source BaaS landscape, what to evaluate when choosing a platform, and why open-source matters for backend ownership and cost control.
+date: 2024-06-21
+cover: /images/blog/open-source-baas-alternatives/cover.png
+timeToRead: 6
+author: aditya-oberai
+category: product
+featured: false
+unlisted: true
+---
+
+Backend-as-a-service has matured into a crowded market. Firebase brought the category to mainstream developer awareness, and since then dozens of platforms have emerged, some proprietary, some open source, some somewhere in between. For teams evaluating their backend options, the open-source tier deserves serious consideration, not just as a cost-saving measure but as a fundamentally different way of thinking about backend ownership.
+
+## Why proprietary BaaS creates lock-in
+
+Proprietary BaaS platforms (those where the source code is not public and the service is only available as a managed offering) create a specific category of dependency:
+
+- **You can't leave without rewriting.** When your data model, authentication logic, and real-time subscriptions are built around a proprietary API, migrating to another platform requires significant engineering work.
+- **Pricing is not in your control.** Firebase, in particular, has a history of pricing changes that caught teams off-guard when their applications grew. You discover the true cost of a proprietary platform at scale, not during the evaluation phase.
+- **The vendor's roadmap drives your options.** Features you need that aren't on the vendor's roadmap simply don't get built. Workarounds become permanent fixtures of your architecture.
+- **Data portability is limited.** Exporting your data from a proprietary platform is often technically possible but practically cumbersome.
+- **Shutdown risk is real.** Google has a documented history of discontinuing products. Teams that built on Google Cloud Messaging, Google Firebase App Indexing, and other discontinued products learned this the hard way.
+
+## The open-source BaaS landscape
+
+Several serious open-source alternatives have emerged. Here's a high-level comparison of the most prominent:
+
+## Appwrite as a BaaS alternative
+
+Appwrite is an open-source developer infrastructure platform for building web, mobile, and AI apps. It includes both a backend server (providing authentication (email/password, OAuth2 with 30+ providers, phone/SMS, anonymous sessions, and MFA), a document-oriented database with real-time subscriptions, file storage with granular access controls, serverless functions supporting multiple runtimes (Node.js, Python, Go, PHP, Ruby, Dart, and more), and messaging (push notifications, email, SMS)) and [Appwrite Sites](https://appwrite.io/docs/products/sites), a fully integrated hosting solution for deploying static and server-side rendered frontends. It can be fully self-hosted on any Docker-compatible infrastructure or used as a managed service through [Appwrite Cloud](https://cloud.appwrite.io). Appwrite is Apache 2.0 licensed, with no restrictions on commercial use.
+
+For teams moving away from proprietary BaaS platforms, Appwrite offers the most complete feature coverage of any open-source alternative:
+
+- **No gaps requiring additional services**: Auth, database, storage, functions, real-time, and messaging are all built in. You don't need a separate email service or a separate push notification provider.
+- **Managed-to-self-hosted migration path**: Start on Appwrite Cloud for convenience; migrate to self-hosted when data residency, compliance, or cost requirements change. The APIs and SDKs are identical in both modes.
+- **Active development**: Appwrite has a dedicated engineering team, regular releases, and a large open-source contributor community.
+
+**Best for:** Teams that need a comprehensive, self-hostable backend with a broad feature set, strong community support, and active development.
+
+### Other open-source options
+
+### Supabase
+
+Supabase is an open-source Firebase alternative built on top of PostgreSQL. It provides authentication, a Postgres database with an auto-generated REST and GraphQL API, real-time subscriptions, file storage, and edge functions. It's strong for teams that want a relational data model and are comfortable with SQL.
+
+**Best for:** Teams with SQL expertise who want a Firebase-like developer experience on top of a relational database.
+
+### PocketBase
+
+PocketBase is a single-file open-source backend written in Go. It provides authentication, a SQLite-backed database, file storage, and real-time subscriptions. Its simplicity is its primary appeal: a single executable that runs anywhere.
+
+**Best for:** Small applications, MVPs, and solo developers who want minimal operational overhead and are comfortable with its more limited feature set.
+
+### Directus
+
+Directus is an open-source data platform and headless CMS. It wraps any SQL database in a REST and GraphQL API and provides a visual data studio for content management. It's less of a traditional BaaS and more of a data layer with API generation.
+
+**Best for:** Teams that need a content management backend or want to add an API layer to an existing database.
+
+## What to evaluate when choosing an open-source BaaS
+
+- **Feature coverage.** Does the platform provide authentication, database, storage, functions, and real-time? Or will you need to add other services to fill the gaps?
+- **Self-hosting quality.** How well-documented and operationally simple is the self-hosting experience? Is it a single Docker Compose file or a complex multi-service setup?
+- **Community and maintenance.** How active is development? How quickly are issues resolved? Is there a commercial entity behind the project that will continue funding development?
+- **SDK and language support.** Does the platform provide SDKs for the languages and frameworks your team uses?
+- **Migration path.** If you start with the managed cloud offering and want to self-host later (or vice versa), how straightforward is the migration?
+- **License.** What does the license permit? Some open-source projects use licenses that restrict commercial use or require open-sourcing your own code.
+
+## Pick an open-source BaaS that won't trade one lock-in for another
+
+Open-source BaaS platforms have closed most of the capability gap that once made proprietary platforms the default choice. For most applications, from MVPs to production-scale products, an open-source backend platform provides everything needed while giving teams significantly more control over their data, their costs, and their future migration options.
+
+[Appwrite](https://appwrite.io) stands out in this space for its comprehensive feature set, active development community, clean self-hosting experience, and Apache 2.0 license that imposes no restrictions on commercial use. Whether you choose [Appwrite Cloud](https://cloud.appwrite.io) for a managed start or self-host from day one, you're working with a platform where you're never locked into a single vendor's infrastructure.
+
+- [Appwrite Documentation](https://appwrite.io/docs)
+- [Appwrite Self-Hosting docs](https://appwrite.io/docs/advanced/self-hosting)
+- [Appwrite Authentication docs](https://appwrite.io/docs/products/auth)
+- [Sign up for Appwrite Cloud](https://cloud.appwrite.io)
diff --git a/src/routes/blog/post/open-source-backend-vs-managed-saas/+page.markdoc b/src/routes/blog/post/open-source-backend-vs-managed-saas/+page.markdoc
new file mode 100644
index 0000000000..fbc16fe02c
--- /dev/null
+++ b/src/routes/blog/post/open-source-backend-vs-managed-saas/+page.markdoc
@@ -0,0 +1,93 @@
+---
+layout: post
+title: "When open-source backend beats managed SaaS"
+description: The real trade-offs between self-hosted open-source backends and managed SaaS platforms, and how to decide which approach fits your team's situation.
+date: 2024-07-05
+cover: /images/blog/open-source-backend-vs-managed-saas/cover.png
+timeToRead: 6
+author: aditya-oberai
+category: product
+featured: false
+unlisted: true
+---
+
+The default choice for most developers reaching for a backend platform has shifted toward managed SaaS: sign up, get credentials, start building. The convenience is real and significant. But the convenience of managed SaaS comes with trade-offs that aren't always visible at the start of a project, and for certain teams and use cases, open-source self-hosted backends are the better choice by a significant margin.
+
+## What managed SaaS backends give you
+
+The appeal of managed SaaS backends is genuine:
+
+- **No infrastructure to manage.** No servers to provision, no Docker configurations to maintain, no database backups to schedule.
+- **Automatic scaling.** The vendor handles the infrastructure scaling as your application grows.
+- **Built-in reliability.** Managed platforms provide SLAs, redundancy, and uptime guarantees backed by dedicated operations teams.
+- **Fast start.** Sign up and make your first API call in minutes. No deployment, no configuration.
+
+For early-stage projects and small teams, these advantages are often decisive. The goal is shipping a product, not operating infrastructure.
+
+## Where managed SaaS creates friction
+
+As projects mature and teams grow, managed SaaS platforms introduce friction in several predictable ways:
+
+**Cost at scale.** Most managed SaaS backends price based on monthly active users, API calls, database records, or storage volume. These metrics grow with your application, and the costs can grow non-linearly. Teams that haven't modeled their usage trajectory carefully have been unpleasantly surprised.
+
+**Data sovereignty concerns.** For applications serving users in specific regulatory environments (the EU, healthcare in the US, government), the question of where data is stored and who has access to it is not optional. Managed SaaS stores your data on vendor infrastructure. You have contractual guarantees about how it's handled, but you don't have operational control.
+
+**Vendor risk.** Managed platforms can change pricing, deprecate features, or shut down. Teams that built their core infrastructure around a vendor's proprietary APIs are exposed to those decisions.
+
+**Limited customizability.** A managed platform provides the features it provides. When you need something it doesn't support (a specific authentication flow, a database index type, a storage configuration), you're dependent on the vendor's roadmap or forced to build a workaround.
+
+**Enterprise customer requirements.** Enterprise buyers increasingly ask where data lives, who can access it, and whether it can be hosted in their own environment. "It's in our vendor's cloud" is often an acceptable answer for individual customers but not for procurement in regulated industries.
+
+## When open-source self-hosted backends win
+
+### Data residency and compliance
+
+If your application must handle data that is subject to GDPR, HIPAA, or similar frameworks with data residency requirements, self-hosting your backend puts the data in your infrastructure, in the regions you choose, under the access controls you configure. You become the data processor, with full operational visibility.
+
+### Cost predictability at scale
+
+Self-hosted backends have infrastructure costs (compute, storage, bandwidth) that are typically lower and more predictable at scale than the per-seat, per-call pricing models of managed SaaS. Teams running applications with many users or high query volumes often find self-hosting substantially cheaper once past the early scaling phase.
+
+### Customization requirements
+
+Open-source backends can be modified. If you need a custom authentication provider, a specialized database index, or integration with internal infrastructure, you can build it. Managed SaaS platforms are fixed in what they support.
+
+### Enterprise customer requirements
+
+When your customers need a version of your application running in their own cloud account or data center, self-hosted open-source backends enable that deployment model. This is increasingly a selling point for B2B products in enterprise markets.
+
+### Long-term cost certainty
+
+With an open-source backend, your infrastructure costs are determined by cloud compute and storage pricing, which is highly competitive and predictable. You're not exposed to a vendor's next pricing revision.
+
+## The operational cost is real but manageable
+
+Self-hosting has real costs: someone on your team needs to manage deployments, monitor uptime, handle database backups, and apply updates. This is not free. But it's also not as complex as it once was:
+
+- Container orchestration (Docker, Kubernetes) has matured significantly
+- Cloud providers make managed Postgres, object storage, and compute easy to operate
+- Modern open-source backends like Appwrite are designed to be operated with a single Docker Compose file, not a team of DevOps engineers
+
+The operational burden of self-hosting a modern open-source backend is manageable for most teams that have already outgrown the free tier of a managed SaaS platform.
+
+## Appwrite: open-source and managed, in one platform
+
+Appwrite is an open-source developer infrastructure platform for building web, mobile, and AI apps. It includes both a backend server, providing authentication, databases, file storage, serverless functions, real-time subscriptions, and messaging, and a fully integrated hosting solution for deploying static and server-side rendered frontends. Appwrite can be fully self-hosted on any Docker-compatible infrastructure or used as a managed service through [Appwrite Cloud](https://cloud.appwrite.io).
+
+Appwrite is purpose-built for the path described in this post, starting managed, moving to self-hosted when it makes sense:
+
+- **Start managed**: [Appwrite Cloud](https://cloud.appwrite.io) provides a fully managed experience with no infrastructure to configure. The free tier is sufficient for most early-stage applications.
+- **Move to self-hosted**: When data residency, compliance, cost at scale, or customization requirements change the calculus, Appwrite can be deployed on your own infrastructure. The APIs, SDKs, and data models are identical; your application code doesn't change.
+- **Open source, Apache 2.0**: Appwrite's code is publicly available and permissively licensed. Your investment in learning the platform and building on its APIs is not at risk from vendor pricing changes or product discontinuation.
+- **Data portability**: Appwrite stores data in standard formats. If you ever need to move, the migration path is your own infrastructure or another data store, not a vendor export format.
+
+## Start managed, migrate to self-hosted when the economics shift
+
+The decision between managed SaaS and open-source self-hosted is not a permanent one. Many teams start with managed SaaS for speed and simplicity, then move to self-hosting when their data requirements, scale, or compliance needs evolve. Choosing an open-source backend that also offers a managed cloud version makes this transition smoother: you can start managed and migrate to self-hosted later using the same codebase and APIs.
+
+[Appwrite](https://appwrite.io) is built for exactly this path. [Appwrite Cloud](https://cloud.appwrite.io) provides a fully managed experience for teams that want to start without infrastructure concerns. The same platform is fully self-hostable when your requirements change. The APIs, SDKs, and data models are identical, so migrating between deployment modes doesn't require rewriting your application.
+
+- [Appwrite Self-Hosting docs](https://appwrite.io/docs/advanced/self-hosting)
+- [Sign up for Appwrite Cloud](https://cloud.appwrite.io)
+- [Appwrite Databases docs](https://appwrite.io/docs/products/databases)
+- [Appwrite Authentication docs](https://appwrite.io/docs/products/auth)
diff --git a/src/routes/blog/post/open-source-regulated-environments/+page.markdoc b/src/routes/blog/post/open-source-regulated-environments/+page.markdoc
new file mode 100644
index 0000000000..fdffda8032
--- /dev/null
+++ b/src/routes/blog/post/open-source-regulated-environments/+page.markdoc
@@ -0,0 +1,99 @@
+---
+layout: post
+title: "Open-source backends in regulated industries: what to check"
+description: How to evaluate open-source backend tools for regulated industries like healthcare and finance, covering maintenance cadence, licensing, and compliance fit.
+date: 2024-04-19
+cover: /images/blog/open-source-regulated-environments/cover.png
+timeToRead: 6
+author: aditya-oberai
+category: security
+featured: false
+unlisted: true
+---
+
+Open-source software has become foundational infrastructure for most of the modern web. But when a team building in a regulated industry (healthcare, finance, insurance, government) reaches for an open-source backend library or platform, they encounter a set of questions that don't come up in unregulated development.
+
+Is the project maintained well enough to trust in a production system? Who's responsible if there's a security vulnerability? What does "open source" mean for our compliance posture? These are the right questions. This post walks through how to think about them.
+
+## Why regulated industries have specific concerns about open source
+
+Regulated environments require demonstrable controls. A HIPAA audit doesn't care whether your authentication system is custom-built or open source; it asks whether the controls are in place, documented, and tested. The same applies to SOC 2, GDPR, PCI DSS, and FedRAMP.
+
+The concern with open source in regulated environments is not that it's inherently less secure; in many cases, widely-used open-source projects are more rigorously reviewed than proprietary alternatives. The concern is about:
+
+- **Accountability.** Who is responsible for security vulnerabilities in the open-source code you're using?
+- **Maintenance.** Is the project actively maintained, or is it a security incident waiting to happen?
+- **Vendor support.** Can you get a signed agreement, support SLA, or indemnification from the project maintainers?
+- **Known vulnerabilities.** Open-source projects have public CVE histories, which is good for transparency, but also a question of how quickly issues get patched.
+
+## What to evaluate when using open-source tools in regulated contexts
+
+### Project health and maintenance cadence
+
+A security vulnerability in an unmaintained open-source project is a serious risk. Before adopting an open-source tool in a regulated environment, check:
+
+- When was the last commit? Last release?
+- How many active maintainers does the project have?
+- How quickly are reported security vulnerabilities patched?
+- Is there a clear security disclosure process (a `SECURITY.md` or CVE program)?
+- Does the project have a public roadmap and changelog?
+
+Projects with multiple active maintainers, recent releases, and a clear security disclosure process are materially lower risk than solo-maintained projects with sporadic update histories.
+
+### License compatibility
+
+Different open-source licenses have different implications for commercial use and distribution. GPL licenses, for example, have copyleft requirements that may affect how you can distribute your application. MIT and Apache 2.0 licenses are generally permissive.
+
+For regulated environments, license review also matters for compliance audits; auditors sometimes ask for a software bill of materials (SBOM) that includes the licenses of your dependencies.
+
+### Self-hosting and data residency
+
+One of the most significant advantages of open-source tools in regulated environments is self-hosting. When you self-host, your data stays in your controlled infrastructure. No third-party BAA required for the backend platform itself (though you'll still need BAAs for the cloud provider hosting your servers).
+
+For HIPAA, GDPR, and other data residency-sensitive frameworks, the ability to run software entirely within your own infrastructure is a meaningful compliance simplification.
+
+### Commercial support and liability
+
+Open-source software comes with no warranty by default. For many teams in regulated industries, this is mitigated by purchasing commercial support from the project maintainers or a third-party support provider. Commercial support agreements can also provide:
+
+- Security patch SLAs
+- Indemnification clauses
+- Formal BAA or DPA agreements (for projects that offer a managed cloud version)
+
+### Vulnerability tracking
+
+Before adopting an open-source tool, review its CVE history. Frequent vulnerabilities that are quickly patched indicate a mature security process. Infrequent vulnerabilities with slow patches, or a history of vulnerabilities being disclosed publicly before patches were available, are warning signs.
+
+Integrate vulnerability scanning into your CI/CD pipeline for all open-source dependencies using tools like Snyk, Dependabot, or OWASP Dependency-Check.
+
+## Open source as a compliance advantage
+
+When evaluated correctly, open-source tools can actually be an advantage in regulated environments:
+
+- **Auditability.** You can read the source code of every component in your stack. Proprietary software requires you to trust the vendor's claims about security.
+- **Self-hosting.** You control exactly where your data lives and who has access to the infrastructure.
+- **Customizability.** Regulated environments often have specific requirements that proprietary platforms don't support. Open source lets you adapt.
+- **Community scrutiny.** Widely-adopted open-source projects benefit from security researchers and community members reviewing the code continuously.
+
+## Appwrite in regulated environments
+
+Appwrite is an open-source developer infrastructure platform for building web, mobile, and AI apps. It includes both a backend server, providing authentication, databases, file storage, serverless functions, real-time subscriptions, and messaging, and a fully integrated hosting solution for deploying static and server-side rendered frontends. Appwrite can be fully self-hosted on any Docker-compatible infrastructure or used as a managed service through [Appwrite Cloud](https://cloud.appwrite.io).
+
+Against the evaluation criteria outlined above, Appwrite performs well for regulated environment use:
+
+- **Project health**: Appwrite has an active core development team, frequent releases with a public changelog, and a formal security disclosure process. It is backed by a commercial entity that continues to fund ongoing development.
+- **Self-hosting**: Appwrite is designed first and foremost to be self-hosted. A Docker-based installation runs the full platform within your own infrastructure, in the regions you specify, under your operational control, directly addressing data residency requirements.
+- **License**: Appwrite uses the Apache 2.0 license, which imposes no restrictions on commercial use and does not require open-sourcing your application code.
+- **Vulnerability management**: Appwrite maintains a public security policy and releases security patches promptly. The open-source codebase means vulnerabilities can be identified through community review, not only internal audits.
+- **Commercial support**: Teams that need formal support agreements or SLAs can engage through Appwrite Cloud, which provides a managed hosting option with defined service terms.
+
+## Evaluate open-source backend health before it becomes a compliance liability
+
+Choosing open-source tools for regulated environments is not inherently riskier than choosing proprietary ones. It requires a different evaluation process, one focused on project health, maintainability, and your ability to operate and support the software in production.
+
+[Appwrite](https://appwrite.io) is an open-source backend platform designed with regulated environments in mind. It supports full self-hosting, meaning you can deploy it entirely within your own infrastructure and cloud account. Appwrite's authentication, databases, file storage, and functions all run within your environment, giving you complete data control. Its active development community, regular releases, and commercial support options through [Appwrite Cloud](https://cloud.appwrite.io) make it a strong candidate for teams evaluating open-source backends for compliance-sensitive applications.
+
+- [Appwrite Self-Hosting docs](https://appwrite.io/docs/advanced/self-hosting)
+- [Appwrite Security overview](https://appwrite.io/docs/advanced/security)
+- [Appwrite Authentication docs](https://appwrite.io/docs/products/auth)
+- [Sign up for Appwrite Cloud](https://cloud.appwrite.io)
diff --git a/src/routes/blog/post/save-weeks-managed-backends/+page.markdoc b/src/routes/blog/post/save-weeks-managed-backends/+page.markdoc
new file mode 100644
index 0000000000..8cf8582c3c
--- /dev/null
+++ b/src/routes/blog/post/save-weeks-managed-backends/+page.markdoc
@@ -0,0 +1,124 @@
+---
+layout: post
+title: "How Developers Can Save Weeks by Using Managed Backends"
+description: A concrete look at the development time saved when using a managed backend platform instead of building and maintaining backend infrastructure from scratch.
+date: 2024-09-27
+cover: /images/blog/save-weeks-managed-backends/cover.png
+timeToRead: 6
+author: aditya-oberai
+category: product
+featured: false
+unlisted: true
+---
+
+Developer time is the most constrained resource in most software projects. When teams are small, every engineering hour spent on infrastructure is an hour not spent on the product features that differentiate the application and drive growth. The decision of where to spend those hours is one of the highest-leverage choices a development team makes.
+
+Managed backend platforms have changed the economics of this decision significantly. What used to require weeks of backend infrastructure work can now be set up in hours. This post makes that concrete: a realistic accounting of what it takes to build common backend components from scratch versus using a managed platform.
+
+## The time cost of building backend infrastructure from scratch
+
+Let's walk through the backend components a typical web application needs and a realistic estimate of the development time required to build each from scratch, correctly.
+
+### User authentication system
+
+Implementing authentication from scratch means:
+
+- Password hashing with bcrypt or Argon2
+- Secure session token generation and storage
+- Session expiration and invalidation on logout
+- Email verification for new accounts
+- Secure password reset flow with expiring tokens
+- Brute-force protection and rate limiting
+- OAuth integration for "Sign in with Google/GitHub/etc."
+- Multi-factor authentication
+- Account lockout policies
+- Security testing
+
+A rigorous implementation of all of the above for a production application: **2-4 weeks** for an experienced backend developer. A partial implementation that misses some security requirements: faster, but not acceptable for a production application.
+
+### Database setup and API layer
+
+Setting up a database, designing a schema, building a CRUD API with proper validation, pagination, filtering, and access control: **1-2 weeks** depending on the complexity of the data model.
+
+### File upload and storage
+
+Implementing file uploads with proper validation, storage configuration, CDN integration, access control, and handling of large files: **3-5 days**.
+
+### Email notifications
+
+Integrating an email provider, building email templates, handling delivery failures, and managing unsubscribes: **2-4 days**.
+
+### Serverless functions / background jobs
+
+Setting up a queue-based job processing system or serverless function infrastructure for background operations: **3-5 days** depending on the platform.
+
+**Total: roughly 4-7 weeks** of backend development work before the first meaningful product feature is built.
+
+## The time cost with a managed backend platform
+
+With a managed backend platform like Appwrite, the same components are available on day one:
+
+- **Authentication** is configured in the console and available via SDK. Adding OAuth providers takes minutes per provider. MFA, password policies, and session limits are toggle configurations.
+- **Database** is set up by creating collections with defined schema and indexes. The query API is available immediately. No API layer to build.
+- **File storage** is configured in a storage bucket with permission settings. The SDK handles chunking, validation, and serving files.
+- **Messaging** (push notifications, email, SMS) is available via the Messaging service with configured providers.
+- **Serverless functions** deploy from a connected Git repository and are triggered by HTTP, events, or schedules.
+
+The setup time for all of the above on Appwrite, to a level equivalent in functionality to the from-scratch implementations described above: **1-2 days** for an experienced developer, including reading documentation for unfamiliar features.
+
+## What happens with the saved time
+
+The 4-6 weeks of development time saved by using a managed backend doesn't disappear; it redirects. For a typical product, this is the difference between:
+
+- Launching in 3 months versus 5 months
+- Building 5 product features in the first sprint versus 1
+- Discovering whether anyone wants the product before running out of runway
+
+For indie developers and small teams where engineering time is directly connected to business outcomes, this compounding effect is significant.
+
+## The ongoing maintenance savings
+
+The savings don't stop at initial development. Managed backend platforms also reduce ongoing maintenance:
+
+- **Security patches** for the authentication system are applied by the platform vendor, not your team
+- **Infrastructure scaling** as user count grows is managed by the platform, not by you provisioning additional database capacity
+- **Dependency updates** for the platform's own dependencies are handled by the vendor
+- **Feature additions** (new OAuth providers, new messaging channels, new database capabilities) arrive as platform updates rather than engineering projects
+
+A rough estimate: a self-managed backend authentication and database system for a mid-scale application requires 1-2 days of engineering time per month for maintenance, updates, and incident response. A managed backend platform reduces this to near zero for most months.
+
+## What managed backends don't eliminate
+
+Using a managed backend platform doesn't remove all backend engineering work:
+
+- **Application-specific business logic** still needs to be written, typically as serverless functions
+- **Data modeling** (designing the right schema for your application's data) is still your work
+- **Integration with third-party services** that aren't provided by the platform (specialized analytics, industry-specific APIs) still requires custom development
+- **Security configuration** (setting appropriate permissions, reviewing access controls) is still your responsibility
+
+The managed platform handles the commodity infrastructure. The custom work that's unique to your product remains yours.
+
+## How Appwrite saves development time
+
+Appwrite is an open-source developer infrastructure platform for building web, mobile, and AI apps. It includes both a backend server, providing authentication, databases, file storage, serverless functions, real-time subscriptions, and messaging, and a fully integrated hosting solution for deploying static and server-side rendered frontends. Appwrite can be fully self-hosted on any Docker-compatible infrastructure or used as a managed service through [Appwrite Cloud](https://cloud.appwrite.io).
+
+The time savings described in this post are concrete when using Appwrite:
+
+- **Authentication in hours, not weeks**: Email/password, OAuth2 (Google, GitHub, Apple, and 30+ others), phone/SMS, anonymous sessions, and MFA are all available via configuration and SDK calls. No custom implementation, no security gaps to discover later.
+- **Database and query API immediately**: Create a collection, define your attributes and indexes in the console or via the CLI, and start querying. Filtering, ordering, and pagination are built into the SDK. No API layer to build.
+- **File storage without infrastructure work**: Storage buckets with permission controls, image transformations via `getFilePreview`, and antivirus scanning are available immediately. No S3 policies, no upload URL generation, no CDN configuration required for basic use.
+- **Serverless functions via Git**: Connect a repository, define your function's entry point, and deploy. Functions are triggered by HTTP, events, or schedules. No job queue infrastructure to maintain.
+- **Messaging for notifications**: Push notifications (FCM, APNS), email, and SMS are available through Appwrite's Messaging service. Integrate notification sending in hours rather than days.
+
+The **1-2 day setup estimate** for a production-ready backend is achievable with Appwrite precisely because these components are designed to be configured and used immediately, not assembled from parts.
+
+## Replace weeks of backend infrastructure work with hours of configuration
+
+The decision to use a managed backend platform is a decision about where to spend development time. Teams that use managed backends for solved infrastructure problems ship faster, launch earlier, and put more engineering capacity into the product work that actually matters.
+
+[Appwrite](https://appwrite.io) covers the full backend layer: authentication, databases, file storage, serverless functions, real-time, and messaging. It can be set up in hours and extended as your application grows. [Appwrite Cloud](https://cloud.appwrite.io) provides a fully managed hosting experience; self-hosting is available when control or compliance requirements demand it.
+
+- [Appwrite Documentation](https://appwrite.io/docs)
+- [Sign up for Appwrite Cloud](https://cloud.appwrite.io)
+- [Appwrite Authentication docs](https://appwrite.io/docs/products/auth)
+- [Appwrite Functions docs](https://appwrite.io/docs/products/functions)
diff --git a/src/routes/blog/post/secure-user-data-non-expert/+page.markdoc b/src/routes/blog/post/secure-user-data-non-expert/+page.markdoc
new file mode 100644
index 0000000000..90b5f86477
--- /dev/null
+++ b/src/routes/blog/post/secure-user-data-non-expert/+page.markdoc
@@ -0,0 +1,124 @@
+---
+layout: post
+title: "How to Secure User Data Without Becoming a Security Expert"
+description: Practical security steps that every developer can implement to protect user data, without needing deep security expertise or a dedicated security team.
+date: 2024-08-23
+cover: /images/blog/secure-user-data-non-expert/cover.png
+timeToRead: 7
+author: aditya-oberai
+category: security
+featured: false
+unlisted: true
+---
+
+Security is one of those topics that can feel overwhelming for developers who didn't specialize in it. The threat landscape is complex, the terminology is opaque, and the stakes feel high. But most application security incidents don't happen because developers lacked advanced security knowledge; they happen because basic, well-understood security practices weren't followed.
+
+The practical steps below move a typical web application from "probably has exploitable vulnerabilities" to "applies current best practices" without requiring a security engineering background.
+
+## Why security feels harder than it is
+
+Security has a communication problem. The field produces an enormous volume of material about advanced adversarial techniques, nation-state threats, zero-day exploits, and sophisticated attack chains. This is interesting and important in certain contexts, but it's not what most application developers need to think about.
+
+Most application security incidents involve:
+
+- Compromised user credentials (weak passwords, credential stuffing, phishing)
+- Authorization bugs (users accessing data they shouldn't be able to see)
+- Unpatched dependencies with known vulnerabilities
+- Exposed secrets and API keys
+- Insecure data transmission (missing HTTPS)
+
+None of these require advanced security knowledge to prevent. They require consistent application of well-documented practices.
+
+## The fundamentals that prevent most incidents
+
+### Use a managed authentication system
+
+Authentication is one of the most security-critical pieces of any application, and one of the most frequently implemented incorrectly. Password hashing, brute-force protection, session management, token rotation, and secure password reset flows each have well-known failure modes.
+
+The practical recommendation: don't implement authentication from scratch unless you have a very specific reason to. Use a backend platform or authentication service that has implemented these patterns correctly and has been audited for security. The time saved is large and the security quality is typically higher than a custom implementation.
+
+What to look for in an authentication system:
+- Password hashing with bcrypt, scrypt, or Argon2 (not MD5 or SHA-1)
+- Brute-force protection and account lockout after failed attempts
+- Secure session tokens that expire and are invalidated on logout
+- Multi-factor authentication support
+- Password strength enforcement
+- Email verification for new accounts
+
+### Apply least-privilege access control
+
+Every user in your system should have access to exactly the data and actions they need. No more. This seems obvious but is frequently violated:
+
+- Users who can read their own profile can also read other users' profiles through predictable ID enumeration
+- Admin functionality is accessible to any authenticated user, not just administrators
+- API endpoints return more data fields than the calling user is authorized to see
+
+Implementing access control correctly means defining your permission model explicitly: which users can read which resources, which users can modify which resources, and enforcing those rules at the data layer, not just the UI.
+
+### Keep dependencies updated
+
+A significant portion of application security vulnerabilities are in third-party dependencies, not in code you wrote. CVEs (Common Vulnerabilities and Exposures) are published regularly for popular libraries. Applications that don't update dependencies accumulate known vulnerabilities over time.
+
+Practical steps:
+- Enable automated dependency update PRs (Dependabot, Renovate)
+- Run `npm audit`, `pip check`, or equivalent regularly
+- Integrate a dependency vulnerability scanner into your CI/CD pipeline
+- Treat dependency updates as routine maintenance, not an interruption
+
+### Use HTTPS everywhere
+
+All application traffic should be encrypted in transit. This is table stakes and is easy to verify: check that your application does not serve anything over HTTP, including APIs, image endpoints, and redirect flows. Check that all your backend service-to-service communication is also encrypted.
+
+Most hosting platforms (Vercel, Netlify, Railway, etc.) and cloud providers handle TLS certificate provisioning automatically. There's very little reason for any modern web application to have unencrypted traffic paths.
+
+### Never store secrets in code
+
+API keys, database connection strings, OAuth client secrets, and encryption keys should never appear in source code, configuration files committed to version control, or client-side JavaScript bundles.
+
+Use environment variables for secrets in all environments. Review your `.gitignore` to ensure `.env` files are excluded. Audit your repository history if you suspect a secret was ever committed, as git history is public on public repositories and can be scraped.
+
+### Hash passwords, always
+
+If you're implementing any custom credential handling, passwords must be hashed using a modern, slow hashing algorithm: bcrypt, scrypt, or Argon2. Never store plaintext passwords. Never use MD5, SHA-1, or SHA-256 for password storage; these are fast algorithms designed for integrity checking, not password hashing.
+
+If you're using a managed authentication system, this is handled for you. Verify that it is.
+
+### Validate and sanitize inputs
+
+Data from users (form submissions, URL parameters, file uploads) must be validated before being used. At minimum:
+- Validate that data matches the expected format before processing
+- Sanitize HTML input to prevent XSS (use an established library, not custom string replacement)
+- Use parameterized queries instead of string concatenation for database queries (this prevents SQL injection)
+- Validate file uploads by type and content, not just by file extension
+
+## What managed backend platforms handle for you
+
+A significant share of the security work described above is in the authentication and data access layer. Backend-as-a-service platforms that implement security correctly by default take this burden off application developers:
+
+- Password hashing and session management are handled by the platform
+- Rate limiting on authentication endpoints is built in
+- Granular permission systems let you enforce least-privilege access declaratively
+
+The security that remains (input validation, dependency updates, secrets management, HTTPS configuration) is still your responsibility, but it's a much smaller surface area.
+
+## Appwrite's built-in security features
+
+Appwrite is an open-source developer infrastructure platform for building web, mobile, and AI apps. It includes both a backend server, providing authentication, databases, file storage, serverless functions, real-time subscriptions, and messaging, and a fully integrated hosting solution for deploying static and server-side rendered frontends. Appwrite can be fully self-hosted on any Docker-compatible infrastructure or used as a managed service through [Appwrite Cloud](https://cloud.appwrite.io).
+
+For developers who aren't security specialists, Appwrite handles the authentication and data access security layer correctly by default:
+
+- **Argon2 password hashing**: Appwrite hashes user passwords using Argon2, the current recommended algorithm for password storage. You never store or handle plaintext passwords.
+- **Brute-force protection**: Login endpoints have built-in rate limiting and account lockout after repeated failed attempts, protecting against credential stuffing attacks without any configuration.
+- **Secure session management**: Appwrite generates cryptographically secure session tokens, enforces session expiration, and invalidates tokens on logout.
+- **Multi-factor authentication**: MFA can be enabled for your application with minimal configuration, adding a second verification factor for all users or specific user groups.
+- **Granular permissions**: Appwrite's permission system lets you define exactly which users or teams can read, create, update, or delete each resource. Authorization bugs (users accessing data they shouldn't) are prevented at the data layer, not just the UI.
+- **Password policies**: Minimum password length, password history, and dictionary checks can be configured to prevent weak or reused credentials.
+
+## Apply consistent security practices to protect users without a security team
+
+Securing user data doesn't require becoming a security specialist. It requires applying a set of well-documented practices consistently: use managed authentication, enforce least-privilege access, update dependencies, use HTTPS, protect secrets, and validate inputs. With Appwrite handling the authentication and access control layer, your security surface area shrinks to the parts of your application that are genuinely unique.
+
+- [Appwrite Authentication documentation](https://appwrite.io/docs/products/auth)
+- [Appwrite Multi-factor Authentication](https://appwrite.io/docs/products/auth/mfa)
+- [Appwrite Databases permissions](https://appwrite.io/docs/products/databases/permissions)
+- [OWASP Top Ten](https://owasp.org/www-project-top-ten/)
diff --git a/src/routes/blog/post/when-custom-backend-stops-being-worth-it/+page.markdoc b/src/routes/blog/post/when-custom-backend-stops-being-worth-it/+page.markdoc
new file mode 100644
index 0000000000..70d9bc8757
--- /dev/null
+++ b/src/routes/blog/post/when-custom-backend-stops-being-worth-it/+page.markdoc
@@ -0,0 +1,76 @@
+---
+layout: post
+title: "When 'custom backend' stops being worth it for small teams"
+description: The real costs of maintaining a custom backend and how to decide when switching to a managed backend platform makes more business sense for your team.
+date: 2024-05-17
+cover: /images/blog/when-custom-backend-stops-being-worth-it/cover.png
+timeToRead: 6
+author: aditya-oberai
+category: product
+featured: false
+unlisted: true
+---
+
+There's a point in many small teams' development journey where the backend they built (once a source of pride and flexibility) starts feeling like a liability. Deployments take longer than they used to. A security update broke something unexpectedly. The one person who understands the authentication system is on vacation. Every new feature requires touching infrastructure that nobody is confident enough to change quickly.
+
+This is the moment to ask an uncomfortable question: is our custom backend still worth it?
+
+## What "custom backend" actually costs
+
+The appeal of building a custom backend is real. You control everything. You can optimize for your exact use case. You're not paying platform fees. But the true cost of a custom backend includes more than just the initial development time:
+
+- **Ongoing maintenance.** Authentication libraries need updates. Database drivers get new security patches. Server configurations drift. Every week that passes, someone on your team is spending time on infrastructure instead of features.
+- **Security expertise.** A secure authentication system, password hashing, brute-force protection, session management, and MFA are each non-trivial engineering problems. Getting them right requires expertise that most product-focused teams don't have in depth.
+- **Operational burden.** Deployments, monitoring, alerts, backup and recovery, and incident response all require time and attention. For a small team shipping a product, this is time not spent on the product.
+- **Knowledge concentration.** Custom systems tend to have one or two people who really understand them. When those people leave or are unavailable, the rest of the team is flying blind.
+- **Scaling complexity.** Handling more users means thinking about database connection pools, caching layers, horizontal scaling, and stateless architecture. None of this is trivial.
+
+## Signs that a custom backend is costing more than it's worth
+
+- **New feature development is slower than it should be.** If adding a new endpoint requires touching five different files across three services because of how the backend was originally structured, the architecture is working against you.
+- **You're scared to make changes.** A system that nobody wants to touch is a system that's accumulating technical debt at an accelerating rate.
+- **Security incidents feel likely.** If your team is not confident that the authentication, authorization, and data access patterns are correct, that's a real risk.
+- **Deployment takes significant developer time.** Manual deployment processes or complex CI/CD configurations that require constant maintenance are signs of a system that has grown beyond the team's capacity to maintain it well.
+- **The backend consumes a disproportionate share of engineering attention.** If maintaining infrastructure is regularly taking time away from building product, the math has shifted.
+
+## When custom backends are still the right choice
+
+Not every custom backend is a mistake to continue maintaining:
+
+- If your application has genuinely unique backend requirements (complex business logic, specialized data processing, proprietary algorithms), a custom backend may be the right approach.
+- If you have dedicated backend or DevOps engineers whose full-time job is maintaining and improving the infrastructure, the operational burden is someone's actual job.
+- If your scale or compliance requirements rule out managed platforms, custom is sometimes the only option.
+- If you've built something that has become a competitive moat (where the backend architecture itself is part of what makes your product special), that's worth protecting.
+
+The problem is that most small teams don't meet these criteria. They have a custom backend because they built it before managed backend platforms were as capable as they are today.
+
+## What the migration actually looks like
+
+The fear of migrating away from a custom backend often outweighs the reality. Modern backend platforms support:
+
+- **Gradual migration.** You don't have to swap everything at once. Authentication can move first, then storage, then databases. Each service you migrate reduces your maintenance burden.
+- **Data export and import.** Appwrite's databases are standard JSON/document stores. Exporting your existing data and importing it is straightforward for most data models.
+- **API compatibility.** Most backend platforms provide REST and SDK-based APIs that your existing front-end can call with modest changes.
+
+## Appwrite as your managed backend
+
+Appwrite is an open-source developer infrastructure platform for building web, mobile, and AI apps. It includes both a backend server, providing authentication, databases, file storage, serverless functions, real-time subscriptions, and messaging, and a fully integrated hosting solution for deploying static and server-side rendered frontends. Appwrite can be fully self-hosted on any Docker-compatible infrastructure or used as a managed service through [Appwrite Cloud](https://cloud.appwrite.io).
+
+What makes Appwrite a strong candidate for teams migrating away from a custom backend:
+
+- **Breadth of coverage**: Authentication, database, storage, functions, real-time, and messaging in one platform means fewer migration steps and fewer new vendors to evaluate separately.
+- **No proprietary lock-in**: Appwrite is Apache 2.0 licensed and fully open source. The APIs follow standard REST conventions. If you ever need to move again, the migration path exists.
+- **Self-hosting option**: Teams that built a custom backend to keep data on their own infrastructure don't have to give that up. Appwrite can be deployed within your own cloud account, satisfying data control requirements while eliminating the maintenance burden of a custom implementation.
+- **Security handled correctly**: The concerns that make custom backends risky (password hashing, brute-force protection, session management) are handled at the platform level using proven implementations (Argon2 for password hashing, configurable rate limiting, secure session tokens).
+- **Gradual migration support**: Appwrite's REST API means your existing frontend can call Appwrite endpoints without a full rewrite. Authentication, storage, and database can be migrated service by service rather than all at once.
+
+## Migrate away from your custom backend before it becomes a blocker
+
+The question isn't whether building a custom backend was wrong. It was probably the right decision at the time. The question is whether continuing to maintain it is the highest-value use of your team's engineering time right now.
+
+[Appwrite](https://appwrite.io) is an open-source backend platform that covers authentication, databases, file storage, serverless functions, and real-time subscriptions in a single, self-hostable platform. It handles the infrastructure concerns: security patches, scaling configurations, session management, password policies. Your team focuses on the product. Because it's open source, you're not locked into a pricing model or a vendor's roadmap. Explore the [Appwrite documentation](https://appwrite.io/docs) to see what migrating to a managed backend platform could look like for your project.
+
+- [Appwrite Documentation](https://appwrite.io/docs)
+- [Appwrite Self-Hosting docs](https://appwrite.io/docs/advanced/self-hosting)
+- [Appwrite Authentication docs](https://appwrite.io/docs/products/auth)
+- [Sign up for Appwrite Cloud](https://cloud.appwrite.io)