diff --git a/.optimize-cache.json b/.optimize-cache.json
index 3338a7f69b..59e15bb631 100644
--- a/.optimize-cache.json
+++ b/.optimize-cache.json
@@ -995,6 +995,7 @@
   "images/blog/the-journey-and-meaning-behind-our-new-logo/old_logo.png": "0690abbd5e2720df68534729973ff0155c383900d64bcd297e1c67e517c785ce",
   "images/blog/the-shift-from-SaaS-to-Vertical-AI-what-startup-founders-need-to-know/cover-image.png": "e4030cb8b735baa8f4f6eec9d0d32233011759b160882015738cda2e79da14d6",
   "images/blog/the-subtle-art-of-hackathon ideation/cover.png": "a4007fb895ed8cb284e2409897282a784b803c199b91d58e90a2dd69f367ba33",
+  "images/blog/the-underrated-value-of-great-sdk-design/cover.png": "9440e4f5a69b01d20796926ef3543dbba61fd1ba66e114713cf4ee503bc1d4b9",
   "images/blog/threads-cover.png": "fa44d6cd70000ac7a62d3b9446b171f8e9fe1b27f157cb6ba2f98c1f8c043526",
   "images/blog/three-important-steps-you-need-to-complete-with-appwrite/3-important-steps.png": "5a3ad677a3aff5f27f0ceb8b751ba830fb6e11ca5edca126df34777f378b15a4",
   "images/blog/three-important-steps-you-need-to-complete-with-appwrite/add-platform.png": "8f055abaa1fa38a447166f712903c297ca966dc22316e864bcbd9acc45195e55",
@@ -1042,6 +1043,7 @@
   "images/blog/valentines-day-sonnet-generator/templates.png": "e69192c1944e31f086780e91b034797af48bafe4f469631947f73bac50243503",
   "images/blog/vibe-coding-security-best-practices/cover.png": "b0c69c03743fc542ff384da87d2cd733a85d1a057e654dc3bee1f572999a6500",
   "images/blog/webp-support-for-safari/cover.png": "ea4e965ffe21500f3552073bb7ca325d453020cf095d67164329edbda3f1c799",
+  "images/blog/what-developers-actually-want-from-a-backend-platform/cover.png": "0c540d48b12cd7031e3cadaf4223086ded946b42dc283c641cfa024311b2ec36",
   "images/blog/what-is-cdn/cover.png": "ef77860288e150c6c22f3950a5eae4c88aefefb6db204f10c2a0544e51548703",
   "images/blog/what-is-ciam/cover.png": "45a5261ae1bb8a38777f60a21ea60426c0832e3d58bf3164100548400d388ce1",
   "images/blog/what-is-mcp/claude-mcp-chat.png": "26842cfebca3ec2cec89448e1c0d7ddb3f5421cc57acdb8780d48d30a54cad82",
@@ -1050,6 +1052,7 @@
   "images/blog/when-custom-backend-stops-being-worth-it/cover.png": "d03b13c4e8f3294823a7883cdae89ca18a4030b170c51f597bd139c9ca274793",
   "images/blog/why-developers-choose-appwrite-auth/cover.png": "f56c37ebfc25191e113b928ff3cf144563be740159e46d75a427bdafdd11214b",
   "images/blog/why-developers-leaving-nextjs-tanstack-start/cover.png": "4581dead0651adab3e28e50610efa900956a0d120f222d991c207a65fbd09f7c",
+  "images/blog/why-documentation-is-the-most-underrated-developer-feature/cover.png": "52a9dde70eeefcd7e489305fc30d2d6f6a63142c5bb00ee027a81454eaef4676",
   "images/blog/why-multi-cloud-is-taking-over/cover.png": "e588be61a1cfd1cd49f5e5268b13cd29d4525a0ff8b6c0e708aec57976a15561",
   "images/blog/why-use-go-cover.png": "a3251fd6f2b87ef968f9d45a7020222649d8472e08ad5fd8442cde70ea17f947",
   "images/blog/why-you-need-to-try-the-new-bun-runtime/bun-buildtime.png": "69b92a76d4e7935d666da1b010e6606a8b73c009de23e00a891c551fb1d042dd",
