When you’re bootstrapping or indie hacking, every dollar counts. SaaS subscriptions and cloud bills can eat into your runway fast. That’s why I set out to build a **fully serverless screenshot and web-scraper pipeline**—with zero monthly cost, using only free tiers.

This article breaks down the architecture, code, and lessons learned from running a production-grade pipeline for screenshots, scraping, and reports—without paying a cent.

---

## TL;DR

You can build a robust, automated screenshot and scraping pipeline for free using:

- **QStash** for scheduling and queueing jobs - **Inngest** for orchestration and retries - **Puppeteer + Browserless** for headless Chrome screenshots - **Vercel Blob** for free file storage - **Neon + Prisma** for Postgres metadata

All running on Vercel’s Hobby plan, with no always-on servers.

---

## 🛠️ Why Serverless? Why Free?

For indie hackers, cost and simplicity are everything:

- **No idle servers:** Functions only run when needed. - **No patching or maintenance:** Providers handle the heavy lifting. - **Free quotas:** Each service offers a generous free tier—combine them for a $0 bill.

---

## Architecture Overview

```mermaid graph TD A[QStash request] -->|POST| B[/api/analysis/process] B --> C{Inngest steps} C --> D[Vercel Fn → Puppeteer via Browserless] D --> E[Vercel Blob Storagedesktop.png / mobile.png] D --> F[Prisma → Neoncapture metadata] ```

---

## 1. Queue & Schedule with QStash

```js

const qstash = new Client({ token: process.env.QSTASH_TOKEN })

await qstash.publishJSON({ topic: 'on-demand-analytics', body: { url: 'https://site.dev', email: 'owner@site.dev' }, }) ```

> **Why QStash instead of DIY cron?** > QStash gives you a managed webhook queue with built‑in retries and cron scheduling on Upstash’s free tier (500 requests **per day**, far more than you’ll need for your usage). No Redis instance, no CloudWatch rules—just publish JSON and let QStash worry about persistence and back‑off.

- **Free quota:** 500 requests/day + cron at no cost.

---

## 2. Event Orchestration with Inngest

```js

export default inngest.createFunction( { id: 'scrape' }, { event: 'analysis.triggered' }, async ({ event, step }) => { const { url, email } = event.data

const data = await step.run('scrape-site', () => scrapeSite(url)) const record = await step.run('store-meta', () => saveCapture(url, data)) }, ) ```

Inngest also allows you to bypass typical serverless timeouts for longer jobs by splitting them into multiple steps, enabling advanced website scraping and user interactions that take more time to complete. For my analytical tools, this enables more complex screenshot analysis without hitting function limits.

- **Free:** 100k invocations/month.

---

## 3. Scrape & Screenshot with Puppeteer + Browserless

```js

export async function scrapeSite(url) { const browser = await puppeteer.connect({ browserWSEndpoint: `wss://chrome.browserless.io?token=${process.env.BROWSERLESS_TOKEN}`, })

const page = await browser.newPage() await page.setViewport({ width: 1440, height: 900 }) await page.goto(url, { waitUntil: 'networkidle0', timeout: 45000 }) const desktop = await page.screenshot({ fullPage: true })

await page.setViewport({ width: 390, height: 844, isMobile: true }) await page.reload({ waitUntil: 'networkidle0' }) const mobile = await page.screenshot({ fullPage: true })

await browser.close()

// store in Vercel Blob (public URL) const desktopUrl = (await put(`${Date.now()}-desk.png`, desktop)).url const mobileUrl = (await put(`${Date.now()}-mob.png`, mobile)).url

return { desktopUrl, mobileUrl } } ```

- **Browserless free:** 3 concurrent sessions / 1,000 sec daily - **Vercel Blob free:** 100 GB storage, 100 GB egress

---

## 4. Metadata into Neon Postgres via Prisma

```txt model Capture { id Int @id @default(autoincrement()) url String desktopShot String mobileShot String createdAt DateTime @default(now()) } ```

```js

