diff --git a/.optimize-cache.json b/.optimize-cache.json
index fa2881382e..999a1ccc68 100644
--- a/.optimize-cache.json
+++ b/.optimize-cache.json
@@ -280,6 +280,7 @@
   "images/blog/baas-vs-custom-backend/storage.png": "6ed39797b1d5f67299c55b1be3944912860811564c38e849adb31a0d4a23ec46",
   "images/blog/baas.png": "e5353595cc9c6c8037a7b9b3a8ff25552cb39f61a120ecb867c63de46f14aa74",
   "images/blog/backend-mistakes-that-quietly-cost-small-teams-weeks/cover.png": "c804b93ac334b4224c612fc5c177469f30a6a6e548db1c93e90fb95b35544bda",
+  "images/blog/backend-platform-longevity-what-to-look-for-beyond-features/cover.png": "234650617a90c69a898eb456ae2d807f3a1d0f627376ac6481074b24c1712196",
   "images/blog/backend-platform-security-responsibilities/cover.png": "030e20752d00612ff677b28c2fd30665ed34fcd77ee80a6efa89d9d789cb9d94",
   "images/blog/backend-that-scales/cover.png": "1d6ee39bc41387024bb9beded27137e7f135293c654add113ca9ee3fd4b8c9cb",
   "images/blog/backup-encryption/cover.png": "4a3b2f9f2acc75681669c1dcefa407455e6f7ee29f2dc04bd4e9cae5f9d646c9",
@@ -614,6 +615,7 @@
   "images/blog/how-to-build-remote-tech-stack/8.png": "f12c97de435dd9c2ee75fa0f20c4c8656f427e2d7152da397d591bea28d44670",
   "images/blog/how-to-build-remote-tech-stack/9.png": "58eee849e77fe9dba8ff44ccf6684287da8fb70ba35c21d180895c6f1068d04f",
   "images/blog/how-to-build-remote-tech-stack/cover.png": "6fe081cb2fb1a6201707a2af0141c6cdb8805a6e2fea00a79d1ed1d81bfafed8",
+  "images/blog/how-to-evaluate-open-source-maturity-before-using-it-in-production/cover.png": "b4bb31d2054e5db2a874c7495cdc3eba03e0778d60db7ff9b01b1c7f7e1f55f5",
   "images/blog/how-to-leverage-dynamic-api-keys-for-better-security/1.png": "fe8b06f98101c69b6d50e71f3d312efff6838ee880bcedd1dab9ca1ce9234a1f",
   "images/blog/how-to-leverage-dynamic-api-keys-for-better-security/cover.png": "bee9d6ac2b5a0b18835dcca25ded91087722724daafe10c1579a4f35e3d3a9f2",
   "images/blog/how-to-migrate-database-with-cli/1.png": "bc2168b4d96ad07d844fd0599bb87b3235cc612ca96246780b817933d6e30b79",