diff --git a/src/routes/blog/post/the-underrated-value-of-great-sdk-design/+page.markdoc b/src/routes/blog/post/the-underrated-value-of-great-sdk-design/+page.markdoc
new file mode 100644
index 0000000000..886c441bec
--- /dev/null
+++ b/src/routes/blog/post/the-underrated-value-of-great-sdk-design/+page.markdoc
@@ -0,0 +1,103 @@
+---
+layout: post
+title: The underrated value of great SDK design
+description: "Great SDK design can make or break developer adoption. Here's why SDK quality matters, and what developers actually expect from modern backend platforms."
+date: 2026-03-31
+cover: /images/blog/the-underrated-value-of-great-sdk-design/cover.png
+timeToRead: 5
+author: aishwari
+category: product
+featured: false
+unlisted: true
+---
+
+Most developers evaluate a backend platform by its features, pricing, and scalability. The SDK barely gets a second look. That's a mistake.
+
+A badly designed SDK can make even a capable backend feel hostile. A well-designed one makes authentication, file uploads, and database queries feel like they belong in your language, not like you're fighting a foreign API layer bolted onto HTTP.
+
+# SDK design is a first-order problem for developer adoption
+
+When developers describe a backend platform as "easy to use," they usually mean the SDK is well designed. The underlying REST API may be near-identical across competing platforms, but the layer between your code and those endpoints is where adoption is won or lost.
+
+The average developer doesn't read API reference docs before trying a new service. They install the package, look for autocomplete hints, try a few methods, and check whether error messages tell them what went wrong. If any of those steps produce friction, they move on.
+
+**SDK quality is directly correlated with time-to-first-success.** That window is shorter than most teams building developer tools want to admit. A developer who gets a working integration in ten minutes will remember that. A developer who spends an hour decoding cryptic errors will remember that too.
+
+# Language-native patterns are not optional
+
+A JavaScript SDK that requires manual callback management in 2026 is not just inconvenient. It signals that the people who built it don't use JavaScript day-to-day.
+
+Good SDK design means writing code that feels idiomatic in the language it targets:
+
+- Promises and async/await in JavaScript and TypeScript
+- Suspend functions in Kotlin
+- async/await in Swift with structured concurrency
+- Context-based patterns in Go
+- Dataclasses and type hints in Python
+
+If a developer has to mentally translate your SDK into their language's idioms, they are doing extra work they shouldn't need to do. The seams show, and they will remember them.
+
+Appwrite maintains [official SDKs](/docs/sdks) for Web, Flutter, React Native, Apple, Android, Node.js, Python, Dart, PHP, Ruby, .NET, Go, Swift, and Kotlin. Each SDK is built to respect the conventions of its platform, not just to wrap HTTP calls.
+
+# Type safety removes an entire class of runtime bugs
+
+A raw REST API gives you strings and JSON blobs. A well-designed SDK gives you typed objects, enums, and method signatures that make incorrect usage impossible at compile time.
+
+This matters more than it might seem. Passing a plain string where an enum value is expected fails silently during development and loudly in production. Type-safe SDKs shift that entire class of error to compile time, where it costs seconds to fix instead of hours of debugging a live system.
+
+Appwrite SDKs ship with [enumeration classes](/docs/sdks#enums) for predefined values used across authentication factors, storage compression algorithms, query operators, runtime environments, and more. These enums are available across all supported languages, not just TypeScript.
+
+The [type generation feature](/docs/products/databases/type-generation) takes this further. Run `appwrite types` and the CLI generates typed model classes directly from your database collections, in your project's language. Schema changes propagate to your types automatically, without any manual mapping.
+
+# Error messages that tell you what actually went wrong
+
+This is where many SDKs fall apart. An HTTP 400 error that surfaces as `Bad request` is useless. An error that says `Attribute 'email' is required and cannot be null` is actionable.
+
+Good SDK error handling means:
+
+- **Structured error objects** with codes, messages, and relevant context
+- **Error codes that map to documentation** so developers know exactly where to look
+- **Consistent error shapes** across all methods, not different formats per service
+
+Developers who hit a clear error fix it and move on. Developers who hit a cryptic one start digging through GitHub issues, Stack Overflow, and community forums. Every minute spent decoding an error message is friction that could have been eliminated at the SDK layer. Appwrite's [response codes](/docs/advanced/platform/response-codes) are documented and consistent, so an error in the SDK maps directly to an explanation in the docs.
+
+# Consistent naming and surface area
+
+Nothing slows a developer down faster than having to re-learn conventions every time they cross service boundaries within the same SDK.
+
+If calling `account.get()` fetches the current user, then fetching a database document shouldn't use a different parameter order or a different naming convention for a conceptually similar operation. If pagination works one way for files, it should work the same way for database queries.
+
+Consistency lowers the cognitive load of learning a new platform. Once developers understand the pattern, they can predict the API for features they haven't used yet. That confidence builds trust, and trust keeps teams on a platform long after the initial integration.
+
+Inconsistency is cumulative. One off-pattern method is a minor annoyance. Five of them across a single SDK is a signal that there is no design coherence, and developers will treat the whole thing with suspicion.
+
+# Good defaults, not over-configuration
+
+A common trap in SDK design is exposing every API option as a required parameter. It gives developers maximum control, but it also forces them to understand the full system before they can do anything simple.
+
+The better approach is sensible defaults with opt-in complexity. Create a document without specifying permissions and it uses safe defaults. Fetch a list without specifying pagination and it returns a reasonable page size. The happy path should be obvious and short.
+
+This is the difference between an SDK that onboards developers in minutes and one that requires reading three pages of documentation before the first successful call. New developers should not need to understand your entire platform architecture to get a value out of the database.
+
+# What to look for when evaluating an SDK
+
+Before committing to a backend platform, check a few things that take less than ten minutes and will tell you more than any feature comparison table:
+
+- **Does the SDK feel native to your language?** Look at how async operations are handled, whether method names follow the language's conventions, and how errors surface.
+- **Is type coverage complete?** Partial type coverage is often worse than none because it creates a false sense of safety in the areas it misses.
+- **Are the error messages actionable?** Try triggering a validation error intentionally and see what you get back.
+- **Is the surface area consistent?** Check two or three different services and see if the naming patterns hold across them.
+- **Is the SDK actively maintained?** Check the release history, open issue count, and whether recent framework versions are supported.
+
+Evaluating these things before you integrate will save significant time compared to discovering the gaps mid-project.
+
+# Getting started with Appwrite SDKs
+
+Appwrite's SDKs are open source and actively maintained across 14 platforms. The [SDK generator](https://github.com/appwrite/sdk-generator) is itself open source, which means the community can contribute support for new languages and runtimes without waiting on a vendor roadmap.
+
+If you're evaluating Appwrite or already building with it, these resources are the right place to start:
+
+- [Browse Appwrite's SDKs and supported platforms](/docs/sdks)
+- [Quick start guides by framework](/docs/quick-starts)
+- [Type generation for typed database models](/docs/products/databases/type-generation)
+- [Utility classes for queries, permissions, and IDs](/docs/sdks#utility-classes)
diff --git a/src/routes/blog/post/what-developers-actually-want-from-a-backend-platform/+page.markdoc b/src/routes/blog/post/what-developers-actually-want-from-a-backend-platform/+page.markdoc
new file mode 100644
index 0000000000..268488f258
--- /dev/null
+++ b/src/routes/blog/post/what-developers-actually-want-from-a-backend-platform/+page.markdoc
@@ -0,0 +1,109 @@
+---
+layout: post
+title: What developers actually want from a backend platform
+description: Explore what developers expect from modern backend platforms, from scalability and permissions to pricing predictability and long-term flexibility.
+date: 2026-03-31
+cover: /images/blog/what-developers-actually-want-from-a-backend-platform/cover.png
+timeToRead: 5
+author: aishwari
+category: product
+featured: false
+unlisted: true
+---
+
+Picking a backend platform on feature lists alone is a mistake. Every serious platform offers authentication, databases, storage, and functions. The differentiation isn't in what's listed on a landing page. It's in how the platform behaves when you're deep in a deadline, debugging an auth edge case, or watching costs spike unexpectedly.
+
+Most developers learn this the hard way. They pick a platform quickly, build something, and only later discover the gotchas: a billing model that scales badly, SDKs that don't match their stack, or permissions that are too coarse for real-world access control.
+
+This post covers the criteria that actually matter when evaluating a backend platform, and why getting this decision right early saves significant pain later.
+
+# The real cost of choosing the wrong backend platform
+
+A bad backend choice doesn't announce itself immediately. The first sign is usually a billing alert you weren't expecting. The second is a feature you need that the platform either doesn't support or only supports with a clunky workaround.
+
+By the time you realize you've chosen wrong, you've accumulated real cost: user data in a proprietary format, frontend code tied to platform-specific SDKs, and a migration that will take weeks to execute safely.
+
+The criteria below aren't abstract preferences. They're derived from where migrations actually come from.
+
+# Predictable pricing, not per-operation billing
+
+Pricing anxiety is one of the main reasons developers leave platforms like Firebase. When reads, writes, and function invocations are all metered separately, it becomes genuinely hard to estimate costs at scale, and easy to rack up a surprising bill during a traffic spike.
+
+What predictable pricing actually looks like:
+
+- Usage metered on dimensions you can model in advance
+- Budget caps or spending alerts that fire before you're surprised
+- A free tier that covers real development workflows, not just toy projects
+
+Appwrite's [pricing plans](/pricing) include configurable budget caps on the Pro plan. You set a spending limit, and the platform stops rather than charging you past it. This is the kind of safety net that makes it possible to experiment without financial risk.
+
+# Flexibility and no vendor lock-in
+
+Every backend platform creates some degree of lock-in. The question is how much, and in what form.
+
+Lock-in shows up as proprietary query languages, data stored in formats only the platform understands, or SDKs that have no equivalent if you migrate. Open-source platforms reduce this substantially because you can inspect, fork, and if necessary self-host the stack.
+
+Appwrite is [open-source and self-hostable](/docs/advanced/self-hosting). Most teams use the managed cloud because it removes infrastructure work, but the self-hosted option means your data and your deployment aren't contingent on any pricing or product decision Appwrite makes in the future.
+
+For teams evaluating the trade-offs between building a custom backend and using a BaaS, flexibility is often the deciding factor. The [BaaS vs. custom backend comparison](/blog/post/baas-vs-custom-backend) covers this in more detail.
+
+# Developer experience that reduces friction
+
+A backend platform's SDK is the interface your team will interact with hundreds of times per week. A poorly designed SDK creates friction at every step.
+
+The markers of good developer experience:
+
+- **Type-safe SDKs** with proper type inference so errors surface at compile time, not in production
+- **Local development tooling** so you're not testing against a shared cloud environment
+- **Consistent error messages** that tell you what went wrong, not just that something did
+
+Appwrite provides SDKs for Web, Flutter, Android, iOS, and most server-side languages. The [CLI](/docs/tooling/command-line/installation) supports local development for both functions and the full backend stack, so your development loop stays fast without touching production.
+
+# Full-stack coverage that avoids service sprawl
+
+Every external service your backend relies on is another integration to maintain: another set of API keys, another billing account, another failure point, another status page to watch during incidents.
+
+Backend platforms that cover the full surface area reduce this overhead significantly:
+
+- **[Authentication](/docs/products/auth)** - email, phone, magic links, 30+ OAuth2 providers, MFA, and session management
+- **[Databases](/docs/products/databases)** - structured queries, relationships, real-time subscriptions, and document-level permissions
+- **[Storage](/docs/products/storage)** - file uploads with access control, image transformations, and resumable uploads
+- **[Functions](/docs/products/functions)** - serverless, supporting multiple runtimes, triggered by HTTP, events, or schedules
+- **[Messaging](/docs/products/messaging)** - push notifications, email, and SMS under a single API
+
+With Appwrite, all of these live in one project, share one permission model, and are accessible via consistent SDKs. You're not gluing together separate services for auth, image handling, and transactional email.
+
+# Security built into the platform, not bolted on
+
+Authentication and permissions are the areas where rolling your own solution introduces the most risk. Not because the concepts are hard, but because the attack surface is broad and the consequences of mistakes are severe.
+
+A backend platform should handle the following by default:
+
+- Password hashing with modern algorithms and automatic upgrades
+- Breached password detection at login
+- Rate limiting on authentication endpoints
+- Session management with configurable expiry
+
+Appwrite's [permissions model](/docs/products/databases/permissions) operates at the collection, document, and attribute level. Combined with [roles and labels](/docs/products/auth/roles) on user accounts, you can model granular access patterns without writing custom middleware for every endpoint.
+
+# Scalability from first commit to production
+
+The platforms that work well for MVPs often create problems at scale. Not because they can't handle traffic, but because the developer experience degrades when you need more control or the pricing model doesn't hold up under real usage.
+
+Questions worth asking before committing to a platform:
+
+- Is there a clear upgrade path when you hit free tier limits?
+- Can the database handle complex queries without manual index tuning?
+- Is scaling automatic, or does it require infrastructure decisions you're not ready to make?
+
+Appwrite Cloud scales automatically. Upgrading from the free tier to Pro or Scale happens without touching infrastructure. For teams that need specific configurations or data sovereignty, self-hosting keeps those options open.
+
+# Getting started with Appwrite as your backend platform
+
+If you're actively evaluating platforms, a working prototype tells you more than any comparison post. Appwrite's [quick start guides](/docs/quick-starts) cover most major frameworks and take under ten minutes to set up.
+
+For teams migrating from Firebase or Supabase, the [migration documentation](/docs/advanced/migrations) covers the process step by step.
+
+- [Read the Appwrite docs](/docs)
+- [Start on the free plan](https://cloud.appwrite.io/)
+- [Join the Appwrite Discord](https://appwrite.io/discord)
diff --git a/src/routes/blog/post/why-documentation-is-the-most-underrated-developer-feature/+page.markdoc b/src/routes/blog/post/why-documentation-is-the-most-underrated-developer-feature/+page.markdoc
new file mode 100644
index 0000000000..157fff9a50
--- /dev/null
+++ b/src/routes/blog/post/why-documentation-is-the-most-underrated-developer-feature/+page.markdoc
@@ -0,0 +1,91 @@
+---
+layout: post
+title: Why documentation is the most underrated developer feature
+description: Why documentation is one of the most important developer features, and how great docs improve onboarding, usability, and backend adoption.
+date: 2026-03-31
+cover: /images/blog/why-documentation-is-the-most-underrated-developer-feature/cover.png
+timeToRead: 5
+author: aishwari
+category: product
+featured: false
+unlisted: true
+---
+
+When developers evaluate a new tool, they check the feature list, the pricing page, and maybe a quick-start example. Documentation rarely makes the shortlist. It is treated as a nice-to-have, something to polish after the "real" work is done.
+
+That is a mistake. Documentation is not a supplement to a developer product. It is the product. A feature that nobody can figure out how to use is effectively a feature that does not exist.
+
+# Bad documentation has a measurable cost
+
+The cost of poor documentation is not abstract. It shows up in support tickets, in abandoned trials, and in developers switching to a competitor whose docs answered their question in under a minute.
+
+Consider what happens when a developer hits a wall during onboarding. They try the search bar. They find a reference page with no context. They open a GitHub issue. They ask on Stack Overflow. Two hours later, they close the tab. That is not a documentation problem, that is a retention problem.
+
+Good documentation compresses this path from confusion to working code. It is the difference between a developer recommending your tool to a colleague and silently moving on.
+
+# What good developer documentation actually looks like
+
+Not all documentation is created equal. Most platforms have some form of docs. Few have docs that genuinely help developers ship faster. The difference comes down to a few specific things.
+
+## A fast path to working code
+
+The first thing a developer should be able to do in your docs is get something working. Not read an architecture overview. Not install a dependency manager. Get something running.
+
+A good quick-start guide answers: what do I install, what do I configure, and what does "hello world" look like for this tool? If a developer cannot reach that point in under ten minutes, the onboarding has failed.
+
+## Reference that explains, not just lists
+
+API reference pages often read like the output of a code generator. Every parameter is listed, nothing is explained. Good reference documentation tells you not just what a parameter does, but when you would use it and what happens if you leave it out.
+
+Appwrite's [Auth documentation](/docs/products/auth) is a useful example of this. Rather than listing method signatures, it walks through authentication flows, explains the trade-offs between session types, and links to related guides. That context is what turns a reference page into a learning resource.
+
+## Guides for real developer workflows
+
+Reference covers what exists. Guides cover what to build. The most useful documentation addresses specific developer workflows: how to set up role-based access control, how to handle file uploads with resumable support, how to configure email verification end to end.
+
+These guides matter because developers do not use tools in isolation. They integrate them into existing applications with existing constraints. A guide that matches a real workflow shortens the gap between reading and shipping.
+
+## Search that actually works
+
+Poor documentation search is a silent killer. If a developer cannot find the right page in two or three queries, they will reach for Google instead, and Google may send them to outdated StackOverflow threads rather than your canonical docs.
+
+Good documentation search handles synonyms, partial matches, and typos. It prioritizes results by relevance to the developer's likely intent, not just keyword frequency.
+
+# Why documentation quality drives backend adoption
+
+Backend tools face a specific adoption challenge: they require integration work before a developer sees any value. Authentication libraries, database SDKs, and storage APIs all have a setup cost. Documentation determines whether that setup cost feels manageable or prohibitive.
+
+This is especially true for open-source platforms. When a developer is comparing two tools with overlapping feature sets, documentation quality often becomes the deciding factor. Not because one tool is technically better, but because one tool made it easier to understand how to use it.
+
+The same logic applies to developer experience within teams. When a new engineer joins a project and needs to understand how the backend is structured, the quality of the platform's docs affects how quickly they become productive. Good documentation scales knowledge across a team without requiring one-on-one explanations every time.
+
+# The signal that documentation sends
+
+Well-maintained documentation signals something beyond usability. It signals that the team behind the tool cares about developer experience, not just feature output.
+
+Developers notice when documentation examples use outdated API versions. They notice when a guide references a feature that was deprecated two releases ago. They notice when the changelog does not explain why a change was made, only what changed.
+
+These signals accumulate. A platform that keeps its documentation current, responds to doc issues, and updates guides when the product changes is a platform developers are more willing to depend on. It reduces the risk of adopting the tool.
+
+# How to evaluate documentation before committing to a platform
+
+Before committing to a backend platform, documentation quality is worth treating as a first-class evaluation criterion. A few practical checks:
+
+- **Try the quick start without help.** Open the docs cold and try to reach a working example. Note how long it takes and where you get stuck.
+- **Look for guides covering your actual use case.** If you need JWT-based auth, role-based permissions, or a specific file storage pattern, check whether those workflows are covered with working code.
+- **Search for a specific error message.** If you can find relevant results for a realistic error, the search is functional.
+- **Check the update history.** Documentation that has not been updated in 18 months is a warning sign, even if the product itself has been actively developed.
+
+Appwrite's [documentation](/docs) covers all major product areas with quick starts, per-language SDK references, and guides that match real integration patterns. If you want to see what that looks like in practice, the [quick start guides](/docs/quick-starts) are a good place to start.
+
+# Getting started with Appwrite
+
+Documentation is a proxy for product quality. A platform that invests in helping developers understand and use it well is a platform worth trusting in production.
+
+If you are evaluating backend platforms and documentation quality matters to you, the following links are a good starting point.
+
+- [Appwrite quick starts](/docs/quick-starts)
+- [Appwrite Authentication docs](/docs/products/auth)
+- [Appwrite Databases docs](/docs/products/databases)
+- [Appwrite Storage docs](/docs/products/storage)
+- [Appwrite Functions docs](/docs/products/functions)
diff --git a/static/images/blog/the-underrated-value-of-great-sdk-design/cover.png b/static/images/blog/the-underrated-value-of-great-sdk-design/cover.png
new file mode 100644
index 0000000000..1d9e72db63
Binary files /dev/null and b/static/images/blog/the-underrated-value-of-great-sdk-design/cover.png differ
diff --git a/static/images/blog/what-developers-actually-want-from-a-backend-platform/cover.png b/static/images/blog/what-developers-actually-want-from-a-backend-platform/cover.png
new file mode 100644
index 0000000000..caed350cfc
Binary files /dev/null and b/static/images/blog/what-developers-actually-want-from-a-backend-platform/cover.png differ
diff --git a/static/images/blog/why-documentation-is-the-most-underrated-developer-feature/cover.png b/static/images/blog/why-documentation-is-the-most-underrated-developer-feature/cover.png
new file mode 100644
index 0000000000..082a29ee0e
Binary files /dev/null and b/static/images/blog/why-documentation-is-the-most-underrated-developer-feature/cover.png differ