export function saveCapture(url, shots) { return prisma.capture.create({ data: { url, desktopShot: shots.desktopUrl, mobileShot: shots.mobileUrl, }, }) } ```

- **Neon free:** 10 GB storage, generous row limits

---

## Cost Table @ Vercel Hobby Tier

| Service | Free Tier | | ---------------- | ----------------------------------- | | Vercel Functions | 100k invocations + 100 GB-hr/month | | Vercel Blob | 1 GB storage, 10 GB egress, 10k ops | | Browserless | 1,000 units, 1 concurrency, 1-min | | QStash | 500 msgs/day, 100 RPS | | Inngest | 50k runs, concurrency=5 | | Neon | 0.5 GB, 191.9 compute-hr, 5 GB eg. |

**Total monthly bill: $0.**

---

## Updated Implementation Notes

You can combine Vercel’s Hobby plan, a free Browserless token, QStash, and Neon DB to handle scraping and screenshots at zero cost. Each service stays within free tiers under typical usage. By connecting Puppeteer to Browserless, storing images on Vercel Blob, and triggering workflows through QStash and Inngest, the entire process runs serverless with minimal setup or maintenance.

---

## Lessons Learned

1. Single Browserless session, many tabs → stay under free concurrency. 2. Blob Storage beats S3 for DX → `put()` returns a url instantly. 3. Inngest retries → isolate failure; one step re-runs without duplicating emails. 4. Prisma + Neon → serverless driver means no “max connections” pain. 5. Vercel Hobby is plenty → tasks barely scratch 2% of the compute quota.

---

## Result

This pipeline now:

- Runs entirely on free‑tier, server‑less services—no idle servers, no surprise bills. - Captures full‑page desktop and mobile screenshots, stores them on Vercel Blob, and logs metadata in Neon. - Completes each job in under 30 seconds of function runtime.

The tech industry is evolving rapidly, and with it, the expectations for software engineers are shifting. Competition for jobs is higher than ever, AI is automating repetitive tasks, and companies are looking for developers who bring more to the table than just writing code.

That doesn’t mean specialists will disappear—far from it. If you’re deeply skilled in a particular domain, there will always be demand for your expertise. However, even specialists need to evolve, incorporating AI and automation where relevant.

For those looking to grow their careers, three distinct trends are emerging—particularly for UI engineers, front-end-focused developers, back-end engineers, and even full-stack engineers who want to future-proof their skill sets. These three roles aren’t just about survival; they’re about standing out in an increasingly crowded job market.

So, if you’re wondering what to focus on in the coming years, here are three career paths that are becoming more prevalent—and why they matter.

---

## 1. The Product Engineer: Bridging Development and Ownership

### (A developer who can think like a product owner and prototype ideas fast)

- More companies are valuing engineers who can think beyond code and understand business needs. - Startups, especially, love engineers who can build the first version of a product, iterate quickly, and even contribute to product strategy.

### What this role looks like in practice:

- You understand **customer needs** and business goals. - You can **prototype an idea quickly** (whether in Figma, Webflow, or code). - You work closely with designers, marketers, and product teams to **ship fast and refine based on feedback**.

### Why this is valuable:

- Startups often don’t have dedicated product managers in the early stages. - Being able to translate an idea into an interactive prototype is a huge advantage. - You don’t need to become a full-fledged product manager, but knowing how to **turn ideas into working experiences** makes you incredibly valuable.

🚀 **Who should go for this?**

- Front-end or back-end developers who enjoy **product thinking, rapid prototyping, and iterating based on user feedback**. - Developers who want to work **closer to business decisions and user needs** rather than just writing features from Jira tickets.

---

## 2. The Design Engineer: Merging UI Design With Front-End Engineering

### (A front-end engineer who can also design, or a designer who can also code)

- The barrier between designers and developers is shrinking. More companies expect engineers to handle UI work that previously required a separate designer. - This role is especially valuable in small teams and startups, where hiring a separate UX/UI designer isn’t always possible.

### What this role looks like in practice:

- You can **design and implement** a user interface, going from Figma to production code yourself. - You understand **design principles**, accessibility, and UI best practices. - You can work in tools like **Figma, Adobe XD, or even Webflow** while still being a strong coder.

### Why this is valuable:

- Reduces the gap between design and development, making teams more efficient. - Companies love engineers who can **make design decisions on their own** rather than waiting for handoffs. - Modern UI frameworks (like Tailwind, Radix, and component libraries) make it easier to bridge this gap than ever before.

🎨 **Who should go for this?**

- Engineers who enjoy **design, visuals, animations, and front-end performance**. - Designers who want to expand their **technical skill set** and become more independent.

---

## 3. The Cloud-Enabled Engineer: Mastering the Infrastructure Behind Software

### (A developer who understands cloud infrastructure and scalable deployment)

- The **cloud industry is growing at 16% per year** and will surpass **$1 trillion by 2030**. - Knowing how to deploy and manage infrastructure **sets you apart** from other front-end or back-end developers. - Companies want engineers who understand **serverless, CDNs, API gateways, and cost optimization**.

### What this role looks like in practice:

- You’re comfortable with **AWS, GCP, or Azure** (even at a basic level). - You know how to **deploy apps efficiently**, whether via Vercel, Netlify, or custom cloud setups. - You understand **serverless computing, edge functions, and API scaling strategies**.

### Why this is valuable:

- Full-stack engineers who know cloud infrastructure **can build, deploy, and scale applications with minimal DevOps dependency**. - Even front-end engineers benefit from knowing **how their apps are deployed, optimized, and secured**. - AI-powered infrastructure management is becoming more common, and knowing cloud concepts allows you to integrate **cost-saving, automated deployment strategies**.

☁️ **Who should go for this?**

- Full-stack engineers who want to **expand into DevOps, serverless computing, or scalable web architecture**. - Developers who want to be more **self-sufficient** rather than waiting on a DevOps engineer for every deployment.

---

## Final Thoughts: Stand Out, Don’t Blend In

The competition in software engineering is **tougher than ever**, and the best way to stand out is by evolving your skill set. That doesn’t mean becoming a “jack of all trades” and being mediocre at everything—it means choosing **one or two adjacent skills** that make you uniquely valuable.

If you’re a **front-end engineer**, consider learning **product ownership or design**. If you’re a **back-end engineer**, consider **cloud infrastructure** to boost your career.

💡 **My Plan:**

- I’ll continue **honing my front-end and back-end skills** while expanding into **cloud infrastructure**—not just because it's a growing field, but because I want to become a more powerful engineer. Mastering cloud allows me to solve different kinds of problems, build diverse applications, and integrate across multiple domains. For me, this is the best way to grow and push my capabilities forward. - If you’re figuring out your next move, pick one of these paths and **start learning today**—because staying still in tech means getting left behind.

And if all else fails? Well, there’s always the option of creating a van-life YouTube channel.

— **Tómas**

Monorepos consolidate all your code—frontends, backends, and shared libraries—into one repository. This simplifies how you **build, deploy, and maintain** multiple projects. Whether you're a **solo indie hacker** or a **scaling startup**, a monorepo can cut overhead and streamline your workflow.

---

## 🛠️ **For Indie Hackers: Efficiency Made Simple**

### **Pros of Using a Monorepo**

1. **One Repo to Manage Everything** Keep dependencies, tests, and deployments in one place. No more switching between multiple repositories.

2. **Effortless Code Sharing** Share components and utilities between projects without duplicating code.

3. **Unified Tooling and Automation** Centralize CI/CD pipelines, linters, and test runners for consistent workflows.

4. **Reduced Costs and Cognitive Load** Simplify infrastructure and reduce the mental overhead of juggling multiple repos.

5. **Faster Product Launches** Spin up new projects quickly using shared resources and configurations.

---

### **Visualizing the Difference**

```bash Monorepo: Multi-Repo: Root Directory Project A Repo ├── App A Project B Repo ├── App B Project C Repo └── Shared Components └── Shared Components (duplicated) ```

In a **monorepo**, everything is streamlined. In a **multi-repo**, managing shared code can quickly become tedious.

---

## 🚀 **For Startups Scaling to Billion-Dollar Unicorns**

### **Why Companies Like Google and Meta Use Monorepos**

1. **Seamless Growth** Scale your team and codebase without fragmenting projects.

2. **Simplified Dependency Management** Update shared libraries in one place, ensuring consistency across all projects.

3. **Efficient Refactoring** Make changes across multiple projects in a single commit.

4. **Improved Collaboration** Teams can share and reuse code effortlessly.

5. **Unified Tooling** Standardize CI/CD pipelines, linters, and tests for smoother development.

---

## 🤝 **Potential Downsides to Consider**

- **Initial Complexity** Setting up a monorepo can be challenging if you're new to the approach.

- **Performance Issues** Without proper caching, large monorepos can lead to longer build times.

- **Team Adjustment** Teams used to separate repos may need time to adapt to shared ownership.

**Tip:** Tools like **Nx**, **Turborepo**, and **Bazel** can help with caching, incremental builds, and easier configuration.

---

## 🔧 **Tooling Tips: Fast-Track Your Monorepo Setup**

- **Frameworks & Tools:** Use **Nx**, **Turborepo**, or **Bazel** for efficient monorepo management. They provide pre-configured templates, shared libraries, and CI/CD pipelines.

- **Testing & Quality Assurance:** Adopt a single test runner (like **Jest**) and a shared **ESLint** config for consistency.

- **CI/CD Integration:** Use one pipeline with caching and parallelization for faster builds and deployments.

---

## 🎯 **Real-World Example**

You’ve built a successful SaaS—**App A**—and want to launch **App B** to expand your business. With a monorepo:

- **Shared Libraries:** Both apps use the same design system and utilities. - **Centralized Updates:** Update a shared component once and both apps benefit. - **Unified Deployment:** Deploy both apps from the same pipeline.

---

## 🌱 **From Side Projects to Scaling Startups**

Monorepos help you transition from small projects to scalable applications by reducing complexity and fostering collaboration.

Environment-driven feature flags offer a cost-effective, reliable, and scalable method for managing application features. By leveraging environment variables, you can toggle features across different environments—such as development, staging, and production—to support controlled rollouts, A/B testing, seamless deployments, and iterative development. This approach optimizes performance and ensures consistency.

While this guide focuses on implementing feature flags using Typescript in React and Next.js projects, the concepts and strategies discussed can be adapted to other frameworks and technologies, making it a versatile resource for any developer.

**Key benefits include:**

- **Optimize Performance**: Disabled features are stripped from the final build, enhancing load times and security. - **Environment-Specific Configurations**: Tailor features for production, staging, or testing environments without code changes. - **Eliminate Costs**: Remove the need for external services or runtime API calls—everything is built into your environment. - **Ensure Consistency**: Deterministic behavior reduces runtime errors and simplifies debugging. - **Support Advanced Use Cases**: Extend flags for A/B testing, role-based features, and percentage rollouts. - **Unified Context**: Seamlessly work across server and client components.

This guide covers the foundational setup for environment-driven feature flags and advanced configurations for progressive rollouts, A/B testing, and role-based access control.

---

## Handling Feature Flags in Server and Client Components

Feature flag implementations differ between client and server components due to the environment and rendering context. Below are the recommended approaches for each:

### In Client Components: Use a Context Provider and Custom Hook

In client components, feature flags should be passed through a provider and accessed via a custom hook. This ensures reliable and centralized management, avoiding issues with accessing environment variables directly in the browser.

**Set Up the Feature Flag Context and Hook:**

```typescript 'use client';

