Open-source project
braydoncoyer/braydoncoyer.dev avatar
braydoncoyer/braydoncoyer.dev

braydoncoyer.dev: A Portfolio Rebuilt on Next.js, Supabase and Velite

My portfolio rebuilt from the ground up using Next.js 15, Tailwind, Supabase, and Framer Motion! Deployed on Vercel ▲

799 stars124 forksTypeScriptLicense varies

At a glance

What is it?
braydoncoyer.dev is a personal portfolio and blog built with Next.js 15, Tailwind, Supabase and Framer Motion, with content held in Markdown and processed by Velite, live code samples from Sandpack, and a script that generates link preview images. It is worth reading as a worked example of a modern personal site, not as a reusable framework.
Who is it for?
braydoncoyer.dev fits a developer who wants a personal site with a blog, live code samples and a real content pipeline rather than a static page, and who wants to read how one person assembled those pieces. It is the wrong tool if you need a starting template, because the readme is still the stock create-next-app text and the repository offers no licence to reuse the code.
Can I use it commercially?
Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
Is it still maintained?
Yes. The repository last received commits 62 days ago.
What is it written in?
Mainly TypeScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.

Editorial analysis

A portfolio rebuilt on the current Next.js stack

braydoncoyer.dev is the personal site of a developer, described as a portfolio rebuilt from the ground up with Next.js 15, Tailwind, Supabase and Framer Motion, deployed on Vercel. The repository is public and the deployed site is at braydoncoyer.dev. The default branch is named v4, which tells you the site has been through at least three rebuilds and that the current work happens on a version branch rather than on main. The last push was on 2026-08-22 and the repository publishes no GitHub releases, so the running site on Vercel is the only artefact anybody consumes, and the repository is a deployment source rather than a distributed package. The topics include blog, portfolio-website, cloudinary, nextjs, react, supabase, tailwindcss and vercel, which is an accurate summary of the stack.

The readme is still the create-next-app text

The readme is worth reading as a signal about how the repository is maintained, because it is the stock text from Next.js create-next-app, describing a project bootstrapped with that tool and pointing at the Next.js documentation, the learn tutorial and the Vercel deployment docs. Nothing in it describes the actual site. The practical consequence is that a visitor gets no map of the codebase from the readme, and anyone considering the project as a starting point gets nothing to copy without reading the source. The pages it does contain are still correct for the framework: the dev server starts with `npm run dev`, the site is served at `http://localhost:3000`, and edits to `app/page.tsx` hot-reload. The project uses `next/font` to load Inter as a custom Google font automatically optimized.

The scripts section, and the commands that actually matter

The package manifest lists six scripts, and two of them are the interesting ones because they are specific to this site rather than to the framework. The dev, build, start and lint scripts are the create-next-app defaults, running next dev, next build, next start and next lint. The other two are custom, named generate-previews and fix-previews.

bash
npm run dev

The generate-previews script, which runs scripts/generate-link-previews.ts through tsx, generates link preview images for the posts, and the fix-previews script runs scripts/fix-failed-previews.ts to repair the ones that failed, which implies preview generation is a separate step from the site build rather than something done on request at render time. That is the sensible arrangement for a site with many posts, and the existence of a repair script says the failure mode is common enough to need a dedicated tool. The scripts run through tsx, so TypeScript in the scripts directory is executed directly without a separate compile step, and the cloudinary topic tag fits with image and preview hosting.

Markdown content and a content layer built on Velite

The repository has a `content/` directory at the root alongside the `app/` directory, and the manifest lists velite as a development dependency with a `velite.config.ts` file at the root. Taken together, that describes a static content pipeline where the posts live as source files and are compiled into a typed collection the app imports, rather than posts being fetched from a database at request time. The choice makes sense for a blog whose content changes on a schedule rather than continuously, and it keeps the markdown next to the code in the same repository and the same review process. The typographic dependencies support that reading: reading-duration computes the reading time of a post, rehype-raw lets raw HTML through the markdown pipeline when a post needs it, and sugar-high does lightweight syntax highlighting for fenced code blocks rather than pulling in a full highlighter.

Supabase, SWR and the split between content and data

