DEV Community: Şükrü Çelik

ShowDev: I built a modern platform for pet adoption and care using Next.js & Node.js 🐾

Şükrü Çelik — Sat, 04 Apr 2026 10:23:50 +0000

Hello DEV community! 👋

As a computer engineering student, I’ve always wanted to build a product that not only challenges me technically but also creates a positive impact in the real world. Today, I’m excited to share a project I’ve been building and scaling: Patify.

What is Patify? 🐶🐱

Patify is a centralized digital ecosystem designed to modernize pet care, streamline the adoption process, and help reunite lost pets with their families quickly. Instead of relying on fragmented local forums, I wanted to create a global, lightning-fast hub for pet parents.

You can check out the live production environment here:
👉 Patify - Global Pet Adoption & Care Platform

The Tech Stack 💻

To ensure the platform is incredibly fast, scalable, and highly discoverable on search engines (SEO is a massive priority for this project), I chose a modern JavaScript ecosystem:

Frontend: Next.js (utilizing SSR for dynamic content)
Backend: Node.js
Database & API: Optimized for rapid, location-based queries.

Key Features (And Technical Wins) 🚀

1. High-Performance Server-Side Rendering (SSR)
Since we provide state-specific veterinary guides, microchip laws, and telemedicine costs, organic discovery is crucial. Next.js allows us to serve fully rendered HTML to search engine crawlers, meaning our complex data is indexed almost instantly without wasting crawl budget.

2. Seamless Multilingual Content Hub
Patify is built for a global audience. I engineered a robust i18n architecture that changes seamlessly based on the user's region without client-side layout shifts. You can explore the English iteration of our architecture on the Patify English Content Hub.

3. "Lost & Found" Radar
When a pet is lost, every second counts. The platform allows users to instantly upload pet details, generating a highly optimized, easily shareable dynamic page that loads instantly even on poor 3G mobile connections.

Why I Built It 💡

Navigating pet insurance, local laws, and adoption processes can be an absolute headache. I wanted to use my software engineering background to solve a problem I care deeply about, building a platform that feels modern, reliable, and incredibly fast.

I'd Love Your Feedback!

Since I am continuously optimizing the platform, I would love to hear from this community. What do you think about the UI/UX? How does the initial load time feel in your region?

Let me know your thoughts or any feature suggestions in the comments below! 👇

How I Built a Scalable, SEO-Optimized Multilingual Content Hub with Next.js 🚀

Şükrü Çelik — Sat, 04 Apr 2026 10:14:13 +0000

Building a platform that targets multiple regions and languages is always a fun architectural challenge. Recently, while scaling my pet adoption and care platform, Patify, I hit a classic roadblock: How do we serve highly dynamic, localized content (i18n) to different countries while maintaining perfect Technical SEO and lightning-fast load times?

In this post, I want to share the architecture I used combining Next.js (SSR) and a Node.js backend to build a high-performance content hub.

The Problem with Client-Side i18n 🚨

When I first started drafting the architecture, the easiest route was to use a simple client-side translation library. However, since the primary goal of our content hub is organic discovery (SEO), relying on client-side rendering (CSR) was a huge red flag.

Google's crawlers (and definitely other search engines) need to see fully rendered HTML to index content quickly and accurately. If they hit a loading spinner while the translations are being fetched, the "Crawl Budget" is wasted.

The Solution: Server-Side Rendering (SSR) & Dynamic Routing 🛠️

I decided to leverage the Next.js routing system combined with Server-Side Rendering to ensure that every language variation of the site acts as its own static-like entity for crawlers.

Here is a simplified version of how I structured the dynamic routing for the content pages:

// pages/[lang]/content/index.js (or App Router equivalent)

export async function getServerSideProps(context) {
  const { lang } = context.params;

  // Validate supported languages to prevent 404 spam
  const supportedLangs = ['en', 'de', 'tr'];
  if (!supportedLangs.includes(lang)) {
    return { notFound: true };
  }

  // Fetch localized content from the Node.js API
  const res = await fetch(`https://api.patifyapp.com/v1/content?lang=${lang}`);
  const data = await res.json();

  return {
    props: {
      articles: data.articles,
      currentLang: lang,
    },
  };
}