export type FeatureFlags = Record;

const FeatureFlagContext = createContext(undefined);

interface FeatureFlagProviderProps { children: React.ReactNode; featureFlags: FeatureFlags; }

export const FeatureFlagProvider: React.FC = ({ children, featureFlags, }) => { return ( {children} ); };

export function useCheckIsFeatureEnabled(): (featureName: string) => boolean { const featureFlags = useContext(FeatureFlagContext); if (featureFlags === undefined) { throw new Error( 'useCheckIsFeatureEnabled must be used within a FeatureFlagProvider', ); }

return (featureName) => { const flagValue = featureFlags[featureName]; return flagValue === 'true' || flagValue === true; }; } ```

**Providing Feature Flags in the App:**

```typescript

export default function App() { const featureFlags = { FF_NEW_DASHBOARD: process.env.NEXT_PUBLIC_FF_NEW_DASHBOARD === 'true', FF_BETA_FEATURE: process.env.NEXT_PUBLIC_FF_BETA_FEATURE === 'true', };

return ( ); } ```

**Usage in Client Components:**

```typescript 'use client';

export function Dashboard() { const isFeatureEnabled = useCheckIsFeatureEnabled();

return ( {isFeatureEnabled('FF_NEW_DASHBOARD') ? ( ) : ( )} ); } ```

### In Server Components: Use a Wrapper Component or Direct Method

In server components, you have two options for checking feature flags:

1. **Using the `FeatureEnabled` Wrapper Component** 2. **Using the `checkIsFeatureFlagEnabled` Method Directly**

#### Option 1: Using the `FeatureEnabled` Wrapper Component

**Implementing the Wrapper Component:**

```typescript

