Coder Legion - Recent posts tagged portfolio

The Portfolio Lie: Why Side Projects Do Not Prove You Can Ship

Sun, 13 Sep 2026 22:28:24 +0000

There is a piece of advice that circulates constantly in developer communities, in bootcamp curriculums, in career coaching threads, and in well-meaning LinkedIn posts:

Build side projects. They are the best way to show what you can do.

It is not wrong. But it is incomplete in a way that quietly misleads a lot of capable developers about what hiring managers and clients are actually looking for, and why their portfolio is not landing the way they expected.

Side projects demonstrate capability. They show that you can learn a framework, build a feature, and put something on the internet. That is genuinely valuable, especially early in a career when you have no other evidence to offer.

What they do not show is whether you can ship.

Shipping, in the sense that matters professionally, is not the same as finishing a project. It is what happens when the requirements are unclear, when the deadline is real, when someone else is depending on the outcome, and when the consequences of being wrong belong to someone other than you. It is the ability to make good decisions under those conditions, consistently, over time.

A side project removes almost all of those conditions. You set the scope. You set the deadline, or you ignore it. If something is harder than expected, you simplify it or you shelve it. Nobody is waiting. Nothing breaks if you do not finish. The feedback loop is entirely internal.

That is a fine environment for learning. It is a poor environment for demonstrating professional readiness.

WHY THE LIE PERSISTS

The side project gospel persists for a few reasons, none of which are malicious.

First, it is genuinely the most accessible advice. Not everyone has work experience to point to, and a GitHub profile is something anyone can build regardless of background, location, or employment history. The advice democratises entry in a way that feels fair.

Second, it worked. Many developers did land their first role because of a side project, and they remember that. What they often forget is the other things they brought to the table: how they spoke about the project in the interview, the problems they articulated, the tradeoffs they described. The project was the entry ticket. The conversation was the actual evaluation.

Third, the people giving the advice are not the people doing the hiring. There is a persistent gap between what career content creators recommend and what technical leads and engineering managers actually find convincing when they review a candidate.

The project was the entry ticket. The conversation was the actual evaluation.

WHAT HIRING MANAGERS AND CLIENTS ARE ACTUALLY LOOKING FOR

When a technical lead reviews a portfolio, they are not asking: can this person build things? They are asking something harder:

Can this person make good decisions when the problem is ambiguous?
Do they understand why they made the choices they made, not just what they made?
Have they worked against real constraints, or only self-imposed ones?
When something went wrong, what did they do?
Can I hand them a brief and trust them to come back with the right questions, not just an implementation?

A todo app, a weather widget, or a clone of an existing product does not answer any of those questions. Not because the code is bad, but because the conditions under which it was built do not generate evidence of professional judgment.

Clients are asking a version of the same question. They are not buying your ability to write code. They are buying your ability to take their problem, translate it into a solution they did not have to fully specify, and deliver it in a way that does not require constant supervision. Side projects do not demonstrate that either.

WHAT ACTUALLY PROVES YOU CAN SHIP

The good news is that the evidence hiring managers and clients want is buildable. It requires a different kind of intentionality than most portfolio advice talks about.

Document the decisions, not just the outcome

The single highest-leverage thing you can do with any project, side or otherwise, is write about the decisions you made and why. Not a readme. Not a bullet list of technologies. A genuine account of the problem as you understood it, the approaches you considered, the one you chose, and what you learned from the result.

This transforms a project from a code artifact into evidence of thinking. It answers the interview question before the interview happens. It gives a potential client something to evaluate beyond the visual design of the finished product.

Most developers skip this entirely. Which means doing it, even briefly, is a meaningful differentiator.

Introduce real constraints

The closest you can get to professional conditions on a personal project is to impose real constraints on yourself and honour them. A fixed scope. A genuine deadline with a consequence, even a small one, like a public commitment. A user who is not you, whose feedback you actually incorporate.

A project built under those conditions generates fundamentally different evidence than one built at your own pace with unlimited scope changes. The constraint is the point. It forces the kinds of decisions that professional environments force, and your account of navigating them is what makes the project interesting to someone evaluating you.

Contribute to something with stakes

Open source contributions, freelance work, contract projects, even internal tools built for a real organisation, all of these put you in a professional context where someone else has a stake in the outcome. The feedback is external. The constraints are real. The decisions you made had consequences beyond your own learning.

One project built in that context is worth more, as portfolio evidence, than ten side projects built in isolation. Not because the code is necessarily better, but because the conditions were real.

Show the iteration, not just the finish line

Shipping is not a single moment. It is a process of building, getting feedback, revising, and shipping again. A portfolio that only shows finished products hides the most interesting part of the work.

Showing an earlier version of something alongside the current version, and explaining what changed and why, demonstrates exactly the kind of iterative judgment that professional environments depend on. It also shows that you can receive feedback and act on it without ego, which is something no amount of polished code can communicate on its own.

One project built under real constraints is worth more as portfolio evidence than ten side projects built in isolation.

THE REFRAME THAT CHANGES EVERYTHING

The goal of a portfolio is not to show everything you have built. It is to answer one question as clearly as possible: can I trust this person with a real problem?

Side projects can contribute to that answer. But they need to be presented in a way that generates evidence of judgment, not just capability. The project is context. The thinking is the content.

If you are currently building a side project, this is not an argument to stop. It is an argument to be more intentional about what you build, how you constrain yourself, and how you talk about it afterward. The project matters less than you think. How you account for it matters more than you probably realise.

And if you have real projects under your belt, whether freelance, contract, open source, or production work, stop burying them under a list of personal projects built on weekends. That work is the most credible thing in your portfolio. Lead with it.

CLOSING THOUGHT

Side projects are a starting point, not a destination. The developers who move fastest are not the ones with the most projects. They are the ones who can articulate most clearly what they learned from building them, why they made the decisions they made, and what they would do differently now.

That is what shipping looks like from the outside. And that is what a portfolio actually needs to show.

Improving my developer portfolio — latest changes in v0.1.4

Wed, 09 Sep 2026 02:14:41 +0000

I’ve shipped another iteration of my personal portfolio: v0.1.4.

This update continues the direction I want for the site: less of a conventional resume and more of a structured place to explore my work, projects, experience, tools, and approach to building software.

The portfolio now uses a more intentional, editorial-style interface while keeping the focus on the work itself particularly the intersection of web development, blockchain, AI-native tooling, and practical product systems.

I’m still refining it, so I’d value feedback from the CoderLegion community on:

First impression: does the site quickly communicate what I do?

Navigation: is it easy to move between my background, projects, experience, and writing?
Presentation: does the design support the content, or does it get in the way?
Professional positioning: would you understand the type of roles, collaborators, or clients I’m looking to work with?
Mobile and accessibility: anything I should prioritize in the next update?

Explore the latest version here: https://jstn.site/
If you have direct, critical feedback, I’d genuinely appreciate it. I’m treating this portfolio as an evolving product not a finished page.

How to Build a Portfolio Website That Actually Gets You Hired

Fri, 21 Aug 2026 05:00:00 +0000

Introduction

I've rebuilt my own portfolio more times than I can count, and every rebuild taught me something the last version got wrong. Most developer portfolios fail for the same handful of reasons — and none of them are "not enough animations" or "not a fancy enough design."

This article covers what actually matters, based on what I've learned building my own portfolio and two client portfolio sites.

What a Portfolio Is Actually For

A portfolio has one job: convince someone (a client or a hiring manager) that you can solve their problem. It's not a design showcase for its own sake — every section should answer the visitor's unspoken question, "can this person help me?"

The Sections That Actually Matter

1. A Clear Headline (Not Just Your Name)

Weak: "Muhammad Farhan"
Better: "Frontend Developer building fast, clean websites with React & Tailwind CSS"

The second version tells a visitor exactly what you do within two seconds — no scrolling required.

2. 3-5 Real Projects (Quality Over Quantity)

A portfolio with 3 well-explained projects beats one with 10 half-finished ones. For each project, include:

