DEV Community: Ikram Ul Haq

The answer was somewhere in a one-hour video. That's the whole reason I built this.

Ikram Ul Haq — Mon, 07 Sep 2026 05:33:36 +0000

I didn't set out to build a product. I built this for myself, and the reason is small and specific.

Other AI tools have gotten dramatically better over the last couple of years, and the complaint isn't that they won't stick to one source. Ask one to answer only from a particular website and it mostly will — that site's pages are indexed, and it can reach them.

The problem starts where the index stops.

Think of a site with a thousand PDFs on it — a research library, a manuals archive, years of annual reports. A general AI tool can find the page that lists those files. It can't read across them. Some are indexed shallowly, many aren't indexed at all, and the scanned ones have no text in them to index in the first place. You can upload one PDF into a chat and ask about it — I do that all the time — but that's one file, in one conversation, for me. It isn't a searchable body of knowledge, and nobody else can use it.

Video is worse. One channel I follow has hundreds of videos, plenty of them over an hour long. The answer I wanted was somewhere around minute 43 of a video whose title and description never mention it. The title, description, and chapter markers get indexed. What's actually said at minute 43 doesn't — not in any way a general tool can search. So you either remember roughly where it was, or you scrub through and hope.

So I built a small thing for myself: point it at the videos and documents I trust, ask a question, get an answer with the exact timestamp or the exact page. I shared it with a few friends and they used it more than I expected. No revenue, no customers, no plan — just a tool that solved my own problem.

The realization came later and was obvious in hindsight: that gap isn't mine, it's structural. General AI tools are excellent at everything the index can reach and blind to everything it can't — and the moment knowledge lives in a pile of documents or hours of video, it can't. Which means anyone sitting on a body of content has this exact problem pointed at their own audience: a business with its documentation, a non-profit with material to distribute, an academy with recorded lectures, a creator with a back catalogue.

What's actually under the hood

Content gets chunked and embedded with BAAI/bge-m3, stored in a separate vector collection per tenant — no shared index across customers. At query time, it's retrieved and reranked, then the top passages are passed as context to a generation model, with a fallback chain across providers so one outage doesn't take the whole thing down.

Documents that are scanned rather than text-based go through an OCR cascade rather than silently returning nothing. Video transcripts come from captions where they exist and speech-to-text where they don't. Every tenant gets its own database, not just its own rows in a shared one.

The part I care most about: answers are confined to that tenant's content and always attributable. If it can't find support in the material, it says so rather than filling the gap. Citations point at the specific page or the specific moment, not just "somewhere in this document."

Is this just a wrapper around a model?

Worth answering directly rather than dodging it: the generation model is one component, and it's swappable. The retrieval, the per-tenant isolation, citation-to-exact-page-or-timestamp, the OCR and transcription cascades, and the branding/domain/billing layer on top are the actual product.

Where it ended up

About two months of evenings and weekends around a full-time software job — six years as an engineer — from the thing I built for myself to the thing anyone can sign up for. Multi-tenant, so you bring your own PDFs, DOCX files, or a YouTube channel, and it comes with an embeddable widget so you're not sending people to a separate site to ask a question.

The result is your own branded AI, on your own domain, trained only on your content, answering only from it, citing the exact page of a document or the exact moment in a video. It's live at ultranivo.com.

Happy to answer anything — the retrieval setup, the multi-tenant design, the OCR/transcription cascades, or what I'd do differently.

HTTP 500 on AWS Amplify After Deployment — Solved by a Monorepo Dependency Mismatch

Ikram Ul Haq — Thu, 12 Mar 2026 16:20:16 +0000

I used Claude Code to investigate this issue. What could have taken a day of back-and-forth debugging was resolved in a focused session — pinpointing the root cause, testing fixes, and ruling out dead ends systematically.

The Problem

After a successful deployment on AWS Amplify, the app was returning HTTP 500 with no build failure, no warning — just a blank page. CloudWatch logs showed this:

ln: failed to create symbolic link '/tmp/app/node_modules/node_modules': Read-only file system
ln: failed to create symbolic link '/tmp/app/public/public': Read-only file system
ln: failed to create symbolic link '/tmp/app/.next/static/static': Read-only file system
ln: failed to create symbolic link '/tmp/app/.next/server/chunks/chunks': Read-only file system
INIT_REPORT Init Duration: 767.95 ms   Phase: invoke   Status: error   Error Type: Runtime.ExitError

