The Emmanuel Asika Story: 10 Years of Writing Code & Content

From hacking PHP in WordPress to architecting cloud infrastructure in Ireland. Here is the raw, 10-year evolution of my tech stack, mindset, and career.

Ten years. That’s a decade of staring at screens, debugging logic errors, and trying to explain to non-technical people why their website is broken.

If you looked at my GitHub contribution graph or my portfolio today, you’d see a lot of Next.js, Supabase, and AWS configurations. You’d see a guy obsessed with Cloud Engineering and shipping SaaS products. But the path here wasn’t linear. It wasn’t a straight shot from a CS degree to a FAANG cubicle.

It was messy. It involved a lot of bad PHP, thousands of hours of writing content, and a complete architectural shift in how I view software. This isn't just a biography. It's a dissection of a decade-long technical evolution. From modifying functions.php via FTP to deploying serverless architectures in the cloud.

The Cowboy Coding Era (2014-2019)

We need to talk about where I started because it informs everything I do now. I didn’t start with strict type safety or CI/CD pipelines. I started with WordPress.

Back then, "deployment" meant dragging a folder from my desktop into FileZilla and praying the connection didn't drop halfway through. If you know, you know.

I wasn't just building sites. I was churning them out. High-volume delivery taught me something that a lot of perfectionist engineers miss: shipping is the only metric that matters. Clients didn't care about the cleanliness of the code or whether I used a factory pattern. They cared if the checkout button worked.

But technically? It was the Wild West.

I remember writing loops inside of loops in PHP files mixed directly with HTML. It looked something like this:

<?php
  $args = array( 'post_type' => 'product', 'posts_per_page' => 10 );
  $loop = new WP_Query( $args );
  while ( $loop->have_posts() ) : $loop->the_post();
    echo '<div class="product-item">';
    the_title();
    echo '</div>';
  endwhile;
?>

There was no separation of concerns. The database logic lived right next to the <div> tags.

While this period was profitable, it was technically suffocating. I hit a ceiling. I realized that monolithic CMS structures were great for basic content but terrible for complex applications. I was fighting the framework rather than using it. I needed more control. I needed to understand what was happening under the hood of the server.

The Pivot: Writing as a Debugging Tool

Somewhere in the middle of the chaos, I started writing.

Not code. English.

I realized that if I couldn't explain a technical concept in simple terms, I didn't actually understand it. Writing became my primary debugging tool. When I was stuck on a complex logic problem, I would write a tutorial about it.

This bridged the gap between being a "coder" and being an "engineer." A coder writes syntax. An engineer solves problems and communicates the solution.

Writing technical content forced me to slow down. You can't fake knowledge when you're writing a 2,000-word guide on DNS propagation or asynchronous JavaScript. You have to research it. You have to verify it.

This habit of documentation is what eventually led me to Cloud Engineering. In the cloud, if you don't document your infrastructure, you're building a time bomb. Writing trained me for the meticulous nature of AWS and Azure architecture.

The "Oh Sh*t" Moment: Discovering Modern Stacks

The real shift happened when I tried to build a dynamic app with WordPress and realized I was using a hammer to drive a screw. The page loads were slow. The database queries were heavy. The user experience felt clunky.

Enter the JavaScript ecosystem.

Switching from PHP to JavaScript (specifically React and Node.js) was painful at first. I missed the ease of WordPress hooks. But then I saw the power of the Virtual DOM and state management.

The concept of a decoupled architecture changed my life. Instead of the server sending a fully formed HTML page, the server just sends raw data (JSON), and the client builds the UI.

Look at the difference in mindset. In my old world, I queried the database to print HTML. In my new world (Next.js + Supabase), I query the database to get data, which I then hydrate into components.

// The modern approach using Supabase client
const { data: products, error } = await supabase
  .from('products')
  .select('*')
  .limit(10)

if (error) console.error('Error fetching:', error)

// This data is then passed to a React component
// No HTML generation happens here.

This shift gave me freedom. I wasn't tied to a theme structure anymore. I could build anything. This is when I fell in love with Next.js. It offered the SEO benefits of server-side rendering (which I was used to from PHP) but with the interactivity of a SPA (Single Page Application).

Going Deep: Cloud Engineering & The Masters

Building apps is one thing. Hosting them so they don't crash when 10,000 people hit the link is another.

I decided to pivot hard into Cloud Engineering. I moved to Ireland to pursue a Masters in Cloud Computing. Why? Because I wanted to understand scale.

Freelancing teaches you how to handle one server. Cloud engineering teaches you how to handle thousands.

I started diving into AWS and Azure. The complexity was intoxicating. It wasn't just about "hosting" anymore. It was about:

Load Balancing: Distributing traffic so no single server dies.
Auto-scaling: Spinning up new resources automatically when traffic spikes.
IAM (Identity and Access Management): The absolute nightmare of permissions that keeps data secure.

