DEV Community: Alexis Zamanidis

Why I Built My Own Bio Page Instead of Using Linktree

Alexis Zamanidis — Sun, 19 Jul 2026 16:14:19 +0000

Why I Built My Own Bio Page Instead of Using Linktree

If you're a software engineer, chances are you've spent countless hours crafting the perfect portfolio.

Projects. Experience. Tech stack. Timeline. Blog posts. Contact information.

Everything is there.

And that's exactly the problem.

The Problem

A portfolio and a bio page serve two completely different purposes.

When someone visits your portfolio, they're usually interested in learning about you:

What have you built?
What technologies do you use?
What's your professional experience?
Can you solve the problem they're hiring for?

They're willing to spend a few minutes exploring.

But not every visitor has that intention.

Sometimes people just want one thing.

Maybe they scanned your QR code at a meetup.
Maybe they found you on social media.
Maybe they're reading one of your articles.
Maybe you shared your profile in a Discord server.

In those cases, nobody wants to navigate through your entire portfolio just to find your GitHub or LinkedIn.

They just want the link.

Why I Didn't Use Linktree

There are already plenty of services that solve this problem:

Linktree
Bento
Carrd
Beacons
and many more.

They're all good products.

But as developers, we often have different priorities.

I wanted:

Complete control over the design
My own domain
The exact colors and branding as my portfolio
Zero unnecessary features
No vendor lock-in
The freedom to change anything whenever I want

Most importantly, I wanted the experience to feel like it belongs to my personal website, not to a third-party service.

Keeping the Same Identity

My portfolio already has its own visual identity.

Changing fonts, colors, spacing, and animations just because someone clicked a different URL felt wrong.

So the bio page keeps the same design language.

When someone moves from the bio page to the portfolio, it feels like they're still inside the same website.

Consistency matters.

Different Pages for Different Intentions

Instead of trying to make one page do everything, I separated the two experiences.

Portfolio

The portfolio is for people who want to know more about me.

It includes:

My projects
Experience
Skills
Articles
Background
Contact information

It's where the story lives.

Bio Page

The bio page is intentionally simple.

Its job is to answer one question:

"Where's the link I'm looking for?"

That's it.

No long descriptions.

No scrolling through projects.

No reading my life story.

Just quick access to the places people usually want:

GitHub
LinkedIn
DEV
Email
Portfolio
Other important links

Fast in.

Fast out.

Why This Small Change Improved My Workflow

Since creating the bio page, I've started sharing it much more often.

Instead of asking myself:

"Should I send my portfolio or my GitHub?"

I simply send the bio page.

It becomes the universal entry point.

If someone wants my GitHub, it's there.

If they want LinkedIn, it's there.

If they decide they want to learn more about me, they can continue to my portfolio with one click.

Everyone gets what they came for.

A Small UX Lesson

As developers, we often think about what information we want to present.

Instead, we should ask:

What information is the visitor trying to find?

Those are two very different questions.

Reducing friction is often more valuable than adding more content.

Sometimes the best user experience isn't another feature.

It's one fewer click.

Final Thoughts

Your portfolio doesn't have to solve every problem.

Sometimes a dedicated landing page with your most important links is all people need.

For me, the setup now looks like this:

Bio page → the starting point for quick access.
Portfolio → the place for anyone who wants to dive deeper.

It's a small change, but it better matches how people actually interact with personal websites.

Have you separated your portfolio from your "link in bio" page, or do you use a single page for everything? I'd love to hear how others approach this.

If you're curious, here's my implementation:

🔗 Bio page: https://bio.alexiszamanidis.com
💼 Portfolio: https://alexiszamanidis.com

I'm always interested in seeing how other developers structure their personal sites, so feel free to share yours in the comments.

Handling Incomplete GitHub Issues in Your Open Source Project

Alexis Zamanidis — Tue, 19 Aug 2025 23:26:24 +0000

If you maintain an open source project, you’ve probably seen this scenario:

Someone opens a GitHub issue with almost no details.

You get something like:

“It doesn’t work!”

No steps to reproduce, no environment info, not even the version they’re using. Frustrating, right?

For maintainers, these vague issues can become a huge time sink. You spend more time chasing details than actually solving the problem.

Why this happens

Many contributors are new to GitHub or open source. They know there’s a problem but don’t know what information is important.

