Emmanuel Asika's Manifesto: Build Helpful Things

Software isn't about complexity; it's about utility. A manifesto on pivoting from freelancing to Cloud Engineering, and why Next.js, AWS, and 'helpful' code matter.

There is a noise in the software industry right now. A deafening, constant hum of new frameworks, AI wrappers, and people screaming about 10x productivity on Twitter. It is easy to get lost in it. It is easy to think the goal of software engineering is to write the most complex code possible or to use the bleeding-edge stack just because it exists.

That is wrong.

The goal is not to write code. The goal is not to master Kubernetes for a static blog. The goal is to build helpful things.

This sounds simple. It sounds like a platitude you’d find on a corporate motivational poster. But when you strip away the ego of engineering, "helpful" is actually the hardest metric to hit. It requires you to stop obsessing over the tool and start obsessing over the outcome.

I am pivoting. I am moving from a world where I built what clients asked for, into a world where I build what people actually need. From high-volume output to high-value systems. This is my manifesto on how I plan to do it, and the technical philosophy backing my shift into Cloud Engineering and Indie Hacking.

The fallacy of "Complex Equals Good"

For a long time, I equated lines of code with value. If I spent three days wrestling with a custom PHP implementation, I felt productive. I felt like an engineer.

But users do not care about your struggle. They do not care if you used a linked list or an array. They care if the button works. They care if the page loads in under a second. They care if the tool solves the pain that brought them there in the first place.

Building helpful things means killing your ego. It means choosing the boring solution if it solves the problem faster. It means recognizing that complexity is often just procrastination in a tuxedo.

We need to shift our focus from "How do I build this?" to "Why does this exist?"

The Stack: Next.js and Supabase as Velocity Multipliers

To build helpful things, you need speed. You cannot spend three weeks setting up authentication before you’ve even validated the idea. This is why I have gone all-in on the modern stack: Next.js, Tailwind, Shadcn, and Supabase.

This isn't just following trends. It is a strategic choice for velocity.

In the old days, setting up a backend meant spinning up a server, configuring Nginx, setting up a MySQL database, and writing boilerplate CRUD APIs. It was slow. It killed momentum.

Now, I use Supabase. It gives me a Postgres database, Auth, and Realtime subscriptions out of the box. I can move straight to the logic that actually helps the user.

Here is what "helpful" looks like in code. Instead of writing 500 lines of boilerplate to handle a user subscription status, I can write a reusable hook in Next.js that talks directly to Supabase. It is clean. It works.

import { createClient } from '@/utils/supabase/server'
import { redirect } from 'next/navigation'

export async function getSubscriptionStatus() {
  const supabase = createClient()
  
  const { data: { user } } = await supabase.auth.getUser()

  if (!user) {
    return null
  }

  const { data: subscription } = await supabase
    .from('subscriptions')
    .select('status, tier, current_period_end')
    .eq('user_id', user.id)
    .single()

  // Return the raw helpful data, no fluff
  return subscription
}

Notice the simplicity. No ORM configuration madness. No connection pool management in the application code. Just the data the application needs to function. This allows me to ship the feature today, not next week.

When we talk about Indie Hacking, this velocity is the difference between a launched product and a folder full of unfinished side projects.

Cloud Engineering: Scaling "Helpful"

But here is the nuance. "Helpful" does not just mean "it works on localhost."

Helpful means reliable. Helpful means scalable. If I build a tool that helps 10 people, that is good. If I build a tool that helps 10,000 people, but it crashes when the 11th person logs in, that is useless.

This is where my Masters in Cloud Computing comes into play. There is a distinct difference between a hacker and an engineer. The hacker gets it working. The engineer keeps it working.

While I love the speed of Vercel, understanding the underlying infrastructure on AWS or Azure is critical. You need to know what happens when the abstraction leaks. You need to understand cost optimization.

A truly helpful system is one that doesn't bankrupt the creator.

I am diving deep into AWS not because I want to manually configure EC2 instances for fun, but because I want to understand the architectural patterns that allow software to survive success.

Take Infrastructure as Code (IaC). It seems like overkill for a small project. But defining your infrastructure in code ensures that your environment is reproducible. It prevents the "it works on my machine" disaster.

Here is a snippet of Terraform. It might look boring. But this blocks public access to an S3 bucket. That protects user data. That is helpful.

