DEV Community: Ayman Atif

Why Most Local Business Websites Fail in 2026 (And How to Fix It)

Ayman Atif — Sun, 10 May 2026 21:05:38 +0000

Most local business websites do not fail because the business is bad.

They fail because the website silently pushes customers away.

A slow homepage.
An outdated design.
No clear call-to-action.
Poor mobile experience.
Weak trust signals.

The result?

Visitors leave without calling, booking, or filling out a form.

And in 2026, that problem is becoming more expensive than ever.

Search engines are smarter, users are less patient, and AI-powered search is raising expectations for website quality and structure. Recent industry reports show that slow websites, poor mobile usability, weak SEO structure, and missing trust elements are still among the biggest reasons local businesses lose rankings and conversions. ()

After reviewing dozens of local business websites across industries, I noticed the same mistakes appearing over and over again.

Here are the biggest ones.

1. The Website Looks Outdated

People judge websites incredibly fast.

If your website feels old, cluttered, or poorly designed, users subconsciously assume the business itself is outdated.

That means:

lower trust
fewer calls
fewer leads
higher bounce rates

Many local business websites still look like they were built years ago and never updated.

Modern websites need:

clear visual hierarchy
premium typography
clean spacing
responsive layouts
modern interactions
trust-focused sections

Design is no longer just “appearance”.

It directly affects conversion and credibility.

2. The Mobile Experience Is Terrible

Most local traffic now comes from mobile devices.

Yet many local business websites still:

load slowly on phones
have broken layouts
use tiny text
hide important contact buttons
feel frustrating to navigate

Studies and SEO audits continue to show that mobile usability problems are one of the biggest conversion killers for local businesses. ()

If users cannot quickly:

understand what you do
trust your business
contact you

they leave.

Fast.

3. There Is No Clear Conversion Flow

A surprising number of websites never clearly guide the user toward action.

You land on the homepage and ask:
“What am I supposed to do next?”

Good business websites guide users intentionally.

That means:

visible CTA buttons
clear service structure
trust-building sections
strategic contact placement
pricing clarity
strong visual hierarchy

Your website should function like a salesperson, not a digital brochure.

4. The Website Is Slow

This one quietly destroys both SEO and conversions.

Slow websites:

hurt rankings
increase bounce rates
reduce trust
lower conversions

Google increasingly prioritizes performance and user experience signals. Technical SEO experts continue to highlight slow loading speed, broken mobile experiences, and crawl issues as major ranking problems for local businesses. ()

Most local business websites become slow because they rely on:

bloated WordPress plugins
outdated themes
poor hosting
unoptimized assets

Modern frameworks and optimized architecture make a massive difference.

5. The Website Has Weak SEO Foundations

Many websites look decent visually but are almost invisible on Google.

Common local SEO problems include:

poor page structure
weak local targeting
missing schema markup
inconsistent business info
duplicate location pages
weak internal linking

Recent local SEO research shows these mistakes are still extremely common in 2026. ()

And now AI-powered search systems are making quality and structure even more important.

Businesses that optimize properly for modern search experiences are seeing stronger traffic and conversion performance. ()

6. The Website Does Not Build Trust

Trust is everything for local businesses.

Before someone contacts you, they ask:

Can I trust this company?
Are they professional?
Are they active?
Are they legitimate?

That is why modern business websites need:

testimonials
reviews
case studies
premium visuals
clean branding
strong About pages
professional pricing presentation

Without trust signals, even good traffic struggles to convert.

What Modern Local Business Websites Need in 2026

Modern local business websites should focus on:

speed
mobile-first UX
conversion structure
modern design
SEO foundations
trust-building
clear messaging
premium branding

The websites performing best today are no longer “simple business sites”.

They feel closer to modern SaaS products and premium agency experiences.

That shift is happening because users now compare every website to brands like Stripe, Linear, Apple, and Vercel.

Expectations are higher than ever.

The Solution

That is exactly why I built VERTEX LOCAL.

A premium Next.js website system designed for local businesses, freelancers, and agencies that want modern high-converting websites without starting from scratch.

Built with:

Next.js 16
TypeScript
Tailwind CSS v4
Framer Motion

It includes:

Home page
Services page
About page
Projects page
Pricing page
Blog system
Contact & booking UI
Premium dark-mode design system
Conversion-focused layouts
Reusable architecture

The goal was simple:

Build a local business website system that actually feels modern, premium, fast, and conversion-focused.