interface FeatureEnabledProps { featureFlag: string | string[]; children: React.ReactNode; }

function checkIsFeatureFlagEnabled(featureFlag: string): boolean { return process.env[featureFlag] === 'true' || process.env[featureFlag] === true; }

export function FeatureEnabled({ featureFlag, children, }: FeatureEnabledProps) { const isEnabled = Array.isArray(featureFlag) ? featureFlag.some((flag) => checkIsFeatureFlagEnabled(flag)) : checkIsFeatureFlagEnabled(featureFlag);

return isEnabled ? <>{children} : null; } ```

**Usage with the Wrapper Component:**

```typescript

export function Dashboard() { return ( ); } ```

#### Option 2: Using the `checkIsFeatureFlagEnabled` Method Directly

**Implementing the `checkIsFeatureFlagEnabled` Function:**

```typescript export function checkIsFeatureFlagEnabled(featureFlag: string): boolean { return ( process.env[featureFlag] === 'true' || process.env[featureFlag] === true ) } ```

**Usage with Direct Method:**

```typescript

export function Dashboard() { const isNewDashboardEnabled = checkIsFeatureFlagEnabled('FF_NEW_DASHBOARD'); const isOldDashboardEnabled = checkIsFeatureFlagEnabled('FF_OLD_DASHBOARD');

return ( {isNewDashboardEnabled && } {isOldDashboardEnabled && } ); } ```

**Choosing Between the Two Methods:**

- **Use the Wrapper Component (`FeatureEnabled`)** when you prefer to wrap components declaratively, making your JSX cleaner and more readable. - **Use the Direct Method (`checkIsFeatureFlagEnabled`)** when you need more control within the component logic or when conditional rendering is more complex.

---

## Implementing Simple Feature Flags

### Defining Feature Flags in Environment Files

Create environment-specific files to define your feature flags:

```bash # .env.production FF_NEW_DASHBOARD=false

