Ferdinand Web Academy

Ever got that “CORS error” and wondered why your code isn’t working even though everything looks right? It’s not really your code, the browser is just doing its job to protect users.

CORS (Cross-Origin Resource Sharing) is like having a security guard at your gate. You tell him exactly who can come in and who can’t. By default, browsers block all cross-origin requests, so if your frontend and backend are on different origins, your frontend will be blocked from talking to your backend.

If you’re new to backend development, this can look like a nightmare and feel stressful. But once you understand how CORS works, you’ll actually appreciate it. Your browser is helping you block all unauthorized origins by default, which keeps your app safe.

That’s where installing CORS comes in. You can do something like:
npm install cors
and then set it up as:
cors.allowOrigin("frontend_origin")

This means only your frontend can access your backend. If you have multiple frontends, you can pass them as an array and check if the current origin is allowed before giving access.

For better security, always allow specific origins instead of using *, avoid exposing sensitive routes, use HTTPS to prevent data interception, and handle credentials carefully if your app uses login sessions or tokens.

Ferdinand Web Academy

“The chicken and egg problem” The marketplace dilemma

The core problem of every marketplace is simple:

You need two sides to create value.

Supply and demand.

But neither side wants to join first.

👉 Suppliers don’t come without demand
👉 Demand doesn’t come without supply

This is the chicken and egg problem.

Logically, you cannot grow both sides at the same time in the beginning.

So you pick one side.

In most cases, you start with supply.

Why?

Because demand only stays if there is something to consume.

No one opens a marketplace to see nothing.

So the strategy becomes:

1️⃣ Acquire a small number of suppliers
2️⃣ Ensure quality and availability
3️⃣ Manually bring demand to them
4️⃣ Facilitate transactions yourself

At this stage, you are not running a scalable system.

You are manually simulating liquidity.

From my experience working on Camirent, this is the part that is not obvious until you start.

Building the platform is straightforward.

Creating initial liquidity is the real challenge.

Until there is consistent interaction between both sides, the marketplace is effectively empty.

And without liquidity, there is no value.

Most founders underestimate this.

They build the product first.

But in marketplaces, value is not in the product.

It is in the interaction between users.

Solve that first.

Ferdinand Web Academy

Vibe Code 👉 Vibe Check = “I have no idea what I just wrote… but it works!” 😂💻

It’s become clearer now🥲

I just spent $46.30 because I didn’t read the docs and I just assumed things would be fine.

Here’s what happened:

I usually don’t care much about hosting, so I use Railway’s Hobby Plan ($5) for my backend (server + Redis). My bills were usually around $7, so I was shocked when the last two months came to $22.30.

I thought it was because I added LibreTranslate and Elasticsearch. Later, my team and I decided to stop using them. They were too expensive for our free marketplace and small budget.

We assumed that if we didn’t use them, Railway wouldn’t charge us. But January’s bill came: $24.

Then I checked the docs carefully. I learned that Railway charges for every service that is running, even if you don’t use it, and extra if you go over your plan limits.

If I had read that earlier, I could have saved that money.

It might not seem like a lot, but imagine if it was hundreds of dollars on another host.

Lesson for developers, especially those on a small budget: read the docs, at least the parts about billing and usage. It can save you money and headaches.

Ferdinand Web Academy

For those of you developers planning to build a startup, let me tell you something I only truly understood after building Camirent and launching it.

When you start learning how to code, your biggest dream is basic but powerful:
“I just want to write my first function.”

Then you level up and your dream becomes:
“I want to build real projects.”

After that it turns into:
“I hope someone sees my work and I land a job.”

So you keep pushing.

More projects.
More skills.
More complex systems.
More confidence.

And one day you start thinking beyond just coding.

You start thinking like someone who wants to build a real product that solves a real problem.

That’s when reality hits.

Because you realize the part you thought would be the hardest, building the app, is not the hardest at all.

The hardest part is what comes after the launch.

Because users don’t care how clean your code is.
They don’t care how smart your architecture is.
They don’t care how long you spent perfecting the UI.

They care about results.

Does it help me?
Is it useful?
Is it better than what I’m already doing?

Building a good app is one thing.
But getting people to actually use it and keep using it is a whole different game.

These days, I even find myself wishing I could just hide in my code editor and build in peace 😂
But I can’t.

Because no matter how good the product is, if it’s not useful to users, it won’t survive.

For me, coding and building the app was the easy part.

What comes after, traction, adoption, trust, retention, especially with a low budget, that’s the real challenge.

Ferdinand Web Academy

As a developer, I always believed I could build almost any type of website using the MERN stack. That belief held until I started working seriously on Camirent, a marketplace designed to help renters find commercial and residential properties across Cameroon.

React has been great for building the product experience, but I eventually realized it falls short where an online marketplace matters most: SEO. Search engine visibility is one of the greatest assets a marketplace can have, yet properties listed on Camirent were unlikely to appear on search engines because of how traditional React applications work. With client-side rendering, the initial load shows mostly a skeleton, and the actual content is fetched afterward, making it difficult for search engines to index meaningful data.

I knew about this limitation early on, but I ignored it, driven by the excitement and flexibility of building a powerful SPA with React. Building Camirent taught me an important lesson: technical convenience should never outweigh business fundamentals.

I’m now taking the time to properly familiarize myself with Next.js and rethink how I approach frontend architecture, especially for SEO-driven marketplaces. If you’ve gone through a similar transition or have advice on building discoverable, scalable products with Next.js, I’d really appreciate your insights.

Ferdinand Web Academy

What do you really want to be called😀

I won’t call names, you know yourself😅

If you have ever planned on going into cyber security, now is the best time because these vibe coded apps are about to hit production and someone has to clean up the mess 😅🔐