You can check it out here:

VERTEX LOCAL

Final Thoughts

Most local business websites are not losing because competition is impossible.

They are losing because their websites were never designed for modern user expectations.

The good news?

Most of these problems are fixable.

A faster, more modern, conversion-focused website can completely change how people perceive your business online.

And in 2026, perception matters more than ever.

Why Most Small Business Websites Never Get Traffic (And How I Solved It With Next.js)

Ayman Atif — Sat, 09 May 2026 18:35:55 +0000

Every day, thousands of small businesses launch new websites.

Most of them look decent.

But almost none of them get visibility.

No traffic.
No leads.
No Google rankings.
No discoverability.

And honestly, the problem usually is not the business itself.

The problem is the website foundation.

After spending months analyzing modern websites, I kept noticing the same issues everywhere:

Poor SEO structure
Slow performance
Weak page hierarchy
No sitemap setup
Generic layouts
Low conversion design
Bad mobile experience

Many websites are built to “exist”.

Very few are built to grow.

The Hidden Problem Most Developers Ignore

A lot of developers focus only on making the UI look good.

But visibility starts much deeper than visuals.

Search engines care about:

Structure
Speed
Metadata
Crawlability
Semantic hierarchy
User experience
Performance

Even AI-driven search systems are increasingly rewarding websites that are clean, structured, and easy to understand.

That means your website architecture matters more than ever.

Why I Started Using Next.js

As someone coming from a backend development background, I always preferred clean architecture and maintainable systems.

Frontend development often felt chaotic to me.

Then I discovered Next.js.

And surprisingly, it solved many of the problems I hated about frontend development:

Cleaner structure
Better organization
Easier scalability
Excellent performance
SEO-friendly rendering
Reusable architecture

Instead of fighting the framework, I finally felt productive building frontend applications.

*The Realization
*
I realized I was rebuilding the same SEO and marketing foundation every single time:

Hero sections
Landing pages
Metadata setup
Responsive sections
SEO configuration
Navigation
Footers
Conversion-focused layouts

The repetitive setup phase was consuming more time than actually building products.

So I decided to solve that problem once.

Building AquaFlow

I built AquaFlow as a modern SEO-ready Next.js template focused on one goal:

Helping developers and businesses launch websites that are already optimized for visibility, performance, and conversions.

Instead of starting from scratch every time, the template already includes:

Modern responsive sections
SEO-ready structure
Fast performance
Clean reusable architecture
Conversion-focused UI
Production-ready organization

The idea was simple:
Stop rebuilding the plumbing. Start building the actual product.

Why This Matters More in 2026

Search is changing fast.

Websites are no longer competing only for Google rankings.

They are competing for visibility across:

Google
AI search systems
ChatGPT recommendations
Perplexity
Search snippets
Local discovery

Structured, fast, well-organized websites now have a huge advantage.

Most businesses still underestimate this.

That creates a massive opportunity for developers who understand both:

clean architecture
modern SEO foundations

Final Thoughts

A beautiful website without visibility is just an expensive placeholder.

Modern websites need to:

load fast
rank properly
scale cleanly
convert visitors
support growth

That is exactly why I built AquaFlow.

If you are interested in seeing the template:

AquaFlow : SEO-Ready Next.js Template

I Built a Production-Ready ASP.NET Core + Next.js SaaS Boilerplate So You Don’t Have To

Ayman Atif — Fri, 08 May 2026 22:31:56 +0000

After building several SaaS products, I got tired of rewriting the same foundational code every single time: authentication, multi-tenancy, billing, tenant isolation, email templates, etc.

So I decided to package everything into ShipReady — a clean, modern full-stack SaaS boilerplate.

The Problem Every Solo Developer or Small Team Faces

You have a great idea.

You start building.

Two weeks later you’re still setting up:

User authentication & authorization
Multi-tenant database isolation
Stripe subscription management + webhooks
Tenant switching logic
Proper project structure and Clean Architecture

Sound familiar?

What is ShipReady?

ShipReady is a full-stack SaaS starter that combines:

Backend: ASP.NET Core (Clean Architecture + CQRS-ready)
Frontend: Next.js 15 (App Router, Server Actions, TypeScript)
Payments: Stripe integration (Subscriptions, Webhooks, Customer Portal)
Core Feature: Robust Multi-tenancy with proper data isolation
Modern Auth: Built with best practices (JWT + cookies or your preference)

Key Features

