Taking Risks: Why Stability is an Illusion

Stability is a trap. From leaving high-volume WordPress freelancing to moving to Ireland for Cloud Engineering, here is why risk is the only real security.

Most people view their careers through the lens of a relentless, desperate search for solid ground. We are taught from university - or even earlier - that the goal of engineering is to find a company with a good breakroom, a matching 401k (or pension), and a tech stack that doesn't change too much. We call this "stability."

It is a lie.

Stability in the tech industry is actually just slow-motion decay. If you are standing still in a field that moves at the speed of light, you aren't stable. You are obsolete. You just haven't looked down to see that the floor fell out yet.

I realized this while I was deep in the trenches of high-volume WordPress freelancing. I was making money. Good money. I had a queue of clients wanting custom themes and plugin tweaks. By all traditional metrics, I was successful. I had "made it."

But I looked at the code I was writing. It was PHP spaghetti, tangled with jQuery, dependent on a monolithic architecture that felt like it was held together by duct tape and prayers. I looked at the market. Headless CMS solutions were rising. React was eating the web. Serverless functions were replacing managed hosting.

I had two choices. I could keep riding the WordPress wave until it crashed into the shore of low-code/no-code builders like Webflow and Framer. Or I could burn the boats.

I chose the latter. I packed my bags, left my comfort zone in Nigeria, and moved to Ireland to pursue a Masters in Cloud Computing. I pivoted my entire engineering philosophy from "patching legacy code" to "architecting scalable systems."

Here is why playing it safe is the most dangerous thing you can do.

The Monolith Trap

Let's look at this from a systems architecture perspective. It clarifies everything.

In the old world, we built monoliths. You had your server, your database, and your application logic all tightly coupled in one giant box. It feels safe because it is all in one place. You can touch it. You can SSH into it.

But what happens when traffic spikes? What happens when one module fails? The whole thing crashes. This is exactly how most people treat their income and their skills.

They have a Monolithic Career. One employer. One skill set. One location.

If that employer fails, or if that skill becomes redundant (looking at you, manual QA testers in the age of AI), your entire life crashes. That isn't stability. That is a single point of failure (SPOF).

When I started studying AWS and Azure deeply, the concept of decoupling fascinated me. In the cloud, we design for failure. We assume things will break. So we build distributed systems.

We use microservices or serverless functions. If the authentication service goes down, the static content is still served. If one availability zone floods, the traffic routes to another.

This is how I approach my career now. I am not just a "WordPress Developer." I am building a distributed portfolio of assets and skills.

High-Level Education: My Masters in Cloud Computing.
Hard Tech Skills: Next.js, TypeScript, Supabase, Postgres.
Indie Hacking: Building my own SaaS products that generate revenue while I sleep.
Content: Documenting the journey to build authority.

If one of these nodes fails, the system stays online. That is true reliability. It looks risky to the outside observer because I am juggling a lot, but it is actually much safer than betting everything on a single 9-5 contract.

The Technical Pivot: Why I Dumped PHP for the T3 Stack

Transitioning from PHP to the modern stack (Next.js, Tailwind, Supabase) was not just a trend-chasing move. It was a calculation of leverage.

With WordPress, I was fighting the framework. To build a truly dynamic, app-like experience, I had to hack around the DOM, inject React into random divs, or deal with the nightmare of the WordPress REST API.

Here is a standard, painful way I used to handle data fetching in a custom WP plugin:

function get_custom_data() {
    global $wpdb;
    $results = $wpdb->get_results( "SELECT * FROM {$wpdb->prefix}custom_table WHERE status = 1" );
    
    if ( empty( $results ) ) {
        return null;
    }
    
    // Manually sanitizing and formatting output because the ORM is weak
    $formatted = [];
    foreach ( $results as $row ) {
        $formatted[] = [
            'id' => $row->id,
            'name' => esc_html( $row->name )
        ];
    }
    return $formatted;
}

It works. But it scales poorly. It is imperative, verbose, and tied strictly to the server instance.

Now, look at the freedom of using Supabase with TypeScript in a Next.js environment. This isn't just code; it is leverage. I can define my schema, generate types, and interact with my database directly from the client (safely) or edge functions without managing a single server.

import { createClient } from '@supabase/supabase-js'
import { Database } from '@/types/supabase'

const supabase = createClient<Database>(req_url, key)

// Type-safe, auto-completed, and runs on the Edge
const { data, error } = await supabase
  .from('projects')
  .select('*')
  .eq('status', 'active')

if (error) console.error(error)

The risk here was the learning curve. I had to learn React hooks, hydration, server vs. client components, and RLS (Row Level Security) policies. I spent weeks feeling stupid. I felt slow.

But that temporary drop in productivity was the price of admission for future velocity. Now, I can ship a full SaaS MVP in a weekend using Shadcn UI and Supabase. In my old stack, setting up the environment and boilerplate took that long.