As a project maintainer, it’s up to you to make it easy for them to communicate clearly.

Your solution: GitHub Issue Templates

If you have an open source project, issue templates are your best friend. They guide contributors to provide the right details upfront.

For example, a Bug Report Template can ask for:

Steps to reproduce
Expected vs. actual behavior
Environment details (OS, browser, versions)

A Feature Request Template can ask for:

Motivation for the feature
Use cases
Possible implementation ideas

By providing a clear structure, you reduce back-and-forth and get issues that are actionable from day one.

How it looks when a contributor creates a new issue

Create new issue

Bug Report

My experience as a maintainer

After adding issue templates to my projects, I noticed a huge improvement:

Contributors provided detailed information from the start
Debugging and fixing issues became faster
Overall collaboration improved

Even a small project benefits from templates: they save time, reduce frustration, and keep your community happy.

Takeaway

If you maintain an open source project, don’t wait for contributors to “figure it out.” Set up GitHub issue templates.

It’s a simple way to improve communication, streamline your workflow, and help your project thrive.

Open source works best when everyone knows how to collaborate effectively, and issue templates make that easy.

Bonus: How to add an issue template on GitHub

Go to your repository on GitHub.
Click Settings → Issues → Set up templates.
Choose Bug report, Feature request, or Custom template.
Fill out the sections to guide contributors.
Save and commit the template.

Now, every new issue will prompt the contributor to fill out the relevant details.

VS Code Git Worktrees

Alexis Zamanidis — Sun, 01 May 2022 09:15:27 +0000

VS Code Git Worktrees

A Wrapper for Git Worktree Operations that provides an interactive API so developers can have a better experience.

Purpose of the extension

After creating a ZSH plugin that was responsible for wrapping up my daily git operations(zsh-git-fzf), I found myself very often switching between the terminal and my main Editor(VS Code). So I decided to create an extension for my main Editor that would help me avoid switching between them and keep everything in one tool.

Requirements

Git version: 2.34.1

Supported operations

git worktree add [new-branch] [remote-branch]

Create a new worktree

Behavior
- If you do not select a remote branch(ESC), you will create a new worktree with the new branch you typed. This was made for convenience, instead of having git worktree add master master, you can just run git worktree add master.
git worktree list

Display all worktrees and switch between them
git worktree remove [worktree-name]

Remove a worktree

Behavior
- If you have untracked or modified files a Popup will be shown at the bottom left of the screen.
  - If you want to force delete the worktree with the untracked or modified files, just click Force delete on the Popup
Restrictions
- You cannot delete the same Worktree as the one you are currently working on

Getting started

Steps:

Install Git Worktree VS Code extension
Open the palette: CTRL + SHIFT + P
Search for any available operations
- Prefix: Git Worktree:

Features/Operations/Error

If you are not able to see the GIFs in the post, take a look at GitHub README and open each GIF in a new tab.

Worktree Add (Create)

Worktree List (Switch)

Worktree Remove

Error

If anything goes wrong a Popup will be shown at the bottom left of the screen

If you see anything weird, please open an issue

Properties

Property	Type	Default value	Description
vsCodeGitWorktrees.remove.stalledBranches	boolean	false	Removes local(stalled) branches that do not exist on remote

Contribution

Reporting a bug
Improving this documentation
Writing tests
Sharing this project and recommending it to your friends
Giving a star on this repository
TODO

Run the Extension locally

# install dependencies
yarn
# compile code and watch input files
yarn watch
# Then, inside the editor, press F5. This will
# compile and run the extension in a new Extension
# Development Host window.

DEV Community: Alexis Zamanidis

Why I Built My Own Bio Page Instead of Using Linktree

Why I Built My Own Bio Page Instead of Using Linktree

The Problem

Why I Didn't Use Linktree

Keeping the Same Identity

Different Pages for Different Intentions

Portfolio

Bio Page

Why This Small Change Improved My Workflow

A Small UX Lesson

Final Thoughts

Handling Incomplete GitHub Issues in Your Open Source Project

Why this happens

Your solution: GitHub Issue Templates

How it looks when a contributor creates a new issue

My experience as a maintainer

Takeaway

Bonus: How to add an issue template on GitHub

VS Code Git Worktrees

VS Code Git Worktrees

Links

Purpose of the extension

Requirements

Supported operations

Getting started

Features/Operations/Error

Properties

Contribution

License