Handling hreflang Meta Tags for Google 🕷️

Serving the content in different languages isn't enough; you have to explicitly tell search engines which page targets which region to avoid "Duplicate Content" penalties.

Inside the <Head> component of the layout, I dynamically generate the hreflang tags based on the current route:

<Head>
  <title>Pet Care Guides & Content Hub | Patify</title>
  <link rel="alternate" hrefLang="en" href="[https://patifyapp.com/en/content](https://patifyapp.com/en/content)" />
  <link rel="alternate" hrefLang="de" href="[https://patifyapp.com/de/content](https://patifyapp.com/de/content)" />
  <link rel="alternate" hrefLang="x-default" href="[https://patifyapp.com/en/content](https://patifyapp.com/en/content)" />
</Head>

The Live Implementation (Testing the SSR Performance) ⚡

Theory is great, but real-world performance is what matters. By offloading the localization to the server, the Time to First Byte (TTFB) drastically improved, and Google started indexing our deeply nested, state-specific veterinary guides almost instantly.

If you want to test how this SSR localization architecture performs in a live production environment, you can check out the two main hubs I deployed:

🇬🇧 English Hub: Patify English Content & Guides
🇩🇪 German Hub: Patify German Content & Guides

Clicking around these hubs, you'll notice there are no client-side layout shifts when changing regions, which is a massive win for Core Web Vitals.

What's Next?

The next phase for my Node.js backend is to implement programmatic SEO to automatically generate hyper-local guides based on JSON datasets (like specific state laws for pets).

How are you handling internationalization in your Next.js projects? Do you prefer SSG over SSR for content-heavy pages? Let's discuss in the comments! 👇

Building a Global Pet Rescue Platform: My Next.js & MongoDB Architecture Journey

Şükrü Çelik — Tue, 17 Mar 2026 13:03:26 +0000

`As a software developer, I've always believed that technology should solve real-world problems. One of the most heartbreaking issues in any city is the disconnect between lost pets and their owners, or stray animals needing a home.

To bridge this gap, I built Patify, a comprehensive platform designed to reunite lost pets with their families and facilitate adoptions. In this article, I want to share the technical architecture behind the project and why I chose my specific tech stack.

The Tech Stack: Why Next.js and Node.js?

When designing a platform that needs to handle real-time notifications, image uploads, and SEO-friendly dynamic pages (like individual pet profiles), the tech stack choice is crucial.

Frontend: Next.js (React)
Backend: Node.js (Express)
Database: MongoDB
Mobile: Flutter (for the upcoming app integration)

1. Next.js for SSR and SEO

For a platform where people search for "lost cat in [City]" or "adopted dogs," Search Engine Optimization is not just a marketing buzzword; it's a core feature. Next.js allows us to use Server-Side Rendering (SSR). This means when a user creates a lost pet listing, the page is immediately indexable by search engine bots.

If you want to see how the SSR performs in a real-world scenario, you can check out the live platform at Patify - Lost Pet & Adoption Platform.

2. Node.js & MongoDB for Flexibility

Pet data is highly unstructured. A turtle might have different attributes than a dog. MongoDB’s document-based model allows us to store varying pet characteristics, medical histories, and microchip data without rigid schemas. Our Node.js backend handles these API requests efficiently, managing user sessions, image processing (via Cloudinary), and location-based queries.

3. Handling Global Traffic

One of the biggest challenges was making the platform accessible in multiple languages. We built a custom Global Content Controller in our Node.js backend to serve localized content (English, German, French, etc.) based on the user's region, dynamically updating our hreflang tags for international SEO.

The Road Ahead

Building a platform from scratch is challenging, especially when balancing university studies with full-stack development. But seeing the system successfully connect a lost pet with its owner makes every line of code worth it.

I'd love to hear feedback from the developer community on handling large-scale image rendering in Next.js or optimizing MongoDB geospatial queries! Let me know your thoughts in the comments.`