Deployment was marked successful. The app was dead on arrival.

Stack: Next.js · pnpm monorepo · AWS Amplify SSR

Context

This is a pnpm monorepo with two apps:

app-1 — already deployed and working on Amplify
app-2 — newly added to the monorepo, deployed in the same commit

Both apps share the root node_modules via pnpm hoisting.

What We Tried (All Failed)

1. `output: 'standalone'` in `next.config.mjs`

The idea was to bundle all dependencies into .next/standalone to avoid symlink resolution issues at runtime.

// next.config.mjs
const nextConfig = {
  output: 'standalone',
};

Same symlink errors in CloudWatch. Didn't help.

2. Scoped install in Amplify build spec

preBuild:
  commands:
    - pnpm install --filter app-1...

The intent was to install only app-1's dependency tree to avoid app-2's deps affecting the hoisting layout. Same error.

3. Removed `node_modules` from Amplify cache

cache:
  paths:
    - '.next/cache/**/*'
    # removed: node_modules/**/*

Ruled out stale cached node_modules. Same error.

4. `pnpm.overrides` to force a single React version

"pnpm": {
  "overrides": {
    "react": "^19.0.0",
    "react-dom": "^19.0.0"
  }
}

This was an attempt to eliminate the version conflict at the root. Same symlink error on Amplify.

5. Redeployed the last known-working commit

Redeploying the commit before app-2 was added worked perfectly. This confirmed the issue was introduced entirely by app-2 being part of the monorepo — not an Amplify infrastructure issue.