Complete multi-tenant architecture (tenant resolution middleware, scoped services, etc.)
Stripe billing fully integrated
Tenant management dashboard + switching
Clean, well-organized codebase with clear separation of concerns
Ready for production deployment
Live demo available

Tech Stack

Backend: .NET 8/9 + EF Core + Clean Architecture
Frontend: Next.js 15 + TypeScript + Tailwind
Database: SQL Server / PostgreSQL ready
Payments: Stripe
Authentication: ASP.NET Core Identity + JWT

See It in Action

I recorded a full walkthrough demo showing the project structure, how multi-tenancy works, and how fast you can get started.

[Watch the Demo Here] ← (embed your YouTube video)

Who is This For?

.NET developers who want a modern frontend without the headache
Solo founders or small teams building B2B SaaS
Anyone tired of starting every project from scratch

EarlyBird Launch Offer (Limited)

I’m running a 30% LAUNCH30 discount for the first 30 buyers.

Original price: $129.99

→ Get ShipReady here: https://yaman95.gumroad.com/l/shipready

Use code: LAUNCH30

Even if you don’t buy right now, I’d love your honest feedback. Drop a comment below — what’s the biggest pain point you face when starting a new SaaS project?

Happy shipping! 🚀

dotnet #aspnetcore #NextJS #SaaS #boilerplate #buildinpublic #csharp #webdev

Stop Rewriting AI Code. Start Building Real Stuff.

Ayman Atif — Thu, 07 May 2026 23:27:54 +0000

Let’s be honest for a second.

You sit down, open your editor, and ask your AI for some C# code. A few seconds later, it hands you a mess. Extra namespaces you didn’t ask for. Old patterns that don’t fit .NET 8. So much XML comment noise that you can barely find the actual logic.

So you sigh, delete half of it, and rewrite the rest.

That’s not saving time. That’s just a different kind of work.

I ran into this same wall for months. Then I found a small playbook that changed how I prompt entirely.

The Usual AI Frustration

C# and .NET developers have a unique problem. AI models are great at English, but they often learned from old Stack Overflow posts or outdated tutorials. They will happily write Entity Framework queries from 2017. They will add patterns you don't need. They will guess your .NET version wrong.

And the worst part? Long, fluffy prompts just burn through tokens. You end up paying more for code you have to fix anyway.

This is why the playbook 70+ Battle Tested AI Prompts for C# and ASP.NET Core caught my attention. It was clearly made by someone who actually builds production software.

What You Actually Get

The pack includes over 70 prompts split into 12 practical chapters. Not random theory. Things you use every day:

Architecture patterns like Clean Architecture, Vertical Slices, and DDD
EF Core 8 for queries, raw SQL, and compiled queries
Security with JWT, refresh tokens, and rate limiting
Modern APIs using Minimal APIs, gRPC, and versioning
Frontend work with Blazor components and SignalR
Testing with xUnit, integration tests, and snapshots
Performance using Span, multi-level caching, and memory debugging
DevOps covering Docker, GitHub Actions, and Azure Key Vault

There are also four bonus system prompts. You can turn your AI into a Senior Architect, a Security Auditor, a Legacy Code Expert, or a Code Reviewer. That alone is worth a lot.

Why This Pack Is Different

First, it saves you money. Each prompt includes a "Token Tip" that helps you strip out unnecessary words. The creator claims you can cut your token usage by 30 to 50 percent. Less noise means lower API bills.

Second, this is production ready. These are not clean textbook examples. They include real constraints like SemaphoreSlim for cache protection and batch backfilling for heavy loads. This is code that won't crash when traffic hits.

Third, every prompt was tested against GPT-4o, Claude 3.5, and GitHub Copilot. No guessing. No "it works in my head." Real verification.

Fourth, you learn how to prompt better. Beyond the templates, you get the "6 Golden Rules of .NET Prompting." It is a simple framework that stops you from ever writing a vague, bloated prompt again.

Who Is This For

This is for .NET developers using Copilot, Cursor, or ChatGPT who are tired of fixing AI mistakes. It is for tech leads who want consistent AI output across a team. And it is for freelancers who need to ship quality features fast without endless debugging.

You only need basic knowledge of .NET 8 and C#. In fact, working through these prompts will teach you proper patterns along the way.

My Honest Take

I have used a lot of prompt collections. Most are just recycled tips. This one feels different because it focuses on C# first. The author clearly knows how modern .NET development works and what actually breaks in production.