# .env.staging FF_NEW_DASHBOARD=true ```

For client-side access, prefix the variables with `NEXT_PUBLIC_`:

```bash # .env.production NEXT_PUBLIC_FF_NEW_DASHBOARD=false ```

### Accessing Feature Flags in Code

**Server-Side Access:**

```typescript export function isFeatureEnabled(feature: string): boolean { return process.env[feature] === 'true' || process.env[feature] === true } ```

**Client-Side Access via Provider:**

In client components, use the `FeatureFlagProvider` and `useCheckIsFeatureEnabled` hook to access feature flags, as described in the previous section.

---

## Advanced Feature Flagging

Extend feature flags to support **A/B testing**, **percentage-based rollouts**, and **user-based targeting**, such as **role-based features**.

### Role-Based Feature Flags

Role-based feature flags allow you to enable or disable features for specific user roles, such as `admin`, `editor`, or `premiumUser`. This approach is useful when you want to grant access to features based on user permissions or subscription levels.

#### Implementing Role-Based Feature Flags

**Defining Feature Configurations:**

```typescript interface FeatureConfig { roles?: string[] }

const featureFlags: { [key: string]: FeatureConfig } = { FF_ADVANCED_DASHBOARD: { roles: ['admin', 'manager'], }, FF_PREMIUM_CONTENT: { roles: ['premiumUser'], }, } ```

**Function to Check Role-Based Access:**

```typescript function isFeatureEnabledForRole( featureName: string, userRole: string, ): boolean { const featureConfig = featureFlags[featureName]

if (!featureConfig || !featureConfig.roles) { // Feature is not defined or not restricted by roles return false }

return featureConfig.roles.includes(userRole) } ```

#### Using in Components

**Server Component Example:**

```typescript

export function RoleBasedFeature({ userRole }: { userRole: string }) { const isEnabled = isFeatureEnabledForRole('FF_ADVANCED_DASHBOARD', userRole);

return isEnabled ? : ; } ```

**Client Component Example with Provider:**

In client components, pass the user role through context or props and use it within your hook or component logic.

```typescript 'use client';

export function RoleBasedFeature({ userRole }: { userRole: string }) { const isFeatureEnabled = useCheckIsFeatureEnabled();

const isEnabled = isFeatureEnabled('FF_ADVANCED_DASHBOARD') && isFeatureEnabledForRole('FF_ADVANCED_DASHBOARD', userRole);

return isEnabled ? : ; } ```

### Combining Multiple Feature Flagging Strategies

You can combine role-based flags with percentage-based rollouts and A/B testing for more granular control.

#### Percentage-Based Rollouts

**Determining Feature Availability:**

```typescript

function isFeatureEnabledForUser( userId: string, featureName: string, rolloutPercentage: number, ): boolean { if (!userId || !featureName) { console.error('Invalid user ID or feature name') return false } const hashInput = `${featureName}-${userId}` const hash = murmurhash.v3(hashInput)

// Compute bucket number between 1 and 100 const bucket = (hash % 100) + 1 // Adjust to 1-100 range

return bucket ; }

const variant = getABTestVariant(userId, 'FF_NEW_EXPERIENCE');

return variant === 'A' ? : ; } ```

