Forem: Laurina Ayarah

[Boost]

Laurina Ayarah — Sat, 21 Mar 2026 06:21:07 +0000

Laurina Ayarah

Nov 1 '25

It’s almost 2026: Why Are We Still Arguing About CSS vs Tailwind

#webdev #programming #tailwindcss #productivity

Comments 14

7 min read

Why Is the Tech Job Market So Brutal Right Now? (An Honest Look at What Changed)

Laurina Ayarah — Wed, 21 Jan 2026 20:22:23 +0000

I need to tell you something nobody wants to admit.
The "learn to code and get a high-paying remote job" dream? It's not dead, but it's definitely on life support.

And if you're sitting there wondering why you've sent 200 applications and gotten 3 responses (all rejections), or why that coding bootcamp certificate isn't opening doors as they promised, or why companies want "entry-level developers with 3 years of experience", you're not crazy.

The game changed and most people are still playing by the old rules.
I'm writing this because I'm in it too. I'm watching friends with Computer Science degrees struggle to get interviews. I'm seeing talented developers give up after months of silence. I'm experiencing firsthand how brutal this market has become.

This isn't a success story. This isn't "10 tips to land your dream job." This is an honest look at what the hell happened to the tech job market, and what might actually help if you're trying to break in right now.

Remember When "Learn to Code" Was the Answer to Everything?

2020 was a different world.
Tech companies were hiring like crazy. Remote work exploded. Everyone and their uncle was starting a SaaS company. VC money was flowing like water. Bootcamps were popping up everywhere, promising six-figure salaries after 12 weeks of training.
The narrative was simple: "Tech is the future. Learn to code. Get a remote job. Make $100k. Work from anywhere."
And for a while? It was kind of true.
Companies were desperate for developers. They'd hire bootcamp grads. They'd take chances on self-taught developers with decent portfolios. Junior positions actually existed. "Entry-level" meant entry-level.
Fast forward to 2026, and it's like someone flipped a switch.

Now you see job postings like:

"Junior Developer (3–5 years experience required)"
"Entry-level position (must be proficient in React, TypeScript, Node.js, AWS, Docker, Kubernetes…)"
"Hiring freeze until further notice"
Or worse, no postings at all.

What happened?

The Perfect Storm: Why Everything Changed at Once

This isn't just one thing. It's everything hitting at the same time.

The Money Dried Up (And Tech Companies Panicked)

Let's start with the big one: money.

For years, tech companies were running on cheap money. Interest rates were near zero. Investors were throwing cash at anything with "AI" or "blockchain" in the pitch deck. Growth was everything. Profitability? Who cares, we'll figure that out later.

Then 2022–2023 happened. Interest rates shot up. Suddenly, that free-flowing VC money became expensive. Investors started asking uncomfortable questions like "When will you actually make money?"

And tech companies responded by doing what they do best when they panic: mass layoffs.
Google laid off 12,000 people. Meta cut 21,000 jobs. Amazon let go of 27,000 employees. Microsoft, Twitter, Salesforce, Stripe, the list goes on. We're talking about hundreds of thousands of experienced tech workers suddenly looking for jobs.

Now imagine you're a junior developer competing against someone who just got laid off from Google with 5 years of experience. Who do you think companies are hiring?

Yeah.

AI Became the Excuse for Everything