My perspective shifted from "Does the code work?" to "Is the infrastructure resilient?"

I fell in love with Infrastructure as Code (IaC). Using tools like Terraform, I could define my entire server environment in code files.

resource "aws_instance" "app_server" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  tags = {
    Name = "EmmanuelsAppServer"
  }
}

If I messed up a server configuration, I didn't have to SSH in and fix it manually. I just destroyed the resource and ran terraform apply again. This was the ultimate version of the "freedom" I had been chasing for 10 years. The ability to destroy and rebuild worlds with a few keystrokes.

The Indie Hacker Mindset: Merging the Two Worlds

So here I am. A Cloud Engineer with a freelancer's hustle. This combination is dangerous.

Most corporate engineers get stuck in analysis paralysis. They spend weeks designing the perfect microservice architecture for an app that has zero users.

Most freelancers ship fast but build unscalable spaghetti code that falls apart under pressure.

My goal is to sit right in the middle. I call it the Scalable Indie Hacker.

I use the heavy-duty tools of the enterprise (AWS, TypeScript, PostgreSQL) but I use them with the speed of a startup.

My current stack reflects this balance:

Next.js (App Router): For the frontend and API routes. It's fast, structured, and deploys anywhere.
Supabase: It’s Postgres wrapped in a nice DX. It gives me the relational database power I need without the management overhead of raw RDS.
Tailwind + Shadcn/ui: I don't write CSS from scratch anymore. It's a waste of time. Shadcn gives me accessible, beautiful components that I can copy-paste and own.
Vercel/AWS: Vercel for the frontend, AWS for when I need heavy compute or specific services like S3/Lambda.

This stack allows me to go from idea to deployed SaaS in a weekend. But unlike my WordPress days, the code is clean, type-safe, and ready to scale if the product takes off.

The Importance of "Boring" Tech

Over 10 years, I've seen frameworks rise and fall. Anyone remember Backbone.js? Exactly.

I’ve learned to bet on "boring" technology. SQL is boring. It works. Linux is boring. It runs the world.

I see a lot of new devs jumping on the latest hype train every week. They spend all their time learning the tool and no time building the product.

As an Indie Hacker, I stick to what I know works. I don't experiment with my production stack. I experiment with the product features.

If I need to add a feature, I ask: "What is the simplest, most reliable way to ship this?" Usually, the answer isn't a bleeding-edge library that was released yesterday. It's usually a standard SQL query or a basic API hook.

The Role of AI in the Next 10 Years

You can't talk about code in 2024 without talking about AI.

Some devs are scared. They think Devin or ChatGPT is going to take their jobs.

I disagree. I view AI as a force multiplier. It replaces the grunt work. It writes the boilerplate. It helps me regex string patterns that I’ve never bothered to memorize.

But AI cannot architect a system. It doesn't understand the context of a business requirement. It doesn't know that your client, Bob, hates the color blue or that the legacy database has a weird schema quirk from 2016.

I use AI to code faster, not to think for me. I use it to generate the initial structure of a component or to explain a weird error message.

// I might ask AI to generate a Zod schema for form validation
// But I still have to integrate it into the user flow myself.
const formSchema = z.object({
  username: z.string().min(2).max(50),
  email: z.string().email(),
})

The engineers who will win in the next decade are the ones who can orchestrate AI tools to build systems, not the ones who just write syntax. We are moving from "Software Writers" to "Software Architects."

Building for Freedom

Why do I do all this? Why the Masters in Ireland? Why the late nights debugging Terraform scripts?

It’s not for the accolades. It’s for freedom.

Code is the greatest leverage available to an individual in human history. With a laptop and an internet connection, I can build a system that works for me while I sleep.

When I was strictly freelancing, if I stopped working, the money stopped. If I went on vacation, my income went on vacation.

With SaaS and Cloud Engineering, I am building assets. I am building systems.

This is the philosophy I'm taking into the next 10 years. I'm not just trading time for money anymore. I'm trading code for value.

What's Next?

I am currently heads-down on a few things:

Finishing the Masters: Solidifying the academic, theoretical side of distributed systems.
Shipping Micro-SaaS: I have a notebook full of ideas. I'm validating them one by one. Ship fast, fail fast, learn.
Content Creation: I'm documenting this journey. Not just the wins, but the bugs. The billing alarms. The frustration.

If you are early in your journey, or if you are stuck in a stack that feels like a dead end, my advice is simple: Pivot.

Don't be afraid to throw away what you know. The skills transfer. The logic transfers.

I used to think my 5 years of WordPress were "wasted" when I moved to React. They weren't. They taught me how to deal with clients, how to structure data, and how to finish projects.

The stack changes. The mission remains the same: Build cool sh*t. value freedom.

Let's get back to work.