The risk of learning new tech is an illusion. The real risk is being the best mechanic for a car they stopped manufacturing in 2010.

The Ireland Move: Geography is Arbitrage

Moving to Ireland was perhaps the biggest "risk" on paper. I left my family, my friends, and a cost of living where my currency went a long way. I moved to a high-cost environment with a rigorous academic schedule.

Why?

Because environment dictates output.

In cloud engineering terms, I moved my availability zone. I needed to be closer to the backbone of the internet. Ireland is the data center capital of Europe. Amazon, Google, Microsoft - they all have massive footprints here. Being physically present in this ecosystem changes the opportunities available to me.

It also forced a hard reset on my mindset. When you are an immigrant student, you have no safety net. You have to perform. That pressure is a feature, not a bug. It forces you to optimize your time and your focus.

I see so many developers staying in their hometowns, complaining about the lack of local opportunities. We live in a digital world, yes. Remote work is real. But physical proximity to innovation hubs still matters. The conversations you overhear in a pub in Dublin are different from the conversations in a cafe in a non-tech city.

Taking the risk to move was about increasing my Surface Area of Luck.

Indie Hacking: The Ultimate Hedge

Working for a corporation is renting your time. Indie Hacking is building equity.

The biggest lie in the software industry is that being a "Senior Engineer" at a Big Tech company is the pinnacle of safety. I watch LinkedIn. I see the #OpenToWork banners on people who were making $250k a year doing niche work on proprietary internal tools.

If you are laid off, and your only skill is navigating the internal bureaucracy of Google, you are in trouble.

Indie Hacking forces you to be a generalist. You have to understand product, marketing, design, database schema, and customer support.

When I build a project now, I am not just writing code. I am validating a market.

For example, I recently started exploring AI wrappers. The "safe" engineer says, "Oh, that's just a wrapper, it's not real engineering." The Indie Hacker says, "There is market demand here, I can ship this in 48 hours, and I can start collecting emails."

I am using the T3 stack (Tailwind, TypeScript, tRPC/Next.js) because it allows me to move at the speed of thought. I don't have to wait for a product manager to write a JIRA ticket. I just build.

If I launch a product and it fails? I lost a weekend. I gained knowledge. If I launch a product and it hits? I gain a recurring revenue stream that pays my rent whether I have a job or not.

That is financial resilience.

The Architecture of a Risk-Taker

So, how do you actually execute this without ruining your life? You don't just jump off a cliff. You take asymmetric bets.

An asymmetric bet is a scenario where the potential downside is capped (and known), but the potential upside is uncapped.

The Downside: I spend 6 months studying for my Masters and learning Next.js. I lose some sleep. I make less money from freelancing in the short term.
The Upside: I quadruple my earning potential. I build a SaaS that gets acquired. I secure a Cloud Architect role in Europe.

The math is obvious.

Here is how I structure my week to balance this:

Core Stability (60%): My Masters degree. This is the foundation. It gets me the visa, the network, and the theoretical depth in distributed systems.
Upskilling (20%): grinding LeetCode, learning Terraform, mastering Supabase Edge Functions. This keeps me sharp for the job market.
Wild Bets (20%): Building my own apps. Shipping side projects. Writing this blog. This is the lottery ticket bucket. If one of these takes off, the ROI is infinite.

Most people spend 100% of their time on Core Stability. They work their job, they go home, they watch Netflix. They are optimizing for a local maximum.

Shipping is the Only Truth

You can read all the books on Cloud Computing you want. You can watch a hundred tutorials on the "Perfect Next.js Setup."

But until you ship, you haven't taken a risk. You are just larping as an engineer.

Real risk involves the possibility of public failure. It involves pushing a commit that breaks production. It involves launching on Product Hunt and getting zero upvotes.

I crave that feeling now.

When I was strictly a WordPress freelancer, I was terrified of breaking things. Now, using modern CI/CD pipelines with Vercel and GitHub Actions, I push code multiple times a day. If it breaks, I revert.

name: E2E Tests
on: [push]
jobs:
  cypress-run:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Run E2E
        uses: cypress-io/github-action@v2
        with:
          build: npm run build
          start: npm start

This automation gives me the confidence to take risks. I have safety rails.

Conclusion: Stop optimizing for a world that doesn't exist

The world where you work for one company for 40 years and retire with a gold watch is gone. It died somewhere between the 2008 crash and the invention of ChatGPT.

Stability is an illusion created to keep you docile. It keeps you in the middle lane, driving the speed limit, while the people who understand leverage zoom past you.

Moving to Ireland was a risk. Switching to the Cloud was a risk. Betting on Indie Hacking is a risk.

But staying where I was? That was a guarantee. A guarantee of stagnation.

Go break something. Ship that half-finished project. Apply for the job you aren't qualified for. Move to a new city.

The floor isn't as solid as you think, so you might as well learn how to fly.