Then there's the AI elephant in the room.
ChatGPT launched in November 2022, and suddenly, every CEO decided they could do more with fewer people. Not because AI actually replaced developers (it hasn't), but because it gave them the perfect excuse to cut hiring.

"AI will handle the simple tasks." "We need fewer junior developers now." "AI makes our senior developers more productive."

And you know what? Some of that is true. GitHub Copilot can write boilerplate code. ChatGPT can debug basic errors. AI tools are genuinely making certain tasks faster.

But here's what they're not telling you: AI still needs humans to guide it, review it, and fix its mistakes. The technology isn't replacing developers, it's changing what skills matter.

The problem is companies are using AI as justification to not hire, not train, and not invest in junior talent. They're looking at the hype and making decisions based on fear and cost-cutting, not reality.

Everyone Learned to Code (At the Same Time)

Remember the pandemic?
Everyone was stuck at home. Everyone was anxious about job security. And everyone heard the same advice: "Learn to code!"
Bootcamps exploded. Online courses had record enrollments. YouTube tutorials went viral. Millions of people started learning web development, data science, and software engineering.

Which sounds great for inclusion and accessibility. And it is! More people having tech skills is genuinely good.

But it also means the market is now flooded with junior developers who all have:

The same bootcamp certificates
The same portfolio projects (to-do apps, weather apps, Netflix clones)
The same GitHub with tutorial code
No real work experience

When 100 junior developers were competing for 50 jobs, you had a decent shot. When there are 10,000 competing for 5 jobs? The math just doesn't work.

And companies responded by raising the bar. Why hire someone with 6 months of bootcamp training when you can hire someone with a CS degree and internship experience? Why take a chance on a self-taught developer when you have laid-off senior developers willing to take junior salaries?

The supply-demand equation broke.

The "Entry-Level Experience" Paradox Got Worse

You've seen it. We've all seen it.

"Entry-level position. Requirements: 3–5 years of professional experience."

This has always been frustrating, but it's gotten exponentially worse. Companies are genuinely posting junior roles with senior requirements because they can. The market is so saturated that they can afford to be unrealistic.

They want someone who can start contributing from day one. No training period. No onboarding costs. Just plug and play.
Which would be fine if there were also actual entry-level roles for people to get that first year or two of experience. But those positions have largely disappeared.

Internships are more competitive than ever. Junior roles get hundreds of applications. Companies aren't investing in training programs like they used to.

It's a catch-22: Can't get experience without a job, can't get a job without experience. And the gap keeps widening.

Remote Work Became a Double-Edged Sword

The pandemic normalised remote work, which seemed like a huge win for developers. Work from anywhere! No geographic limitations! Access to global opportunities!
Except it works both ways.

Now you're not just competing with developers in your city or country. You're competing with developers globally. That remote job at a US company? You're competing with candidates from India, the Philippines, Eastern Europe, Latin America, and everywhere else.

And many companies discovered they can hire senior developers from countries with lower costs of living for the same price they'd pay a junior developer in expensive markets.

Why hire a junior developer in San Francisco when you can hire a senior developer in Nigeria or Poland for less?

Plus, many companies started pulling back on remote work entirely. "Return to office" mandates cut the number of truly remote positions. Even "remote" jobs often have geographic restrictions now.

The advantage remote work promised to international developers? It's being eroded by these same market forces.

The Africa-Specific Layer (Because Location Still Matters)

If you're in Africa; Nigeria, Kenya, Ghana, South Africa, anywhere on the continent, you're dealing with all of the above plus some extra challenges.

The Infrastructure Tax

Let's be real: reliable power and internet aren't guaranteed. And for remote tech work, they're non-negotiable.
You might be the best developer in the room, but if your internet cuts out during a client call, or you can't meet deadlines because power has been out for 8 hours, that's a problem.
International clients worry about this. They've heard the stories. They've had bad experiences. And unfortunately, you pay the "trust tax" for it even if your personal setup is solid.

Payment Platform Restrictions

Stripe doesn't work in Nigeria. PayPal is limited. Payoneer has fees. Wise has restrictions.

Getting paid as a freelancer or contractor is genuinely harder from Africa. And many international companies don't want to deal with the complexity.

"We only hire contractors who can invoice through Stripe" eliminates you before the conversation even starts.

Currency Devaluation Pressure

The naira has lost significant value. The cedi is struggling. Many African currencies are under pressure.
Which means two things:

Local salaries can't keep up with inflation. That ₦200,000/month job from last year is worth significantly less today.
Dollar-paying remote jobs become even more competitive. Everyone wants to earn in dollars or euros, which makes those positions brutally competitive.

You're not just competing for jobs, you're competing for economic survival.

The Local Market Maturity Gap

The African tech market is growing, but it remains immature in most places.
There are fewer tech companies. The startups that exist are struggling to raise funding. Corporate digital transformation is slow. Many businesses still don't see tech as essential or they want it done as cheaply as possible.

"My cousin can build a website for ₦30,000" is still a common response.
This means fewer local opportunities, increased competition for international remote work, and pressure to undervalue your skills just to gain experience.

The Time Zone Challenge

Most high-paying tech jobs are in the US or European time zones. Which means:

Interview scheduling is complicated
Real-time collaboration is difficult
You might need to work odd hours
Asynchronous communication becomes critical

Some companies love hiring in different time zones for round-the-clock coverage. Others see it as a dealbreaker. And you can't always tell which one you're dealing with until you're deep in the process.

Why Entry-Level Developers Got Hit Hardest

Here's the uncomfortable truth: when companies tighten budgets, junior developers are the first to go.

Training Is Expensive

Junior developers need mentoring. Code reviews. Guidance. Time to ramp up. Senior developers need to spend time teaching instead of shipping features.
When companies are focused on efficiency and cutting costs, training programs get axed. Junior positions get eliminated. They'd rather hire one senior developer who can work independently than two juniors who need support.

AI Took the "Learning Tasks"

A lot of what junior developers used to do, writing basic CRUD operations, fixing simple bugs, writing tests, and updating documentation, can now be partially automated by AI tools.
Not completely. Not perfectly. But enough that companies think "we can have our senior devs use AI for this instead of hiring juniors to do it."
Which means the tasks that used to be learning opportunities for junior developers are disappearing. And with them, the justification for junior roles.

Risk Aversion in Uncertain Times

When the market is good, companies take chances. They hire promising juniors. They invest in potential.
When the market is uncertain, they play it safe. They want proven skills. Immediate impact. No risk.
Junior developers, by definition, are a risk. You might be great. You might struggle. You need time to prove yourself.
In this market, companies don't want to take that risk.

The Skills Paradox: Everyone Has the Same Resume

Here's something I've noticed: most developer portfolios look identical.
Same projects: To-do app. Weather app. E-commerce clone. Netflix clone.
Same skills listed: HTML, CSS, JavaScript, React, Node.js, MongoDB.
Same GitHub: Full of tutorial code and incomplete projects.
Same about section: "Passionate developer eager to learn and grow."
When everyone has the same skills and the same projects, how do you stand out?
You don't. You're just another resume in a pile of 500.
The baseline skills that used to be impressive (knowing React, building a portfolio site, having a GitHub) are now just… expected. They're not differentiators anymore. They're table stakes.
And this creates a problem: what used to get you hired now just gets you in the door. And the door is crowded.

What Companies Are Actually Looking For (Hint: It's Changed)

From what I've learned and noticed, the job requirements haven't just gotten harder; they've gotten different.

They Want Specialists, Not Generalists

"Full-stack developer" used to be impressive. Now it's generic.
Companies want depth, not breadth. They want someone exceptional at one thing, not mediocre at everything.
"Expert in React performance optimisation" is more valuable than "knows React, Vue, Angular, and Svelte."
"Specialised in building accessible UIs" beats "can do frontend and backend and mobile and…"

They Want Proof, Not Potential

"I'm eager to learn" doesn't cut it anymore.
They want: "Here's a live product I built that 500 people use."
They want: "I contributed to this open-source project and got my PRs merged."
They want: "Here's my technical blog with 10,000 readers where I explain complex concepts."
Potential is cheap. Everyone has potential. Proof is expensive and rare.

They Want Communication Skills (More Than Ever)

With remote work and distributed teams, communication isn't just nice to have; it's essential.
Can you write clear documentation? Can you explain technical concepts to non-technical stakeholders? Can you collaborate asynchronously across time zones?
Technical skills might get you the interview. Communication skills get you the job.

They Want People Who Can Work Independently

Hand-holding is expensive. Training is expensive. Constant questions are expensive.

They want developers who can:

Figure things out independently
Ask good questions when stuck
Manage their own time and priorities
Ship features without constant oversight

Which, again, disadvantages junior developers who are still learning these skills.

What Might Actually Help (No BS, Just Honest Strategies)
I can't promise these will get you a job. The market is tough, and sometimes it's just bad luck or bad timing.
But here's what seems to be working for people who are breaking through:
1. Go Niche (Really Niche)
Stop being "a frontend developer." Start being "the developer who builds e-commerce sites for Nigerian fashion brands" or "the specialist in making government websites accessible."
Niching feels scary because you think you're limiting opportunities. But you're actually making yourself more visible to a specific group that needs exactly what you do.
2. Build in Public
Document your learning. Share your projects. Write about what you're building and why.
Not for clout. Not to go viral. But to create a paper trail that shows:
You actually ship things
You can explain your thinking
You're consistently learning and improving

This is more impressive than any portfolio.
3. Contribute to Real Open Source (Not Just Beginner-Friendly Repos)
Everyone knows the "find an issue labelled 'good first issue'" advice.
Go deeper. Find a project you actually use. Spend a month understanding the codebase. Then make a meaningful contribution.
One substantial PR to a real project is worth more than 20 tiny contributions to "beginner-friendly" repos.
4. Solve Actual Problems (Not Tutorial Problems)
Build something someone actually needs. Even if it's just your friend's small business website or a tool for your local community.
"I built a booking system for my uncle's barbershop that handles 50 appointments a week" is infinitely more interesting than "I built a Netflix clone following a YouTube tutorial."
Real problems have constraints, edge cases, and users. Tutorial problems don't.
5. Network Locally (Not Just Online)
Twitter applications disappear into the void. LinkedIn cold messages get ignored.
But showing up to local tech meetups, developer communities, and startup events? That creates relationships.
Most jobs come from referrals. Referrals come from people who actually know you. And people get to know you in person or through sustained online relationships, not from a cold email.
6. Add Adjacent Skills
Pure coding skills are commoditized. Coding + something else is valuable.
Developer + designer = rare and valuable
Developer + writer = technical writing opportunities
Developer + domain expertise (healthcare, finance, education) = specialized roles
Developer + data analysis = product-focused roles

Don't just be another developer. Be a developer who brings something extra.
7. Be Realistic About Timeline
This sucks to hear, but it might take longer than you thought.
Not because you're not good enough. Not because you're doing something wrong. But because the market is genuinely tough right now.
Six months of job searching is becoming normal for junior developers. A year isn't unheard of.
That doesn't mean give up. It means adjust expectations and plan accordingly. Keep learning. Keep building. Keep applying. But also keep your day job or freelance income flowing because this might take a while.

8. Consider Alternative Entry Points
If direct-hire developer roles aren't working:
Freelancing (smaller projects to build experience and income)
Contract work (temp roles that might convert to permanent)
Agencies often hire more junior devs than product companies.
Startups (more willing to take chances, though often lower pay)
Adjacent roles (QA, technical support, technical writing) that get you in the door

These aren't failures. They're strategic entry points that build experience and connections.

The Uncomfortable Truth Nobody Wants to Say

The "learn to code = guaranteed job" narrative was oversold.
Not because coding isn't valuable. It is.

But because the market changed faster than the narrative did. The promise was made when the market was hot. Now it's cold. And people are still making decisions based on old information.
Does that mean learning to code was a waste of time? No.
Does it mean everyone who learns to code will get a high-paying tech job? Also no.

The truth is messier: tech skills are valuable, but they're not a guaranteed meal ticket anymore. The market is oversaturated at the entry level, undersupplied at specialist levels, and in flux everywhere else.

Some people will break through quickly. Others will struggle for months. Some will need to pivot or add skills. Others will find success in unexpected places.
There's no one path anymore. And anyone selling you a guaranteed path is lying.

What Happens Next? (Looking Forward)

The market will shift again. It always does.
AI will stabilize from hype to reality. Companies will realize they actually do need developers (just different kinds). The economic cycle will turn. New technologies will create new opportunities.
But when? How? Nobody knows.
What we do know:

Junior positions will probably stay rare for a while. Companies are prioritizing experienced hires.
Specialization will matter more. Being good at one thing beats being okay at everything.
Non-technical skills will differentiate. Communication, problem-solving, business understanding, these separate good developers from great ones.
Alternative paths will become more common. Fewer people will go straight from boot camp to a full-time dev job. More will freelance, contract, contribute to open source, or enter through adjacent roles.
The African opportunity is still there, but it requires different strategies. Building for local markets, solving local problems, and creating products for African users might be more sustainable than competing for international remote roles.

Final Thoughts: You're Not Crazy, the Market Is

If you're struggling to get a tech job right now, it's not because you're not good enough.

It's because you're entering the market at one of the hardest times in recent tech history.

Layoffs. AI hype. Market saturation. Economic uncertainty. Everything hit at once.
That doesn't make it easier. But maybe it makes it less personal.

You're not failing. You're navigating a genuinely difficult situation that's affecting thousands of talented people.
Keep building. Keep learning. Keep applying. But also be kind to yourself. The market is brutal right now, and that's not your fault.

Some of you will break through next month. Some will take a year. Some will find success in unexpected directions.
But if you're still in the game, still learning, still trying, you're doing better than you think.
The tech job market is brutal right now.
But it's not forever.

And knowing what you're actually up against? That's the first step to figuring out how to navigate it.

If this resonated with you, share it with other developers who need to hear this. We're all figuring this out together.

What's your experience with the current tech job market? Drop your story in the comments, let's talk about what's really happening out there.

What Clients ACTUALLY Want From Frontend Devs (Not Clean Code)

Laurina Ayarah — Sat, 10 Jan 2026 13:24:46 +0000

Clean code doesn't get you hired. This does.

I learned this the hard way.
I spent years obsessing over best practices. Learning the latest frameworks. Writing DRY code. Organizing my files perfectly. Following every convention I could find.
Then I started working with real clients, and none of that mattered as much as I thought it would.
Don't get me wrong, technical skills matter. But they're just the baseline. The entry ticket. What actually determines whether clients hire you again, refer you to others, or leave you great reviews?

It's everything else.

The stuff nobody talks about in developer forums or YouTube tutorials. The soft skills. The business understanding. The communication. The things that have nothing to do with JavaScript but everything to do with getting paid.
Let me break down what clients actually care about, from someone who's been learning this in real time.

They Want to Understand What You're Doing (In Plain English)

Picture this: A client asks you to add a feature to their website. You dive into the code, implement it beautifully, and send them a message:
"I've refactored the component architecture and implemented a custom hook for state management. The API calls are now memoized for better performance, and I've added proper error boundaries."
The client reads this and thinks, "What did any of that mean? Did you actually do what I asked?"

Here's the thing: most clients aren't technical. They don't know what React hooks are. They don't care about your component architecture. They just want to know: "Did you add the feature? Does it work? When can I see it?"
Technical jargon makes you sound smart to other developers. To clients, it sounds like you're either showing off or hiding something.

What they actually want to hear:
"Yes, I added the contact form as you requested. It now collects name, email, and message, and sends everything to your inbox. I also added validation so people can't submit blank forms. You can test it here: [link]"

Simple. Clear. Actionable.

Save the technical details for your documentation or when they specifically ask. In regular communication, speak like a human talking to another human, not a developer talking to a code review bot.

They Want Honesty More Than They Want "Yes"

Clients will ask for things that are:
Technically possible but extremely time-consuming
Bad ideas that will hurt their website
Features that already exist, but they don't know how to use them
Completely outside the original scope

Your instinct might be to just say "yes" to everything. Keep the client happy. Don't rock the boat.
But here's what I've learned: clients respect honesty more than they respect compliance.

If a client asks you to add 17 different animations to their homepage because "it needs to pop," you could just do it. Spend hours implementing animations that will make the site slower, harder to maintain and honestly, kind of annoying to use.

Or you could say:
"I can definitely add animations, but I want to make sure we're using them strategically. Too many animations can actually slow down the site and distract from your main message. What if we focus on 2–3 key areas where animation would really enhance the user experience? That way, we get impact without overwhelming visitors."

Notice what happened there:

You didn't just say "no"
You explained why their idea might not work
You offered an alternative solution
You positioned yourself as someone who cares about their success, not just about getting paid

Clients who just want you to do whatever they say without question usually aren't great anyway. The good ones appreciate when you push back respectfully and offer better solutions.
You're not just a code executor. You're a consultant. Act like it.

They Want to See Progress (Not Just the Final Product)

This is huge, and so many developers get it wrong.

You take on a project. You estimate it'll take two weeks. The client agrees. You go silent for 13 days, work frantically to finish, then deliver everything on day 14.

From your perspective, you did exactly what you promised. You delivered on time.

From the client's perspective, you disappeared for almost two weeks, and they had no idea if you were even working on it. They were stressed. Wondering if you ghosted them. Questioning whether they should follow up or wait.

Even if you deliver great work, that anxiety sours the experience.
What clients actually want: regular updates.
Even if there's nothing major to report, just send a quick message:

"Hey! Quick update: I've finished the homepage layout and navigation. Working on the contact form now. Should have that done by tomorrow. Everything's on track."

That's it. 30 seconds to write. But it completely changes the client experience.
They're no longer anxious. They can see progress. They know you're working. They feel involved.

And when the project wraps up, they remember how smooth and stress-free it was, even if there were bumps along the way.

They Want Problems Solved Before They Become Disasters

Clients don't know what they don't know.
They'll ask you to build a website and forget to mention that they need:

A way to update content themselves
Mobile optimization
Fast loading times
Contact forms that actually work
Security measures
Backup systems

They assume all of this is just… included. Because they don't understand that these are separate considerations.

If you just build what they ask for and nothing else, they'll launch the site, realize it doesn't work on mobile, and blame you.

"Why didn't you tell me it wouldn't work on phones?"
"You didn't ask for mobile optimization."
"I didn't know I had to ask!"

And now you have an unhappy client, even though technically you did what they asked.

This is where good developers separate from great ones.
Great developers anticipate problems and address them proactively:

"Hey, just a heads up, I noticed you didn't mention mobile optimization in the requirements. These days, about 70% of web traffic comes from phones, so I'd strongly recommend we make sure the site works well on mobile. I can include that in the project if you'd like."

Now you've:

Shown expertise
Prevented a future problem
Potentially increased the project scope (and your pay)
Positioned yourself as someone who cares about their success

Clients remember this. They tell other people about developers who "just get it" and save them from mistakes they didn't even know they were about to make.

They Want Fast Responses (Even If You Don't Have Fast Solutions)

You know what kills client relationships faster than anything?

Going silent.

A client sends you a message. You see it. But you're in the middle of debugging something, so you think, "I'll respond when I'm done."
Three hours later, you're still debugging. You forget to respond.
The next day, the client follows up: "Hey, did you see my message?"

Now they're annoyed. Not because you couldn't solve their problem immediately, but because you made them wonder if you even saw their message.

Here's the fix: acknowledge immediately, solve later.
Client: "Hey, the contact form isn't working. Can you check it?"
You (immediately): "Just saw this! Looking into it now. I'll get back to you within the hour with an update."
That's it. 10 seconds to write. But the client knows:

You saw their message
You're working on it
They can expect an update soon

Even if the fix takes 3 hours, they're not anxious because you communicated.
Fast responses don't mean fast solutions. They just mean you're present and engaged.

They Want to Feel Like Their Project Matters

Most developers are juggling multiple projects. Maybe you're working on 3–4 sites at once. That's normal.
But clients don't care about your other projects. They care about theirs.

If a client asks about the timeline and you say, "I'm working on a few other projects right now, so it might take longer," they hear: "Your project isn't my priority."

Even if that's not what you meant.

Instead, say: "I'm committed to delivering quality work on your site. Based on the scope, I estimate it'll take about two weeks. I'll keep you updated on progress throughout."

See the difference?
The first response makes them feel like an afterthought. The second makes them feel like you're dedicated to their success.

Small language shifts. Big perception difference.

They Want Reasonable Pricing (Not Necessarily Cheap Pricing)

Here's a mistake I see a lot: developers pricing themselves based on what they think clients want to pay, not what the work is actually worth.

"I'll just charge $100 for this website so I can get the client."

Then you spend 40 hours on the project. That's $2.50 per hour. You're working skilled labour for unskilled wages.

And here's the kicker: the client doesn't even appreciate the low price. They either think:

The work must not be very good if it's that cheap
Or they take advantage and ask for endless revisions because "it's not that expensive anyway"

Cheap pricing attracts cheap clients.

What clients actually want is reasonable pricing for the value they're getting.

If you build them a website that helps them get more customers, make more sales, and grow their business, that's worth way more than $100.

Price based on value, not hours.

And when a client says, "That's too expensive," don't immediately drop your price. Ask questions:

"What's your budget for this project?"
"What results are you hoping the website will bring?"
"What happens if you don't have a professional website?"

Sometimes they genuinely can't afford you, and that's fine.
Not every client is a fit.

But often, they just need to understand why it costs what it costs. And once they see the value, price becomes less of an issue.

They Want Someone Who Takes Ownership

Clients don't want to micromanage you. They want to trust that you've got it handled.

That means:

If something breaks, you fix it (or let them know immediately)
If you spot a problem, you address it
If there's a better way to do something, you suggest it
If you make a mistake, you own it and correct it

Clients aren't looking for perfection. They're looking for responsibility.

I've seen developers lose clients not because they made mistakes, but because they made excuses.

"The hosting is slow, that's why the site is slow." "The images you sent were too big, that's why they don't load." "You didn't tell me you needed that feature, so I didn't build it."

Maybe all of that is technically true. But it sounds like you're deflecting blame instead of solving problems.
Compare that to:

"The site is loading slower than I'd like. I'm going to optimize the images and look into the hosting to see if we need an upgrade. I'll have an update for you tomorrow."

Same situation. Completely different response.

One makes the client feel like you're pointing fingers. The other makes them feel like you're handling it.

They Want to Trust You

At the end of the day, this is what it all comes down to: trust.
Do they trust that you'll deliver what you promised? Do they trust that you'll communicate honestly? Do they trust that you care about their success, not just your paycheck?

You build trust through:

Consistent communication
Delivering on time (or early)
Being honest when something won't work
Proactively solving problems
Treating their project like it matters

Your code quality matters. Your technical skills matter.
But clients can't see your code quality. They can't evaluate your technical skills.
What they can see is how you make them feel throughout the process.

And that's what determines whether they hire you again. Whether they refer you to others. Whether they leave you a great review or testimonial.

Final Thoughts: Be a Developer Clients Actually Want to Work With

Thousands of developers can write clean code.
There are far fewer who can write clean code and communicate well and understand business needs and make clients feel confident and stress-free throughout the process.

That's the space you want to occupy.

Because when you do, clients stop shopping around for the cheapest developer. They stop comparing you to 10 other people.

They just hire you. And they keep hiring you.

Not because your code is the best (though it should be good).

But because working with you is easy. And in a world where most developer-client relationships are full of miscommunication, missed deadlines, and frustration, "easy" is incredibly valuable.

Be the developer who gets it.
Be the one who communicates clearly, solves problems proactively, and treats every project like it matters.

Your technical skills will get you in the door.
Everything else will keep you in the room.

What’s your experience with client communication?
Drop your stories in the comments 👇

If this helped you, save it for later, like and share with a dev friend who needs to hear this!

Originally published on Medium.

What Is My IP Address?

Laurina Ayarah — Wed, 17 Dec 2025 00:14:57 +0000

And Why It Actually Matters

Ever wondered what that string of numbers is that websites see when you visit them? Or why some streaming services know you’re not actually in the US when you’re trying to watch that show?

That’s your IP address at work.

And whether you know it or not, it’s following you around the internet, telling websites where you are, who your internet provider is, and sometimes even blocking you from accessing content.

Let me break down what an IP address actually is, why it matters, and what you can do about it.

Check Your IP Address Right Now

Before we dive into the technical stuff, here’s your current IP address:

Check Your IP Address Here — Live Tool

I built a simple IP checker tool that shows your public IP, location, ISP, and timezone instantly. Click here to use it.

That number (and the location info) is what every website you visit can see. Keep that in mind as we go deeper.

So… What Is an IP Address?

IP stands for Internet Protocol. Your IP address is essentially your device’s unique identifier on the internet.

Think of it like this:

When you send a letter, you need:

Your address (so they know where to send a reply)
Their address (so it gets to the right place)
The internet works the same way. When you visit a website:
Your IP address = your return address
The website’s IP address = where you’re sending your request

Without IP addresses, the internet wouldn’t know where to send data. Your Netflix video wouldn’t know how to reach your laptop. Your email wouldn’t arrive. Nothing would work.

In simple terms, your IP address is how the internet finds you.

What Does an IP Address Look Like?

There are two types you’ll see:

IPv4 (The Old Standard)

Looks like this: 192.168.1.1

Four numbers separated by dots. Each number ranges from 0 to 255.

Problem: We’re running out of IPv4 addresses. There are only about 4.3 billion possible combinations, and with billions of devices online, we’ve basically run out.

IPv6 (The New Standard)

Looks like this: 2001:0db8:85a3:0000:0000:8a2e:0370:7334

Way longer. Uses letters and numbers. Looks complicated.

Good news: IPv6 has 340 undecillion possible addresses. That’s 340 with 36 zeros after it. We’re not running out anytime soon.

Most of the internet still uses IPv4, but IPv6 is slowly taking over.

Public IP vs Private IP: What’s the Difference?

Here’s where it gets interesting.

Your Public IP Address

This is what the internet sees. It’s assigned by your Internet Service Provider (ISP).

Everyone on your home WiFi shares the same public IP address. Your laptop, phone, and smart TV all look like they’re coming from the same place to the outside world.

Example: 203.0.113.45

Your Private IP Address

This is your device’s address on your LOCAL network (your home WiFi).

Your router assigns private IPs to each device so they can talk to each other. But these addresses are invisible to the outside internet.

Example: 192.168.1.10 (your laptop), 192.168.1.11 (your phone)

The tool above shows your PUBLIC IP, the one websites see.

Why Your IP Address Actually Matters

Okay, so you have an IP address. So what? Why does it matter?

1. Websites Know Your Location

Your IP address reveals your approximate location. Not your exact address, but usually your city and country.

This is why:

YouTube knows to show you ads in your language
Netflix blocks content based on your country
Google shows you local search results

Your IP = your digital location tag.

2. Your Internet Activity Can Be Tracked

Every website you visit sees your IP address. And your ISP (internet provider) can see EVERYTHING you do online, every site you visit, every video you watch.

In some countries, ISPs are required to log this data. In others, they sell it to advertisers.

3. Geo-Restrictions Use Your IP

Ever tried to watch a show and got hit with:

“This content is not available in your region”

That’s geo-blocking. They checked your IP, saw your location, and blocked you.

4. Some Services Ban IPs

Get banned from a forum or game? They probably banned your IP address.

Problem: If you have a dynamic IP (most people do), it changes periodically. So you might get unbanned automatically when your IP changes. Or someone else might get banned because they got assigned your old IP.

Fun side effect: Sometimes you’ll visit a website and be mysteriously blocked because someone who had your IP before you did something bad.

5. Hackers (Technically) Can Use Your IP

Let’s be real: Knowing your IP address alone isn’t that dangerous.

A hacker can’t “hack you” simply by knowing your IP address. But they CAN:

See your approximate location
Launch a DDoS attack (flood your connection with traffic to knock you offline)
Try to exploit vulnerabilities in your router (if you haven’t updated it)

Should you panic? No. Your IP address is already semi-public. Every website you visit sees it.

Should you be careful? Yes. Don’t give out your IP in random forums or chat rooms.

How to Find Your IP Address (If the Tool Above Didn’t Work)

Quick Method:

Just Google: “What is my IP”

Google will show it instantly.

On Windows:

Open Command Prompt
Type: ipconfig
Look for “IPv4 Address”

On Mac/Linux:

Open Terminal
Type: ifconfig or `ip addr
Look for your IP address

On Mobile:

iPhone: Settings → WiFi → Tap the (i) icon
Android: Settings → Network & Internet → WiFi → Tap your network

Note: This shows your PRIVATE IP (local network). To see your PUBLIC IP (what websites see), use the tool above or Google it.

Can Someone Track You With Your IP Address?

Short answer: Kind of, but not really.

What they CAN see:

Your approximate location (city/region)
Your ISP (internet provider)
Your timezone

What they CANNOT see:

Your exact home address
Your name
Your browsing history
Your personal information

Exception: Law enforcement with a warrant can ask your ISP to reveal who was assigned a specific IP address at a specific time. But random people on the internet can’t do this.

How to Hide or Change Your IP Address

Want to mask your IP? Here’s how:

1. Use a VPN (Virtual Private Network)

What it does: Routes your traffic through a server in another location. Websites see the VPN’s IP, not yours.

Popular VPNs:

NordVPN
ExpressVPN
ProtonVPN (has a free tier)
Mullvad Good for: Privacy, bypassing geo-restrictions, hiding from your ISP

2. Use a Proxy Server

What it does: Similar to a VPN, but less secure and usually slower.

Good for: Quick IP changes, but not for serious privacy

3. Use Tor Browser

What it does: Routes your traffic through multiple servers (nodes) around the world, making it nearly impossible to trace.

Good for: Maximum anonymity

Bad for: Slow, some sites block Tor users

4. Connect to Public WiFi

What it does: You’ll have a different IP address from your home network.

Warning: Public WiFi is insecure. Use a VPN if you do this.

5. Ask Your ISP for a New IP

Most ISPs assign dynamic IPs that change periodically. You can sometimes get a new one by:

Restarting your router
Calling your ISP and asking

Static IP vs Dynamic IP

Dynamic IP (Most People)

Your ISP assigns you a temporary IP that changes every few days/weeks/months.

Pros: More privacy (your IP changes), cheaper
Cons: If you’re running a server, your IP change breaks things

Static IP (Businesses, Servers)

Your IP never changes.

Pros: Good for hosting websites, servers, and remote access
Cons: Costs extra, less privacy

Most home users have dynamic IPs.

Do You Need to Worry About Your IP Address?

Honestly? Not really.

Your IP address is like your phone number. It’s semi-public. Websites need it to function. And alone, it’s not that dangerous.

You SHOULD care about your IP if:

You’re worried about ISP tracking
You need to bypass geo-restrictions
You’re in a country with heavy internet censorship
You want more privacy online

You DON’T need to panic if:

Someone “found your IP” (they can’t do much with it)
You accidentally revealed it online
A website logged it (every website does this)

Quick FAQs

Q: Can someone find my exact address from my IP?
A: No. They can see your city/region, but not your street address.

Q: Does my IP change when I use mobile data vs WiFi?
A: Yes. Different networks = different IPs.

Q: Can I be tracked in incognito mode?
A: Yes. Incognito mode doesn’t hide your IP. It just doesn’t save your browsing history locally.

Q: Do I have the same IP as my neighbour?
A: No (unless you’re sharing WiFi). Each household gets its own public IP from the ISP.

Q: Is IPv6 better than IPv4?
A: Technically, yes (more addresses, better routing), but for normal users, it doesn’t matter much.

In Summary

Your IP address is your internet identity card. It’s necessary for the internet to work, but it also reveals information about you.

Should you hide it? Depends on your privacy needs.

Should you panic if someone knows it? No.

Should you use a VPN? If you care about privacy, yes.

Most importantly: Your IP address is just one piece of your digital footprint. If you care about privacy, focus on the bigger picture, use HTTPS, strong passwords, two-factor authentication, and be smart about what you share online.

Here’s my source code for the IP address checker on my Github.

Want to hide it? Get a VPN.

Want to learn more? Drop questions in the comments.

Is ChatGPT Making You Dumber? How to Use AI Without Killing Your Brain

Laurina Ayarah — Thu, 27 Nov 2025 13:31:52 +0000

YOU! Come here. Remember how we all wanted AI to make life easier?

For school assignments. Better emails. Faster code. Better writing. Instant answers to absolutely everything.

And it worked.

But somewhere along the way, something changed. We stopped thinking. We stopped Googling. We stopped trying to figure things out on our own before asking AI to do it for us.

And now? I’m starting to wonder if AI is quietly making us mentally lazy.

The Problem Nobody Wants to Talk About

Here’s what I’ve noticed in myself and in everyone around me:

We’ve stopped thinking first.

Got a coding problem? Ask ChatGPT.
Forgot a Git command? Ask AI.
Don’t understand a concept? Copy-paste the AI explanation without really reading it.

We’ve replaced learning with prompting.

Instead of understanding why something works, we just ask AI for the answer, copy it, and move on. We’re becoming really good at asking AI questions and really bad at figuring things out ourselves.

We trust AI outputs blindly.

How many times have you:

Copied code from ChatGPT without fully understanding it?
Used AI to write an email and sent it without really reading?
Asked AI for advice and just… did what it said?
I’ve done these, I can’t even lie. Multiple times this week.

What This Actually Looks Like

Let me give you some real examples:

Scenario 1: The Git Command You’ve Used 100 Times

Last night, I needed to undo my last commit.

Instead of thinking “oh right, it’s git reset -- soft HEAD~1" or even Googling it as I used to...

I just asked ChatGPT.

For a command I’ve used literally hundreds of times.

I didn’t even TRY to remember. I just went straight to ChatGPT because it was “faster.”

But was it? Or am I just training my brain to stop remembering things?

Scenario 2: The Developer Who Can’t Debug

A junior dev on Twitter tweeted: “ChatGPT wrote this function, but it’s not working. What’s wrong?”

Not “Here’s my code, here’s the error, here’s what I tried.”

Just: “AI gave me this, fix it.”

They couldn’t debug their own code because they didn’t write it. They don’t understand it.

Scenario 3: The Student Who Thought Agile Was a Frontend Framework

I watched this happen in real-time during a class presentation.

A student was presenting their project on software development methodologies. Everything sounded good until the Q&A.

Supervisor asked: “So how does Agile fit into your frontend architecture?”

The student, without hesitation: “Agile is a frontend framework...”

Dead silence.

The professor asked them to explain what they meant. They couldn’t. Just kept saying variations of “it’s a framework for organizing frontend code.”

They had no idea what Agile actually was. ChatGPT wrote the entire project, never bothered to understand it either.

The Consequences Are Real

Here’s what happens when you rely on AI for everything:

1. Your Problem-Solving Skills Atrophy
When you always have a crutch, you never learn to walk on your own.

You stop trying to debug. Stop thinking through solutions. Stop figuring out why something broke.

You ask AI.

And when AI isn’t available? You’re stuck.

Imagine you’re in a coding interview. The internet dropped mid-interview.

Suddenly, you can’t lean on ChatGPT for syntax you’ve forgotten.

Skill issues? Yes, and a dependence problem.

2. You Build Things You Don’t Understand
Ever copy a chunk of code from ChatGPT, paste it in your project, and it works… but you have no idea how?

Cool, your feature shipped.

But what happens when:

It breaks in production?
You need to modify it?
Someone asks you to explain your code in an interview?

You can’t. Because you didn’t write it. AI did.

3. Your Memory Gets Weaker
Remember when you’d struggle with something, finally figure it out, and then remember it?

Now? We just re-ask AI every time:

That Git command you used yesterday? Ask AI again.
The array method you looked up last week? Ask AI again.
The concept you had ChatGPT explain three times already? Ask AI again.

We’re not building knowledge anymore. We’re renting it from AI, over and over.

4. You Stop Being Creative
AI gives you answers. But creativity comes from exploring without answers.

From trying things that don’t work. From combining ideas in weird ways. From struggling and then figuring it out.

When AI solves everything instantly, you skip the struggle. And the struggle is where creativity lives.

But Here’s the Thing…

AI doesn’t make you dumb.

Your usage of it does.

Let me say that again: The tool isn’t the problem. How you use it is.

AI can make you smarter if you use it right.

How to Use AI Without Becoming Dumb

Here’s how I’m trying to fix this for myself:

1. Try First, Ask AI Second
Old habit:
Hit an error → immediately ask ChatGPT

New habit:
Hit an error → read the error message → Google it → try to fix it → then ask ChatGPT if stuck

Why it matters: You actually learn something. AI becomes a teacher, not a replacement.

2. Ask AI to Explain, Not Just Give Answers
Bad prompt:
“Write a function that fetches user data”

Good prompt:
“Explain how to fetch user data with error handling. What are the steps and why?”

Then write it yourself using AI’s explanation as a guide.

3. Don’t Copy-Paste Code You Don’t Understand
If ChatGPT gives you code and you don’t fully get how it works?

Ask it to explain line by line.

Or better yet: try to break it. Modify it. See what happens when you change things.

Understanding through experimentation > blindly trusting AI

4. Use AI as a Debugging Partner, Not a Solution Machine
Instead of:
“My code doesn’t work, fix it”

Try:
“Here’s my code and the error. What might be causing this? Walk me through debugging steps.”

You’re learning to debug, not just getting a fix.

5. Set Boundaries for AI Usage
I’m experimenting with:

30-minute rule: Spend 30 minutes trying to solve something myself before asking AI
No AI for basics: If it’s fundamental (loops, Git commands, array methods), I force myself to recall it from memory
Explain it out loud: After using AI, I explain the concept to myself. If I can’t, I didn’t learn it.

The Balanced Truth

AI is incredible when used right:

Speeds up boilerplate code
Helps you learn faster when you’re genuinely stuck
Explains complex concepts in simple terms
Acts as a rubber duck/brainstorming partner
Catches errors you might miss

But it’s dangerous when you:

Use it to avoid thinking
Copy without understanding
Let it replace learning fundamentals
Become dependent on it for everything

The difference? Whether you’re using AI as a tool or as a crutch.

My Honest Take

I love AI. I use it daily. ChatGPT has legitimately helped me learn faster, debug quicker, and build better.

But I’ve also noticed myself getting lazier. Less willing to struggle. Quick to outsource thinking.

And that scares me.

Because the developers I admire? The writers who inspire me? The people building cool shit?

They use AI to amplify their skills, not replace them.

They know when to use it. And when to turn it off and think for themselves.

The Real Question

Here’s what I’m asking myself now:

Am I using AI to get better, or am I using AI to avoid getting better?

Am I learning faster, or just appearing to learn while actually understanding less?

Am I building skills, or building dependence?

I don’t have all the answers yet. But I’m paying attention.

The Bottom Line

The smartest people of this decade won’t be the ones who use AI the most.

They’ll be the ones who know when not to use it.

They’ll be the ones who:

Struggle first, then optimize with AI
Understand fundamentals before taking shortcuts
Use AI as a teacher, not a brain replacement
Know the difference between speed and understanding

AI isn’t making us dumb.

But if we’re not careful, we’ll use it to make ourselves dumb.

So, are you using AI to get smarter? Or are you letting it make you lazy?

Be honest. Because I’m still figuring it out myself.

What’s your relationship with AI? Are you noticing this in yourself too? Drop your thoughts in the comments. I’d love to hear how you’re handling this.

Liked this one? Hit that like, share it, helps people find and learn more easily. Join the Dev.to community! I post more takes on web dev, design, Web3, and tech.

Building Delta Health: Frontend Adventures in Empowering Rural Clinics

Laurina Ayarah — Fri, 21 Nov 2025 21:56:54 +0000

I never thought I’d be building healthcare systems for rural clinics. And yet, here I am, late 2025, staring at lines of React code that feel like they might just save lives.

I’m a frontend developer. My world usually revolves around components, state, and CSS. But this project “Delta State Health Information & Appointment Booking System” pulled me out of my comfortable bubble and threw me into a reality that’s messy, complex, and astonishingly human.

Let me tell you what it’s like.

When Technology Meets Reality

Working on rural healthcare in Delta State isn’t like coding for a SaaS startup in Lagos or Abuja. Here, the constraints are real: intermittent internet, limited tech literacy, stretched clinic staff, and patients whose days are consumed by survival, not appointments.

Our challenge as a team wasn’t just to build software; it was to create a system that could function in an imperfect world, a tool that people could actually rely on, without adding frustration. And it had to work for everyone:

Patients with smartphones
Patients with feature phones
Clinics with one computer and a pile of paperwork

The system had to adapt to human realities, not force humans to adapt to the system.

My Role: Making the Invisible, Tangible

As the frontend developer, my responsibility was deceptively simple: make this complex system usable, intuitive, and reliable. But “simple” in this context was anything but.

Interfaces had to be intuitive: Even users who had never used a web app before had to understand it. Buttons, forms, alerts, they had to communicate clearly.

Responsiveness mattered:Some patients were on tiny phones with small screens; some on larger devices. Every pixel mattered.

Data visualization was crucial: Clinics needed dashboards that didn’t just show numbers; they had to tell a story about patient flows, appointments, and recurring health issues.
It was a balancing act. I had to take raw backend data, appointments, patient info, clinic capacity, and turn it into something people could grasp in seconds.

The Stack That Made It Possible

We weren’t reinventing the wheel. We had tools, and we leveraged them meticulously:

Frontend: React + Next.js for dynamic, interactive, and server-rendered components that could scale

Backend: Laravel + PHP, providing secure endpoints and business logic

Database: MySQL, storing patient records, appointments, and clinic data reliably

Integrations: Twilio for SMS notifications, Google Maps API for mapping clinics, and email reminders for patients who prefer digital communication

Every line of code, every component, every API call had a purpose. This wasn’t just a project; it was a lifeline.

The Experience: Learning on Fire

Working on Delta Health wasn’t just coding. It was empathy in motion.

I learned about patients: Why missed appointments happen. Why follow-ups don’t happen. Why access to information transforms behavior.

I learned about clinics: The pressure staff operate under. How a small dashboard can reduce hours of manual work. How they measure success in minutes saved, not lines of code.

I learned about teamwork: This wasn’t a solo endeavour. Backend devs, database engineers, health experts, and project managers all contributed. My role was to make their work visible and usable.

There were nights I stared at my laptop, wondering if a dropdown would confuse users, or if the font size on a notification was readable on a small device. And yet, that was exhilarating. This was code with immediate, tangible impact.

Making Technology Accessible

One of the hardest and most rewarding parts of frontend work in this project was accessibility.

We had to ensure that:

SMS notifications didn’t just send a message, they conveyed information clearly to someone who may not be tech-savvy.
The web interface worked offline or under poor connectivity.
Colours, labels, and interactions were intuitive across age groups, literacy levels, and device types.

I didn’t just code buttons, I coded trust. And every user interaction mattered.

Lessons I’ll Carry Forward

Working on Delta Health taught me things no tutorial ever could:

Code for humans first, devices second. A beautiful component means nothing if the person using it doesn’t understand it.
Frontend isn’t decoration, it’s impact. I always thought of my work as “making things look nice.” Here, every pixel could improve a patient’s experience or a clinic’s workflow.
Collaboration is everything. I am not a backend expert, nor am I a healthcare professional. But I am a bridge, transforming logic and data into something tangible. That’s powerful.
Simplicity is the ultimate sophistication. The most elegant solutions were rarely the most complex, they were the ones that worked effortlessly for the user.

The Bottom Line

Delta Health is live now. Real people are using it. Real clinics rely on it. And somewhere in that chain of impact, there’s a piece of code I wrote, a button, a layout, a flow, quietly making someone’s day smoother. Patients can book appointments, receive reminders, and access health information. Clinics can finally see who’s coming, when, and what resources they’ll need without digging through piles of handwritten notes.

That’s what stays with me. Not the syntax. Not the tools. But the fact that something I built is out there in the wild, doing work that matters, helping real humans navigate something as important as their health.

I’m proud of my work, proud of my team, and proud of what this project represents: technology that listens, adapts, and serves. For me, that’s the heart of frontend development, not just making things look good, but making them meaningful.

Live Demo: Delta Health
Source Code: GitHub

If this piece resonates with you, go ahead and click the follow button and hit that like button. Share with your friends, colleagues, etc, if you’re into honest takes on frontend dev, design, Web3, and the reality of building things that actually matter, you can reach out to me on X (Twitter). I write the way I build, simply, clearly, and with intention.

Your Web3 Product’s UX Is Driving Users Away.

Laurina Ayarah — Sun, 16 Nov 2025 21:08:59 +0000

As a frontend developer who’s watched countless people, parents, friends, newcomers try and fail to use Web3 applications, I need to be direct: most Web3 UX is unacceptably bad. Not “needs improvement” bad. Not “could be better” bad. It’s “watch someone give up in real-time” bad.

This isn’t about aesthetics or minor usability tweaks. This is about fundamental barriers that prevent otherwise capable people from using your product at all. If you’re building in Web3, your users are leaving before they even start. And the problem isn’t them, it’s your interface.

The Reality: Users Are Quitting During Onboarding

I’ve used Binance. The experience is a masterclass in user hostility, nested menus, unexplained terminology, critical actions buried under layers of navigation, and zero guidance for what to do next. For someone coming from traditional banking apps, it’s overwhelming to the point of paralysis.

Compare that to Phantom Wallet on Solana. Clean interface. Clear actions. Logical flow. It proves Web3 UX can work, which makes every other poor experience even less defensible.

But here’s what matters more than my opinion: I’ve watched non-technical people try to set up wallets, attempt their first transaction, or simply figure out what “gas fees” mean. Most don’t make it past the first few screens. They don’t persevere through confusing interfaces. They don’t Google every unfamiliar term. They just leave.

And they don’t come back.

Why Your Technical Team Doesn’t See the Problem

Most Web3 platforms are built by developers who already understand blockchain concepts, wallet mechanics, and transaction flows. If you’re reading this and you work in Web3, you probably set up your first wallet years ago. You instinctively know what “approve token allowance” means. You understand why transaction confirmations take time.

Your users don’t.

The disconnect happens because teams design for themselves rather than for their actual users. My survey of new users revealed that 36% are stopped by “big language that I truly dislike.” Another simply said, “I don’t know how it works.”

You’re building for a technical elite, not for the grandmother, the freelancer, or the curious newcomer. These users encounter:

Wallet setup that assumes prior knowledge: Multiple seed phrase warnings with no explanation of what they’re protecting against or why it matters.
Transaction flows that generate anxiety: Signing requests that look like security threats, fees that change without warning, irreversible actions with no safety net.
Interfaces designed for developers: Technical jargon presented without context, information density that overwhelms rather than informs.
Zero forgiveness for mistakes: One wrong click can mean permanent loss of funds with no customer service to call.

This isn’t a learning curve. It’s a cliff.

The Data Tells the Same Story, And It Gets Worse

A 2024 ConsenSys report found that 55% of potential users abandon onboarding during wallet setup. That’s not a small usability issue; that’s half your potential audience deciding your product isn’t worth the effort.

My own research echoes this at a granular level. When first-time users were asked what frustrated them most, the answers were telling:

60% cited fundamental confusion with concepts like “liquidity pools.”
40% were exhausted by the process itself, with one user stating, “Verification and too many words and steps… Before I can set up, I’m already tired.”
Nearly half reported getting lost in the interface after completing actions, with one saying, “I just got stuck looking for the tokens I swapped.”

Think about what that means for your growth metrics. You could have the most innovative protocol, the best tokenomics, the most robust security, and you’re still losing users because they’re tired, confused, and can’t find their own money. You can’t scale when your front door is locked.

What Actually Works: Lessons From Products Users Can Use

Some Web3 products have figured this out:

Phantom Wallet succeeded on Solana by treating UX as seriously as security. Clean visual hierarchy, progressive disclosure of complexity, and onboarding that guides rather than gatekeeps. Users can complete basic tasks without understanding Solana’s architecture.

Lens Protocol delivers decentralized social media using familiar interaction patterns from Web2. Users don’t need to understand the underlying protocol to post, follow, and engage.

Base by Coinbase abstracts blockchain complexity during onboarding. New users can start transacting without first becoming blockchain experts.

An everything app that brings together a social network, apps, payments, and finance. One place to earn, trade, and chat with everyone, everywhere.

These aren’t dumbed-down versions of Web3. They’re properly designed versions that respect users’ time and cognitive limits.

How to Fix This: Actionable Changes for Development Teams

1. Start With User Testing, Not Assumptions
Watch someone who’s never used crypto try to use your product. Don’t help them. Don’t explain things. Just observe where they get stuck, confused, or frustrated. Those moments are your UX failures; fix them first.

2. Write for Humans, Not Developers
Replace every piece of jargon with plain language. “Approve token allowance” becomes “Let this app access your tokens for this transaction.” If you can’t explain a concept in simple terms, your interface shouldn’t expose it to users.

3. Design Mobile-First
In emerging markets where Web3 has the most potential impact, mobile is the primary access point. If your interface requires a desktop computer and MetaMask extension, you’ve already excluded most of the world.

4. Build Progressive Onboarding
Let users explore limited functionality before requiring wallet setup. Show value before demanding commitment. Each additional step should feel earned and necessary, not arbitrary.

5. Provide Contextual Help When It Matters
Don’t hide documentation in separate help centers. Integrate tooltips, inline explanations, and interactive guides exactly where users need them. When someone hovers over “gas fee,” explain it right there in language they understand.

6. Add Safety Rails for Irreversible Actions
Confirmation dialogs should clearly explain consequences: “This will permanently transfer X tokens to address Y. This cannot be undone.” Give users a moment to verify before they commit.

The Path Forward: UX as a Competitive Advantage

Web3 doesn’t have a technology problem; the infrastructure is mature and robust. Web3 has an accessibility problem. The winning projects in the next wave won’t be the ones with the most sophisticated protocols. They’ll be the ones that normal people can actually use.

If you’re building in Web3 right now, you have a choice. You can keep designing for developers and early adopters, accepting that your user base will remain small and technical. Or you can invest in real UX design from day one and build products that work for everyone.

Your competitors are making this choice right now. The ones who choose accessibility will reach mainstream adoption. The ones who don’t will remain niche curiosities, celebrated in developer communities but ignored by the market.

A Direct Call to Web3 Builders

If you’re a founder, product manager, or developer working in Web3, your UX is probably worse than you think. The friction you’ve normalized is driving away the users you need to succeed.

Test your product with people outside crypto. Watch them struggle. Feel the frustration. Then fix it.

Because right now, you’re not competing against other Web3 platforms. You’re competing against every Web2 app that lets users accomplish tasks without thinking about the underlying technology. Until your UX matches that standard, mainstream adoption will remain a distant goal rather than an approaching reality.

The future of Web3 depends on builders who care as much about user experience as they do about decentralization.

Be one of them.

Liked this one? Hit that like, share it, and follow me on X(Twitter).
I post more takes on web dev, design, Web3, and tech.

I Learned React + Next.js in Three Months Without Watching a Single Tutorial.

Laurina Ayarah — Fri, 14 Nov 2025 23:34:25 +0000

I’m going to tell you something that sounds fake but isn’t:

I built a full-stack healthcare booking system with React and Next.js before I ever watched a React tutorial.

Not “I watched tutorials first, then built.” Not “I learned the basics then jumped in.”

I just… built it. With zero React knowledge. Just JavaScript, Google, AI search tools, and pure desperation.

And honestly? I still don’t know if that makes me brave or just stupid. LOL!

How It Started (Badly)

I was a computer science student. Selling jewelry and accessories on the side to survive. Barely done with my internship, where all I did was write basic JavaScript and fix small bugs.

Then I got pulled into a project.

Full-stack healthcare booking system. Frontend was mine. Backend team was already working. Timeline? Three months!

Cool. Great. One problem:

I had never touched React. Or Next.js. Or any modern frontend framework.

I had JavaScript. That’s it.

And also, my life was kind of falling apart.

Not in a “I’m stressed about school” way…In a “I can’t function properly and everything feels heavy” way.

But I couldn’t say no because I needed the work. Because I was still trying to prove I could do this. Because saying “I can’t handle this right now” felt like an admission of defeat.

So I said yes. And immediately regretted it.

Week 1: Pretending I Understood Anything

The first team call was on Google Meet. Backend devs explaining the architecture, database structure, API endpoints, and project timeline.

I was nodding. Taking notes. Looking engaged.

Inside my head: “What the hell is SSR? What’s a component? Why does everyone keep saying ‘state’ like I’m supposed to know what that means?”

After the call, I stared at my laptop.

Then I opened Google. Typed: “How to build a website with Next.js”

And that’s how it started.
Not with a course. Not with a tutorial. Just me, a search bar, and a deadline.

The Friend Who Got Frustrated (And the One Who Saved Me)

I tried talking to a friend about what I was going through. About how overwhelmed I was. How I couldn’t think straight.

He got pissed by the way.

“You only ever talk about work”

“You need to deal with your personal stuff.”

“I already explained that!”

He was right. But I couldn’t explain that work was the only thing keeping me from completely falling apart.

Then I met one of the backend devs.

Different guy, didn’t really know me personally, had no reason to help me as much as he did.

But when I showed up in the project group with panicked questions about state management, he answered. Patiently. Without judgment.

When I apologized for not understanding something fast enough, he’d say: “You’re learning. It’s fine. Here’s how it works.”

He didn’t get frustrated. He just… helped.

Selflessly. The kind of help you don’t forget.

And somehow, with his guidance and a lot of Googling, I started figuring things out.

How I Actually Learned (The Messy Truth)

Here’s what nobody tells you:

You don’t need tutorials to learn. You need problems to solve.

I didn’t sit through a 10-hour React course. I didn’t watch “Next.js for Beginners.” I didn’t do the step-by-step.

I just started building.

When I needed a navigation bar, I Googled: “how to make navbar in Next.js”

When my form wouldn’t update, I searched: “Why is my state not updating React?”

When I needed to fetch data from the backend, I asked the AI search tool: “How to call API in Next.js?”

Every feature became a Google search. Every error became a learning moment.

I wasn’t studying React. I was using React to solve real problems. And somehow, that taught me faster than any tutorial ever could.

The Only Tutorial I Ever Watched (And When I Watched It)

Want to know the wild part?

I didn’t watch a single React tutorial until AFTER I finished the project.

Not before. Not during. After.

By the time I watched one, I already understood most of it. Because I’d already lived it.

The tutorial was just confirming what I’d learned by doing.

And that’s when I realized:

Tutorials teach you theory. Projects teach you reality.

What Was Actually Happening in My Life

While I was learning React and Next.js, I was also:

Attending university full-time (computer science student)
Selling jewelry and accessories to survive
Dealing with personal stuff that made it hard to function
Trying to keep up with assignments, exams, side hustle, and coding
Running on maybe 4–5 hours of sleep a night I was exhausted. Emotionally drained. Barely holding it together.

But the project gave me something to focus on. Something I could control when everything else felt out of control.

So I kept going.

Not because I was disciplined. Because I was desperate for something, anything, to work out.

The Moments I Almost Quit

There were days I’d stare at an error message for hours and feel like the dumbest person alive.

Days where I’d be photographing jewelry for Instagram (btw my account was disabled for NO REASON, when does it end!), then switching tabs to debug a Next.js API route, then rushing to a lecture, then coming home to code until 3 AM.

I felt like I was drowning.

But every time I wanted to quit, I’d remember:

If I quit this, what do I have left?

School? Overwhelming.
Personal life? A mess.
Side hustle? Barely paying anything.

This project was the one thing I could finish. The one thing I could control.

So I didn’t quit.

What We Built (Somehow)
Three months later, the project was done.

A full healthcare booking system. With:

User authentication
Appointment scheduling
Real-time clinic data
SMS notifications
Admin dashboard
Responsive design

Was it perfect? No.

Was my code clean? Absolutely not.

Did I cry multiple times during those three months? Yes. Yes. Yes.

But did it work? Yes. And that’s what mattered.

What I Learned About Learning

1. You Don’t Need Tutorials to Learn
I built an entire React + Next.js application without watching a single tutorial until after I was done.

How? Google. AI search tools. Documentation. Stack Overflow. Trial and error.

Tutorials are helpful. But they’re not required.

2. Real Projects Teach You Faster Than Courses
Courses teach you syntax. Projects teach you problem-solving.

I learned React by needing a component to work TODAY. Not “someday when I finish the course.”

3. You Learn Best When You Have No Other Choice
I didn’t choose to learn React and Next.js in three months. I was forced to.

And that’s the only reason I learned it that fast.

4. Imposter Syndrome Never Really Goes Away
Even now, I still feel like I don’t know what I’m doing for real.

But at the same time? I’m confident in my designs. In my work. In what I can build.

Both things can be true.

You can feel like a fraud and still be competent. That’s just how this works.

5. The Right People Make All the Difference
That backend dev who helped me selflessly? I wouldn’t have finished without him.

Learning isn’t a solo journey. It’s messy, collaborative, and deeply human.

The Uncomfortable Truth

Nobody talks about learning to code while your life is falling apart.

All the “learn to code” content is clean. Motivational. Inspiring.

But real life is messy.

You’re learning React while juggling school, side hustles, personal chaos, and trying to keep your mental health intact.

And you’re still expected to deliver.

So if you’re going through something right now and wondering how you’re supposed to learn while barely functioning, I see you.

You’re not weak. You’re surviving. And that’s enough.

Where I Am Now

I build React and Next.js applications. I still use tutorials when necessary, though.

Do I feel confident? Sometimes.

Do I still have imposter syndrome? Always.

But do I know I can figure things out? Yes.

Because if I can learn React and Next.js while my life was chaos, while selling jewelry between coding sessions, while attending university full-time, while barely sleeping,

I can handle anything.

What I’d Tell You

If you’re stuck in tutorial hell, waiting to “feel ready” before building something real, STOP. Like right now.

You don’t need another course. You need a project.

Pick something. Build it. Break it. Google the errors. Fix it. Ship it.

That’s how you actually learn.

Not perfectly. Not cleanly. But effectively.

And if some broke computer science student juggling school, a side hustle, and personal chaos can learn React without tutorials,

You definitely can too.

The Bottom Line

I learned React + Next.js in three months without watching a single tutorial.

Not because I’m smart. Because I didn’t have time to watch tutorials.

I had a deadline. A team depending on me. And no other option.

So I Googled. I asked questions. I broke things. I fixed them. I shipped.

And that’s the secret:

Sometimes the fastest way to learn is to stop preparing and start building.

P.S. Maybe one day I’ll write about how I started writing too. But that’s a story for another time.

For now? Just know that you don’t need to have it all figured out to start. You just need to start.

If this story helped you or made you feel seen, tap the like button. It helps more people find it.

Connect with me on X (Twitter) and LinkedIn. I’m always open to meeting people in tech and making new friends along the way.

I built my first NFT-Gallery in 2 days! https://dev.to/toboreeee/i-built-my-first-nft-gallery-in-2-days-and-didnt-lose-my-mind-44ha

Laurina Ayarah — Fri, 07 Nov 2025 18:51:00 +0000

I Built My First NFT Gallery in 2 Days (And Didn’t Lose My Mind)

Laurina Ayarah ・ Nov 7

#webdev #nextjs #react #tutorial

Let's connect on X https://x.com/toboreeee

Laurina Ayarah — Fri, 07 Nov 2025 18:49:08 +0000

x.com

Hi guys! I'm Rina, a Front-end Developer and Technical Writer with almost 3 years of experience building web apps and creating clear, engaging technical content. I love connecting with fellow developers and tech enthusiasts from around the world. Let’s sha

Laurina Ayarah — Fri, 07 Nov 2025 18:46:56 +0000

I Built My First NFT Gallery in 2 Days (And Didn’t Lose My Mind)

Laurina Ayarah — Fri, 07 Nov 2025 13:33:54 +0000

I built my first NFT gallery in 2 days. No blockchain degree, no Web3 bootcamp, just me, some API docs, and a lot of confused Googling.

Two days ago, I had no idea how to fetch NFT data. Now I have a working gallery that displays any wallet’s NFTs. Here’s exactly how I did it (and all the dumb mistakes I made along the way)…

Here’s what I built: nft-gallery

And here’s how I did it, including all the stupid mistakes I made so you don’t have to…

What I Actually Built

It’s simple: you connect your wallet, and it shows all your NFTs in a grid. That’s it. Nothing fancy.

But getting there? That was a journey.

The Stack (What I Used and Why)

I went with Next.js because:

I already know React
Typescript (tsx)
API routes make backend stuff easy
Deployment to Vercel is literally one click

For wallet connection, I used RainbowKit:

Handles multiple wallets (MetaMask, Coinbase, WalletConnect)
Looks clean out of the box
Saves you from writing 100 lines of connection logic

For fetching NFT data: Moralis API

Free tier is generous
One API call gets all NFTs from a wallet
Documentation is actually readable

Day 1: Fighting With Wallet Connection

The goal: Get a “Connect Wallet” button working.

Reality: Spent way too long reading RainbowKit docs.

The setup looks scary:

'use client'

import '@rainbow-me/rainbowkit/styles.css'
import { RainbowKitProvider, getDefaultConfig } from '@rainbow-me/rainbowkit'
import { WagmiProvider } from 'wagmi'
import { QueryClient, QueryClientProvider } from '@tanstack/react-query'
import { mainnet } from 'wagmi/chains'

const config = getDefaultConfig({
      appName: 'NFT Gallery',
  projectId: '6344a99eb87ffdddeaac02a39972d21d', // from reown.com / WalletConnect Cloud
  chains: [mainnet],
  ssr: true,
})

const queryClient = new QueryClient()

export default function Providers({ children }: { children: React.ReactNode }) {
  return (
    <WagmiProvider config={config}>
      <QueryClientProvider client={queryClient}>
        <RainbowKitProvider modalSize="compact">
          {children}
        </RainbowKitProvider>
      </QueryClientProvider>
    </WagmiProvider>
  )
}

But here’s the thing, most of it is copy-paste from their docs. You just need:

A WalletConnect project ID (free from reown.com takes 2 minutes)
Copy their config code
Wrap your app in their providers

My mistake: I forgot to actually wrap my app in the providers. Spent 20 minutes staring at a blank screen, wondering why nothing worked. Check your layout.tsx first. Don’t be me.

Once it’s set up, though? The connect button is literally just <ConnectButton />. That's it.

It handles MetaMask, Coinbase Wallet, WalletConnect, everything. I didn’t have to write any of that logic.

Day 2: Okay, Now, How Do I Get the NFTs?
Connected wallet? Check.
Knowing what to do next? (give me a sec, let me breathe)…

So…

I needed to fetch NFT data. But from where? and how?

Enter: Moralis API.

The free tier gives you 40,000 requests/month, more than enough for a side project.

I created a Next.js API route (because I didn’t want to expose my API key):

// app/api/nfts/route.ts
export async function GET(request: Request) {
  const { searchParams } = new URL(request.url);
  const address = searchParams.get('address');

  // Call Moralis
  const url = `https://deep-index.moralis.io/api/v2.2/${address}/nft?chain=eth&format=decimal`;

  const res = await fetch(url, {
    headers: {
      'X-API-Key': apiKey,
    },
  });

  const data = await res.json();
  return NextResponse.json(data);
}

What I learned:

Moralis returns EVERYTHING about an NFT (metadata, images, contract info)
Some NFTs don’t have images (yes, really)
IPFS URLs are… interesting

What broke: First tried calling Moralis directly from the frontend. CORS said no. That’s why you need the API route.

P.S. CORS means Cross-Origin Resource Sharing. It’s basically a security rule built into browsers that controls which websites are allowed to talk to each other.

Making It Not Look Terrible
Now I had NFT data. Time to actually display it.

{nfts.map((nft, i) => {
  const image = 
    nft.normalized_metadata?.image ||
    nft.collection_logo ||
    nft.collection_banner_image;

  return (
    <div className="bg-[#141414] rounded-2xl...">
      {image ? (
        <img src={image} alt={nft.name || "NFT"} />
      ) : (
        <div>No Image</div>
      )}
      <h2>{nft.name || "Unnamed NFT"}</h2>
    </div>
  );
})}

Things that surprised me:

Not every NFT has an image. Some are just… data? Had to add a “No Image” fallback or the whole thing broke.
NFT names can be null. Because why would every NFT have a name? That would make too much sense.
Loading takes time. 2–3 seconds to fetch. If you don’t show a loading state, users think it’s broken.
Tailwind Grid is actually nice. grid gap-6 grid-cols-1 md:grid-cols-3 - boom, responsive without writing media queries.

The Demo Wallet Trick
I wanted people to see it work without connecting their wallets. So I used a random public wallet address as a fallback:

const walletAddress = isConnected
  ? address
  : "0xED5AF388653567Af2F388E6224dC7C4b3241C544";

Just Googled “Ethereum wallet with NFTs” and grabbed one. Now visitors see NFTs immediately, but can still connect to view their own.

Deployment (The Only Easy Part)

git push origin main
vercel deploy

Done. 5 minutes. Vercel is magic.

What Still Annoys Me

Error messages are generic and boring
No search bar
Some wallets have HUNDREDS of NFTs, no pagination
The code could be cleaner
Dark mode is the only mode (should add a toggle)

But it works. And that’s what matters.

Honestly?
Building this taught me that Web3 frontend development is just… frontend development. With some extra APIs.

You don’t need to understand blockchain internals. You don’t need to write Solidity. You just need to:

Connect wallet (libraries handle this)
Fetch data (APIs handle this)
Display it nicely (React + Tailwind handle this)

Is my code perfect? No.
Is it production-ready? Also no.
Did I learn a ton? Yes.

Live demo: nft-gallery (let me know what you think)
Code: GitHub (checkout my GitHub)

If you build something with this, drop the link below. I’d really love to see it. And if you get stuck on some weird error, comment it —maybe I experienced it too!