A live link (not just a GitHub repo — most non-developers won't clone your code)
A short description of the problem it solves
Your specific role and the tech stack used
1-2 sentences on a challenge you solved

Example:
"UX Gazette — A blog platform built for a real client using WordPress.
Customized the theme, set up categories and SEO structure, and optimized
page speed from a 60 to a 92 Lighthouse score."

That last sentence — a specific, measurable outcome — is worth more than any amount of visual polish.

3. About Section (Keep It Short and Human)

Skip the generic "passionate developer who loves clean code" line — everyone writes that. Say something specific: how you started, what you're currently learning, what kind of projects you enjoy.

4. Clear Contact Options

Don't make people hunt for how to reach you. Email, and at minimum one social/professional link (GitHub, LinkedIn), visible without scrolling to the very bottom.

What to Leave Out

A skills section with progress bars. "HTML — 90%" means nothing measurable — show skill through projects instead, not arbitrary percentages.
Every single project you've ever built. Tutorial clones and unfinished experiments dilute your best work. Curate ruthlessly.
Overly complex animations that slow load time. A portfolio that takes 6 seconds to load is actively working against you, no matter how good it looks once it finally does.

Technical Details That Quietly Matter

Mobile responsiveness. A huge percentage of visitors, including recruiters, will open your link on their phone first. If it breaks there, that's often the entire impression formed.
Fast load time. Run it through Lighthouse (see Article 1). Aim for 90+ on performance.
Working links. Sounds obvious, but broken project links are one of the most common portfolio mistakes I've seen — test every single one before sharing.
A resume/CV download link, if you're job hunting alongside freelancing.

Real Example: My Own Approach

My portfolio Muhammad Farhan follows exactly this structure: a clear one-line headline about React + Tailwind, a curated project section instead of everything I've built, and direct contact info without needing to scroll far. It's not the most visually elaborate portfolio out there — but it's fast, clear, and gets straight to the point.

Common Beginner Mistakes

Launching a portfolio, then never updating it. Add your best new project as soon as it's live — an outdated portfolio signals inactivity.
No live demo links. A GitHub repo alone asks too much of a busy visitor. Deploy everything (see Article 10) and link the live version.
Copying a template without understanding it. If someone asks about your portfolio's code in an interview and you can't explain a decision, that's a red flag they'll notice.
Burying your best project. Lead with your strongest, most relevant work — not chronologically, but by impact.

Final Thoughts

A great portfolio isn't the flashiest one — it's the clearest one. Someone should be able to land on your site, understand what you do, see proof you can do it, and know how to contact you, all within about 30 seconds. Everything else is secondary.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: Muhammad Farhan

What Would You Change About My Developer Portfolio?

Tue, 16 Jun 2026 09:18:56 +0000

Hey everyone, c0d3l0v3r Here

I'm a final-year B.Tech student preparing for software engineering roles.

Portfolio: https://portfolio-one-rust-77.vercel.app/

I'm looking for honest feedback.
If you were a recruiter, hiring manager, or senior developer:

What stands out immediately?
What looks weak or unnecessary?
Which sections would you remove, improve, or redesign?
Do the projects feel impressive enough for internships or entry-level roles?
Does anything make the site feel unprofessional?

Feel free to be brutally honest. I'd rather hear harsh feedback here than get silently rejected later.

Thanks.

The Weekend I Finally Finished 17 Projects

Fri, 12 Jun 2026 00:14:34 +0000

You know that feeling when you open a folder you haven't touched in months and find... yourself?

Not metaphorically. I mean literally — old projects you don't even remember writing, with code that's somehow good? And you're sitting there like, "wait, I wrote this?"

That was my Saturday.

The Mess

I decided it was time. My portfolio was a ghost town. My GitHub was full of half-finished dreams. You know the drill, you start a project, get 80% there, then a shinier thing comes along and suddenly it's gathering dust for a year.

I had 17 of those.

LIS — An AI tutoring app for Cameroonian students. Works offline. Has a Learning DNA that adapts to how you study. I literally submitted this for a social impact prize and then... just left it there.
Mbende Stay — A booking platform with mobile money payments. Fully functional. Zero visitors.
"418 I'm a Teapot" — A game where you play as a teapot that can never win and an AI roasts you every time you fail. I'm not kidding.
elementTouch — A JavaScript library I built from scratch. Drag and drop. Typewriter effects. A whole code editor. Just... sitting there.

And I'm looking at all of this thinking: bro, you really just built things and then forgot to tell anyone?

So I made a decision: polish them all, put them in my portfolio, and actually show the work.

First step: build an admin import tool. One click, seed 17 projects into Firestore. Felt like a genius.

Then the Universe Laughed

npm run build

ReferenceError: location is not defined
    at v (.next/server/app/admin/blog/new/page.js:1:11128)
    at y (.next/server/app/admin/projects/import/page.js:1:16875)
    at y (.next/server/app/admin/projects/new/page.js:1:8262)
    at j (.next/server/app/admin/resumes/new/page.js:1:4056)

Four pages. Dead. And I have no idea where location is coming from.

You ever debug a Firebase + Next.js app and feel like you're chasing a ghost? Because I was definitely chasing a ghost.

Turns out, Firebase's SDK references location (as in window.location) at the module level. Not inside a function you call. At import time. So when Next.js tries to server-render your admin page, Node.js is like "what's location? never heard of her."

The fix?

import dynamic from "next/dynamic"
export default dynamic(() => import("./page.client"), { ssr: false })

I wrapped each page in next/dynamic with ssr: false. Basically told Next.js: "Don't even look at this page on the server. Not once. Not ever. Just send the JS and let the browser figure it out."

Moved all the actual code to page.client.tsx. Build passed. I felt like a god for approximately 12 minutes.

The Betrayal

Then I looked at my blog.

You see, my blog posts are stored in Firestore as HTML. And somewhere along the way, I'd written them with beautiful Tailwind dark mode classes:

<div class="not-dark:bg-white dark:bg-gray-900 dark:shadow-lg">

Here's the problem: Tailwind v4's JIT compiler has never heard of your database.

It scans your source files — your app/, your components/, your lib/. It does NOT make a Firebase query to find class names.

So dark:bg-gray-900 in a blog post? Never compiled. It renders as plain text with zero styles. My "beautiful blog content" was just... floating in the void. No background. No shadow. Nothing.

I sat there staring at the screen feeling personally betrayed by a CSS framework.

But hey, I fixed it:

function prepareHtml(html: string): string {
  return html.replace(/\b(?:not-)?dark:[^\s"'>]+/g, "").trim()
}

Strip the prefixes. Then override everything with CSS variables:

.blog-content .text-gray-900 { color: inherit !important; }
.blog-content .bg-white, .blog-content .bg-gray-900 { background: transparent !important; }
.blog-content .shadow-md, .blog-content .shadow-lg { box-shadow: none !important; }

Now every hardcoded class respects the theme. Dark mode, light mode, it just works. The blog content is finally alive.

Then There Were 17

So now I've got 17 projects in my portfolio. On one page. One. Grid. Screen. You see the problem.

I needed pagination. Not the boring kind — something that actually looks good:

Chevrons that bounce when you hover
Page numbers with the accent color on active
Ellipsis that only show when there's actually a gap
A quiet little "Page X of Y · N projects" at the bottom

The button logic nearly broke me. You try handling "first page, last page, exactly 5 pages, exactly 6 pages, ellipsis-or-no-ellipsis" without your brain melting:

const pages = useMemo(() => {
  const p: (number | "...")[] = []
  if (totalPages <= 5) {
    for (let i = 0; i < totalPages; i++) p.push(i)
  } else {
    p.push(0)
    if (safePage > 2) p.push("...")
    // ... more edge cases
  }
  return p
}, [safePage, totalPages])

It works. It's clean. I'm proud of it.

What I Actually Learned

1. You probably have better code than you think

Open that old project. The one you're embarrassed about. I bet it's not as bad as you remember. We're all way too hard on ourselves.

2. Admin pages don't need SSR

If your page is behind a login wall, there's zero SEO value in server-rendering it. Just use ssr: false and save yourself the headache. Your admin panel will survive without being indexed by Google.

3. Tailwind v4 JIT is amazing until your content is dynamic

If your HTML lives in a database, plan ahead. CSS variables are your escape hatch. Hardcoded utility classes in data strings will come back to haunt you.

4. A portfolio is never done

Every time I thought "okay this is final," I found another project, another bug, another thing to improve. That's not failure. That's just what building in public looks like.

What's Left

elementTouch still has 2 unfinished tasks out of 7. I'll get to them.

And there's a missing admin/blog/edit/[id] page that keeps crashing the build. One day.

Anyway, that's my weekend. What's the most embarrassing bug you've fought with Next.js + Firebase? Drop it below so I don't feel alone.
Here's my portfolio btw: Portfolio

Why I Ditched VS Code for Zed (And How It Accelerated My Full-Stack Work on Recipe-Finder.org)

Wed, 03 Jun 2026 17:20:21 +0000

For the past few years, VS Code was my comfortable, heavily customized home. It had my extensions, my themes, and a decade's worth of muscle memory. But recently, as my stack evolved heavily into Express.js, Vue 3, and Tailwind CSS, I started noticing the micro-frictions.

VS Code is an industrial powerhouse, but it is built on Electron. Under the hood, it’s running a wrapped version of Google Chrome. When you are deeply indexing thousands of dependencies inside node_modules, running real-time frontend dev servers, and layering on AI code completions, those micro-stutters and cursor lags start to compound.

Two weeks ago, I completely cut the cord and switched to Zed—the new open-source, GPU-accelerated code editor written from scratch in Rust.

Here is the real, unvarnished story of why I made the jump, the brutal financial reality check I ran into with token billing, and how this layout shift dramatically accelerated development on my main production project, recipe-finder.org.

The Blazing Speed (The Rust Difference)
The very first thing you notice when you open Zed is that it doesn't "launch"—it just appears. Because it's compiled natively in Rust and uses your computer's graphics card to render text, everything from file searching (Ctrl + P) to global project searching is instantaneous.

When working on the codebase for recipe-finder.org, jumping back and forth between a complex Express backend route and a Vue frontend single-file component used to feel like dragging a heavy cart. In Zed, switching tabs and editing massive lines of code feels buttery smooth. It completely eliminated the cursor lag that used to break my typing flow.

Perfect Out-of-the-Box Tooling for Vue & Tailwind
I was worried that leaving VS Code's massive ecosystem of 50,000+ extensions would break my stack. It didn't.

Tailwind CSS: Zed has native support built right in. As I write utility classes inside my .vue templates, autocomplete popups appear flawlessly. Hovering over a class instantly shows the raw CSS output.

Vue.js: A quick trip to Zed's extension marketplace (Ctrl + Shift + X) to grab the official Vue extension hooked up Volar (the Vue Language Server) seamlessly. Full type-checking, diagnostics, and scoped styling worked instantly.

Express.js: Because Zed indexes node_modules instantly in the background without locking up the editor UI thread, my Node/Express server setup became incredibly responsive to work with.

The Token Price Shock (And How I Fixed It)
If you use Zed’s native AI panel on the right side, you need to understand how it bills. Zed Pro gives you a $5 monthly token credit and then switches to pay-as-you-go raw API costs +10%.

Within my first hour, I burned through $2.63 in just four questions.

I had massive sticker shock until I realized how LLMs work under the hood. It’s called the Context Snowball Effect. Every time you type a follow-up question in the right-hand panel, Zed bundles the entire chat history plus your active code files and flings them back to the model. You aren't paying for small questions; you are paying the AI to re-read your entire file over and over again from scratch.

The Solution: The Ultimate Hybrid Workflow
Instead of paying for metered usage-based billing with Zed-hosted models, I leveraged a brilliant feature built directly into the editor: I plugged in my existing $39 GitHub Copilot subscription.

By pressing Ctrl + Shift + P and running copilot: sign in, I authorized my GitHub account. Then, I switched my right-side AI panel dropdown provider to "GitHub Copilot Chat".

Now, I get the flat-rate predictability of Copilot (ask 500 questions a day, leave massive Vue files attached, no extra fees) combined with the lightning-fast, zero-lag editing environment of Zed. It’s the ultimate setup.

How It Accelerated Recipe-Finder.org

We’ve been sprinting hard to push out a massive referral marketing campaign on the site: a brand-new invite portal titled "Get a FREE Month of Premium!".

This required writing a specialized absolute overlay over our main Vuetify cards to handle asynchronous loading states smoothly. In my old workflow, tweaking the custom Vue deep selectors (:deep(.v-loader)) and alignment styling while waiting for code completions to catch up was tedious.

With Zed docked perfectly to my preferences—with the terminal and project panels pushed over to the right side just like VS Code, and the minimap file preview pinned—the cycle time dropped to zero.

Fragment de cod

<!-- A snippet of the optimized portal cards we shipped under the new setup -->
<template>
  <v-card loading class="premium-invite-card">
    <v-card-title>Get a FREE Month of Premium!</v-card-title>
    <!-- Referral portal components -->
  </v-card>
</template>

<style scoped>
.premium-invite-card :deep(.v-loader) {
  background-color: rgba(var(--v-theme-surface), 0.85) !important;
  backdrop-filter: blur(6px);
}
</style>

The combination of instant file-saving formatting, snappy inline AI predictions, and zero-latency UI rendering allowed us to prototype, style, and ship the invite portal features significantly faster than before.

The Final Verdict

If your engineering workflow depends on hyper-niche VS Code extensions (like complex graphical visual debuggers or proprietary database managers), keep VS Code close by.

But if you are a full-stack developer working in the JavaScript/Node ecosystem, handling reactive frontends, and writing code alongside AI assistants all day, do not sleep on Zed. Connect your existing Copilot key, clean up your layout, and enjoy a text editor that finally keeps up with the speed of your brain.

Have you tried switching to Zed yet, or are you staying loyal to VS Code? Let me know your setup below!

Reading obsessively about Stripe for a month taught me one thing that changed how I build billing

Mon, 01 Jun 2026 12:10:06 +0000

daily.dev handed me a "Top Reader" badge for the Stripe topic this month, which is mostly the platform politely telling me I have a problem. But the upside: it forced a pattern I now build around — every Stripe webhook handler has to be idempotent, because Stripe will deliver the same event twice and your "charge succeeded" logic will happily run twice if you let it. Dedup on the event ID before you do anything with side effects. It's the cheapest insurance in payments and the most common thing I see skipped.
What's the billing edge case that bit you hardest — duplicate webhooks, proration math, or failed-payment recovery?

Why I Feel Most Side Projects Fail in Production

Sat, 30 May 2026 11:39:05 +0000

Building Is Fun. Running It in Production Is the Real Test.

Most developers have at least one side project they’re proud of.

Maybe it started as a weekend experiment. Maybe it came from frustration with an existing tool. Maybe it was the app idea you were convinced people would love if you could just get it online.

And to be fair, getting a side project working at all is an achievement. You design the UI, write the backend, connect the database, deploy it somewhere, and finally see it live on the internet. That moment feels amazing.

But then reality shows up.

The app goes down after a traffic spike. Login breaks. Database queries slow to a crawl. Error messages start appearing in places you didn’t expect. Small issues pile up, and the project that once felt exciting suddenly becomes exhausting to maintain.

That is where many side projects quietly die.

The problem is not that developers lack good ideas. It is not even that the code is always bad. The real issue is that many side projects are built to launch, not to survive production.

The good news is this: most side projects do not fail because the developer is incapable. They fail because production introduces a completely different set of challenges reliability, scalability, maintenance, user trust, and operational discipline. Once you understand that shift, you start building differently.

In this post, I want to break down why most side projects fail in production, what developers often underestimate, and how to avoid the common traps that kill promising projects early.

The Real Difference Between a Working Project and a Production Ready Project

One of the biggest mindset shifts in software development is realizing that a project can be functional without being production ready.

A side project often works perfectly in a controlled environment:

your local machine
your test account
your sample data
your internet connection
your ideal workflow

But production is messy.

Real users behave differently. They click unexpected things. They use weak passwords. They refresh during requests. They upload weird files. They open ten tabs. They forget what you assumed was obvious. They show you where your product is fragile.

That is why building something that works is only step one. Building something that continues working under real world conditions is where the actual engineering begins.

1. Most Side Projects Are Built for Excitement, Not Sustainability

Let’s be honest: side projects usually begin with energy, not long term planning.

You are excited about the idea, the stack, the design, or the problem you want to solve. You want momentum, so you move fast. That speed is often a good thing in the beginning. It helps you ship.

But the same speed can also create hidden technical debt.

A lot of side projects are built around questions like:

How fast can I get this live?
What’s the easiest way to make this work?
What’s the quickest feature I can show?

Those are useful early stage questions. The problem is when they remain the only questions.

Production asks different ones:

What happens when this endpoint fails?
Can I debug this issue quickly?
What if 100 users hit this at once?
How do I roll back a bad deployment?
What happens if my database gets corrupted?
Can I maintain this code in six months when I barely remember writing it?

This is where many developers get trapped. The project was optimized for shipping fast, but not for operating reliably.

What helps instead?

Treat even small projects with a bit more production respect:

use clear project structure
write maintainable code, not just clever code
keep configuration organized
think about failure states early
document setup, deployment, and core decisions

You do not need enterprise level complexity. But you do need enough discipline to support the project after the launch excitement fades.

2. Side Projects Often Ignore Boring but Critical Production Needs

This is probably the biggest reason side projects fail in production: developers focus on visible features and ignore invisible infrastructure.

Features are fun. Reliability is not glamorous.

Nobody gets excited tweeting:

“I added proper logging”
“I improved rate limiting”
“I set up health checks”
“I created backup and recovery procedures”

But those “boring” things are exactly what keep production systems alive.

A project can look polished on the surface and still be extremely fragile underneath.

Common areas side projects neglect:

error handling
monitoring and observability
rate limiting
retries and timeouts
backup strategy
security basics
environment variable management
deployment rollback plans

When these are missing, even small problems become major incidents.

For example, if users report that checkout is failing and you have no logs, no alerts, and no tracing, you are not debugging a bug anymore you are guessing in public.

That is one of the fastest ways for users to lose trust.

The solution

If you want your side project to survive production, you need to fall in love with operational basics:

add structured logging
use uptime monitoring
track key errors
set up database backups
validate input properly
protect APIs with rate limits
test deployment flow before you need it under pressure

These steps are not “extra.” They are part of the product.

3. Many Side Projects Break Because the Developer Is the Entire System

This one is deeply relatable if you have ever solo built something.

In many side projects, the developer is not just writing code. They are also:

the product manager
the designer
the QA tester
the support team
the DevOps engineer
the marketer
the incident response team

That works for a while. But in production, this becomes a bottleneck very quickly.

If you are the only person who understands how the app works, every issue depends on your availability, energy, and memory. And that becomes dangerous once real users depend on the product.

A lot of side projects do not fail because the software is terrible. They fail because the maintenance burden becomes too heavy for one person to carry consistently.

Signs this is happening:

you are afraid to change code because you might break something
deployments feel stressful
bugs pile up faster than you fix them
users ask questions and you do not have a clear answer
you have no documentation, so every task starts with learning your own app again

What helps?

Reduce the “only I know how this works” problem:

write basic documentation
automate repetitive tasks
simplify architecture where possible
avoid unnecessary services and abstractions
create a deployment checklist
leave your future self helpful notes

Your future self is part of your team, even if you are building alone.

4. Developers Underestimate the Gap Between Demo Traffic and Real Usage

A side project can feel stable when only you and two friends are using it.

That does not mean it is ready.

Production stress exposes weaknesses that local development never reveals. It can be something as simple as:

unoptimized database queries
too many API calls on one page
memory heavy background jobs
bad caching decisions
synchronous operations that should not be blocking

Many developers assume scaling problems only happen at massive scale. That is not true.

Sometimes just a small wave of real users is enough to break an app that was never designed for concurrency, uneven traffic, or messy user behavior.

Why this happens

Because local success creates false confidence. On your machine:

the database is small
latency is low
file storage is simple
requests are limited
everything runs under ideal conditions

Production removes those safety rails.

What to do instead

You do not need to over engineer for millions of users. But you should build with realistic usage in mind:

paginate large datasets
optimize expensive queries
use caching where it actually helps
move heavy tasks to background jobs
test with seeded data, not just empty tables
measure performance before users complain

A production ready side project is not one that scales infinitely. It is one that handles its expected load responsibly.

5. Security Is Often Treated Like a Future Upgrade

This is a serious one.

A lot of side projects treat security as something to “tighten later.” But if your app is public, then “later” may already be too late.

Developers sometimes think:

“Nobody will target my small app.”
“It’s just a side project.”
“I’ll improve auth after launch.”
“This admin route is obscure enough.”

Unfortunately, the internet does not care whether your app is a side project or a funded startup.

If it is public, it can be abused.

Common security gaps in side projects:

weak authentication flows
poor session handling
exposed secrets
missing input validation
insecure file uploads
no rate limiting
overly permissive APIs
lack of authorization checks

And the painful part is that one security issue can erase user trust immediately.

The better mindset

Treat basic security like a product requirement from day one:

validate and sanitize input
hash passwords correctly
protect secrets
verify authorization, not just authentication
limit abuse with rate controls
use proven libraries for auth flows where possible

Security does not have to be perfect on day one, but it must be taken seriously.

6. Too Many Side Projects Are Built on Overcomplicated Architecture

This may sound ironic, but sometimes side projects fail not because they are too simple but because they are too ambitious architecturally.

A lot of developers, especially when excited, build side projects like they are designing the next global platform.

Suddenly the “simple app” includes:

microservices
event buses
multiple databases
complex CI/CD pipelines
premature abstractions
layers of tooling that are hard to debug

The project becomes impressive on paper, but painful to maintain.

The more moving parts you add, the more production surface area you create for bugs, outages, and deployment issues.

For a small product, complexity kills momentum.

What usually works better

Choose boring, reliable solutions where possible:

one backend if one backend is enough
one database if one database is enough
simple deployment workflows
fewer services to monitor
fewer places for failures to hide

A side project does not become more serious because it is more complex. It becomes more serious when it is dependable.

7. Feedback Loops Are Weak, So Problems Stay Hidden Too Long

One reason side projects die in production is that developers often have poor visibility into what users are actually experiencing.

If users silently struggle and you do not know:

where they drop off
what errors they see
which features they ignore
what confuses them
what breaks on certain devices

then you are not improving the product based on reality. You are improving it based on assumptions.

That is dangerous.

Healthy production feedback loops include:

user feedback channels
bug reports
analytics on important flows
error tracking
basic performance monitoring
support messages that are easy to act on

Without feedback loops, a side project can feel “fine” to the developer while frustrating actual users enough to make them leave.

Solution

Build simple ways to learn from real usage:

add error reporting tools
monitor key user actions
make it easy for users to report issues
review logs and analytics regularly
talk to early users directly if possible

Production success is not just about uptime. It is also about learning fast.

8. Motivation Drops Once the Project Stops Feeling New

This is the most human reason of all.

A lot of side projects fail in production because once the initial excitement fades, maintenance starts to feel like work.

And honestly, it is work.

Shipping version one feels creative and energizing. Maintaining version one after bug reports, edge cases, user requests, and deployment stress feels very different.

That is where many side projects lose momentum:

the dopamine of building is gone
the hard parts are now visible
users want stability more than novelty
the developer wants to move on to the next idea

This is normal. It does not make you a bad developer.

But it does explain why many projects disappear after launch.

What helps here?

Be honest about the kind of project you are building.

Ask yourself:

Do I want to experiment, or do I want to maintain?
Am I building a portfolio piece, a learning project, or a real product?
Do I actually want users, or do I just want to prove I can build it?

Those are different goals, and they require different commitments.

Many side projects fail because the developer wanted to build a product but only planned for a prototype.

How to Give Your Side Project a Better Chance in Production

If you want your project to survive beyond the launch phase, here are a few practical principles that matter:

Start simpler than you think

Simple systems are easier to debug, deploy, and maintain.

Build for recovery, not just success

Assume things will fail. Plan for how you will detect, fix, and recover from those failures.

Add visibility early

Logs, monitoring, analytics, and alerts save time and reduce panic.

Respect performance before it becomes a crisis

You do not need massive scale to need decent performance practices.

Take security seriously

Even a small public app deserves strong basics.

Be realistic about maintenance

A project with users becomes an ongoing responsibility.

Define the project clearly

Know whether you are building a learning experiment, portfolio project, or real long term product.

That clarity changes your decisions.

Conclusion: Most Side Projects Don’t Fail Because the Idea Was Bad

They fail because production is where software stops being theoretical.

That is where assumptions get tested. That is where weak architecture gets exposed. That is where missing monitoring, poor security, shaky performance, and unclear ownership become real problems.

As developers, it is easy to focus on getting to “live.” But live is not the finish line. It is the beginning of a very different phase.

If there is one lesson I keep coming back to, it is this: a side project that survives production is not usually the flashiest one. It is the one that was built with enough care, humility, and realism to handle the messiness of real users.

So if you are building your next side project, absolutely move fast. Experiment. Ship. Learn.

But while you are building, ask yourself one important question:

If real users start depending on this tomorrow, would this project hold up?

That question alone can change how you build.

If this post resonated with you, share it with another developer who is building in public, launching side projects, or learning what production really means. And if you’ve had a side project break in production before, you’re definitely not alone that experience is practically part of the developer journey.

How I Built a Hospital Management System with Laravel

Mon, 25 May 2026 12:07:28 +0000

Hey everyone! I'm Ibtisam, a developer from Somaliland learning full-stack web development. Recently, I built MediTrack, a hospital management system with Laravel, and I want to share what I learned along the way.

Why I Built MediTrack

I wanted to understand how real-world applications work beyond simple CRUD projects. Healthcare systems seemed like a perfect challenge because they involve:

Multiple user roles (Admin, Doctor, Receptionist)
Complex data relationships (Doctors → Patients → Appointments)
Real business logic (managing prescriptions, lab tests)

So I built MediTrack to learn and create a solid portfolio project.

What MediTrack Does

It's a role-based hospital management system that helps clinics manage:

Doctors
Patients
Appointments
Prescriptions
Lab Tests

Features:

Secure authentication (login/register)
Real-time dashboard with statistics
Full CRUD operations for all modules
Search functionality
Responsive Bootstrap UI

The Tech Stack (And Why)

Laravel – Powerful yet beginner-friendly framework with great routing and authentication
MySQL – Handles complex database relationships easily
Bootstrap 5 – Build a clean UI without spending time on CSS
Blade Templates – Dynamic templating that feels natural in PHP

The 3 Biggest Challenges (And How I Solved Them)

Database Design

Problem: Connecting Doctors, Patients, Appointments, and Prescriptions without breaking things.

Solution: I learned about Laravel relationships (hasMany, belongsTo) and spent time planning my schema before coding. This saved me from major refactoring later.

Lesson: Plan your database first. It's harder to change later.

Authentication & Authorization

Problem: Different users (Admin, Doctor, Receptionist) need different dashboards and permissions.

Solution: Used Laravel's built-in middleware and route guards to check user roles before showing data.

Lesson: Never trust the frontend for security. Always validate on the backend.

Getting Real-Time Statistics

Problem: The dashboard needed to show live counts of doctors, patients, appointments, etc.

Solution: Used Laravel's query builders and Eloquent to aggregate data efficiently, then displayed it with simple JavaScript.

Lesson: Database queries matter. Bad queries slow down your app fast.

Here's What It Looks Like

Dashboard

Managing Doctors

Patients Overview

Appointments Management

Labs Management

Medication Management

Key Lessons for Beginners

Start with a real problem – Don't build random projects. Build something that solves a real need.
Plan before coding – Spend 30 minutes sketching your database. It saves hours later.
Use the framework's tools – Laravel has authentication, routing, and validation built-in. Use them instead of reinventing the wheel.
Test locally first – Make sure features work before pushing to production.
Document your code – Future you (and contributors) will thank you.

Check It Out

Want to see the full code, contribute, or just browse around?

GitHub: github.com/adventureibtisam111/meditrack

If MediTrack helped you learn something or you find it useful, I'd love your support:

⭐ Star the repo – Shows other developers it's helpful

Drop feedback – Issues and suggestions are welcome

[Sponsor my work] (https://github.com/sponsors/adventureibtisam111) – Helps me build more educational projects like this

That's it! Building MediTrack taught me that full-stack development isn't magic—it's just solving problems step by step.

If you're learning Laravel or building your first full-stack project, I hope MediTrack inspires you. Let me know if you have questions or want to collaborate!

Happy coding!

Building "Dev Wrapped" in 3 Days: A daily.dev Hackathon Project (API + LLM + OG Images)

Mon, 25 May 2026 11:50:06 +0000

daily.dev ran a 3-day hackathon (May 20–23, 2026) opening up their Public API. I built Dev Wrapped — Spotify Wrapped, but for your daily.dev reading history. This post walks through how I shipped it, what choices I made, and what I'd do differently.

Live demo: https://hackathon-one-eta.vercel.app

The product
Paste your daily.dev Personal Access Token → get back a shareable card showing:

Total articles read in the timeframe
Top 5 tags with article counts
Top 3 sources
Reading rhythm (peak day / peak month)
An AI-generated "developer persona" — a 2–4 word archetype name with a one-sentence blurb
A permalink with a dynamic OG image for social sharing

The architecture
The whole thing is intentionally simple, because 5-day projects fall apart when you over-engineer:
User → React/TypeScript frontend (PAT input)

 → Vercel serverless function (generate)
       → daily.dev Public API (fetch reading history)
       → Stats engine (compute top tags, sources, rhythm)
       → Groq LLM (generate persona, JSON-constrained output)
       → Store result keyed by short ID
 → Redirect to /wrapped/{id}
 → Dynamic OG image rendered server-side
 → Share button (pre-filled tweet)

No database in the traditional sense. No auth system. No user accounts. PAT in → result out → never stored.
Design decisions worth talking about
PAT auth eliminates 80% of the work. The user brings their own daily.dev credential. I never have to build login, sessions, OAuth, or a user table. One API call uses their PAT, then it's discarded. This pattern is wildly underused for demo and hackathon projects.
Strict JSON output from the LLM. The persona prompt ends with: "Return ONLY valid JSON in this exact format, no markdown, no preamble." The schema is { personaName, personaBlurb }. Two upsides: trivial parsing with JSON.parse(), and the output structure is enforced. If the LLM fails to return valid JSON (rare), I fall back to a generic persona rather than crashing.

We Didn't Ask for AI That Does Tasks. We Asked for AI That Remembers.

Sat, 23 May 2026 09:15:27 +0000

This is a submission for the Gemma 4 Challenge: Write about Gemma 4

Every AI assistant I have used starts the same way.

A blank input field. No memory of yesterday. No idea who you are, what you have been working on, or why you are here. Every session, you explain yourself from scratch. Every session, the context you built up — the decisions, the dead ends, the reasoning — vanishes the moment you close the window.

We accepted this as normal. I no longer think it is.

The Problem Is Not Intelligence. It Is Amnesia.

The current generation of AI assistants is remarkably capable. They reason, they write, they debug. But they are stateless by default — each conversation an island, disconnected from the one before it.

This creates a hidden cost that we rarely talk about. Not the cost of compute, or latency, or accuracy. The cost of re-explaining yourself, every single day.

If you work with an AI assistant regularly, you know the feeling:

"As I mentioned before..."
"To give you some context, I am working on..."
"We already decided that we would..."

You are not talking to a partner. You are filling in a form. Every time.

The gap is not capability. It is memory.

What I Built to Think in Parallel

To explore this problem, I built g4-nexus — a parallel persona engine powered by Gemma 4.

Instead of asking one model one question, g4-nexus runs three specialized worker personas simultaneously, then a fourth leader synthesizes their outputs into a single integrated response. The workers — Mochi (emotion), Jun (logic), Uruu (analysis) — run in parallel via asyncio.gather. The leader, Koyomi, holds the whole picture and responds.

What this unlocked was surprising. Not just speed, but perspective. A single model gives you an answer. g4-nexus gives you a conversation between angles — emotional grounding, logical structure, and critical observation — all at once.

But after running it for a while, I noticed something.

g4-nexus could think in parallel. It could not remember across time.

Every session, Mochi had no idea what we worked on yesterday. Jun had no memory of the decisions we made last week. Koyomi could synthesize beautifully in the moment, but the moment always ended. The slate was always wiped clean.

The thinking was there. The memory was not.

Why Memory Is the Missing Half

There is a difference between an AI that processes and an AI that knows you.

Processing is impressive. But knowing you — knowing your project's history, the choices you made and why, what worked and what didn't — that is what makes the difference between a tool and a partner.

Consider what a real collaborator remembers:

What you tried last week and why it didn't work
The decision you made that you later regretted
The thing you said offhand that turned out to be important
The context that makes today's question make sense

None of that lives in a single conversation. It lives in accumulated time.

Gemma 4's small, steerable models make it practical to run multiple specialized instances locally. But the deeper opportunity they unlock is not just parallel thinking — it is persistent identity. A small model that stays on, that accumulates context, that writes its own notes and reads them back the next morning.

What Comes Next

g4-nexus is the first half. The second half is memory.

We are moving toward a system where each persona maintains:

Session logs — what happened today, in the persona's own words
Handover notes — what the next session needs to know
Morning briefings — auto-generated summaries written overnight, ready before the first message
Memory files — accumulated context that persists across weeks, not just minutes

Not cloud memory. Local memory. Files on disk, readable and inspectable. Owned by the user, not by a platform.

The direction is this: AI shouldn't just respond to you. It should remember you. It should carry yesterday into today, and today into tomorrow. Not as a feature — as the foundation.

A Different Question

We have spent years asking: how do we make AI smarter?

The better question might be: how do we make AI remember?

Intelligence without memory is impressive at a party. It cannot build anything with you over time. It cannot be trusted with a project, a relationship, a long-term goal — because it forgets you the moment the session ends.

The hardware exists. The models exist. Gemma 4's small, local models make it accessible without cloud infrastructure or enterprise budgets. What remains is the architecture — the discipline of writing memory down, carrying it forward, and letting it accumulate into something that feels less like a tool and more like a presence that has been with you.

That is what I am building toward.

GitHub: pepepepepepo/g4-nexus
Build track article: I Built a 4-Persona Parallel AI Engine with Gemma 4

AI Developer | API Integration | Full Stack - Updated my portfolio website

Mon, 11 May 2026 15:07:35 +0000

AI Automation and Agents Developer building intelligent systems and modern web applications. Passionate about machine learning, deep learning, and creating next-gen autonomous agents.

I am a self-taught AI Automation and Agents Developer from Remote. I build intelligent systems, chatbots, and modern web applications with blockchain integration. My expertise includes Machine Learning, Deep Learning, NLP, Smart Contracts, Web3 development, and Full-Stack Web Development with React, Next.js, Node.js, Solidity, and Python. I specialize in creating decentralized applications (dApps), DeFi solutions, and autonomous AI agents. Currently building next-gen AI Agents and JARVIS-like Personal Assistants. Code is poetry, AI is the canvas.

I rebuilt my developer portfolio — focused on systems that scale

Fri, 01 May 2026 21:23:47 +0000

Hey everyone! I’ve been refining my portfolio to better reflect the kind of work I enjoy most: building reliable, scalable systems and clean user experiences.

Portfolio: https://chris-dev.netlify.app/

What you’ll find:
• Real-world projects (not just tutorials)
• Backend-heavy work (Go, Laravel)
• Frontend with Vue / modern tooling
• Focus on performance, structure, and maintainability

I’m currently exploring new opportunities where I can contribute to meaningful systems and continue growing as an engineer.

If you’re working on something interesting or think I could be a good fit for your team, feel free to reach out I’d love to connect.

Also open to feedback from fellow devs

Your Personal Website Is Losing You Opportunities — Here's How to Fix It

Wed, 29 Apr 2026 15:35:30 +0000

Most developer portfolios look fine. Clean layout, dark theme, GitHub links, maybe a splash of green terminal aesthetic. And yet — silence. No recruiter emails, no client inquiries, no speaking invites.

The problem usually isn't the design. It's the architecture of decisions behind it.

It's a Decision System, Not a Gallery

When someone lands on your personal site, they're not admiring your work — they're running a quick risk assessment: Is this person relevant to my problem? Do I trust their capability? Is it worth my time to reach out?

If those three questions aren't answered within the first screen, even genuinely strong work gets ignored.

The fix starts before you touch a template. Define one specific objective for your site this quarter. Not "look professional" — something measurable, like "get discovery calls from early-stage startup founders" or "land a senior frontend role at a product company." That anchor makes every copy and layout decision obvious.

The First Screen Is Doing Too Little

Audit your hero section right now. Does it say:

Who you help (not just your job title)
What outcome you drive (not just your tech stack)
What to do next (one clear CTA, not five links)

A line like "I help product teams improve activation through conversion-focused UX" communicates more trust in 10 words than a three-paragraph bio does in 300.

Broad labels like "Full-Stack Developer" or "Creative Engineer" are resume language. Your website visitor needs decision language.

Portfolio ≠ Evidence

A grid of project screenshots is not proof. Proof is context: what was the problem, what was your specific contribution, what changed as a result?

For each project, write three things:

1.The constraint or challenge
2.Your key decision
3.The measurable or observable outcome

That format turns a gallery into a case study — and case studies convert browsers into clients or hiring managers into advocates.

One CTA Per Page. That's It.

The most common conversion killer on developer portfolios is CTA competition. GitHub, LinkedIn, email, resume download, blog, "let's chat" — all on the same screen.

Pick one primary action per page. Everything else becomes secondary or disappears. Visitors who don't know what you want them to do... leave.

Mobile Is Where Opportunities Actually Come From

Most portfolio traffic arrives via a LinkedIn message, a Twitter bio click, or a Slack DM — all mobile contexts. If your site loads slow or your CTA is buried below the fold on a phone, you're losing the warmest leads.

Test on a real device, not just Chrome DevTools. Load it on a slow 4G connection. That experience is the real first impression for a significant chunk of visitors.

For a deeper breakdown of structuring each page as a conversion layer — including offer pages, testimonial design, and 30-60-90 day execution planning — this high-performance personal website strategy guide is worth the read.

The short version: your site should answer "can this person solve my problem?" within seconds. If it can't, everything else is noise.

What's the one thing on your portfolio you'd change first? Drop it in the comments.

Your Portfolio Is Probably Missing This One Thing (And It Matters More Than You Think)

Tue, 28 Apr 2026 12:05:57 +0000

A lot of developers spend weeks building portfolios.

They add:

Projects ✅
Skills section ✅
GitHub links ✅
Nice UI ✅

And still…

It doesn’t stand out.

Why?

Because many portfolios are missing one thing that matters a lot:

Context.

Or more specifically:

The story behind your projects.

And trust me…

This matters more than you think.

Most Portfolios Look Like This

Project Card 1
Project Card 2
Project Card 3

Tech stack:

React
Node.js
MongoDB

Looks good.

But there’s a problem.

It tells me what you built

Not:

Why you built it
What problem it solves
What challenges you faced

And that’s where strong portfolios become different.

Recruiters Don’t Just Want Projects

They want proof you can think.

A project title alone doesn’t show that.

Example:

❌ “Built Job Portal using MERN”

Okay…

But so what?

Now compare:

✅ Built a job portal solving fragmented job discovery for freshers, with search filters, role-based auth, and scalable backend APIs.

Very different signal.

One shows code.

One shows engineering thinking.

What Your Portfolio Should Include

For every serious project, add:

1. Problem Statement

What problem were you solving?

Not:

“I built a chatbot”

Instead:

“I built a chatbot to simplify candidate support queries.”

Huge difference.

2. Architecture Thinking

Show how you designed it.

Talk about:

Frontend
Backend
Database
APIs
Deployment

Now you sound like a builder.

Not just a coder.

3. Challenges You Faced

This is massively underrated.

Talk about:

Bugs you solved
Scaling issues
Performance fixes
Deployment problems

Because real projects have struggles.

And solving them is experience.

4. Tradeoffs You Made

This is advanced… and powerful.

Example:

Used JWT instead of sessions because…

That shows decision making.

Recruiters love that.

5. Live Demo + Proof

Please…

Don’t just show GitHub.

Show:

Live demo
Screenshots
Demo video
README
Use cases

A project people can try > a repo people may never open.

Projects Don’t Impress.

Project Thinking Impresses.

Read that again.

Anyone can clone a project.

Not everyone can explain:

Why it exists
Why it was designed that way
Why choices were made

That’s what makes portfolios memorable.

Common Portfolio Mistake

Many developers think:

More projects = better portfolio

Not always.

3 strong projects with depth
can beat

10 shallow projects.

Every time.

⚡ Think Product, Not Assignment

Don’t present projects like college submissions.

Present them like products.

Instead of:

“Task App”

Say:

“Task management tool built to solve team workflow tracking.”

Sounds completely different.

Because it is.

A Better Portfolio Formula

Try this:

Project + Problem + Architecture + Challenges + Demo

That combination is gold.

Final Thought

Most portfolios focus on showing code.

Great portfolios show thinking.

And in interviews…

Thinking often matters more.

So if your portfolio feels incomplete…

Maybe you don’t need another project.

You may just need better storytelling around the projects you already have.

And honestly…

That might be the missing piece

What do you think every developer portfolio should include?

Live demos?
Case studies?
Architecture diagrams?

Let’s discuss

Portfolio #Developers #SoftwareEngineering #WebDevelopment #BuildInPublic #CareerAdvice #GitHub

How a Professional Website Helps Small Businesses and Solopreneurs Reach New Customers

Mon, 20 Apr 2026 17:20:45 +0000

How a Professional Website Helps Small Businesses and Solopreneurs Reach New Customers

"Your website is your storefront, your business card, and your sales pitch all rolled into one."

By DevnDesPro · Stavanger, Norway · 4 min read

You have a great product. You deliver excellent service. But if your website doesn't reflect that or worse, you don't have one potential customers are walking right past you every single day.

In today's digital world, getting your website right can be the difference between struggling for clients and having a steady stream of them.

The Hard Truth: First Impressions Happen Online

Before a customer calls you, emails you, or walks through your door they Google you.

Studies show that it takes less than 3 seconds for a visitor to form an opinion about your website. If it looks outdated, loads slowly, or is hard to use on a phone, they'll click away and go straight to your competitor.

A professional website tells your visitors: "This business is real, trustworthy, and worth my time."

Why SMBs & Solopreneurs Can't Afford to Ignore This

Large companies have entire teams managing their digital presence. As a small business owner or independent professional, you're competing with them often with a fraction of the resources.

That's actually where a great website gives you an edge. A well-designed, fast, and SEO-optimized site lets you:

✅ Show up on Google when local customers search for your service
✅ Build instant credibility with visitors who don't know you yet
✅ Convert browsers into buyers with clear calls-to-action and smooth navigation
✅ Work for you 24/7 even when you're asleep or with another client

The playing field online is surprisingly level. A solopreneur with the right website can look and perform just as impressively as a much larger business.

What Makes a Website Actually Work for Your Business

Not all websites are created equal. A website that truly drives customers needs more than just good looks. Here's what matters:

1. Clean, Professional Design

Your design communicates your brand before a single word is read. Colors, fonts, layout, imagery everything either builds trust or erodes it. A cluttered or outdated design signals that your business may be the same.

2. Mobile-First Experience

More than 60% of web traffic comes from mobile devices. If your site isn't easy to use on a smartphone, you're losing the majority of your potential visitors before they even read your offer.

3. ⚡ Fast Loading Speed

Every extra second your site takes to load, you lose visitors. Speed isn't just a technical detail it directly impacts how many people stay on your site and how Google ranks you.

4. Search Engine Optimization (SEO)

A beautiful website that nobody can find is just an expensive digital brochure. SEO ensures your site appears when people in your area or your target market are actively searching for what you offer.

5. Clear Calls-to-Action

What do you want visitors to do? Call you? Book a service? Buy a product? Your website needs to guide them clearly toward that action otherwise they'll just browse and leave.

6. ✍️ Content That Speaks to Your Customer

Your website copy should speak directly to your ideal customer's problems and needs not just list what you do. When visitors feel understood, they're far more likely to reach out.

⚠️ Common Mistakes Small Businesses Make With Their Website

Even well-intentioned business owners fall into these traps:

Mistake	Why It Hurts
Using a free DIY website builder	Looks generic, ranks poorly on Google
Skipping mobile optimization	Losing 60%+ of visitors immediately
Not updating the site regularly	Looks abandoned, loses trust
No clear contact path	Interested visitors can't take action
No SEO strategy	Competitors dominate while you rely on word-of-mouth

⚡ Any one of these can quietly cost you customers every single week.

The ROI of a Great Website

Think of your website as an investment, not an expense. A well-built site can:

Generate leads and inquiries around the clock
Reduce the time you spend on back-and-forth sales conversations
Build your reputation before you even speak to a prospect
Open doors to customers far beyond your immediate local network

For solopreneurs especially, a strong website can be the single most powerful tool for growing income without growing your workload.

Real Businesses, Real Results

Consider what a proper website can do across different fields:

Business Type	Result
️ Personal Trainer	Attracts new clients by ranking for "personal trainer in [city]" on Google
Freelance Photographer	Showcases portfolio and gets booked without cold outreach
Small Accounting Firm	Wins clients away from bigger competitors through online credibility
☕ Local Restaurant or Café	Fills tables through Google searches, reviews, and an attractive online menu

In every case, the website isn't just a nice-to-have it's an active part of the business.

Where Do You Start?

If you're a small business owner or solopreneur who knows your online presence needs work but you're not sure where to begin the answer is simple:

Work with people who do this every day.

You don't need to learn web design. You don't need to figure out SEO from scratch. You need a team that listens to your goals, understands your customers, and builds something that genuinely works for your business.

Ready to Turn Your Website Into a Customer-Generating Machine?

At DevnDesPro, we specialize in helping small businesses and solopreneurs build websites that don't just look great they bring in real customers.

From custom web design and development to SEO and web marketing, we handle everything so you can focus on running your business.

Based in Stavanger, Norway serving clients worldwide.

Visit devndespro.com and let's build something that works for you →

© DevnDesPro · Web Design · Web Development · SEO · Digital Marketing · Stavanger, Norway

I turned Telegram into a WordPress control panel — ShopKeeper v1.2.0

Thu, 16 Apr 2026 22:22:29 +0000

ShopKeeper v1.2.0 is out. Here's what it does and why it's different from every "WordPress management" tool you've seen.

The premise:
Most WordPress tools give you another dashboard. ShopKeeper gives you a chat interface that acts on your site — no clicking, no navigating menus.

What's in v1.2.0:

Comments — fully automated
• List by status (hold/spam/approved)
• Delete, approve, spam-mark individually
• Bulk delete spam with a single confirmation

Plugins — full control
• See every plugin: name, version, status, pending updates
• Update, activate, deactivate from chat

Themes — overview added
• All themes listed with active status

Updates engine — proactive detection
• Surfaces pending updates before you have to ask

The interaction model is different:

The bot doesn't wait for you to check a dashboard.
It tells you: "3 plugins need updates. Handle all of them?"
You say yes. Done.

Built with:
Telegram Bot API + WordPress REST API + Node.js

Open to feedback on what to tackle next. What part of WordPress management is most annoying to you?

Your Personal Website Is Underperforming — And It's Not a Code Problem

Tue, 14 Apr 2026 18:13:40 +0000

Let's get something out of the way first.

If you're a developer reading this, your personal website is probably technically solid. Clean code, fast load times, good Lighthouse scores, maybe even a slick custom animation or two. The stack is fine. The deployment pipeline is fine.

But if it's not generating real opportunities — job offers, freelance inquiries, collaboration requests, speaking invitations — the problem almost certainly isn't technical.

It's architectural. And not the kind of architecture you're used to thinking about.

The Real Stack Problem

Most developer personal sites are built in this order:

Pick an interesting tech stack (Next.js, Astro, SvelteKit,
whatever's trending)
Build something technically impressive
Add content as an afterthought
Wonder why nobody reaches out

The irony is brutal. Developers who can build anything often end up with websites that communicate the least — because the energy goes into implementation, not into the clarity layer that actually converts visitors into opportunities.

Here's the mental model shift: your personal website is not a technical project. It is a communication system that happens to be built with code.

What the Clarity Layer Actually Looks Like

A high-converting personal website — regardless of stack — answers three questions in the first ten seconds:

WHO: Who is this person and what do they specialize in?
WHAT: What outcomes do they create?
NEXT: What should I do right now?

That's it. That's the whole homepage job in pseudo-code.

Most developer sites fail the WHO and NEXT checks immediately. The identity statement is either too vague ("full-stack developer passionate about building things") or buried below a massive hero animation that looks great but communicates nothing. And the CTA? Usually either missing entirely or lost somewhere at the bottom after three scrolls of project thumbnails.

Proof Architecture for Developers

Here's where it gets interesting from a systems perspective. Proof — the thing that makes visitors trust you enough to reach out — needs to be placed architecturally, not just included somewhere on the page.

Think of it like middleware in a request pipeline:

Visitor lands → Identity check → Value prop → [PROOF LAYER] → CTA → Conversion

Most sites skip the proof layer entirely or inject it at the wrong point — after the CTA, where it's useless. Proof needs to intercept hesitation before the ask, not after.

For developers specifically, proof doesn't have to be testimonials. It can be:

Open source contributions with visible impact metrics
A GitHub profile with genuine activity (not just green squares)
A concise case study: problem → your approach → measurable outcome
Writing that demonstrates depth of thinking on a specific technical
topic
Conference talks or technical articles with real engagement

The format matters less than the placement and specificity.

Your Blog Is an Asset — If You Build It Right

Many developers run a technical blog alongside their portfolio. Most of those blogs plateau early — not because the writing is bad, but because the architecture is wrong.

Publishing frequency without structure is just noise generation. What actually compounds over time is a layered content system:

Pillar topics → Define 3-5 areas where you want to be known Cluster content → Specific posts addressing targeted questions within each pillar Evergreen anchors → Deep-dive guides that keep generating search traffic and referrals

Without this structure, readers consume one post and exit. With it, they move through your content ecosystem, build trust over multiple sessions, and eventually reach out when they have a problem that matches your expertise.

Internal linking is the routing logic of this system. It's the thing most developer blogs completely ignore, and it's one of the highest-leverage improvements you can make to an existing blog with minimal effort.

The Portfolio Section Is Not a Gallery

This is where most developer sites get it wrong.
A portfolio is not a showcase of everything you've ever built. It is a decision-support tool for a specific visitor with a specific need.

Curate ruthlessly. Show 4-6 projects maximum on the homepage. For each one, include:

Context: What problem were you solving?
Your role: What specifically did you build or decide?
Outcome: What measurably changed as a result?

That three-part structure turns a project thumbnail into actual evidence. Visitors understand your thinking process, not just your output. That's what makes someone pick up the phone.

Performance Metrics That Actually Matter

If you're tracking your personal site, here's what's worth measuring:

javascript
const metricsActuallyWorthTracking = {
  CTAClickRate: "Are visitors reaching your primary action?",
  InquiryQuality: "Are contacts from the right people for the right reasons?",
  ReadDepth: "Are visitors reading past the first screen?",
  ReturningVisitors: "Are people coming back?",
  ConversionToConversation: "How many contacts become real conversations?"
}

const metricsToStopObsessingOver = {
  PageViews: "Vanity metric without context",
  BounceRate: "Misleading without session depth data",
  SocialShares: "Rarely correlates with opportunity quality"
}

Resources Worth Reading

Three guides that approach this from a content and strategy angle — useful precisely because they're not about the technical implementation, which you've already got covered:

The Great Personal Websites Guide breaks down homepage framework, credibility architecture, and CTA logic with a practical 30-day optimization plan. Good for auditing what you already have.

The Best Personal Blog Websites guide for 2026 covers content architecture, voice positioning, and how to build a blog that compounds over time rather than plateaus. Directly applicable if you're running a technical blog.

And this breakdown of 15 personal brand sites that actually work is useful for pattern recognition — seeing how the same clarity principles appear across totally different visual styles and professional contexts.

The TL;DR

bash
# Run this audit on your personal site

clarity_check() {
  echo "Can a visitor answer these in 10 seconds?"
  echo "1. Who are you and what do you specialize in?"
  echo "2. What outcomes do you create?"
  echo "3. What should they do next?"
}

proof_check() {
  echo "Is your proof placed BEFORE the CTA?"
  echo "Is it specific and outcome-focused?"
  echo "Does it match what your target visitor actually cares about?"
}

portfolio_check() {
  echo "Are you showing 4-6 curated projects?"
  echo "Does each include context, role, and outcome?"
  echo "Can a visitor understand your thinking — not just your output?"
}

clarity_check && proof_check && portfolio_check
# If any check fails — fix that before touching the code again

Your personal website is the one platform you fully own. Make it work as hard as your code does. ️

"You Wouldn’t Steal a DIV": How I Built My Portfolio

Tue, 14 Apr 2026 11:50:00 +0000

A story about how I built my portfolio and what went through my mind while building it

Hello, World! Here's my first ever blog.

I wanted to talk a bit about my portfolio, how I built it, why I made some of these architectural and design decisions, and why I shamelessly 'borrowed' my way to designs I love.

1 Stack, 2 Stack, Tech Stack, 4

(If you didn't read that header in Slim Shady's voice, I don't know what to tell you.)

First of all, let's talk tech stack. I used to have all of my personal projects (including my previous portfolio) built with Next.js. These were small side projects, without complicated logic, and with simple needs. Yet, I would always run into Next.js edge cases. Turbopack was failing my dev builds because it wouldn't play nice with Contentlayer, HMR was taking actual seconds to refresh, and production builds were taking 50 seconds for projects that barely scaled. When I got to choose a stack for a new project at my job, I couldn't justify the Next.js overhead for production apps, considering the friction I had with small personal projects.

At that time, everyone was talking about Tanstack Start: the "DX God." But even their starter app had linting and TS issues, so I wasn't fully impressed. I stuck with only Tanstack Router for that project, and as weeks passed by working with the entire Tanstack Ecosystem (except Start), I was really enjoying it. The documentation is well written and extensive (even too much sometimes), DX actually made sense, and I could find all of the features I liked about Next.js (file base routing for example) while still having great performance (15s builds).

So this led me to give a second chance to Tanstack Start, and I built this portfolio with it! I still love Vercel's UX, and wander around their dashboard to see how I should implement my stuff, but I think I'll leave Next.js behind for now. And personal projects are made to experiment with stuff. So I just want to try out different tech and see what I like or not, purely on feelings.

Then for the component library, I was really into coss ui. I stumbled upon it randomly one day and loved it so much. My Nathan's AI project already had a UI heavily inspired by cal.com: send button, message suggestions... So when I saw they had a shadcn/ui library with that kind of style, it was perfect for what I needed.

I can also consider myself a proud Open Source Contributor after getting two PRs merged into coss ui (a 2-line diff and I'm not even kidding, but quality over quantity, I guess...?).

Stealing...I Mean, Getting Inspired By Chanhdai and Zed

Now I'm not going to lie and say I designed and coded everything myself. I took large parts of the code and page layout from the open-source portfolio by Chanhdai and design inspiration from zed.dev, which I had previously attempted in unfinished side projects (https://trends.brodin.dev and https://ui.brodin.dev if they're still available).

I still went a different way than Chanhdai for the code implementation. For example, I chose to store my content in markdown files using Content Collections. I did this specifically so I could easily serve my portfolio's content in plain text, perfect for LLM consumption, which ties right back into the needs of my Nathan's AI project.
I also used Base-ui (because of coss ui) for components, and generally went with a different style. So this was not just a simple copy/paste or a fork, there was still a lot of work involved.

For Zed, I took the same fonts for the headings and text, and the grid layout with the "diamonds" at the intersections. It really adds personality to my portfolio (not my personality since I stole it, but some personality).

Also, by a great coincidence, Chanhdai had very basic sound design, like a sound when changing the theme, and I wanted to push things further by having different sounds around the entire app. I was looking around on the web for good sound libraries and all, but couldn't find anything interesting. Then the next day, I saw a tweet about the upcoming release of Soundcn, which was exactly what I was looking for. So now you get a bunch of sounds when clicking on stuff in my portfolio. It's a nice touch!

From good to WHOA

Lastly, the thing that elevated my portfolio from a good portfolio to a Whoa portfolio are the dither shaders (from Paper Shaders) that I have for page headings and section dividers. I had dither shaders in mind since the first day I saw them on React Bits, but couldn't find a good way to integrate them. So it ended up being a crossover between inspiration from the heading of zed.dev (open the dev console and see data-paper-shader on the headings) and Fumadocs, which had them as well.

To wrap things up

So in conclusion, I would say this portfolio is a cross between Chanhdai and Zed, with a better stack.

Go ahead, click around to hear the sound integration (it gets annoying after a while, be careful), check out the dither shaders on the headings, and check out the source code here if you want to steal from me like I did from everyone (but at least leave a star on the repo).

Blog Title reference: This classic: "You Wouldn't Steal a Car"
My Portfolio: brodin.dev
Initially posted on my blog

Rethinking My Portfolio as a Developer

Mon, 13 Apr 2026 19:26:03 +0000

I’ve been redesigning my portfolio recently, and one thing became very clear to me:
A lot of developer portfolios are built to look nice, but not necessarily to help visitors understand what we actually do.

For a long time, I treated my portfolio like a place to put:

My tech stack
some projects
a bit about me
contact links

But while working on the redesign, I started asking myself a different question:

If someone lands on my site, will they immediately understand how I can help them?

That changed how I started thinking about the whole site.

I’m a full-stack developer, and over the years, I’ve worked on web apps, mobile apps, backend systems, hospitality software, booking engines, admin panels, and product ideas of my own.

The problem is, when you do many things, it becomes easy for your portfolio to feel scattered.

You know your work.
You know the effort behind each project.
You know the technical decisions, the tradeoffs, the debugging, the late changes, the small wins.

But the person visiting your site does not know any of that.

They just want quick answers:

Who are you?
What do you build?
Have you built something similar before?
Can you actually help with my project?

That’s what I’m trying to improve now.

Instead of making the site feel like a resume, I want it to feel more like a clear and honest introduction to my work.

I want the site to show:

What I build
The type of businesses I can help
the kind of problems I’ve solved
and the best way for someone to reach out if they have an idea or a project

I’m also trying to make it more personal.

Not “personal” in the sense of adding random details, but personal in the sense that the site should actually feel like me:
someone who likes building practical products, solving real business problems, and creating software that is useful, maintainable, and scalable.

I’m also exploring adding a guided chatbot/lead form to the site so visitors can describe what they need, explore relevant services or projects, and contact me more easily.

That feels much closer to what I want the portfolio to do:
not just exist, but actually start conversations.

This redesign has reminded me that a portfolio is not only about showing work.

It is also about making your work understandable.

Still a work in progress, but I’m enjoying the process.

What’s one thing you think most developer portfolios get wrong?

Portfolio: https://manthanbhatt.dev/

The Anthology of a Creative Developer: A 2026 Portfolio

Mon, 13 Apr 2026 18:13:28 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI (just check my github, not for prizes )

The Prologue: Beyond the "Sectioned Resume"

Most portfolios feel like a list of ingredients. For 2026, I wanted mine to be the complete meal.

I’m Nitish Kumar, an undergraduate engineering student and creative developer. I’ve always felt that code is just another way of storytelling—so I ditched the typical "Hero-About-Projects" grid. Instead, I built a narrative experience that reflects how I think, build, and observe the world.

The Gallery

I built this to be "authored"—a stroll through a digital gallery rather than a scroll through a resume.

Explore the Story: https://nitishkr.fun

The Craft (How I Built It)

If this portfolio were a book, here is how I bound the pages:

The Technical Spine

Next.js (App Router): The foundation that holds the chapters together.
TypeScript: My editor, ensuring every "sentence" (and variable) makes sense.
GSAP: The cinematography—adding subtle, intentional motion that guides the eye.
Tailwind CSS: For the editorial aesthetic and spacing.
Cloud Run: My printing press, keeping everything fast and accessible.

The Editorial Vision

I treated the design like a high-end magazine. Each section is a chapter:

Identity: The "Who" and the mindset.
The Workshop: Skills and tools as a craftsman’s kit.
The Lab: Projects as experiments, not just finished products.
The Lens: Using photography as a reflection of how I observe UI/UX in the real world.

Google AI: The Creative Director

Google AI wasn't a "generator" for me; it was a thinking partner. I used it to:

Refine the Copy: Helping me transition from dry technical descriptions to narrative-driven prose.
Accessibility Review: Ensuring the "story" remains readable for everyone.
Logic Soundboarding: Using AI to brainstorm the best way to structure a chapter-based layout.

The "Director's Cut" (What I'm Proud Of)

Story-Driven Flow: The site feels like a single, continuous conversation.
Intentional Dark Mode: Designed from the ground up to feel like a premium "night-time" reading experience.
The Power of Restraint: Knowing when to stop adding features and start refining the white space.
Photography Integration: My photos aren't just "assets"—they are windows into my perspective as a designer.

Closing Thoughts

This portfolio is my way of proving that engineering is an art form. It’s about more than just shipping code; it’s about crafting experiences that linger.

Thanks for checking it out, and Happy New Year!

Let's connect!

Big Tech killed 7 tools used by 500 million people. I rebuilt all of them in one platform

Wed, 08 Apr 2026 13:57:56 +0000

https://sentinel.oblivionzone.com/about
https://sentinel.oblivionzone.com/

The Graveyard of the Open Web
Every product we revived, when it died, and who it left behind.

Google Reader
2005 → killed July 1, 2013 · 8 years old

The web's universal RSS aggregator. 30 million+ active users at death. Google killed it citing "declining usage" while subscriber counts were still growing. RSS subscriptions have grown 34% per year since the murder. Feedly, Inoreader, NewsBlur exist but none replicate Google Reader's clean simplicity — and none use AI. SENTINEL Reader is what Google Reader would have become.

⚡ Yahoo Pipes
2007 → killed September 30, 2015 · 8 years old

The original visual no-code automation builder, before Zapier existed. 90,000+ active pipes at shutdown. Let anyone connect feeds, transform data, and build mashups in a browser. When Yahoo killed it the entire no-code-automation category died for 5 years. Zapier filled the gap but is closed-source and expensive. SENTINEL Pipes brings back open, visual, free workflow automation on n8n.

❓ Yahoo Answers
2005 → killed May 4, 2021 · 16 years old

The internet's biggest open Q&A platform. 200 million+ users. The Internet Archive preserved a 4.75 TB dump of every question and answer ever asked. When Yahoo pulled the plug, Quora became a paywall and Stack Exchange covers only narrow technical topics. The general open Q&A web is empty. SENTINEL Q&A is the AI-augmented replacement: ask anything, AI answers instantly, humans add expertise.

DMOZ / Open Directory Project
1998 → killed March 17, 2017 · 19 years old

The Open Directory Project. 5 million sites, 92,000 volunteer editors, 1 million categories. The largest human-edited web directory ever built — used by Google, Yahoo, AOL, Netscape, and every major search engine for 19 years to bootstrap their rankings. AOL silently killed it in 2017. The complete RDF dump still exists. SENTINEL Directory is rebuilt on top of DMOZ data with AI-powered category suggestions and modern moderation.

Yahoo Directory
1994 → killed December 31, 2014 · 20 years old

The original Yahoo. Before Yahoo was a portal, it was Jerry and David's hand-curated directory of websites — the very first navigation layer of the World Wide Web. By the time Marissa Mayer killed it, the directory cost $299 per submission. SEO professionals still mourn it: a Yahoo Directory listing carried more authority than any backlink today. SENTINEL Directory restores curated web discovery — free, AI-assisted, human-verified.

Delicious
2003 → murdered repeatedly until 2017 · 14 years of slow death

The original social bookmarking site. 5.3 million users at peak. Yahoo bought it in 2005, neglected it, sold it to AVOS in 2011, who sold it to Science Inc in 2014, who sold it to Pinboard in 2017 — Pinboard's sole purpose for the acquisition was to kill it. Pocket got Mozilla'd to death. Raindrop is closed-source. SENTINEL Bookmarks is open social bookmarking with AI tagging.

⬡ iGoogle
2005 → killed November 1, 2013 · 8 years old

Personalized homepage with widgets — weather, news, calendar, RSS, Gmail preview, stock tickers — all on one customizable dashboard. Tens of millions of daily users. Google killed it citing "modern apps" but no replacement ever delivered the same one-glance overview. Netvibes survives but feels frozen in 2010. SENTINEL Dashboard is iGoogle done right: every module on one screen, AI-prioritized.

Uptime Kuma — never killed, never hosted
2021 → present · open source, 62,000+ GitHub stars

The best open-source uptime monitor in the world. Self-hostable, beautiful, free. But nobody offers a hosted version. Pingdom charges $15/month, UptimeRobot's free tier is severely capped, StatusCake is enterprise-priced. There is a massive gap for "Uptime Kuma but you don't have to run a server." SENTINEL Monitor fills it.

Full Stack Portfolio Website — Complete Step-by-Step Breakdown

Tue, 07 Apr 2026 19:28:47 +0000

Introduction

In this blog, I will walk you through my Full Stack Portfolio Website, explaining every section, feature and design decision in a structured, real-world approach.

This is not just a simple portfolio — it is designed like a complete product, including multiple pages, modern UI/UX, smooth animations and practical functionality.

Project Goal

The goal of this project was to:

Build a professional portfolio
Apply real-world frontend architecture
Improve UI/UX design thinking
Create a scalable and maintainable structure

The website starts with a clean navigation bar that allows users to smoothly navigate between all sections.

Key Features:

Smooth scrolling navigation
Active section highlighting
Responsive design for mobile

Home Section (Hero Section)

The Home section is the first impression of the website.

Features:

Animated role titles (Frontend Developer, UI/UX Designer, etc.)
Profile image with animated tech icons
WhatsApp contact button
Resume download option
Social media links

This section is designed to quickly communicate:

Who I am
What I do
How to contact me

About Section

The About section explains my developer journey, mindset, and skills.

Focus Areas:

Problem-solving mindset
Clean coding practices
Continuous learning

Projects Section

This is one of the most important sections of the portfolio.

Features:

12+ real-world projects
Each project includes:
- Live preview
- GitHub link
- Description

This section demonstrates practical experience and skills.

Skills Section

Skills are categorized for clarity and better presentation.

Experience Section

This section highlights my internship experience.

Included:

Multiple internships
Roles and responsibilities
Contributions and learning

It adds professional credibility to the portfolio.

Education & Certifications

This section includes:

IT Diploma
Ongoing BS (IT)
Professional certifications

Shows both academic and practical learning.

Achievements & Testimonials

Achievements:

Project milestones
Internship highlights

Testimonials:

Client-style feedback
Builds trust and credibility

Services Section

This section defines what I offer professionally.

Services:

Web Development
WordPress Development
UI/UX & Design

Structured like real service pages.

Blog Section

This is an advanced feature of the portfolio.

Includes:

Real developer blogs
Learning experiences
Technical insights

Helps in personal branding and SEO.

Contact Section

The contact section includes a fully functional form.

Features:

Email-JS API integration
Working contact form
Social links

Users can directly send messages.

Dark Mode & UI Enhancements

Modern UI features included:

Dark mode toggle
Custom cursor
Smooth animations
Scroll-to-top button

These features improve user experience.

Folder Structure & Development Approach

The project follows a clean and scalable structure.

Approach:

Component-based thinking
Organized assets
Clean naming conventions

This makes the project maintainable and scalable.

Performance & Optimization

Key optimizations:

Fast loading speed
Responsive design
Optimized assets

Ensures smooth user experience across devices.

What I Learned

Through this project, I improved:

UI/UX design
Project structuring
Performance optimization
Real-world development workflow

Watch Full Video Walkthrough

YouTube Video:

[https://youtu.be/XcyAGuaVp_E?si=xUuDt5YaEqvDBxFb]

Project Links

Live Website:
https://yasirawaninfodev.vercel.app/

GitHub Repository:
https://github.com/YasirAwan4831/arch-technologies-internship-task-1-portfolio-website

Final Thoughts

This portfolio is more than just a project — it represents my learning journey, growth and consistency as a developer.

Building this helped me understand how real-world applications are structured and delivered.

More projects, blogs and tutorials are coming soon.

Thanks for reading!

UPDATE: I built a side project that turns GitHub profiles into 3D solar systems

Wed, 25 Mar 2026 18:07:12 +0000

Claim Your Domain in the Stack Universe

Have you ever wondered what your GitHub profile would look like as a 3D solar system? We've been building Stack Universe to answer that exact question. Today, we're excited to share some major updates that bring your digital cosmos to life!

Your Universe, Your Identity

One of the core features of Stack Universe is the ability to "Claim Your Universe." By signing in with GitHub, you can now:

Customize your Central Star: Choose a color that reflects your coding personality.
Write your Origin Story: Add a custom Universe Bio that appears both in the 3D scene and on your profile card.
Pin your Best Repos: Select up to 3 repositories to orbit your star as "planets," showcasing your most important work.

Take Your Universe anywhere with the NEW Embed Widget

We wanted you to be able to show off your custom universe directly in your GitHub README. Our new Animated SVG Embed is a high-performance, pixel-perfect card (540x200px) that features:

Live Orbit Animations: Your pinned repositories rotate in real-time.
Pulsing Stars & Glow Effects: A premium visual layout that matches the full 3D app.
Detailed Stats: Your Universe Score and repo count, all in one sleek card.

Build the Multiverse with Us

Stack Universe is all about visualizing the incredible impact of developers around the world. Whether you're a Python enthusiast (yellow star!) or a TypeScript wizard (cyan star!), your universe is unique.

Check out your universe today: https://stack-universe.vercel.app

Let us know what your Universe Score is in the comments!

Getting Started with Bun: The Fast All-in-One JavaScript Runtime

Sat, 14 Mar 2026 18:21:10 +0000

The JavaScript ecosystem has traditionally relied on multiple tools:

Node.js for runtime
npm/yarn/pnpm for package management
Webpack/Vite for bundling
Jest/Mocha for testing

But modern development demands speed, simplicity, and fewer tools.

This is where Bun comes in.

Bun is an all-in-one JavaScript runtime designed to replace many tools in the modern development stack while being extremely fast.

In this guide, you'll learn:

What Bun is
Why developers are switching to it
How to install and run your first app
Best practices for using Bun in real projects

What is Bun?

Bun is a JavaScript runtime + toolkit built for performance.

Unlike traditional setups where you install many tools separately, Bun includes:

JavaScript runtime
Package manager
Bundler
Test runner
Task runner

All inside one tool.

Bun is written in Zig and uses the JavaScriptCore engine.

This combination makes it significantly faster than traditional Node workflows in many scenarios.

Why Developers Are Excited About Bun

Bun focuses on developer experience and performance.

Key advantages:

Extremely Fast Package Installation

Instead of downloading packages repeatedly, Bun caches them efficiently.

Example:

bun install

This often runs 2–10x faster than traditional package managers.

Built-in Tools

With Bun you don’t need to install:

separate bundlers
separate test frameworks
extra script runners

One command handles most tasks.

TypeScript Support Out of the Box

Bun runs TypeScript without additional configuration.

Example:

bun run index.ts

No build step required.

Installing Bun

Install Bun using a single command:

curl -fsSL https://bun.sh/install | bash

After installation, verify:

bun --version

If you see a version number, Bun is ready.

Creating Your First Bun Project

Create a new project:

bun init

This generates a project structure like:

my-bun-app
 ├─ bun.lockb
 ├─ package.json
 ├─ index.ts
 └─ node_modules

Bun automatically configures the project.

Running Your First Script

Create index.ts:

console.log("Hello from Bun!");

Run the file:

bun run index.ts

Output:

Hello from Bun!

Bun executes TypeScript without transpiling manually.

Installing Packages

Bun works with the existing npm ecosystem.

Install a dependency:

bun add axios

Install dev dependency:

bun add -d typescript

Remove a package:

bun remove axios

Bun also creates a fast lockfile:

bun.lockb

Running Scripts

Scripts inside package.json work the same way.

Example:

{
  "scripts": {
    "dev": "bun run index.ts"
  }
}

Run:

bun run dev

Building HTTP APIs with Bun

Bun includes a built-in HTTP server.

Example API server:

Bun.serve({
  port: 3000,
  fetch(req) {
    return new Response("Hello from Bun API!");
  },
});

Run:

bun run server.ts

Open:

http://localhost:3000

This creates a high-performance API server with minimal code.

Running Tests with Bun

Bun includes a built-in test runner.

Create a test:

import { expect, test } from "bun:test";

test("addition works", () => {
  expect(2 + 2).toBe(4);
});

Run tests:

bun test

No additional frameworks required.

Bundling with Bun

Bun also works as a bundler.

Example:

bun build index.ts --outdir=dist

This bundles your project for production.

Best Practices for Using Bun

To get the most from Bun, follow these practices.

1. Use Bun for Development Tooling

Bun works extremely well for:

CLI tools
development servers
local utilities
build scripts

It can replace many Node-based tooling scripts.

2. Start Small

If you're migrating from Node.js, start with:

side projects
internal tools
microservices

Avoid migrating large production systems immediately.

3. Use Bun with Modern Frameworks

Many frameworks already support Bun.

Examples include:

Next.js
Vite
SvelteKit

Bun can run development servers faster.

4. Use Built-in Features First

Instead of installing extra libraries:

Use Bun’s built-in tools:

testing
bundling
server runtime

This keeps your stack simpler and faster.

5. Keep Compatibility in Mind

Although Bun supports most Node packages, some Node APIs may behave differently.

Before adopting Bun in production:

test dependencies
check compatibility
review build tools

When Should You Use Bun?

Bun is excellent for:

new JavaScript projects
backend APIs
developer tooling
TypeScript applications
high-performance scripts

It may not yet be ideal for:

legacy Node projects
systems depending on complex Node APIs

Bun vs Node.js (Quick Comparison)

Feature	Bun	Node.js
Runtime	JavaScriptCore	V8
Package Manager	Built-in	npm/yarn
Bundler	Built-in	External tools
Test Runner	Built-in	Jest/Mocha
Speed	Very fast	Stable but slower

Final Thoughts

Bun represents a new direction in the JavaScript ecosystem.

Instead of combining many tools, Bun provides a fast, unified developer experience.

For developers building modern applications with TypeScript, APIs, and tooling, Bun can significantly simplify your workflow while improving performance.

If you haven’t tried it yet, Bun is definitely worth exploring.

Writing Code That Future You Won’t Hate

Sat, 14 Mar 2026 13:10:19 +0000

Every developer has experienced this moment.

You open a project you wrote months ago, scroll through the code, and suddenly think: “Who wrote this mess?”

Then it hits you.

You did. Do not act surprised. Yes YOU .

Writing code that works today is easy. Writing code that is still understandable six months from now is much harder. As projects grow and teams scale, maintainability becomes just as important as functionality.

The goal isn’t just to make the code run it’s to make sure future you (or your teammates) can read, modify, and debug it without frustration.

In this guide, we’ll explore practical strategies for writing clean, maintainable code that your future self will appreciate.

Why Writing Maintainable Code Matters

Software rarely stays “finished.” Most codebases evolve constantly with:

New features
Bug fixes
Performance improvements
Security updates

Poorly written code slows down all of these processes. Developers spend more time trying to understand code than actually writing new logic.

Maintainable code helps teams:

Fix bugs faster
Onboard new developers quickly
Scale systems efficiently
Reduce technical debt

In short, writing clean code today saves countless hours tomorrow.

1. Write Code for Humans First

Computers only care that the code runs. Humans care whether it makes sense.

Readable code is one of the most valuable skills a developer can develop.

For example:

x = a * b - c

Technically correct but unclear.

A better version might look like:

final_price = product_price * quantity - discount

Now anyone reading the code immediately understands what it does.

Clear variable names, descriptive functions, and logical structure make a huge difference in long term maintainability.

2. Keep Functions Small and Focused

Large functions often hide complexity and make debugging difficult.

A good rule of thumb is that each function should do one thing well.

Bad example:

processUserData()

Inside this single function you might find:

input validation
database queries
API calls
logging
response formatting

This makes the function difficult to test and maintain.

Instead, break logic into smaller components:

validateUserInput()
saveUserToDatabase()
sendWelcomeEmail()

Smaller functions are easier to understand, test, and reuse.

3. Avoid Clever Code That Nobody Understands

Developers sometimes write clever one liners that look impressive but confuse everyone else.

Example:

const result = arr.reduce((a,b)=>a+b);

While concise, overly compressed code can reduce readability.

Clarity should almost always win over cleverness.

Future maintainers including yourself will thank you for writing code that is easy to follow.

4. Document the “Why,” Not the “What”

Comments are useful but only when they explain something meaningful.

Avoid comments that simply repeat what the code already says.

Bad comment:

// increment counter
counter++

Instead, explain why something exists, especially when the logic is not obvious.

Better comment:

// Retry API call because the payment gateway occasionally returns transient errors

Good comments provide context that code alone cannot explain.

5. Organize Your Project Structure

Even well written code becomes difficult to maintain when it’s scattered across poorly structured directories.

A clear project structure helps developers quickly find what they need.

For example:

src/
  controllers/
  services/
  models/
  utils/
tests/
config/

Consistent folder organization improves collaboration and reduces confusion across teams.

6. Write Code That Is Easy to Debug

Future debugging is inevitable, so make it easier.

Helpful practices include:

meaningful error messages
structured logging
defensive checks
clear exception handling

Example:

Instead of this:

raise Exception("Error")

Use:

raise ValueError("Invalid email format provided during registration")

Specific errors save time when diagnosing issues later.

7. Reduce Technical Debt Early

Technical debt is the result of quick fixes that were never cleaned up.

Common examples include:

duplicated code
unused variables
temporary workarounds
outdated dependencies

Occasional refactoring keeps code healthy.

You don’t need to chase perfection but ignoring technical debt for too long can make systems difficult to maintain.

8. Write Tests for Critical Logic

Automated tests act as safety nets for future changes.

When developers update a feature, tests confirm that existing functionality still works.

Even simple tests can dramatically improve long term reliability.

Testing helps developers:

refactor safely
detect regressions early
build confidence when modifying old code

Future you will appreciate having a safety net.

9. Think Like the Next Developer

Before committing code, ask yourself a simple question:

“Would someone unfamiliar with this code understand it quickly?”

If the answer is no, consider improving:

naming
structure
comments
function organization

Your goal isn’t just to finish tasks it’s to leave the codebase in a better state than you found it.

Final Thoughts: Write Code Like Someone Will Maintain It (Because They Will)

Every developer eventually becomes the “future maintainer” of their own code.

The difference between a painful debugging session and a smooth update often comes down to how the code was written in the first place.

Clean, maintainable code isn’t about perfection. It’s about making thoughtful decisions that prioritize readability, structure, and clarity.

Write code that solves today’s problem but also respects tomorrow’s developer.

And more often than not, that developer will be you.

If you found this helpful, share it with your team or bookmark it for your next code review. Small improvements in coding habits can lead to dramatically better software over time.

Deploying a React/Vite App on Google Cloud Storage + CDN: A Faster and 10× Cheaper Alternative

Tue, 10 Mar 2026 15:09:29 +0000

Modern frontend frameworks like React, Angular, and Vite produce static assets after building the project. These assets include HTML, CSS, JavaScript, and images. Since they are static, they do not require a server runtime like Node.js to serve them.

Many developers initially deploy these apps on Google Cloud Run, but that approach often introduces unnecessary complexity and cost. A much better option is deploying the static build to Google Cloud Storage (GCS) with Cloud CDN.

This article explains why Cloud Storage + CDN is faster, cheaper, and simpler, and how you can deploy your frontend application in minutes.

Why Cloud Run is Not Ideal for Static Frontends

Cloud Run is designed for containerized backend applications. When you deploy a React or Vite app there, you typically run a Node server such as serve or nginx to deliver static files.

This creates several inefficiencies:

• You pay for container compute time
• Containers need to start and scale
• Cold starts can slow down responses
• Infrastructure is more complex than necessary

For applications that only serve static assets, using a compute service is unnecessary.

Why Google Cloud Storage + CDN is Better

Google Cloud Storage can serve static files directly, while Cloud CDN caches those files at edge locations worldwide.

Benefits include:

1. Much Lower Cost

Cloud Storage only charges for storage and bandwidth, not compute time. For most frontend apps, this can reduce costs by up to 90% compared to Cloud Run.

2. Global Edge Performance

Cloud CDN caches your assets across Google's global edge network. Users download files from a location close to them, significantly improving load times.

3. Simpler Infrastructure

There are no containers, Dockerfiles, or runtime environments to manage. You simply upload files.

4. Automatic Scalability

Static hosting with CDN scales automatically to millions of requests without configuration.

Architecture Overview

The deployment architecture looks like this:

User → Cloud CDN → Google Cloud Load Balancer → Cloud Storage Bucket

Static files are stored in the bucket, while CDN nodes cache frequently accessed files.

Step 1: Build Your Application

If you're using Vite or React, generate the production build.

npm run build

This creates a folder such as:

dist/

or for CRA:

build/

This folder contains all files required to host the application.

Step 2: Create a Cloud Storage Bucket

Create a bucket that will host the static files.

gcloud storage buckets create gs://my-react-app-bucket \
  --location=us-central1

Step 3: Make the Bucket Public

Allow public access so users can retrieve the assets.

gcloud storage buckets add-iam-policy-binding gs://my-react-app-bucket \
  --member=allUsers \
  --role=roles/storage.objectViewer

Step 4: Upload the Build Files

Upload the contents of your build folder.

For Vite:

gcloud storage cp -r dist/* gs://my-react-app-bucket

For Create React App:

gcloud storage cp -r build/* gs://my-react-app-bucket

Step 5: Configure the Website Entry Point

Set the default page to index.html.

gcloud storage buckets update gs://my-react-app-bucket \
  --web-main-page-suffix=index.html \
  --web-error-page=index.html

This ensures React Router works correctly by redirecting unknown routes to index.html.

Step 6: Enable Cloud CDN

For production-grade deployments, place the bucket behind a Cloud Load Balancer with Cloud CDN enabled.

Benefits include:

• Global caching
• HTTPS support
• Custom domains
• Faster asset delivery

While optional for small projects, CDN is highly recommended for real-world applications.

Cost Comparison

Typical monthly cost for a medium frontend application:

Cloud Run Deployment

• Compute charges
• Container startup time
• Networking overhead

Estimated cost: $10–$30/month

Cloud Storage + CDN Deployment

• Storage for assets
• Bandwidth usage only

Estimated cost: $1–$5/month

When You Should Use Cloud Run Instead

Cloud Run is still the right choice when your application includes:

• Backend APIs
• Server-side rendering (Next.js SSR)
• Authentication services
• AI or database integrations

In these cases, compute is required.

Final Thoughts

If your application is a pure frontend build, deploying it on Cloud Run is unnecessary. Hosting the build on Google Cloud Storage with Cloud CDN is simpler, faster, and significantly cheaper.

By eliminating containers and compute layers, you can deliver your application globally with minimal infrastructure while benefiting from Google’s edge network.

For most React, Angular, and Vite applications, Cloud Storage + CDN is the optimal production deployment strategy.

Redesigend whole portfolio from scratch

Thu, 12 Feb 2026 08:34:09 +0000

Recently redesigned my entire portfolio from scratch.

This wasn’t just a UI refresh. I rebuilt it with a stronger focus on how I actually approach software development: building interactive, performance-driven, and experience-focused products. I paid extra attention to smoother animations, cleaner navigation flow, and making each section feel intentional rather than just informational.

The goal was simple: turn the portfolio from a project list into a product-like experience that reflects how I think, design, and engineer solutions.

I’m treating this as a living project, so I’m actively looking for honest feedback, criticism, and ideas that could push it further.

Check it out here: https://www.sayoun.studio/

Would really appreciate your review, especially around UX, performance, storytelling, or anything that feels confusing, unnecessary, or missing.

How I Built a React Portfolio in 7 Days That Landed ₹1.2L in Freelance Work

Tue, 10 Feb 2026 03:00:00 +0000

If you are a React developer stuck in tutorial hell with no real portfolio, this walkthrough is for you.

In this article, I’ll break down how I built a React portfolio website with Vite and Tailwind CSS that helped me land ₹1.2L+ in freelance projects in under three weeks. No paid tools, no over‑engineered stack just a clean, fast portfolio that real clients could open and understand.

Step 1: Set up a Vite + React project

Instead of Create React App, I went with Vite because it is extremely fast and lightweight for React projects.

Run these commands:

npm create vite@latest my-portfolio -- --template react
cd my-portfolio
npm install
npm run dev

Your development server should start at http://localhost:5173. Once it is running, clear out the default content in App.jsx so you can start from a blank slate.

Step 2: Configure Tailwind CSS

Tailwind handled all the styling for this project, and getting the config right early made customization much easier.

Install Tailwind and its dependencies:

npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init -p

Update tailwind.config.js to scan the right files:

export default {
  content: [
    "./index.html",
    "./src/**/*.{js,ts,jsx,tsx}",
  ],
  theme: {
    extend: {
      colors: {
        primary: '#3b82f6',
        dark: '#1e293b',
      },
      fontFamily: {
        sans: ['Inter', 'sans-serif'],
      },
    },
  },
  plugins: [],
}

Then add the Tailwind directives to src/index.css:

@tailwind base;
@tailwind components;
@tailwind utilities;

At this point, you can start using Tailwind utility classes directly in your JSX.

Step 3: Build reusable components

To move fast, I leaned heavily on component‑driven design. One of the core building blocks was a ProjectCard component that I reused for each portfolio project.

const ProjectCard = ({ title, description, tech, liveUrl, githubUrl, image }) => {
  return (
    <div className="bg-dark rounded-xl shadow-md overflow-hidden flex flex-col">
      {image && (
        <img
          src={image}
          alt={title}
          className="h-48 w-full object-cover"
        >
      )}
      <div className="p-6 flex-1 flex flex-col">
        <h3 className="text-xl font-semibold text-white mb-2">
          {title}
        </h3>
        <p className="text-slate-300 mb-4">
          {description}
        </p>
        <div className="flex flex-wrap gap-2 mb-4">
          {tech.map((t, i) => (
            <span
              key={i}
              className="px-3 py-1 text-xs rounded-full bg-slate-800 text-slate-200"
            >
              {t}
            </span>
          ))}
        </div>
        <div className="mt-auto flex gap-3">
          {liveUrl && (
            <a
              href={liveUrl}
              target="_blank"
              rel="noreferrer"
              className="text-sm font-medium text-primary hover:underline"
            >
              Live Demo
            </a>
          )}
          {githubUrl && (
            <a
              href={githubUrl}
              target="_blank"
              rel="noreferrer"
              className="text-sm font-medium text-slate-300 hover:underline"
            >
              GitHub
            </a>
          )}
        </div>
      </div>
    </div>
  );
};

You can then use ProjectCard in your main page or a Projects section by passing in different props for each project.

Step 4: Deploy to Vercel in minutes

Once the portfolio was ready, I pushed the code to GitHub and deployed with Vercel.

Basic steps:

Push the repository to GitHub.
Go to vercel.com and sign in with GitHub.
Click Import Project and select your portfolio repo.
Vercel automatically detects Vite just click Deploy.

Vercel gives you a URL like yourname.vercel.app. You can later attach a custom domain from the project settings; I used a .tech domain for a professional look.

If you prefer Netlify, you can run npm run build and drag‑and‑drop the dist folder into Netlify’s UI both options are free and include SSL.

Step 5: Portfolio layout that actually converts

You can see the live portfolio at dtechsolutions.tech. Here is the structure that helped me convert visitors into paying freelance clients:

Hero section: A clear headline such as “Full‑Stack Developer specializing in React + Node.js” plus a concise subheading and a primary CTA.

3 - 4 strong projects: Focus on a handful of solid, deployed projects with live demos and GitHub links.

Tech stack badges: Visual tech tags or icons (for example with react-icons) so clients quickly understand what you use.

Contact form: I used Formspree for contact handling without needing a custom backend.

Tech stack used

React 18
Vite 5
Tailwind CSS 3
Vercel (deployment)
Formspree (contact form)
GitHub (version control)

This stack was enough to ship fast, iterate quickly, and still look professional to clients.

Pros and cons of this stack
text
| Pros | Cons |
| --------------------------------------------- | -------------------------------------------- |
| Tailwind utility classes speed up styling | Initial learning curve for Tailwind syntax |
| Component reusability saves a lot of time | Dark mode requires custom setup |
| Vite dev server is extremely fast | Smaller ecosystem compared to Next.js |
| Free deployment on Vercel/Netlify with SSL | Client-side rendering only (limited SEO) |
| Mobile responsiveness is easy to achieve | Larger CSS bundle than handcrafted CSS |
From zero portfolio to paid gigs
Within about two weeks of making the portfolio public, I started getting actual freelance work:

On Reddit (subreddits like /r/forhire and /r/webdev), I landed a couple of gigs by replying to “looking for developer” posts with my portfolio link.

On LinkedIn, I shared the portfolio with #opentowork and relevant tech hashtags, which led to multiple projects.

Typical project sizes ranged from ₹30K for simpler landing pages to ₹50K+ for dashboards and more complex builds.

Clients particularly liked that they could click a live link and interact with the projects instead of just seeing GitHub repositories.

Practical tips for Indian freelancers
If you are targeting Indian clients specifically, these points helped me:

Quote in rupees initially: For early projects, starting around ₹20K - ₹30K for smaller builds works well; raise rates as you collect testimonials.

Use your time zone as a feature: Promise quick responses and same‑day iterations for IST‑based clients.

Know local payment flows: Show that you can integrate Razorpay/UPI or other Indian payment gateways.

Mention local hosting experience: If clients care about data locality or compliance, highlight any work with Indian hosting providers.

Be visible on LinkedIn: Founders and decision makers are very active there comment on their posts, share your work, and keep your profile updated.

Final thoughts
You do not need an overcomplicated stack or months of planning to start getting freelance work. A simple combination of React, Tailwind, and Vercel was enough for me to go from no portfolio to real paid projects in a matter of weeks.

Focus on shipping a functional, honest portfolio, then refine it as you learn from real client feedback. Your first freelance opportunity might be just one deployed React portfolio away and if you are curious, you can check out mine here: https://www.dtechsolutions.tech/.

Building My Personal Portfolio Website: Design, Decisions and Growth

Tue, 20 Jan 2026 18:32:01 +0000

Building My Personal Portfolio Website: Design, Decisions and Growth

Over the past few days, I’ve been actively working on my personal portfolio website—not just as a showcase of projects, but as a reflection of my learning journey, mindset and growth as a developer.

This portfolio is being built with a clear goal in mind: clarity, simplicity and strong first impressions.

Why I Decided to Rebuild My Portfolio

A portfolio is often the first interaction someone has with a developer. I wanted mine to clearly answer three questions:

Who am I as a developer?
What skills do I bring to the table?
How do I approach design and user experience?

Rather than overloading it with animations or unnecessary complexity, I chose to focus on clean structure, readable content and purpose-driven design.

Design & UI Approach

My primary focus was on keeping the interface modern yet minimal. I paid close attention to:

Layout hierarchy to guide the user naturally
Typography for readability and balance
Spacing and alignment for a clean visual flow

The hero section plays a key role here—it sets the tone of the entire website and delivers the core message within seconds.

Screenshot Placement:

Technical Perspective

From a technical standpoint, I focused on building a structure that is:

Responsive across different screen sizes
Easy to maintain and extend
Cleanly organized for scalability

The goal wasn’t just to make something that looks good but something that is practical, efficient and future-ready.

Challenges & Learnings

While working on this portfolio, I faced many big and small but important challenges—especially around layout consistency and responsive behaviour. Solving these helped me better understand:

How small UI decisions impact overall UX
The importance of testing designs across devices
Writing cleaner more reusable code

Each section I complete adds more clarity—not just to the website but to my own development process.

What’s Next

This is still a work in progress. Upcoming improvements include:

Additional sections with more detailed content
Performance optimizations
Refining responsiveness and accessibility

I believe in building in public, sharing progress honestly and improving step by step.

Final Thoughts

This portfolio is more than a personal website—it’s a snapshot of where I am right now as a developer and where I’m heading next.

Still building. Still improving. One section at a time.

If you’re also working on your portfolio or learning web development, I’d love to hear about your experience.

Connect With Me & View Related Posts

LinkedIn: https://www.linkedin.com/in/yasirawan4831

Medium: https://medium.com/@YasirAwan4831

All Links: https://yasirawan4831.github.io/futuristic-links-dashboard/

_#WebDevelopment #Portfolio #FullStackDeveloper #WebDevelopement #BuildingInPublic #MuhammadYasir #YasirAwan4831
_

Portfolio Perfection: 16 Developers Who Nailed Their Personal Brand

Fri, 18 Jul 2025 09:48:55 +0000

16 Developer Portfolios That Will Make You Rethink Your Personal Brand

Building a developer portfolio in 2025 isn't just about showcasing code. It's about telling your story, demonstrating your problem-solving approach, and creating an experience that potential employers or clients won't forget. After spending countless hours browsing through developer portfolios, I've found 16 that truly stand out from the crowd.

1. Ouassim: When Less Really Is More

Ouassim's portfolio proves that you don't need flashy animations or bold colors to make an impact. His clean, typography-focused design creates a sophisticated experience that puts the spotlight exactly where it should be: on his work. The monochromatic color scheme feels intentional rather than boring, and the subtle animations add just enough movement to keep things interesting.

What makes it work:

Navigation that feels effortless
Case studies that actually tell a story
Looks great whether you're on desktop or mobile

2. Jahir Fiquitiva: Material Design Done Right

If you've ever wondered what happens when someone truly masters Material Design, look no further than Jahir's portfolio. The vibrant colors and smooth transitions don't just look good. They create an experience that feels intuitive and polished. You can tell he genuinely cares about user experience.

What caught my attention:

Projects you can actually interact with
Clear breakdown of what technologies he used
Dark/light mode toggle that doesn't feel like an afterthought

3. Theodorus Clarence: Your Professional Journey as a Story

Theodorus has created something special here. Instead of the typical "here are my projects" approach, his portfolio feels like reading through someone's professional evolution. The way he integrates his personal story with his technical achievements creates a connection that most portfolios miss entirely.

Why it works:

Animations that enhance rather than distract
Personal narrative woven throughout
Project presentations that feel fresh and engaging

4. Bona Brian Siagian: A Visual Feast

Bona's portfolio is what happens when exceptional design skills meet solid development chops. Every project presentation feels like a mini-experience, complete with 3D previews and multimedia case studies. It's ambitious without being overwhelming.

Standout elements:

3D project previews that actually add value
Rich multimedia storytelling
Seamless blend of design and development work

5. Lee Robinson: Impact Over Everything

Lee's portfolio reflects his journey from engineer to executive at Vercel, and it's refreshingly honest about what actually matters in tech careers. Instead of trying to impress with flashy designs, he focuses on the impact he's had. For example, helping grow Next.js to over 1.3 million developers.

What sets it apart:

Clean design that prioritizes content
Focus on measurable impact and achievements
Personal touches that don't feel forced
Emphasis on shipping quickly and effectively

6. Marc Bouchenoire: Simplicity That Works

Marc's approach is refreshingly straightforward. His portfolio doesn't try to reinvent the wheel. It just executes the basics exceptionally well. Sometimes that's exactly what you need.

Strengths:

Interface that gets out of your way
Project descriptions that are actually useful
Fast loading times (seriously, try it)

7. Victor Eke: Breaking the Rules

Victor's portfolio feels like a playground, but in the best possible way. The creative interactions and playful elements demonstrate his technical skills while showing his personality. It's bold without being unprofessional.

Creative touches:

Navigation that surprises without confusing
Project presentations with personality
Consistent branding throughout

8. Ryan Aulia: Modern Without Being Trendy

Ryan has managed to create something that feels contemporary without chasing every design trend. The smooth scrolling effects and modern typography create an experience that feels polished and professional.

Design highlights:

Scrolling that enhances the experience
Typography choices that actually improve readability
Skills section that doesn't feel like a resume

9. Vijay Verma: When Design Meets Development

Vijay's portfolio successfully bridges the gap between design and development. Each project feels carefully crafted, with detailed process documentation that shows how he thinks through problems.

What makes it special:

Projects that showcase both design and code
Process documentation that's actually interesting
Interactions that feel natural

10. Raphaël Chelly: Technical Depth

Raphaël's portfolio goes deeper than most. The technical explanations and personal insights create a picture of someone who doesn't just code, but thinks deeply about the craft of software development.

Unique approach:

Technical breakdowns that teach you something
Personal growth story that feels genuine
Blog integration that adds real value

11. Daniel Wirtz: More App Than Website

Daniel's portfolio challenges what a portfolio website can be. It feels more like interacting with an application than browsing a static site, which perfectly demonstrates his skills as a developer.

Innovation highlights:

Interactive demonstrations that work
Technical explanations that aren't boring
User interactions that feel purposeful

12. David Darnes: Attention to Detail

David's portfolio shows what happens when someone sweats the small stuff. Every element feels intentional and carefully considered, creating an overall experience that feels polished and professional.

Design philosophy:

Details that most people would miss
Layout that guides your attention naturally
Project documentation that's actually comprehensive

13. Håvard Brynjulfsen: Scandinavian Simplicity

Håvard's portfolio embodies everything good about Scandinavian design: it's clean, functional, and beautiful without being showy. The minimalist approach creates focus rather than emptiness.

Why it works:

Layout that doesn't waste your time
Navigation that makes sense immediately
Project presentations that get to the point

14. Alexander Vilinskyy: Visual Storytelling

Alexander uses compelling graphics and smooth interactions to create a visual journey through his professional experience. It's the kind of portfolio that makes you want to scroll through the entire thing.

Standout features:

Visuals that actually communicate something
Smooth scrolling that enhances the story
Personal branding that feels authentic

15. Chánh Đại: The Complete Package

Chánh's portfolio brilliantly showcases his dual skills as both a Software Developer and UI/UX Designer. It's comprehensive without being overwhelming, which is harder to achieve than it sounds.

What works:

Clear presentation of diverse skills
Case studies that show his process
Professional storytelling that doesn't feel corporate

16. Josh W. Comeau: Teaching Through Showcasing

Josh's portfolio goes beyond showcasing. It's an interactive learning experience. The detailed explanations and engaging demonstrations reflect his commitment to education and technical excellence.

Remarkable features:

Code demonstrations you can actually interact with
Tutorials that make complex concepts accessible
Personal narrative that draws you in

Conclusion

These portfolios represent something more than just good design or clean code. They show developers who understand that a portfolio is really about communication. It's about communicating your skills, your personality, and your approach to solving problems.

The best portfolios from this list share a few common elements: they tell a story, they show personality, and they demonstrate both technical and design thinking. Most importantly, they create an experience that makes you want to learn more about the person behind the work.

Your portfolio is often the first impression you make on potential employers or clients. Make it count by focusing on what makes you unique, not what you think everyone else wants to see.

Note: The web is constantly evolving, and what impresses today might be standard tomorrow. The key is to keep experimenting and finding new ways to tell your story.

Solque

Sun, 06 Jul 2025 19:27:30 +0000

I built a portfolio site… and accidentally turned it into a full-blown experience.

Started with: “Just a simple personal website.”
Ended with: “What if I add a galaxy simulation, interactive games, and enough effects to cook a device?”

● What’s inside:

Animated backgrounds powered by Three.js
A full-on mini-game section (because why not?)
Dynamic viewing modes depending on how you visit
Animations everywhere (like, everywhere)

→ Is it over-engineered? Yep.
→ Is it fun? Absolutely.
→ Is it stable? Depends on your device

Still polishing performance and squashing bugs (mobile users, I see you).
Built with React, Three.js, and an unhealthy amount of late-night energy.

I'm open to work — freelance, remote, or full-time.

Got feedback? A wild idea? Something crazy you think belongs in here?
What are you waiting for? Let’s connect!
GitHub: sailwalpranjal

A Web App to Showcase all your GitHub Projects

Mon, 06 May 2024 07:46:17 +0000

Introducing Projects

Present all your projects in style with a super customizable web app! ✨

Projects uses the GitHub API to list all your GitHub projects in a nice searchable grid.
Also shows pretty programming icons using devicons.

Inspiration

Needed a way to display all my projects, that should auto update from my GitHub

Getting Projects

To get projects, follow these steps:

git clone https://github.com/2kabhishek/projects
cd projects

Setup Your Own Projects

You can set up projects for yourself by following these steps:

Fork the repo: https://github.com/2kabhishek/projects
Clone it locally / Open it in GitHub Codespaces
Open up script.js and update the username variable to your GitHub username.
Open up index.html and update the title tag to make it your own.
You may also want to update the favicon by updating the link tag in index.html
Commit and push your changes
Go to repo settings on GitHub, under Pages enable GitHub Pages.
- Choose 'Deploy from a branch' with the main branch and / as the root directory.
Done!

The site should be live on https://<your-username>.github.io/projects

Number Of Repos

The number of repos shown changes with the maxPages variable, the GitHub API supports 100 repos per page max.
If you have less than 100 repos, set maxPages to 1, if you have 300 then 3.

You can also edit the fetch query to reduce the per page repo count.

There's no pagination, all repos show up on the same page.

Authenticated Requests

If you are working locally and notice the API is not sending over data, it might be because of rate limit on GitHub API requests.

You can either wait for an hour or setup a personal access token on GitHub and pass that into the fetch request in script.js

Forked Repos

To show forked repos set hideForks = false in script.js

Authenticated Requests

If you are working locally and notice the API is not sending over data, it might be because of rate limit on GitHub API requests.

You can either wait for an hour or setup a personal access token on GitHub and pass that into the fetch request in script.js

Themes

Comes with a dark and light theme by default, depends upon your system and browser settings.

Edit the variables under :root in styles.css to change color scheme.

Programming Language Icons

This project uses Devicon for adding language icons, if the language name and icon are not
displayed, for any of your repos, update devicons mapping in script.js.

How it was built

I built Projects using HTML CSS JavaScript and Neovim

What I learned

Learned about some quirks of the fetch API, during implementation of maxPages.
Revisited Flex, box-shadow and some other CSS tricks

Hit the ❤️ button if you found this useful.

projects repo