In this example:

- **Role-Based Access**: Users with specific roles can access the feature immediately. - **Percentage Rollout**: A certain percentage of users are granted access. - **A/B Testing**: Users with access are further split into variants 'A' and 'B' for testing purposes.

---

## Limitations and Considerations

### Environment Variables and Build Time in Next.js

**Client-Side Limitations:**

- **Static Injection at Build Time**: In Next.js, environment variables prefixed with `NEXT_PUBLIC_` are statically injected into your client-side code at build time. This means that any changes to these variables require you to rebuild and redeploy your application. - **Limited Dynamic Toggling**: Due to static injection, you cannot dynamically toggle features on the client side without redeployment. If real-time toggling is essential, consider using an API call or real-time configuration service to fetch feature flags at runtime.

### Alternatives for Dynamic Client-Side Feature Toggling

- **API Calls**: Fetch feature flags from a server or API endpoint at runtime. - **Real-Time Configuration Services**: Use services like Firebase Remote Config or LaunchDarkly for dynamic feature management.

---

## Security Considerations

- **Avoid Exposing Sensitive Flags**: Use prefixes like `NEXT_PUBLIC_` cautiously to prevent leaking sensitive data. - **Secure Environment Variables**: Keep sensitive variables on the server side and do not expose them to the client. - **Version Control Practices**: Exclude `.env` files from version control to protect secrets. - **User Role Verification**: Ensure that user roles are securely verified and cannot be tampered with on the client side.

---

## Best Practices

- **Incorporate `featureName` in Hash Functions**: Always include the `featureName` when hashing to assign users to buckets. This ensures fair and independent distribution across different features. - **Use Secure Methods to Determine User Roles**: Fetch user roles from a secure source (e.g., server-side authentication) rather than trusting client-provided data. - **Logging and Monitoring**: Implement logging to track feature flag usage and changes. - **Graceful Fallbacks**: Ensure your application behaves correctly if feature flags are misconfigured. - **Testing**: Rigorously test feature flag logic to prevent unauthorized access or feature exposure. - **Documentation**: Keep clear documentation of your feature flags and their configurations to aid in maintenance and onboarding.

---

## Final Thoughts

Environment variable-driven feature flags provide a robust, scalable, and cost-effective way to manage features across different environments. By starting with simple flags and extending to advanced use cases like role-based access, A/B testing, and percentage rollouts—with the critical step of incorporating the `featureName` into your hash functions—you can:

- **Enhance Deployment Flexibility**: Confidently deploy features across various user segments. - **Improve User Experience**: Tailor features to specific user groups. - **Reduce Costs**: Eliminate the need for external feature flagging services.

However, it's crucial to understand the limitations of environment variables, especially in Next.js. Since client-side environment variables are injected at build time, dynamic toggling on the client without redeployment isn't feasible. For real-time feature management on the client side, consider integrating an API or a real-time configuration service.

By integrating the user role-based feature flag mechanism, you can control feature access based on user permissions, roles, or subscription levels. Combining this with percentage-based rollouts and A/B testing allows for highly granular control over how and to whom features are deployed.

---

Cheers, **Tómas**

---

**Note:** This guide demonstrates how to implement feature flags effectively in both client and server components by using context providers and custom hooks in client components and either wrapper components or direct methods in server components. Adjust the implementation details according to your specific framework and project requirements.

### **Essential Favicons Setup**

For a quick and efficient favicon setup in Next.js, you only need these three files:

1. **favicon.ico**

- **Purpose**: The classic favicon displayed in browser tabs. - **Placement**: Place a 32×32 `favicon.ico` file in the `app` directory. Next.js will automatically serve it at `/favicon.ico`.

2. **icon.svg**

- **Purpose**: Modern browsers prefer SVG icons for scalability and crispness. - **Placement**: Save your SVG icon as `icon.svg` in the `public` directory. - **Usage in Next.js Metadata**:

```javascript { rel: 'icon', url: '/icon.svg', type: 'image/svg+xml', }

```

3. **apple-touch-icon**

- **Purpose**: Used when users add your website to their iOS home screen. - **Placement**: Add a 180×180 PNG named `apple-touch-icon.png` to the `public` directory. - **Usage in Next.js Metadata**:

```javascript { rel: 'apple-touch-icon', sizes: '180x180', url: '/apple-touch-icon.png', } ```

**Note**:

- The `app` directory in Next.js 13 (using the App Router) is special because placing a `favicon.ico` file at the root of this directory ensures it's automatically served at `/favicon.ico` without additional configuration. - The `public` directory is ideal for other static assets because it's served at the root (`/`) of your application, making it straightforward to reference these files in your code.

This minimal setup ensures compatibility with most browsers and devices, providing essential icon support without unnecessary complexity.

---

## Expanded Setup for PWA Support

If your app is a Progressive Web App (PWA), you'll need to define additional icons in a `manifest.json` file. This enhances the user experience when your app is installed on a device.

### Additional Icons for PWAs

1. **192×192 PNG**

- **Purpose**: Used for Android home screen icons and in notifications. - **Placement**: Save as `icon-192.png` in the `public` directory.

2. **512×512 PNG**

- **Purpose**: The default icon for splash screens when the app is launched. - **Placement**: Save as `icon-512.png` in the `public` directory.

3. **512×512 Maskable PNG**

- **Purpose**: Ensures proper display on devices that apply masks to icons (e.g., Android devices with non-rectangular shapes). - **Placement**: Save as `icon-maskable.png` in the `public` directory. - **Design Consideration**: Include extra padding. The safe area for a maskable icon is a central circle of 409×409 pixels inside the 512×512 canvas. Use tools like maskable.app to adjust the padding correctly.

### Example Manifest File

Create a `manifest.json` file in the `public` directory:

```json { "name": "Your App Name", "short_name": "App", "start_url": ".", "display": "standalone", "background_color": "#FFFFFF", "description": "Your app description", "icons": [ { "src": "/icon-192.png", "type": "image/png", "sizes": "192x192" }, { "src": "/icon-maskable.png", "type": "image/png", "sizes": "512x512", "purpose": "maskable" }, { "src": "/icon-512.png", "type": "image/png", "sizes": "512x512" } ] } ```

---

## HTML Reference for Non-Next.js Apps

If you're not using Next.js, include the following in your ``:

```html

```

### Generating the favicon.ico File

To generate the `.ico` file with 128x128, 64x64, 48x48, 32×32 and 16×16 resolutions, use ImageMagick:

** Note use a 1200x1200 image for best results **

```bash magick source.png -resize 16x16 icon-16.png magick source.png -resize 32x32 icon-32.png magick source.png -resize 48x48 icon-48.png magick source.png -resize 64x64 icon-64.png magick source.png -resize 128x128 icon-128.png ```

Combine them into a single favicon.ico file.

```bash magick icon-128.png icon-64.png icon-48.png icon-32.png icon-16.png favicon.ico ```

Place the generated `favicon.ico` in your application's root directory.

---

## Optional: Theming with Media Queries

For advanced theming, you can define light and dark mode icons using media queries in the `metadata.icons` array:

```javascript export const metadata = { icons: [ { rel: 'icon', media: '(prefers-color-scheme: light)', url: '/icon-light.svg', type: 'image/svg+xml', }, { rel: 'icon', media: '(prefers-color-scheme: dark)', url: '/icon-dark.svg', type: 'image/svg+xml', }, ], } ```

This setup automatically displays the appropriate icon based on the user's system settings, enhancing user experience by aligning with their preferred theme.

---

## Understanding the Purpose of Each Icon

### favicon.ico

- **Purpose**: The default icon displayed in browser tabs and bookmarks. - **Why It's Needed**: Provides brand recognition and improves user experience by allowing users to quickly identify your site among multiple tabs. - **Placement in Next.js**: Place it in the `app` directory root. Next.js will automatically serve it at `/favicon.ico`.

### icon.svg

- **Purpose**: A scalable icon for modern browsers, ensuring crisp display on all devices. - **Why It's Needed**: SVGs scale without loss of quality, making them ideal for high-resolution displays. - **Placement**: Place in the `public` directory.

### apple-touch-icon.png

- **Purpose**: Used when iOS users add your website to their home screen. - **Why It's Needed**: Ensures your app icon looks professional and recognizable on iOS devices. - **Placement**: Place in the `public` directory.

---

## SEO and Accessibility Considerations

- **Brand Recognition**: Consistent and professional icons improve brand visibility across devices and platforms. - **User Experience**: Properly sized and formatted icons ensure a seamless experience, whether users are browsing, bookmarking, or adding your app to their home screen. - **Accessibility**: High-quality icons with appropriate sizes enhance readability and usability for all users.