If you are spending too much time fighting your AI instead of shipping real code, this pack will pay for itself very quickly.

You can find it over on Gumroad. The link is straightforward:

yaman95.gumroad.com

Stop fixing broken AI output. Start building.

I used to fail .NET interviews for not giving the “expected answer”

Ayman Atif — Wed, 06 May 2026 16:03:23 +0000

I’m a .NET developer. I can build production-ready applications, APIs, and work with databases.

In the past, I kept failing interviews and getting rejected or ignored, mostly because I wasn’t giving the “expected answer”.

I could solve problems in real code, but I struggled to explain things in the structured way interviewers wanted. I thought performance should matter more than theory, but interviews don’t really work like that. You have to answer first, then prove yourself later.

I even got hired once just because I memorized definitions and answered correctly, even though I wasn’t actually strong in what they asked. I had to learn everything on the job and eventually resigned after a short time.

Now, after going through many interviews, I understand the process much better. I know what they are looking for, how questions are framed, and what kind of answers they expect.

Still, it’s interesting how different real-world development is from interview performance.

For anyone going through the same struggle, I also built something to help track and organize job applications and interview progress in a structured way:

👉 https://yaman95.gumroad.com/l/job-hunt-system

I Built a Job Hunt System for Developers. Here is Why You Need It.

Ayman Atif — Tue, 05 May 2026 17:29:41 +0000

Job hunting as a developer is broken.

You send 50 applications. You hear back from 2. One is a rejection. The other is a ghost.

This happened to me over and over. I knew I had the skills. But my applications were not getting through.

So I built a system.

Not a generic spreadsheet. Not a Notion template. A real desktop app with a complete job hunt methodology.

Here is what I learned and what I built.

The Problem with Most Job Applications

Recruiters spend 6 to 10 seconds on a resume. If it does not signal relevance immediately, it gets skipped.

Strong developers get rejected every day. Not because they lack skills. But because their materials do not communicate those skills in recruiter readable language.

Most people think more applications equal more chances. That is wrong.

What actually works is fewer, highly targeted applications with a resume tailored to each posting.

The System I Built

I created a complete job hunt system for developers. It has three parts.

First, a 12 page PDF playbook. It covers why developers get ignored, the four step loop of Find, Tailor, Reach Out, and Follow Up, resume tailoring with before and after examples, outreach message templates for LinkedIn and email, and a complete tracking system.

Second, a Windows desktop app. It includes an application tracker with add, edit, delete, search, filter, and sort. A dashboard with response rates, source performance, and pipeline visualization. A resume tailoring worksheet with action verbs and metric examples. An outreach swipe file with copy ready templates. A weekly review with save and load past entries. An interview log to track questions and improve. Dark mode toggle. Column visibility toggles. Export JSON backup and import restore. Keyboard shortcuts like Ctrl+S to save and Esc to close dialogs.

Third, the full C# source code. You get the complete WPF and WebView2 project. SQLite database layer. HTML, CSS, JavaScript frontend that you can modify. Build instructions included. You can compile for Mac or Linux yourself.

Why Source Code Matters

Audit the code. Modify the colors. Add your own columns. Compile for your own machine.

Or just run the EXE in the Release folder and never look at the code. The choice is yours.

Where Your Data Goes

Nowhere.

Desktop mode saves to SQLite at your local AppData folder.

Browser fallback mode uses localStorage for testing.

Your data never leaves your computer. No telemetry. No accounts.

No subscription.

What You Will Download

One ZIP file containing a Release folder with the EXE ready to run, a Source folder with the complete C# project, a PDF folder with the playbook, and a README.txt with simple instructions.
No installation required. Just run the EXE.

Pricing

Regular price is $29.

For launch, use code YAMAN95. You get it for $14.

That includes the PDF, the desktop app, and the full source code.

One payment. Lifetime access.

Get It Here

yaman95.gumroad.com

Final Thought

You have the skills. You just need a system to show them.

Stop applying blindly. Start hunting with purpose.

I Sent Out 30 Resumes As A Developer. I Heard Back From 2.

Ayman Atif — Tue, 05 May 2026 00:35:44 +0000

Here is what I learned after 50 interviews and fixing my resume after every rejection.

The problem was never my skills. It was how I presented them.

I wrote the same things most developers write. "Worked on the API." "Helped with database optimization." "Responsible for code reviews."

Those sentences describe presence. They do not describe contribution.