resource "aws_s3_bucket" "user_uploads" {
  bucket = "asika-app-user-uploads-prod"
}

resource "aws_s3_bucket_public_access_block" "block_public" {
  bucket = aws_s3_bucket.user_uploads.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

This five-second configuration can save a company from a data breach. That is high-leverage engineering.

The Interface of Helpfulness

We cannot ignore the frontend. You can have the most robust AWS backend in the world, but if the UI is confusing, you have failed.

I use Shadcn UI and Tailwind CSS. Not because they are pretty, but because they are consistent. They force a structure. They stop me from wasting hours debating pixel widths.

My philosophy on UI is: Don't make them think.

If a user has to guess what a button does, the software is not helpful. It is a puzzle. I am not in the business of building puzzles.

When building with Next.js, I rely heavily on Server Actions now. It blurs the line between frontend and backend in a way that reduces cognitive load for the developer. Less context switching for me means faster bug fixes for the user.

The Role of AI in Being Helpful

AI is the elephant in the room. Everyone is wrapping OpenAI's API and calling it a startup.

I use AI daily. I use it to write boilerplate. I use it to debug regex. But I do not let it define the product.

AI should be an invisible layer of helpfulness. It shouldn't be the entire value proposition. If your entire app is just a prompt wrapper, you are building a feature, not a business. And features get sherlocked by Apple or Google eventually.

I am interested in using AI to parse unstructured data. To take messy inputs and give users clean outputs. That is where the value lies.

For example, imagine a tool for students here in Ireland that takes a messy PDF of a module syllabus and outputs a clean JSON calendar of deadlines.

// Pseudo-code for a helpful AI worker
async function parseSyllabus(text) {
  const completion = await openai.chat.completions.create({
    messages: [
      { 
        role: "system", 
        content: "Extract all dates and assignments. Return strictly JSON." 
      },
      { role: "user", content: text }
    ],
    model: "gpt-4-turbo",
    response_format: { type: "json_object" },
  });

  return JSON.parse(completion.choices[0].message.content);
}

The user doesn't care about the LLM model. They just want to know when the assignment is due. The AI is just the plumbing.

The Indie Hacker Reality check

Moving from freelancing to indie hacking is a psychological shift.

In freelancing, the scope is defined by the client. In indie hacking, the scope is defined by the market. And the market is brutal.

You can build the cleanest, most scalable Next.js app on a perfectly architected AWS VPC, and nobody might care.

This is why "Build Helpful Things" is the mantra. It forces validation. You have to ask: "Who is this helping?"

If the answer is "It helps me learn Rust," that is a hobby. That is fine. But do not call it a product.

If the answer is "It helps freelance writers generate invoices 50% faster," that is a product.

My current focus is on small bets. I am not trying to build the next Facebook. I am trying to build tools that solve specific, annoying problems I encounter in my own workflow or during my Masters program.

Ireland, Academia, and the Real World

Studying in Ireland has given me a new perspective. The academic approach to Cloud Computing is rigorous. It deals with algorithms, distributed systems theory, and security protocols.

Sometimes, it feels disconnected from the "ship fast" mentality of the web. But there is a middle ground.

The discipline of academia improves the chaos of indie hacking. It teaches you to read the documentation. It teaches you to understand the why behind the how.

I am taking these high-level concepts - load balancing, CAP theorem, containerization - and applying them to small SaaS products.

It is about bringing engineering rigour to the maker movement. You don't need a microservices architecture for a To-Do app. But knowing when you might need it prevents you from making architectural mistakes that are impossible to fix later.

The Path Forward

So, what does this look like in practice for Emmanuel Asika?

Shipping consistently. Not just code, but finished artifacts. Blogs, apps, open-source contributions.
Learning publicly. Sharing the AWS failures. Sharing the Supabase wins.
Ignoring the hype. If a new framework drops tomorrow, I will ignore it unless it solves a specific problem I have right now.

We have enough software in the world. We have enough apps that steal our attention and sell our data. We do not have enough software that genuinely respects the user's time and solves their problem efficiently.

That is the mission.

No more bloating the web. No more over-engineering for ego.

Just build helpful things. Then ship them.

And if it breaks? Fix it. That is part of the process too.

Let's get to work.