diff --git a/src/routes/blog/post/backend-platform-longevity-what-to-look-for-beyond-features/+page.markdoc b/src/routes/blog/post/backend-platform-longevity-what-to-look-for-beyond-features/+page.markdoc
new file mode 100644
index 0000000000..02e6227875
--- /dev/null
+++ b/src/routes/blog/post/backend-platform-longevity-what-to-look-for-beyond-features/+page.markdoc
@@ -0,0 +1,110 @@
+---
+layout: post
+title: "Backend platform longevity: What to look for beyond features"
+description: Learn what to look for beyond features when choosing a backend platform—maintenance cadence, governance, security posture, data portability, and long-term stability.
+date: 2026-04-07
+cover: /images/blog/backend-platform-longevity-what-to-look-for-beyond-features/cover.png
+timeToRead: 5
+author: atharva
+category: open-source
+featured: false
+unlisted: true
+---
+
+Most backend platform comparisons focus on features: which authentication methods are supported, how the database query API works, whether there's a serverless functions layer. These are the wrong questions to lead with.
+
+Getting features right is just the starting point. What actually determines whether a backend dependency was a good decision three years from now is whether the platform is still maintained, still trustworthy, and still something you can get off if you need to. Evaluating for longevity requires a different set of questions.
+
+# The real cost of a platform that doesn't last
+
+Platforms get shut down, acquired, or quietly abandoned. When that happens, every team that built on them has to pay the full cost of migrating away. That cost is rarely just "update your imports." It means migrating data out of proprietary formats, rewriting authentication flows, rebuilding API integrations, and doing all of it while your production application continues to serve users.
+
+The problem is that these risks are invisible at evaluation time. A platform with excellent documentation, a polished dashboard, and a generous free tier can show every sign of health and still be one funding round away from a shutdown notice. Evaluating platforms purely on current features is evaluating a snapshot. What you actually need to assess is trajectory.
+
+# What to look for when evaluating backend platform longevity
+
+## Release cadence and active maintenance
+
+A platform's release history tells you how seriously its maintainers take ongoing development. Look for consistent, documented releases with clear changelogs. Not just frequency, but quality: are releases shipping bug fixes and security patches alongside new features, or are they silent for months and then releasing large version jumps with no migration path?
+
+For open-source projects, the GitHub commit graph is a direct indicator. A project with active commits across multiple contributors is resilient to individual contributor churn. A project maintained by one or two people with inconsistent activity carries concentration risk.
+
+Key questions to ask:
+- How frequently are releases published, and are changelogs substantive?
+- Are reported bugs and security issues being closed, or accumulating without resolution?
+- Are there active pull requests from contributors beyond the core team?
+
+## Governance and organizational backing
+
+Who controls the platform, and what are their incentives? This is a particularly important question for platforms that present as open source but are controlled entirely by a single commercial entity.
+
+A platform with a clearly documented open-source license and active governance beyond one company is more durable than one where the license is permissive on paper but the roadmap is controlled by a single vendor with undisclosed commercial priorities. Corporate-backed open source is not inherently problematic, but the terms of that backing matter: is the core software licensed permissively or with a license that restricts self-hosting and forks?
+
+## Community adoption signals
+
+GitHub stars are a vanity metric. Real adoption signals are harder to count but more informative:
+
+- **Active forum or community discussion**: are real developers asking and answering questions about production use cases?
+- **Third-party integrations and tutorials**: is the ecosystem growing independently of the core team?
+- **Production usage references**: are teams at real companies publicly building on this platform, not just early-stage projects?
+- **Contributor diversity**: are contributions coming from outside the core company, indicating that the community has genuine ownership?
+
+A platform with 20,000 stars but a dead community forum and no external contributions is less durable than one with 5,000 stars and a thriving contributor ecosystem.
+
+## Security posture and vulnerability response
+
+How a platform handles security incidents tells you more about its maturity than how it handles feature requests. Look for a documented security disclosure process, a track record of timely CVE acknowledgments and patches, and transparency about what was wrong and how it was fixed.
+
+Platforms without a public security policy, or that have a history of slow or opaque vulnerability responses, are a liability for any team with compliance requirements or sensitive user data.
+
+Key questions:
+- Is there a documented process for reporting and disclosing security vulnerabilities?
+- How quickly have past CVEs been patched?
+- Does the platform publish security advisories proactively?
+
+## Open-source license and self-hosting option
+
+This is the most important escape hatch for long-term platform decisions. If a vendor's cloud service changes pricing, changes terms, or shuts down entirely, an open-source platform with a permissive license and self-hosting support lets you continue operating the same software on your own infrastructure.
+
+A platform that is open source in name but restricts self-hosting in its license, or requires proprietary plugins for essential features, does not provide this escape hatch. Verify the actual license terms, not just the marketing claim of being "open source."
+
+For teams building applications with data residency requirements or compliance obligations, self-hosting is often a hard requirement.
+
+## Data portability
+
+When evaluating any platform, spend time on the exit path: what does it take to move your data elsewhere? The answer tells you how much trust the platform requires you to extend.
+
+Platforms that store data in proprietary formats or require vendor assistance for export create high switching costs by design. Platforms that store data in standard formats (SQL dumps, JSON, CSV) with self-service export tooling treat data portability as a first-class concern.
+
+# A longevity checklist for backend platforms
+
+Before committing to a backend platform, work through these points:
+
+- Does the platform have a consistent, documented release history with meaningful changelogs?
+- Is the codebase actively maintained by multiple contributors, or concentrated in one or two people?
+- What is the open-source license? Are self-hosting and forks unrestricted?
+- Is there a public security disclosure policy and a track record of timely vulnerability patches?
+- Can you export your data in standard formats without vendor assistance?
+- Is the community active in ways that reflect real production usage, not just GitHub stars?
+- If the vendor's cloud service shut down tomorrow, could you self-host the software without code changes?
+
+# Evaluating Appwrite for long-term backend stability
+
+Appwrite is an open-source developer infrastructure platform for building web, mobile, and AI apps. It includes authentication, databases, file storage, serverless functions, real-time subscriptions, and messaging, along with 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 each longevity dimension:
+
+- **Release cadence**: Appwrite maintains a consistent release schedule with detailed changelogs. The project has shipped multiple major versions with documented migration paths, and patches are released on a regular cadence.
+- **Governance**: Appwrite is BSD 3-Clause licensed, which permits self-hosting and forking without restriction. The codebase is publicly available and accepts external contributions.
+- **Community**: Appwrite has a large active developer community, with real production usage across web, mobile, and AI applications. Community discussions, third-party tutorials, and integrations are built independently of the core team.
+- **Security**: Appwrite publishes security advisories and follows a documented vulnerability disclosure process. Authentication security (Argon2 hashing, brute-force protection, rate limiting) is implemented at the platform layer. See [Appwrite's security documentation](/docs/advanced/security) for specifics.
+- **Self-hosting**: Appwrite is fully self-hostable using Docker. If Appwrite Cloud ceased to exist, you could run the same software on your own infrastructure without code changes.
+- **Data portability**: Appwrite supports self-service data migration between Cloud and self-hosted deployments, and databases support CSV export for table data.
+
+Appwrite does not remove the need to evaluate carefully. It is a specific choice with specific trade-offs. But it is designed around the properties that matter for long-term platform decisions: open licensing, self-hosting support, standard APIs, and predictable pricing based on compute and storage rather than per-operation billing.
+
+- [Appwrite self-hosting documentation](/docs/advanced/self-hosting)
+- [Appwrite security overview](/docs/advanced/security)
+- [Appwrite Databases documentation](/docs/products/databases)
+- [Appwrite Auth documentation](/docs/products/auth)
+- [Sign up for Appwrite Cloud](https://cloud.appwrite.io)
diff --git a/src/routes/blog/post/how-to-evaluate-open-source-maturity-before-using-it-in-production/+page.markdoc b/src/routes/blog/post/how-to-evaluate-open-source-maturity-before-using-it-in-production/+page.markdoc
new file mode 100644
index 0000000000..484d373ee7
--- /dev/null
+++ b/src/routes/blog/post/how-to-evaluate-open-source-maturity-before-using-it-in-production/+page.markdoc
@@ -0,0 +1,122 @@
+---
+layout: post
+title: How to evaluate open-source maturity before using it in production
+description: Evaluate open-source maturity before using it in production. Learn what to check, common risks, and a practical framework to choose reliable tools with confidence.
+date: 2026-04-07
+cover: /images/blog/how-to-evaluate-open-source-maturity-before-using-it-in-production/cover.png
+timeToRead: 5
+author: aditya-oberai
+category: open-source
+featured: false
+unlisted: true
+---
+
+You rarely find out a project is abandoned while you're evaluating it. You find out six months after shipping, when a CVE drops and there's no patch on the horizon, or when the project's sole maintainer archives the repository and the last release is two years old.
+
+Adding an open-source tool to a production stack is a bet on the project's future. The evaluation that happens upfront determines whether that bet is informed or accidental. This post covers what to check before making it.
+
+# Why OSS maturity matters in production
+
+The risk isn't that open source is inherently unreliable. Widely-adopted, well-maintained open-source projects are often more battle-tested than proprietary alternatives. The risk is **picking a project that looks active but isn't**, or adopting something with a license that creates legal exposure at scale.
+
+The practical costs of picking the wrong OSS tool:
+
+- Security vulnerabilities with no patches, forcing you to either carry the fix yourself or migrate under pressure
+- Breaking changes in major versions with no migration guides and no community to ask
+- Dependencies that fall behind major ecosystem updates, creating upgrade debt
+- License terms that conflict with your distribution model or compliance requirements
+
+These aren't edge cases. They're the standard outcome of adopting unmaintained or poorly governed open-source projects.
+
+# Check maintenance cadence first
+
+The first thing to look at is how recently and how consistently the project has been updated. A project can have 20,000 GitHub stars and still be effectively dead.
+
+Check these signals:
+
+- **Last commit and last release**: If the last release is more than a year old in an active ecosystem, ask why. A library that wraps a stable protocol might legitimately have rare releases. A backend framework almost certainly shouldn't.
+- **Release frequency**: Does the project release regularly? Irregular bursts followed by long silences suggest a solo maintainer working on spare time.
+- **Issue and PR response time**: Open a few recent issues and look at how quickly they were acknowledged. Response time correlates strongly with how seriously the project takes outside contributors.
+- **Changelog quality**: A detailed changelog signals a team that thinks about the developer experience of upgrading. A vague or missing one signals the opposite.
+
+# Assess the bus factor
+
+**Bus factor** is a term from software engineering that describes how many contributors would need to leave before a project stalls. It's a useful way to think about concentration risk on any team, and it applies directly to open-source projects. A project maintained by a single person is fundamentally higher risk than one with a team of active contributors, even if that solo maintainer is prolific.
+
+To evaluate this:
+
+- **Look at the contributor graph on GitHub.** Is there a clear primary author with one or two occasional contributors, or is the contribution spread across multiple people?
+- **Check if there's a commercial entity backing the project.** Projects backed by a company with revenue tied to their success are more likely to stay maintained than pure volunteer efforts. Companies have incentives to patch vulnerabilities, publish roadmaps, and invest in documentation.
+- **Look for a governance model.** Projects with explicit governance documents, foundations, or steering committees are structurally more resilient than those with informal ownership.
+
+A project maintained by a backed company is not inherently better engineered, but it is more predictable over a multi-year horizon.
+
+# Read the license carefully
+
+License risk is the most commonly skipped part of OSS evaluation. The license determines what you can do with the software, and some licenses have conditions that only matter at scale or in specific distribution contexts.
+
+Key license types to understand:
+
+- **MIT / Apache 2.0 / BSD**: Permissive licenses with few restrictions. You can use, modify, and distribute without open-sourcing your own code. Apache 2.0 adds an explicit patent grant.
+- **GPL / LGPL / AGPL**: Copyleft licenses. GPL requires that derivative works also be GPL-licensed. AGPL extends this to software accessed over a network, which has significant implications for SaaS products.
+- **Business Source License (BSL / BUSL)**: Source-available with a time delay. The code is not truly open source; commercial use is typically restricted for several years after each release. HashiCorp and Directus use this model.
+- **Custom source-available licenses**: Some projects use proprietary licenses that look open source but restrict commercial use, competitive products, or modification. Read the actual text.
+
+*Note: These are simplified summaries. Each license has nuances that may affect your specific use case, and you should read the actual license text or consult legal counsel before making decisions based on them.*
+
+If your product is distributed to customers or runs as a SaaS, understand the copyleft surface area of everything in your stack. An AGPL dependency in a cloud service can create unexpected obligations.
+
+# Evaluate the security posture
+
+An open-source project's security track record is observable in ways that proprietary software's isn't. Use that transparency.
+
+- **SECURITY.md**: Does the project have a documented security disclosure process? This is a basic indicator of whether the maintainers take security seriously.
+- **CVE history**: Search the project name in the [National Vulnerability Database](https://nvd.nist.gov). The presence of CVEs isn't inherently bad. Frequent CVEs that were patched quickly indicate a mature security process. Vulnerabilities that sat open for months, or were disclosed publicly before a patch was available, are warning signs.
+- **Dependency hygiene**: Projects that use outdated dependencies with known vulnerabilities inherit that risk. Check whether the project regularly updates its own dependencies.
+- **Automated scanning**: Does the project run dependency scanning in CI? Dependabot or equivalent tools being active is a positive signal.
+
+# Look at real-world adoption
+
+Stars and forks are lagging indicators. What matters more is whether the project is being used in production by teams with similar requirements to yours.
+
+- **Case studies and testimonials**: Does the project's documentation reference real production users? Public case studies are a signal of a project confident in its production fitness.
+- **Community activity**: Is the Discord, Slack, or forum active? Are questions getting answered? An active community is a support resource for when you hit edge cases.
+- **Stack Overflow and forum presence**: Search for the project name on Stack Overflow and GitHub Discussions. The volume and quality of answers reflects both adoption and community investment.
+- **Production incident reports**: Search for "[project name] production" or "[project name] outage" to find real engineering blogs. Teams that have run the tool at scale and written about it give you more signal than any benchmark.
+
+# A practical evaluation checklist
+
+Before adopting any OSS tool in a production stack, check:
+
+- Last release date and release cadence
+- Number of active maintainers and whether a company backs the project
+- License type and implications for your distribution model
+- SECURITY.md presence and CVE patch response time
+- Dependency scanning in CI
+- Open issues count and average response time
+- Community activity level and support channels
+- Evidence of production use by comparable teams
+
+This is a ten-minute review that prevents months of remediation work.
+
+# How Appwrite scores against these criteria
+
+
+- **Maintenance cadence**: Appwrite releases frequently, with a public changelog and roadmap. The GitHub repository shows consistent commit activity across a distributed team.
+- **Bus factor**: Appwrite is backed by a commercial entity. The engineering team is not a single volunteer; it's a funded organization with incentives tied to the project's production reliability.
+- **License**: BSD 3-Clause. Permissive, with no copyleft, no source-available restrictions, and no commercial use limitations.
+- **Security posture**: Appwrite maintains a public [security policy](/docs/advanced/security) and patches vulnerabilities promptly. The open-source codebase means vulnerabilities can be found through community review, not only internal audits.
+- **Adoption**: Appwrite is used in production across a wide range of application types. The community is active across GitHub and [Discord](https://appwrite.io/discord), and the documentation covers production deployment, scaling, and migration scenarios.
+
+# Evaluating Appwrite for your production stack
+
+Running through the evaluation framework above with Appwrite produces a clear picture: it's a project that was built with production use as a first-class concern, not an afterthought.
+
+The self-hosting documentation covers real deployment scenarios, including high availability, scaling, and upgrades across major versions. The security overview is public and specific. The authentication, database, and storage primitives are the kind of foundational infrastructure where stability and long-term maintenance matter more than novelty.
+
+If you're evaluating a backend platform for a new project, or weighing a migration away from something you've outgrown, the framework in this post gives you a repeatable process. Appwrite is one tool worth running it against.
+
+- [Appwrite self-hosting docs](/docs/advanced/self-hosting)
+- [Appwrite security overview](/docs/advanced/security)
+- [Appwrite authentication docs](/docs/products/auth)
+- [Appwrite Cloud](https://cloud.appwrite.io)
diff --git a/static/images/blog/backend-platform-longevity-what-to-look-for-beyond-features/cover.png b/static/images/blog/backend-platform-longevity-what-to-look-for-beyond-features/cover.png
new file mode 100644
index 0000000000..8e58f0ae84
Binary files /dev/null and b/static/images/blog/backend-platform-longevity-what-to-look-for-beyond-features/cover.png differ
diff --git a/static/images/blog/how-to-evaluate-open-source-maturity-before-using-it-in-production/cover.png b/static/images/blog/how-to-evaluate-open-source-maturity-before-using-it-in-production/cover.png
new file mode 100644
index 0000000000..b4f021088e
Binary files /dev/null and b/static/images/blog/how-to-evaluate-open-source-maturity-before-using-it-in-production/cover.png differ