---

## Troubleshooting Tips

- **Browser Caching**: Browsers often cache favicons and may not immediately reflect updates.

**Solution**: Instruct users (or yourself during testing) to clear the browser cache or perform a hard refresh (usually `Ctrl+F5` or `Cmd+Shift+R`).

- **Incorrect File Paths**: Ensure that your icon files are placed in the correct directories and that the paths in your code match.

- **Missing Sizes or Types**: Omitting `sizes` or `type` attributes can lead to browsers ignoring your icons.

**Solution**: Always specify the `sizes` and `type` attributes in your metadata or HTML tags.

---

## Additional Resources

- **Next.js Documentation on Metadata**: Next.js Metadata API - **Favicon Generator and Checker**: RealFaviconGenerator.net - **PWA Icon Guidelines**: Web.dev - Create app icons for your PWA - **Apple Touch Icon Guide**: Apple Human Interface Guidelines

---

## Recap: All the Icons You Need

Here's a summary of all the icons and their configurations for a fully functional setup:

### Files to Include

- **favicon.ico**: 32×32 (placed in `app/` directory) - **icon.svg**: Scalable SVG icon (placed in `public/` directory) - **apple-touch-icon.png**: 180×180 PNG (placed in `public/` directory) - **icon-192.png**: 192×192 PNG (for Android home screens) - **icon-512.png**: 512×512 PNG (for splash screens) - **icon-maskable.png**: 512×512 PNG with padding (for maskable icons)

### Next.js Metadata Example

```javascript { "icons": [ { rel: 'icon', url: '/icon.svg', type: 'image/svg+xml', }, { rel: 'apple-touch-icon', sizes: '180x180', url: '/apple-touch-icon.png', }, // Only required for PWA apps. { rel: 'manifest', url: '/manifest.json', } ] } ```

---

## A Simple Favicon Solution for MVPs

If you’re building a Minimum Viable Product (MVP) or want a quick solution without worrying about multiple icon sizes, use Next.js’s built-in `ImageResponse` to generate a simple 32×32 favicon dynamically:

```jsx export const contentType = 'image/png'

export default function Icon() { return new ImageResponse( ( MVP ), { width: 32, height: 32 }, ) } ```

### Why This Works

- **Dynamic Generation**: The favicon is created on the fly. - **Simple Setup**: Great for MVPs or quick projects that don’t require complex configurations. - **Good Enough for Most Scenarios**: Works well for browser tabs but may not suit PWAs or iOS home screen icons.

Start with this approach and upgrade to a more comprehensive setup as your project grows.

---

## Conclusion

Setting up favicons in Next.js doesn’t have to be complicated. With just three files, you can ensure your app looks polished and professional across browsers and devices. For more advanced setups, adding PWA support and media queries enhances the user experience even further.

Cheers, **Tómas**

As the owner of **Three Tech Consulting**, I’ve worked with mid-to-large companies serving millions of monthly users to deliver cutting-edge software solutions. At the same time, as a Lead Engineer, I’ve led teams to build scalable applications, tackle complex challenges, and deliver impactful results—all while juggling personal side projects along the way.

This blog isn’t just about the work. It’s also about the journey—how to balance a career in tech with exploring the world. Being a **digital nomad** means typing away in cafes, chasing stable Wi-Fi, and navigating the highs and lows of building a career on the move. Whether it’s brainstorming product ideas on a beach in Bali or squashing bugs on a train in Europe, I’ve got stories to share.

## What to Expect

Here’s what you can look forward to:

- **Entrepreneurship**: Thoughts on starting, scaling, and balancing the chaos of running your own business. - **Web Development**: Tips, tricks, and deep dives into building better, faster, and more scalable applications. - **Nomad Life**: Honest takes on the highs and lows of working while traveling. - **Balancing It All**: How I juggle a full-time Lead Engineer role, running **Three Tech Consulting**, and living the nomadic life. - **Everything Else**: Random musings, tech inspiration, and maybe even a few of my favorite chess opening moves—like the Sicilian Defense or the Ruy-Lopez.

This blog is for anyone curious about blending passion, work, and travel—or for those just looking for a glimpse into the life of someone trying to do it all.

Whether you’re here for entrepreneurial inspiration, tech insights, or nomadic adventures, I hope you find something worth your time.

Cheers, **Tómas**