After months of getting ignored or rejected, I started tracking what actually moved the needle. I studied recruiter behavior. I ran A/B tests on my own resume. I went through 50 interviews and iterated after every single one.

What I found changed how I write about my work completely.

The 10 Second Test That Changed Everything

Print your resume. Set a timer for ten seconds. Look at it fresh.

Can you immediately tell what kind of developer this person is?

Is the most recent job visible without scrolling?

Do the tech skills appear in the top third of the page?

Most developers fail this test. Not because they lack experience. Because their layout buries the information recruiters actually scan for.

A recruiter does not read your resume. They scan it. In about ten seconds, they decide if you are worth a closer look. They look for name, title, company names, job titles, years of experience, and tech stack. If any of those are missing or hard to find, your resume fails before it is read.

The One Change That Got Me Callbacks

I stopped writing what I was responsible for. I started writing what I built.

Here is what I mean.

Before: "Helped improve database performance."

After: "Identified and resolved 12 slow queries using PostgreSQL EXPLAIN, cutting average response time from 2.1 seconds to 310 milliseconds."

The first sentence tells someone you existed near a database. The second sentence tells them exactly what you did, how you did it, and what happened as a result.

Every bullet on your resume needs an action and an outcome. Not every bullet needs a number. But every bullet needs to be specific. If you cannot say "reduced load time by 40 percent," you can say "reduced page load time noticeably by eliminating N plus 1 queries in the product listing endpoint."

Specific is always better than vague. With or without a number.

What I Learned After 50 Interviews

I compiled everything into a 30 page playbook. No fluff. No generic advice. Just what actually works.

The playbook includes two complete resume examples you can study and adapt. A bullet point library with over 50 proven phrases for backend, frontend, and full stack roles. The real ten second scan path recruiters use. Weak versus strong transformations for every section. ATS myths explained. And a final checklist to run before every submission.

You can get it here:

https://yaman95.gumroad.com/l/developer-resume-playbook

It costs $9. That is less than a coffee and a sandwich in most cities. If it helps you land one interview, it has paid for itself a hundred times over.

Build Your Resume Without Fighting Your Word Processor

Writing a great resume is one thing. Getting it into a clean, ATS friendly PDF without smashing your keyboard is another.

I built a tool called ResumeOS that solves this. You drag and drop sections. Click any text to edit it. Switch between one column and two column layouts. Pick a visual style. Your text stays the same, just the spacing changes.

Then the useful stuff:

An ATS score that shows you a number from 0 to 100 percent based on keywords, bullet quality, section completeness, and length. A job matcher that lets you paste a job description and tells you exactly which keywords you are missing. A bullet library with over 300 real achievement bullets sorted by role. A feature that highlights weak bullets starting with "responsible for" or "helped with" and gives you stronger alternatives. Spell check that underlines misspelled words. Export to PDF with A4 or Letter size. Save named templates. Auto save every 30 seconds. Restore any previous version from the history panel.

No account. No monthly fee. One purchase, use it forever.

https://yaman95.gumroad.com/l/resumeos-ats-resume-optimizer

If you apply to more than one job a month, it pays for itself in time saved.

One Last Thing

Done is better than perfect.

A complete, specific, slightly imperfect resume submitted today beats a polished resume submitted after three more weeks of revision. Apply, collect feedback from rejections, iterate. That is the real process.

You are not trying to impress anyone with your resume. You are trying to earn 30 minutes of someone's time. Write it with that goal in mind.

I Was Getting Zero Job Replies Until I Fixed My Resume Formatting

Ayman Atif — Sun, 03 May 2026 23:47:36 +0000

I used to send out application after application and hear nothing back. Not a single reply.

At first, I thought my resume wasn't impressive enough. So I made it fancier. Added columns. Played with layouts. Tossed in some icons.

Still nothing.

Then I learned about Applicant Tracking Systems. Companies use software like Lever, Greenhouse, and Workday to scan resumes before a human ever sees them. If the system can't parse your formatting correctly, you're out. No second chance. No recruiter laying eyes on your experience.

That was my problem. My "nice looking" resume was actually unreadable to the machines doing the first round of filtering.

So I stopped guessing and built something that actually works.

The free live tool

I made a simple ATS-friendly resume builder. Clean structure. No fancy columns or broken layouts. Just your information in a format that parsing software can actually read.

You don't need to sign up for anything. No email. No account. Just open it and use it.

Try it here:

https://ats-friendly-resume-builder-sable.vercel.app/