Supabase appears twice in the dependency list, with `@supabase/ssr` and `@supabase/supabase-js`, which is the standard pairing for a Next.js application that reads and writes from Supabase while keeping cookies server-side. That is a strong hint about how the site is split. Static long-form content comes from the Markdown pipeline, while anything that needs a database, such as a contact form, a view counter or a newsletter list, goes through Supabase. On the client, data fetching uses SWR rather than the query library you would find in a larger application, and the middleware file at the repository root is where the Supabase session would be refreshed on every request. The Framer Motion dependency handles the animation, and Headless UI and clsx with tailwind-merge handle the accessible components and the class name merging that Tailwind projects need.

Live code samples from Sandpack and a component library

The dependency list includes `@codesandbox/sandpack-react`, which is how a site can embed a running code sample in a page rather than a static snippet. That fits a developer portfolio specifically, since showing a component actually running is more persuasive than a screenshot of it, and it is one of the more distinctive choices in the stack. The rest of the interface is built on the geist package, which supplies a font family, with @headlessui/react for the unstyled accessible primitives and Tailwind for the styling, including the typography plugin for rendering Markdown prose and a full-bleed plugin for edge-to-edge layout sections. The usehooks-ts package supplies small reusable hooks, and uuid is there for generating identifiers.

Tooling, configuration and the Next.js version it targets

The build targets Next.js 15.1.9 with React 18 and TypeScript 5, and the manifest pins eslint-config-next at 15.2.6. The interesting detail is that the Next.js version and the eslint config version are not the same minor, which happens when the config is updated on its own schedule. Tailwind is version 3.4.7 with PostCSS 8 and autoprefixer, rather than the Tailwind 4 that newer projects use, and prettier with the prettier-plugin-tailwindcss handles formatting. Playwright is a development dependency, so the site has browser-level tests even though the package scripts do not expose a test command, and the .eslintrc.json and .prettierrc.json files sit alongside a .vscode directory for editor settings. The next.config.mjs and postcss.config.js are plain JavaScript while the Tailwind and Velite configs are TypeScript, which is a common split in this kind of project.

Licence, deployment and what to take from it

The licence field is recorded as unknown, so there is nothing here you can reuse under a stated licence, and the readme does not address it either. That makes the repository usable as a reference and not as a base to fork. The deployment target is the Vercel platform, which the readme describes as the easiest way to deploy a Next.js application, and the topics confirm it. The bun.lockb file alongside package-lock.json suggests the author has experimented with more than one package manager, while the scripts still use npm-style invocations. The honest assessment is that this is a well-chosen set of current tools assembled by one person for one site, with a custom content pipeline and preview generation that are the parts most worth studying. As a starting point for your own portfolio, expect to write the content layer, the preview pipeline and the components yourself, because none of it is packaged for reuse.

Editorial conclusion

braydoncoyer.dev fits a developer who wants a personal site with a blog, live code samples and a real content pipeline rather than a static page, and who wants to read how one person assembled those pieces. It is the wrong tool if you need a starting template, because the readme is still the stock create-next-app text and the repository offers no licence to reuse the code. It is also the wrong choice if you are not willing to write your own content layer. Before adopting any of it, read the app and content directories to see how much of the site is genuinely generic.

Frequently asked questions

What stack is braydoncoyer.dev built on?

Next.js 15.1.9 with React 18 and TypeScript 5, Tailwind CSS 3.4.7, Supabase through the SSR and JavaScript clients, Framer Motion for animation, and Vercel for deployment. Markdown content is processed with Velite and code samples are rendered with Sandpack.

How do I run the site locally?

Run npm run dev, or the yarn, pnpm or bun equivalent, and open http://localhost:3000. Edits to app/page.tsx hot-reload, and the project uses next/font to load Inter automatically.

How are link previews generated?

With two custom scripts run through tsx: scripts/generate-link-previews.ts generates the preview images and scripts/fix-failed-previews.ts repairs the ones that failed, so previews are a separate step rather than something produced during the site build.

Does braydoncoyer.dev have a tutorial or setup guide?

No. The readme is still the stock create-next-app text describing the dev server, next/font and Vercel deployment, and it does not document the site's own architecture. To understand the content pipeline or the preview scripts you have to read the source.

Can I reuse the code from this repository?

The licence is recorded as unknown and the readme does not address licensing, so there is no stated permission to reuse it. You can read it as a reference for how the stack fits together, but check with the author before copying code.

Official sources

  1. braydoncoyer/braydoncoyer.dev on GitHub
  2. Issues
  3. Project website
  4. README
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/braydoncoyer-braydoncoyer-dev.svg)](https://hysenlabs.com/projects/braydoncoyer-braydoncoyer-dev)

Was this useful?