At this point we also found similar reports on the Amplify GitHub repo (#3793, #4079) with identical log output. Those were intermittent platform-side issues. Ours was consistent and reproducible — which pointed back to our code.

The Twist: A Local Build Failure Along the Way

While trying pnpm.overrides, the local build started failing with:

Cannot read properties of null (reading 'useContext')
Cannot read properties of null (reading 'useRef')

Occurring during prerendering of /404 and /500.

Root cause: pnpm was hoisting react@19.2.3 at root but react-dom@18.3.1 at root (pulled in by a transitive dependency from app-2). Two incompatible React instances in the same node_modules — classic split brain.

Fix: After removing the overrides, regenerating pnpm-lock.yaml from scratch cleaned up the hoisting and resolved the local build. This was a separate issue from the Amplify problem but surfaced during the same investigation.

The Actual Root Cause

app-1 and app-2 had different versions of React and Next.js:

	app-1	app-2
`next`	`15.1.11`	`16.1.4`
`react`	`^19.0.0`	`19.2.3`
`react-dom`	`^19.0.0`	`19.2.3`

The version mismatch in Next.js was enough for pnpm to create a conflicting node_modules layout across the two apps — which Amplify's Lambda runtime couldn't handle at bootstrap.

The fix: Downgraded app-2's Next.js from 16.1.4 to 15.1.11 and aligned React/react-dom versions to match app-1. Clean layout, no symlink failures, app running.

Why It Didn't Fail Locally or on Vercel

To rule out our own code, we deployed the same commit to Vercel — it worked fine. Ran it locally — worked fine. Only Amplify was breaking.

That's because Node.js and Vercel are both flexible with how they resolve modules at runtime. Amplify's Lambda compute is not — it expects a specific node_modules layout and breaks silently at the build level but loudly at runtime when that layout doesn't match. - According to Claude 😊

Key Takeaway

If you're running a pnpm monorepo on Amplify SSR and seeing Read-only file system symlink errors in CloudWatch with a successful build — check your dependency versions across all apps before debugging Amplify's infrastructure.

Keep React and Next.js versions consistent across all apps in the monorepo. pnpm's hoisting is sensitive to version conflicts, and Amplify's runtime is sensitive to pnpm's hoisting layout.

Added a comment on the related GitHub issue here: aws-amplify/amplify-hosting#4079

i18n with NextJS output export

Ikram Ul Haq — Tue, 06 Feb 2024 20:44:52 +0000

In this post, I'll guide you through the process of setting up internationalization (i18n) in a Next.js project. We'll explore how to integrate i18n with the page router and address the export output option, overcoming challenges where Next.js doesn't provide direct assistance.

To begin, let's initialize a Next.js v14 project with TypeScript. Alternatively, you can opt for JavaScript; either choice works seamlessly.

Initializing NextJS Project

Execute the following command to set up your project:

`npx create-next-app@latest`

During the setup, you'll encounter several questions; respond based on your preferences. In my case, I opted for the page router and specified the src directory with TypeScript.

Afterward, include the output: "export" in the next.config.js file:

Additionally, remove the api folder from the pages directory, as it's incompatible with the output: "export" configuration.

Installing and Configuring i18n

For internationalization, we'll be utilizing the next-translate package. Although it doesn't inherently support output: export, don't fret – that's where our assistance comes in.

Begin by installing the next-translate package:

`npm i next-translate`

Generate a file named i18n.ts or .js at the project's root level, and insert the following code:

import { I18nConfig } from "next-translate";

export const i18nConfig = {
  locales: ["en", "es"],
  defaultLocale: "en",
  loader: false,
  pages: {
    "*": ["common"],
  },
  defaultNS: "common",
} satisfies I18nConfig;

We've established the fundamental configuration for i18n. Feel free to customize it based on your specific needs.

Now, establish a locales folder at the project's root level. This folder will house translation files for each language.

Navigate to the _app.ts file within the pages directory, and envelop the Component with I18nProvider:

import "@/styles/globals.css";
import type { AppProps } from "next/app";
import I18nProvider from "next-translate/I18nProvider";
import { i18nConfig } from "../../i18n";
import commonES from "../../locales/es/common.json";
import commonEN from "../../locales/en/common.json";

const App = ({ Component, pageProps, router }: AppProps) => {
  const lang = i18nConfig.locales.includes(router.query.locale as string)
    ? String(router.query.locale)
    : i18nConfig.defaultLocale;

  return (
    <I18nProvider
      lang={lang}
      namespaces={{ common: lang === "es" ? commonES : commonEN }}
    >
      <Component {...pageProps} />
    </I18nProvider>
  );
};

export default App;

In this step:

We enclosed the Component with I18nProvider.
Detected the language from the route and passed it as a prop to I18nProvider.
Defined the namespace file based on the current language.

Next, generate a custom hook named useI18n.ts in the src/hooks directory and insert the code there:

import useTranslation from "next-translate/useTranslation";
import { i18nConfig } from "../../i18n";

interface IUseI18n {
  namespace?: string;
}

export const useI18n = ({ namespace }: IUseI18n = {}) => {
  const { t } = useTranslation(namespace ? namespace : i18nConfig.defaultNS);

  return { t };
};

This hook will supply us with translations based on the provided namespace or the default namespace.

Now, proceed to the index.tsx file in the pages directory and include the following code:

import { useI18n } from "@/hooks/useI18n";

export default function Home() {
  const { t } = useI18n();
  return (
    <div>
      <p>{t("greeting")}</p>
    </div>
  );
}

It will display something similar to the following:

Hurrah! We've successfully configured i18n in our project. However, the language detection aspect is still pending. Let's implement that part.

Language Detection

As observed earlier, we were fetching the locale value from router.query. To proceed, establish a folder named [locale] within the pages directory. Note that all our route files will be contained within this folder. Create an index.tsx file in the [locale] folder and insert the following code:

import { useI18n } from "@/hooks/useI18n";

const Home = () => {
  const { t } = useI18n();

  return (
    <div>
      <p>{t("greeting")}</p>
    </div>
  );
};

export default Home;

So, visiting localhost:3000/en will display content in English, and changing it to localhost:3000/es will show content in Spanish. This functionality also seamlessly integrates with dynamic routes.

The structure of your pages folder will resemble this:

Now, let's implement language detection using next-language-detector to cache our chosen language.

Begin by installing next-language-detector:

npm i next-language-detector

Create a folder named lib in the src directory, and within it, generate a file named languageDetector.ts. Open the file and insert the following code:

import nextLanguageDetector from "next-language-detector";
import { i18nConfig } from "../../i18n";

export const languageDetector = nextLanguageDetector({
  supportedLngs: i18nConfig.locales,
  fallbackLng: i18nConfig.defaultLocale,
});

Generate another file named redirect.tsx in the same lib folder and insert the following code there:

import { useRouter } from "next/router";
import { useEffect } from "react";
import { languageDetector } from "./languageDetector";

export const useRedirect = (to?: string) => {
  const router = useRouter();
  const redirectPath = to || router.asPath;

  // language detection
  useEffect(() => {
    const detectedLng = languageDetector.detect();
    if (redirectPath.startsWith("/" + detectedLng) && router.route === "/404") {
      // prevent endless loop
      router.replace("/" + detectedLng + router.route);
      return;
    }

    if (detectedLng && languageDetector.cache) {
      languageDetector.cache(detectedLng);
    }
    router.replace("/" + detectedLng + redirectPath);
  });

  return <></>;
};

Now, open the index.tsx file in the pages directory (outside the [locale] folder) and replace the existing code with the following:

import { useRedirect } from "@/lib/redirect";

const Redirect = () => {
  useRedirect();
  return <></>;
};

export default Redirect;

If anyone attempts to access the home page without specifying a locale, they will now be redirected to the locale page.

However, creating a redirection page for all routes within the [locale] folder may not be the most efficient practice. To address this, let's create a language wrapper that redirects to the route with the language if a user tries to access a page without specifying a language.

Start by creating a folder named wrappers inside the src directory. Within this folder, generate a file named LanguageWrapper.tsx and insert the following code:

import { ReactNode, useEffect } from "react";
import { useRouter } from "next/router";
import { languageDetector } from "@/lib/languageDetector";
import { i18nConfig } from "../../i18n";

interface LanguageWrapperProps {
  children: ReactNode;
}

export const LanguageWrapper = ({ children }: LanguageWrapperProps) => {
  const router = useRouter();
  const detectedLng = languageDetector.detect();

  useEffect(() => {
    const {
      query: { locale },
      asPath,
      isReady,
    } = router;

    // Check if the current route has accurate locale
    if (isReady && !i18nConfig.locales.includes(String(locale))) {
      if (asPath.startsWith("/" + detectedLng) && router.route === "/404") {
        return;
      }

      if (detectedLng && languageDetector.cache) {
        languageDetector.cache(detectedLng);
      }
      router.replace("/" + detectedLng + asPath);
    }
  }, [router, detectedLng]);

  return (router.query.locale &&
    i18nConfig.locales.includes(String(router.query.locale))) ||
    router.asPath.includes(detectedLng ?? i18nConfig.defaultLocale) ? (
    <>{children}</>
  ) : (
    <p>Loading...</p>
  );
};

Now add the LanguageWrapper in your _app.tsx file:

We're almost done, just a few touches left. Let's create a component named Link.tsx in the src/components/_shared directory and insert the following code:

import { ReactNode } from "react";
import NextLink from "next/link";
import { useRouter } from "next/router";

interface LinkProps {
  children: ReactNode;
  skipLocaleHandling?: boolean;
  locale?: string;
  href: string;
  target?: string;
}

export const Link = ({
  children,
  skipLocaleHandling,
  target,
  ...rest
}: LinkProps) => {
  const router = useRouter();
  const locale = rest.locale || (router.query.locale as string) || "";

  let href = rest.href || router.asPath;
  if (href.indexOf("http") === 0) skipLocaleHandling = true;
  if (locale && !skipLocaleHandling) {
    href = href
      ? `/${locale}${href}`
      : router.pathname.replace("[locale]", locale);
  }

  return (
    <NextLink href={href} target={target}>
      {children}
    </NextLink>
  );
};

We will utilize this Link component throughout our project instead of next/link component.

Now, create a file named useRouteRedirect.ts in the hooks folder and insert the following code:

import { useRouter } from "next/router";
import { i18nConfig } from "../../i18n";
import { languageDetector } from "@/lib/languageDetector";

export const useRouteRedirect = () => {
  const router = useRouter();

  const redirect = (to: string, replace?: boolean) => {
    const detectedLng = i18nConfig.locales.includes(String(router.query.locale))
      ? String(router.query.locale)
      : languageDetector.detect();
    if (to.startsWith("/" + detectedLng) && router.route === "/404") {
      // prevent endless loop
      router.replace("/" + detectedLng + router.route);
      return;
    }

    if (detectedLng && languageDetector.cache) {
      languageDetector.cache(detectedLng);
    }
    if (replace) {
      router.replace("/" + detectedLng + to);
    } else {
      router.push("/" + detectedLng + to);
    }
  };

  return { redirect };
};

We will use this custom hook instead of router.push and router.replace as illustrated below:

Now, create a LanguageSwitcher.tsx component in the src/components directory to switch to a specific language with the following code:

import { languageDetector } from "@/lib/languageDetector";
import { useRouter } from "next/router";
import Link from "next/link";

interface LanguageSwitcherProps {
  locale: string;
  href?: string;
  asPath?: string;
}

export const LanguageSwitcher = ({
  locale,
  ...rest
}: LanguageSwitcherProps) => {
  const router = useRouter();

  let href = rest.href || router.asPath;
  let pName = router.pathname;
  Object.keys(router.query).forEach((k) => {
    if (k === "locale") {
      pName = pName.replace(`[${k}]`, locale);
      return;
    }
    pName = pName.replace(`[${k}]`, String(router.query[k]));
  });
  if (locale) {
    href = rest.href ? `/${locale}${rest.href}` : pName;
  }

  return (
    <Link
      href={href}
      onClick={() =>
        languageDetector.cache ? languageDetector.cache(locale) : {}
      }
    >
      <button style={{ fontSize: "small" }}>{locale}</button>
    </Link>
  );
};

Congratulations! You have successfully implemented i18n in your Next.js project with output: export. Keep in mind that if you want to load translations from different namespaces, like the 'dynamic' namespace, you'll need to define the namespaces and their translation files in _app.tsx within the I18nProvider component:

Before testing it after creating a build, first, create a 404.tsx file in the pages directory with the following code:

import { FC, useEffect, useState } from "react";
import { NextRouter, useRouter } from "next/router";
import { getRouteRegex } from "next/dist/shared/lib/router/utils/route-regex";
import { getClientBuildManifest } from "next/dist/client/route-loader";
import { parseRelativeUrl } from "next/dist/shared/lib/router/utils/parse-relative-url";
import { isDynamicRoute } from "next/dist/shared/lib/router/utils/is-dynamic";
import { removeTrailingSlash } from "next/dist/shared/lib/router/utils/remove-trailing-slash";
import { Link } from "@/components/_shared/Link";

async function getPageList() {
  if (process.env.NODE_ENV === "production") {
    const { sortedPages } = await getClientBuildManifest();
    return sortedPages;
  } else {
    if (typeof window !== "undefined" && window.__BUILD_MANIFEST?.sortedPages) {
      console.log(window.__BUILD_MANIFEST.sortedPages);
      return window.__BUILD_MANIFEST.sortedPages;
    }
  }
  return [];
}

async function getDoesLocationMatchPage(location: string) {
  const pages = await getPageList();

  let parsed = parseRelativeUrl(location);
  let { pathname } = parsed;
  return pathMatchesPage(pathname, pages);
}

function pathMatchesPage(pathname: string, pages: string[]) {
  const cleanPathname = removeTrailingSlash(pathname);

  if (pages.includes(cleanPathname)) {
    return true;
  }

  const page = pages.find(
    (page) => isDynamicRoute(page) && getRouteRegex(page).re.test(cleanPathname)
  );

  if (page) {
    return true;
  }
  return false;
}

/**
 * If both asPath and pathname are equal then it means that we
 * are on the correct route it still doesnt exist
 */
function doesNeedsProcessing(router: NextRouter) {
  const status = router.pathname !== router.asPath;
  console.log("Does Needs Processing", router.asPath, status);
  return status;
}

const Custom404 = () => {
  const router = useRouter();

  const [isNotFound, setIsNotFound] = useState(false);

  const processLocationAndRedirect = async (router: NextRouter) => {
    if (doesNeedsProcessing(router)) {
      const targetIsValidPage = await getDoesLocationMatchPage(router.asPath);
      if (targetIsValidPage) {
        await router.replace(router.asPath);
        return;
      }
    }
    setIsNotFound(true);
  };

  useEffect(() => {
    if (router.isReady) {
      processLocationAndRedirect(router);
    }
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, [router.isReady]);

  if (!isNotFound) return null;

  return (
    <div className="fixed inset-0 flex justify-center items-center">
      <div className="flex flex-col gap-10">
        <h1>Custom 404 - Page Not Found</h1>
        <Link href="/">
          <button>Go to Home Page</button>
        </Link>
      </div>
    </div>
  );
};

export default Custom404;

To resolve page not found errors for dynamic routes, the inclusion of a 404.tsx file in the pages directory is essential.

Additionally, add the following command to your package.json file to execute the code after creating the build:

"preview": "serve out/ -p 3000"

Ensure the serve package is installed if it's not already present:

npm i -D serve

After running npm run build and then npm run preview, you can access your project on port 3000.

The complete code can be found on GitHub. Some tweaks have been added there, so make sure to check it out.

Feel free to comment if anything is missing or if you encounter any errors. I'm here to assist you. Thanks!