The downloadable version

If you prefer working offline or want a version you can fully customize and keep on your own computer, I also created a downloadable HTML file. Same clean structure, but you own it. Tweak it however you like. Save multiple versions for different job roles. Everything stays in your browser.

Grab it here (pay what you want, including free):

https://yaman95.gumroad.com/l/ats-friendly-resume-builder

What I'm building next

Right now I'm working on a bigger version with smarter features. Keyword suggestions based on actual job descriptions. Role-specific optimization for frontend, backend, data, and DevOps roles. Better export options.

If you have ideas or run into problems with the current tool, leave a response. I'm building this because I needed it myself, and I want to make it genuinely helpful for other people.

Try it out

If you're job hunting, give the live builder a shot. It's free and takes a few minutes. And if it helps you land an interview, pass it along to another developer still waiting on that first reply.

Sometimes the only thing standing between you and an interview is a resume an ATS can actually read.

How I Structure Authentication in .NET (JWT + Refresh Tokens)

Ayman Atif — Thu, 30 Apr 2026 18:52:36 +0000

If you’ve built a few .NET APIs, you’ve probably done authentication more than once.

JWT setup
login and register endpoints
protecting routes
maybe adding roles

It works, but every time I started a new project, I found myself repeating the same setup again.

After doing this a few times, I decided to settle on a structure that I can reuse and understand without digging through tutorials.

This is the approach I use now.

The goal

I’m not trying to build a full identity system.

I just want:

a clean login and register flow
JWT authentication that works
refresh tokens so users don’t get logged out constantly
a structure that doesn’t turn into a mess later The structure

I keep things split into simple layers.

Api
Application
Domain
Infrastructure
Shared

Nothing fancy. Just enough separation so things don’t get mixed together.

The API handles HTTP and controllers.
The Application layer contains the logic like login and register.
The Domain has the core models like User and Role.
Infrastructure deals with the database and token generation.
Shared contains helpers like password hashing.

This makes it easy to change one part without breaking everything.

Authentication flow

Here’s how the flow works.

1. Register or login

User sends email and password.

Password is hashed before storing it.

If login is successful, the API returns:

a JWT access token
a refresh token

2. Access protected endpoints

The client sends:

Authorization: Bearer

The API validates:

signature
issuer
audience
expiration

If everything checks out, the request goes through.

3. Refresh token

When the access token expires, the client sends the refresh token.

If it is valid:

a new access token is generated
a new refresh token replaces the old one

This avoids forcing users to log in again.

4. Roles

Each user has a role like User or Admin.

Then I can protect routes like this:

[Authorize]
[HttpGet("protected")]
public IActionResult Protected() { ... }

[Authorize(Roles = "Admin")]
[HttpGet("admin-only")]
public IActionResult AdminOnly() { ... }

Simple and clear.

Why I use refresh tokens

JWT alone is not enough for real apps.

If the token expires quickly, users get logged out often.
If it lasts too long, it becomes a security risk.

Refresh tokens solve that.

Short lived access token
longer lived refresh token

You keep security and still have a smooth experience.

Database choice

For this kind of starter, I use SQLite.

No setup needed
works out of the box
easy to switch later

The database file is created on first run, which makes testing simple.

What I keep simple on purpose

I don’t try to solve everything here.

No email verification
No password reset
No advanced permissions

Those can be added later depending on the project.

This is just a clean starting point.

Try it yourself

I put a free demo here:

https://github.com/i95compile/.Net-Auth-System-Core-Demo.git

You can run it, test the endpoints, and see how everything is structured.

If you want the full version

I also packaged a version you can reuse directly in your projects.

Same structure, ready to plug in and extend.

If you’re tired of rebuilding auth every time, this can save you a bit of time.

yaman95.gumroad.com

Final thought

Authentication is one of those things that is not hard, but it’s easy to waste time on.

Having a clean base you understand makes a big difference when starting new projects.

That’s what I aimed for here.

Why You Are Not Getting Better as a Developer (It Is Not More Courses)

Ayman Atif — Wed, 29 Apr 2026 15:37:03 +0000

The uncomfortable truth about consistency and the simple 20 minute system that actually works

You have the courses. The bookmarks. The "must watch" videos saved to watch later.

And still. You are not improving.

Not in any way that actually shows up in your work, your confidence, or your code reviews.

Here is the hard truth no YouTube tutorial will tell you.

It was never a knowledge problem.

The Cycle That Keeps Most Developers Stuck
It starts the same way every time.

New course. New energy. New plan.

You tell yourself, "This time I am doing it properly."

Day 1: focused
Day 2: still good
Day 3: life gets busy
Day 4: you skip
Day 5: you tell yourself you will restart next week

And just like that, you are back to scrolling and watching. You are "learning" but not really building.

Weeks pass. Sometimes months.

The worst part is that you already know what to do. That is what makes it so frustrating.

Why Another Course Will Not Save You

Most developers think they need a better course. Or a different tech stack. Or more prerequisites.

But deep down, you already know the truth.

Every time you actually sat down and wrote code, even for 30 minutes, you made progress. Small progress. But real progress.

The problem is not learning. The problem is showing up consistently enough for that learning to compound.

You do not get better with six hour binge sessions once a month. You get better with 20 minutes every day, even when it feels boring.

The Uncomfortable Realization

Here is what no one really emphasizes.

Consistency is not exciting.

It is repetitive. Quiet. Sometimes boring.

But it is the only thing that works.

Intense sprints feel productive, but they do not build real skill. Small daily actions do, because they force your brain to rewire instead of just cramming information.

Why Consistency Feels So Hard
The advice sounds simple. Just code every day.

But in reality, you run into specific problems.

You do not know what to work on each day

You overthink which topic to learn next

You set goals that are too big

You lose all momentum after missing just one day

So you end up trapped in the same loop.

Start. Stop. Restart. Repeat.

And every restart feels heavier than the last.

This is where most developers quit for good.

What Actually Works

Stop thinking "I need to improve."

Start thinking "I need a system that makes showing up easy."

Not perfect. Just easy.

A system that removes decision fatigue, overthinking, and randomness. Because willpower alone does not last. Structure does.

One Small Shift That Changes Everything

Stop telling yourself, "I will study when I have time."

Start telling yourself, "This is something I do daily, even if it is just 20 minutes."

That shift sounds small, but it changes your identity.

You are no longer someone who tries to learn coding. You are someone who shows up consistently.

That is the difference between stuck developers and developers who actually grow.

The Part Most Developers Skip

Everyone wants results. Better skills. A better job. More confidence.

But very few people build the one thing that actually leads there.

A simple, repeatable system they can stick to. Not for three days. Not for two weeks. But long enough to see real change.

The Free Tool That Fixes This

I got tired of the start stop cycle. So I built something simple.

The 30 Day Coding Consistency Tracker

This is not a course. Not a tutorial. Not another video to save for later.

It is a simple system that tells you exactly what to work on for 20 minutes each day. No decision fatigue. No overthinking. Just show up and code.

Here is what you get.

30 daily prompts designed for real progress
A printable tracker to mark each day

Decision free. Just open and start.

👉 Download the free tracker here

No email required. Just the system you have been missing.

If You Feel Stuck Right Now, Read This

You are not stuck because you are not smart enough.

You are not stuck because you chose the wrong path.

You are not stuck because you need another course.

You are stuck because your effort is inconsistent.

And inconsistent effort does not compound. It just burns you out.

What To Focus On Instead

Do not aim for perfect days.

Aim for showing up. Aim for doing something small. Aim for not breaking the chain.

That is it.

It will not feel impressive at first. But give it a few weeks, and you will notice something.

You are not restarting anymore. You are progressing.

That is when things finally start to change.

Your Next Step

You already know what to learn. You do not need another course.

You need a system.

Here is what to do right now.

Step 1: Click the link below
Step 2: Download the 30 Day Consistency Tracker
Step 3: Commit to 20 minutes today. Not tomorrow. Today.

👉 Get your free consistency tracker here

Async/Await in Production: The Bug That Only Appeared Under Load

Ayman Atif — Tue, 28 Apr 2026 14:21:41 +0000

Most people learn async/await in a clean little test project.

await GetDataAsync();

Looks simple. Feels safe.

Then you push to production, traffic hits, and suddenly async/await is quietly wrecking your backend. This isn't theoretical. It's a real failure pattern: thread starvation mixed with blocking async calls causing cascading latency spikes.

It Worked Fine Locally

We had a typical .NET backend API:

ASP.NET Core Web API
SQL Server
External HTTP calls
Async/await everywhere (or so we thought)

Simplified version of the code:

[HttpGet]
public IActionResult GetUser(int id)
{
    var user = _userService.GetUserAsync(id).Result;
    return Ok(user);
}

If you come from a synchronous background, nothing looks obviously wrong here.

Locally? Fast. Stable. No issues.

First Sign: Random Slow Requests

In production, under moderate traffic:

Some requests take 200ms
Others randomly spike to 5 to 10 seconds
CPU is fine
Database is fine

So what's blocking?

Nothing obvious. That's exactly the problem.

The Real Problem: Blocking Async Code

This line is the silent killer:

_userService.GetUserAsync(id).Result;

Or the same thing with .GetAwaiter().GetResult().

Here's what actually happens:

The async method starts.
It hits an await.
The thread gets freed up... but then
You immediately block, waiting for the result.

Now layer on top of that how the ASP.NET thread pool behaves.

Thread Pool Starvation in Action

Under load:

The thread pool has a limited number of threads.
Each request blocks a thread while waiting on async work.
But that async work needs threads to resume.

Result: threads waiting for threads that are already blocked.

It's not a classic deadlock, but the system acts like one. Requests pile up. Latency explodes.

Why It Didn't Fail Locally

Locally:

Low concurrency
Plenty of free threads
No pressure on the thread pool

In production:

Many concurrent requests
Real external API latency
Real database latency spikes

Everything makes the problem worse.

The Fix: Async All the Way Down

Correct version:

[HttpGet]
public async Task<IActionResult> GetUser(int id)
{
    var user = await _userService.GetUserAsync(id);
    return Ok(user);
}

And inside your services:

public async Task<User> GetUserAsync(int id)
{
    return await _repository.GetUserAsync(id);
}

The rule is simple: if you use async, everything above it must also be async.

A Hidden Trap: Sync over Async in Libraries

Even worse is this pattern:

Task.Run(() => _service.CallAsync()).Result

Or legacy code inside libraries that forces sync wrappers around async calls. That spreads the problem silently across multiple layers of your app.

Another Silent Killer: Context Capture

In UI apps or older ASP.NET:

await SomethingAsync(); // captures context

Fix:

await SomethingAsync().ConfigureAwait(false);

In backend services, this avoids unnecessary context switching overhead.

How We Actually Diagnosed It

We eventually spotted:

Spikes in thread pool queue length
High number of blocked threads
Requests stuck in "waiting" state

Once we removed all the .Result usage:

Latency dropped
Throughput roughly doubled
CPU usage normalized

Key Takeaways

Never mix .Result or .Wait() with async code.
Async has to be end to end. Partial doesn't work.
Thread pool starvation is silent but deadly.
Production behavior is not local behavior.

That's it. No magic. Just don't break the async chain, or the system breaks with it.

3 LINQ Mistakes That Hurt Backend API Performance in .NET

Ayman Atif — Mon, 27 Apr 2026 17:24:31 +0000

LINQ looks clean and harmless in C#.

But in real backend APIs, small mistakes can quietly turn into serious performance issues.

Here are 3 I’ve seen (and made) while working with .NET and Entity Framework:

1. Loading entire tables into memory

A common mistake is doing this:

var orders = dbContext.Orders.ToList();

var recent = orders.Where(o => o.CreatedAt > DateTime.UtcNow.AddDays(-7));

This pulls everything into memory first, then filters in C#.

The problem:

unnecessary memory usage
slow processing on large datasets
wasted database optimization

Fix:

Let the database do the work:

var recent = dbContext.Orders .Where(o => o.CreatedAt > DateTime.UtcNow.AddDays(-7)) .ToList();

2. Hidden multiple database calls

LINQ queries can be deceptively reused:

var query = dbContext.Orders.Where(o => o.Total > 100);

var count = query.Count();
var list = query.ToList();

This can result in multiple database executions depending on how it's used.

Fix:

Materialize once:

var list = dbContext.Orders .Where(o => o.Total > 100) .ToList();

var count = list.Count;

3. Fetching more data than needed

Another common issue:

var orders = dbContext.Orders.ToList();

var result = orders.Select(o => new { o.Id, o.CustomerName });

You are still loading full rows from the database even though you only need 2 fields.

Fix:

Project early:

var result = dbContext.Orders .Select(o => new { o.Id, o.CustomerName }) .ToList();

Key idea

LINQ itself is not the problem.

The real issue is where the execution happens:

in memory
or in the database

In backend systems, that difference matters a lot.

Closing thought

Most performance issues in APIs are not “big architecture problems”.

They start with small LINQ decisions like these.