Blog

I came to this from the content side, so I learned SEO as a creator: keywords, titles, thumbnails, watch time. Learning it properly for client work meant discovering that the discipline had quietly forked underneath me.

Three acronyms, one shift

SEO is optimising to rank in a list of links. AEO, answer engine optimisation, is optimising to be the source an answer box quotes. GEO, generative engine optimisation, is optimising to be what a language model cites when someone asks it a question.

The difference matters because the win condition changed. Ranking third on a results page still got you traffic. Being the third best source for an answer that only quotes one gets you nothing.

What actually works, as far as I can tell

Be quotable. Answer the question in a single clean sentence near the top, then support it. Answer engines lift passages, not pages, so a passage that stands alone travels further than a beautifully structured argument that needs three paragraphs of run up.

Be structured. Real headings that match real questions. Schema markup where it applies. Facts stated plainly with numbers attached, because a specific claim is easier to cite than a vague one.

Be attributable. Say who you are and why you would know. Models and humans both weight sources, and an anonymous page of good advice loses to a named person with a track record.

The part that did not change

All of the above collapses into: write the genuinely useful thing, and make it easy to lift. That was already the advice ten years ago. The mechanism changed, the incentive did not.

For clients I now treat it as one job with three surfaces. You are not choosing between ranking, being quoted and being cited. You are trying to be the obvious source, and the three surfaces all reward that.

This portfolio has a 3D desk on the home page, a spinning globe, a lamp that turns the whole site to night mode. I built it to learn three.js, and picking a real thing to make taught me faster than any course would have.

The first cube is easy and misleading

Scene, camera, renderer, mesh, render loop. Twenty minutes to a spinning cube, and it gives you a completely false sense of progress. Nothing about a cube prepares you for a scene that needs to look intentional.

The difficulty is not geometry. It is everything around it: where the light comes from, what the material does with it, how the camera frames a composition, and how it all reads on a phone.

Lighting is the design

My early scenes looked like plastic toys. Same models, but flat. What fixed them was treating lights like a photographer would: one key light doing most of the work, a fill to stop the shadows going black, and a rim to separate objects from the background.

Once the lamp on the desk became the night mode switch, this got literal. Turning the page dark meant dimming the rig and boosting one bulb, and the mood change did more work than any CSS I wrote.

Performance is a mobile problem

Everything ran beautifully on my laptop and turned a mid range phone into a heater. Capping the pixel ratio, keeping the polygon count honest, disabling the whole scene when someone prefers reduced motion, and pausing the render loop when the tab is hidden. That list is most of the optimisation I needed.

Also: if the 3D fails to load, the site must still be a site. Every scene here is decoration over working HTML, and that was a decision made early, not a rescue later.

Build a thing, not a tutorial

I learned more from wanting a specific desk to look a specific way than I ever did following along with someone else's cube. Pick the thing you actually want to exist, then learn only what stands between you and it.

When I registered Orion Automation in Subang Jaya, I had a theory: the businesses that need automation most are the ones least likely to buy "AI transformation".

A kedai owner doesn't want a digital strategy deck. They want to stop manually copying WhatsApp orders into a spreadsheet at 11pm.

The busywork audit

Every engagement starts the same way: find the tasks that are (1) repeated, (2) rule based, and (3) resented. Posting schedules. Invoice chasing. Answering the same eight customer questions. Moving data from one app to another app that should have been talking to each other all along.

None of this is glamorous. All of it compounds. Six hours a week is 300+ hours a year. For a small team, that's a part time employee made of wasted clicks.

Why now, specifically

Two things changed. First, LLMs made the messy middle automatable: the unstructured stuff (emails, documents, chat messages) that old school automation choked on. An agent can read an enquiry, classify it, draft the reply, and log it. Second, tools like FastAPI, n8n, and managed databases collapsed the build cost. What needed a software house in 2020 needs one engineer who knows the stack in 2026.

The HYGR proof

I lived this before I sold it. Behind those 38M views was an automation pipeline for scheduling, analytics, and campaign tracking, built so the creative work didn't drown in admin. The magic on camera was subsidized by the boring systems behind it. That's the trade I now make for clients: keep the human moments human, automate everything else.

SEO used to mean pleasing Google. Now there's AEO and GEO: becoming the source that answer engines and generative engines cite. The businesses that get quietly systematized this decade will look like luck to everyone else. It won't be luck.

Here is a failure I now recognise instantly. You tweak a prompt, try three examples by hand, decide it is better, and ship. A week later something unrelated is broken and you have no idea when it broke, because you never measured anything.

I did this for a solid two days. The "improvement" fixed the three cases I was staring at and quietly degraded a category I had stopped checking.

A small set beats no set by an enormous margin

You do not need an evaluation framework to start. Twenty examples in a file with the input and what a good answer contains is enough to catch the change that makes things worse. The bar is not rigour, it is having any number at all that moves when you change something.

I built mine out of real failures. Every time something went wrong in testing, that case went into the file. The set grows in exactly the places the system is weak.

Measure the step, not just the output

In a multi step pipeline, a bad final answer tells you almost nothing. Was the retrieval wrong, the extraction wrong, or the reasoning wrong? Scoring each stage separately turned debugging from archaeology into reading a report. Retrieval at 60% is a concrete thing to fix. "The agent is bad" is not.

The uncomfortable part

Evals tell you when your clever idea did nothing. That is genuinely annoying and it is the entire value. Half the prompt engineering I was proud of made no measurable difference, and knowing that saved me from carrying it around forever.

It works, versus it works every time, is the whole distance between a demo and a product. Evals are how you walk it.

Construction tenders are enormous documents, hundreds of pages of requirements, criteria, and compliance language. A response can take a team days. At Gamuda AI Academy, my capstone team set out to compress that to hours. A 50% efficiency gain was the target we wrote on the wall.

The architecture, briefly

Tendervise AI ingests tender documents, runs structured extraction over the requirements, and then an agent evaluates each tender with ESG scoring: environmental, social and governance criteria turned into something measurable. FastAPI on the back, RAG over the document corpus, Langchain orchestrating the agent steps, Postgres holding the structured results.

The hard part was never the LLM call. It was everything around it: chunking documents so retrieval doesn't miss the one clause that matters, structuring extraction output so Pydantic can validate it, making the agent's scoring explainable so a human reviewer trusts it.

What team lead actually meant

I expected to spend the program getting better at Python. I did, but the role that changed me was team lead. Splitting the work so four people aren't blocking each other. Deciding what gets cut when the demo is in five days. Translating between a teammate's technical concern and a stakeholder's business question. My HYGR sales instincts turned out to be load bearing. Leading a build is mostly communication with a compiler attached.

The minister demo

We presented the prototype to YB Chang Lih Kang, Malaysia's Minister of Science, Technology and Innovation. You learn a particular skill preparing for that: compressing eight weeks of engineering into three minutes that someone outside engineering finds obviously valuable. No retrieval augmented anything in the pitch. Just "tenders take days, this takes hours, here's the proof".

That demo is the whole job, honestly. Build something real, then make its value legible in three minutes. Everything I do at Orion Automation now runs on that same loop.

FastAPI is friendly enough that you can ship something working before you understand what you shipped. These are the things I only understood after they hurt.

Async is not free speed

I made every route async def because the docs used it, then called a blocking library inside one and wondered why the whole server stalled under two users. An async route that blocks blocks everything, because it holds the event loop hostage.

The rule I settled on: if the work inside is genuinely awaitable, use async. If it is a blocking library, either use a plain def route and let the threadpool handle it, or push it off the request entirely.

Never make a user wait for a model

An LLM call that takes twelve seconds is not an HTTP response, it is a job. My first version had the browser waiting, the proxy timing out, and the user refreshing, which fired the whole expensive pipeline again.

Accept the request, return an id immediately, do the work in a background task, let the client poll or stream. This is the single change that made the system feel like a product instead of a demo.

Dependencies are where the tidiness lives

The dependency injection system looked like ceremony until I had auth, a database session and a settings object needed in a dozen places. Declaring them as dependencies instead of importing globals made the routes readable and, more importantly, made them testable by substitution.

The docs page is a feature, use it

The automatic interactive docs are not just convenient. They are a forcing function: if a route looks confusing there, it is confusing. I started reading my own generated docs as a design review, and half my naming improved for free.

In late 2025 I had a working formula: shoot, edit, post, repeat. 38M views of proof that I understood distribution. The reasonable move was to keep going.

Instead I enrolled in a Python bootcamp in December 2025, then went all in at Gamuda AI Academy in January 2026. Here's the actual reasoning, minus the romance.

Creators rent. Engineers own.

Every view I generated lived on someone else's platform, subject to someone else's algorithm changes. The content treadmill never stops, and the moment you step off, the views stop too. Software is different. A system you build keeps working when you sleep. I wanted assets, not just output.

The overlap is the moat

There are better pure engineers than me. There are better pure creators than me. But the intersection, someone who can build an AI agent and explain it in four languages and sell it at a booth in Kelantan, gets very thin in the middle of that Venn diagram. My resume calls it a "hybrid talent". It is really just refusing to throw away half my experience.

AI made the timing urgent

I watched AI start writing captions, editing clips, generating voiceovers. The content skill curve was flattening from below. Meanwhile the skill of directing AI, building agents and designing pipelines, was compounding from above. You want to be on the compounding side.

Three months at Gamuda later, I'd led a capstone team, built Tendervise AI, and presented to a government minister. The ring light is still on my desk. It just points at a whiteboard now.

On paper, Orion Automation is an SSM registered sole proprietorship in Subang Jaya. Custom web solutions, business process automation, chatbots. That is the shop window. Here is the back room.

I registered it in November 2025, two months after leaving HYGR, with thin savings and no backup plan. The honest reason was not a grand vision. I wanted to know what building a business actually feels like, and the only way I learn anything is by building the small version first.

The graveyard of small bets

Between November and December 2025 I started more small businesses than most people attempt in a decade, and finished none of them. An Etsy shop selling Notion templates. An e book. An AI influencer generated with ComfyUI on my old HP Victus war machine. A chatbot built to sell to small businesses. A partnership exploration with my cousin for a marketing agency aimed at one very specific industry I keep private. Each one either failed quietly or I quit halfway.

The freest, most stressful months of my life

Unemployment has a strange rhythm. Evenings of procrastination I am not proud of. Then the after dinner rush of motivation, researching and building until midnight, chasing the version of me who had it figured out. Savings shrinking in the background the whole time. Free in every direction and stressed in every direction, at once.

Zero revenue, full tuition

Orion Automation has generated exactly zero ringgit of revenue. There was a time I pointed at the website as proof that I ran a business, and technically I did. What nobody saw was that I was surviving on savings, not sales. I am done polishing that part of the story.

What the company actually paid out was education. Thinking like a founder. Weighing every decision against runway. Looking at my own work from the customer's chair. That thinking followed me into Gamuda AI Academy, into P10X Media, and into how I solve problems everywhere.

What happens to Orion now

The domain runs until November 2026. If I ship something with visible revenue before then, Orion Automation graduates from a lesson into a company. If not, it retires with my gratitude. Either way, the founder it built keeps going.

Between January 2024 and August 2025 I made 261+ videos for HYGR, natural deodorant and tinted lip balm. Not the most glamorous subject in the world. Those videos crossed 38 million views combined.

People imagine virality as lightning. It isn't. It's plumbing.

The first two seconds are the whole video

Nobody decides to watch your video. They decide not to scroll past it. Those are different decisions, made at different speeds. I rewrote hooks five, six, ten times. The body of the video often survived untouched while the first two seconds went through more drafts than my resume.

Volume is a strategy, not a symptom

261 videos means 261 experiments. Maybe twenty of them did the heavy lifting on that 38M number. You cannot predict which twenty. Anyone who says they can is selling a course. The honest play is shipping enough shots that the distribution works in your favor, then studying the winners until the patterns stop being invisible.

Offline taught me more than analytics did

HYGR also put me on booth sales, physically driving to all 13 states of Malaysia. Watching a stranger's face while you pitch them deodorant teaches you things a retention graph never will. Where they lean in. Where their eyes drift. The internet is just that face, multiplied and sped up.

I became an AI engineer afterwards, and people assume I left all this behind. The opposite. Every agent I build, every automation pipeline, still ends at a human deciding whether to keep paying attention. I just automate everything before that moment now.

January to March 2026, Gamuda AI Academy, KL campus. Selected into an intensive full stack AI engineering program: Python, FastAPI, React, Langchain, RAG, agentic workflows, the whole pipeline from data to interface.

I arrived as the guy with the unusual resume. Everyone else had a computer science degree or a dev job. I had 38 million views and a bootcamp certificate.

Being behind is a temporary condition

For the first fortnight I was the slowest person in most rooms and I decided that was information, not identity. I asked the questions that made me look inexperienced, took notes like a student, and spent evenings closing gaps that other people had closed in university.

By week five the gap was mostly gone in the areas that mattered, and I had something they mostly did not: I could stand in front of people and make a thing sound worth caring about.

Team lead was the real curriculum

I was made project team lead for the capstone. We built Tendervise AI, an agent that reads construction tender documents and scores them against ESG criteria, targeting a 50% cut in response time.

Leading it taught me more than the syllabus. Splitting work so four people are not blocked on each other. Deciding what gets cut when the demo is in five days. Sitting between a teammate's technical worry and a stakeholder's business question and translating both directions. My booth years turned out to be load bearing engineering skills.

Three minutes with YB Chang Lih Kang

We presented the prototype to Malaysia's Minister of Science, Technology and Innovation. Eight weeks of work, three minutes of attention, an audience with zero interest in our retrieval strategy.

So we said: tenders take days, this takes hours, here is the proof. I gave the graduation speech that March. Both of those moments were the same skill, and it was not a skill I learned at the academy.

Early on, my extraction step asked the model for JSON, then I parsed it. Most of the time it worked. The rest of the time it wrapped the JSON in a code fence, or added a friendly sentence before it, or invented a field, or returned a number as a string.

I wrote defensive parsing code. Then I wrote defensive code for the defensive code. Then someone showed me schemas.

Describe the shape, not the request

Defining a Pydantic model and having the output validated against it changes the failure mode completely. Instead of receiving something almost right and discovering it three functions later, you fail immediately, at the boundary, with a message that says exactly which field is wrong.

Validation at the edge is not an LLM idea, it is just good engineering that LLMs make impossible to skip. Every unreliable input in a system deserves the same treatment.

Field descriptions are prompt engineering

The part I did not expect: the descriptions you attach to each field do real work. A field described as "score from 0 to 100" behaves differently from one described as "ESG score, 0 to 100, where 100 means full compliance with the stated criteria". The schema is not just a contract with your code, it is instructions to the model.

I now spend more time writing field descriptions than writing prompts.

Optional means optional, so say so

Making a field required when the source document genuinely does not contain it forces the model to invent something. Every hallucination I traced in that pipeline came back to a schema that demanded an answer where none existed. Let fields be optional and let the model say nothing. A blank is honest. A guess is a bug you will find much later.

The tutorial version of retrieval augmented generation takes about fifteen minutes. Load documents, split them, embed them, search, stuff the results into a prompt. It works immediately on a clean PDF and falls apart the moment you point it at a real one.

On Tendervise AI the documents were construction tenders. Hundreds of pages of requirements, tables, appendices and legal language. The first version confidently missed things that were plainly in the document.

Fixed size chunks cut through meaning

My first splitter cut every 1000 characters. That happily slices a requirement in half, so the condition ends up in chunk 14 and the threshold it refers to ends up in chunk 15. Retrieval finds one of them. The model answers from half a rule and sounds certain about it.

Splitting on structure instead of length fixed most of it: section headings first, then paragraphs, with an overlap so a chunk carries the tail of the one before it. Slower to write, much better recall.

A chunk without context is an orphan

The second fix was prefixing each chunk with where it came from. A bare paragraph saying "the threshold shall not exceed 15%" is nearly useless on its own. The same paragraph with its document title and section path attached is retrievable and quotable.

Retrieval is a search problem before it is a model problem. If a human could not find the answer with the same query, the embedding will not save you.

Test with the questions people actually ask

My biggest mistake was evaluating retrieval with queries I invented, which unsurprisingly resembled my chunks. Real questions are vaguer, use different vocabulary, and often ask about two things at once. I built a small set of real questions with known correct sources and measured whether the right chunk came back at all. That number, not vibes, drove every change after.

The lesson generalises. When an LLM system is wrong, look at what you fed it before you blame it.

Everyone's first useful script is embarrassing. Mine renamed and sorted a folder of video exports that I had been dragging around by hand for a year.

Forty lines. os, pathlib, a regex I copied and did not fully understand, and a dry run flag I added after it renamed forty files wrong on the first try.

What I actually learned

Three things, in order of how much they surprised me.

First, that a dry run flag is not a nice extra, it is the difference between an experiment and a disaster. I now write the print version of anything destructive before I write the doing version.

Second, that the hard part is never the logic, it is the edge cases. Files with no extension. A file already named the target name. A folder that does not exist yet. The logic took twenty minutes and the edge cases took the rest of the evening.

Third, that if __name__ == "__main__": makes sense the moment you import your own file for the first time and watch it run itself. No explanation had landed until then.

The economics are a trap and it does not matter

An evening of work to save twenty minutes a week pays back in about ten weeks. That was never the point. The point was that I now believed the loop existed: notice a repeated task, describe it precisely, hand it to a machine.

Everything I have built since is that same loop with more layers on top.

December 2025. No job, some savings, and a decision I had been circling for a year. I enrolled in an intensive Python bootcamp covering fundamentals and AI agent integration.

It was humbling in a very specific way. I was good at something. Now I was bad at something, on purpose, at 24, having recently been the person in the room who knew what he was doing.

The first two weeks are pure friction

Indentation errors. Variables that were strings when I needed numbers. Loops that ran once or forever and never the amount I wanted. There is no way to be clever through this part. You just sit in it until the friction drops.

What kept me going was a trick I stole from content: ship daily. Not learn daily, ship daily. Every night something had to run, however small. A dozen lines that renamed files counts. The habit mattered more than the difficulty.

The moment it clicked

Halfway through the course I wrote a script that pulled numbers I used to copy by hand and dropped them into a sheet, formatted. It took me an evening. It saved me maybe twenty minutes a week. The maths is terrible and the feeling was enormous.

That was the whole pivot, in one small script. Content is output that stops when you stop. Software is an asset that keeps working while you sleep. I had spent two years renting attention on someone else's platform. I wanted to own something.

Then agents

The last stretch of the bootcamp covered AI agent integration, and that is where the two halves of me met. An agent is a system that reads unstructured human mess and does something sensible with it. I had spent two years studying unstructured human mess for a living.

Three weeks later I was accepted into Gamuda AI Academy.

261 videos is not a milestone, it is a habit that got out of hand. Somewhere past a hundred, the work stopped being something I did and became something I could see. That change is worth describing, because nobody warns you about the bad half.

The good half: you stop guessing

Early on I would finish an edit and genuinely not know if it was good. By video two hundred I could tell in the first pass, usually within the first two seconds of the rough cut. Not because I got smarter, but because I had watched enough of my own failures to recognise the shape of one. Taste is just compressed feedback.

It also made me fast. The decisions that used to take an evening, which take to keep, where to cut, whether the hook earns the payoff, collapsed into seconds. Speed is not a shortcut. It is what expertise feels like from the inside.

The bad half: you start optimising the wrong thing

The other thing that happens is you begin to see everything as retention. I caught myself watching films and mentally noting where a normal person would scroll. I caught myself flattening ideas because the interesting version needed four seconds of setup and four seconds is expensive.

That is the damage. When the only feedback loop you have is a metric, the metric slowly becomes your taste instead of informing it. I did not notice until I tried to write something long and found I had no patience for my own sentences.

The fix was changing medium

Learning to code helped more than any advice about balance. Software has a different feedback loop. It either works or it does not, and nobody scrolls past a function. Sitting with a bug for three hours rebuilt an attention span that two years of short form had quietly filed down.

I still make things for people who might scroll. I just no longer let that be the only judge in the room.

Somewhere between filming videos for HYGR, I ended up at booths in all 13 states of Malaysia. Shopping malls, night markets, weekend expos. A folding table, a stack of product, and whoever walked past.

I speak English, Malay and Chinese, plus enough Thai to hold a conversation. At a booth in Malaysia you use all of them before lunch.

You cannot hide behind an edit

On camera, a bad take costs you thirty seconds. At a booth, a bad opening line costs you the customer, and they walk away while you are still talking. There is no second cut. You learn to read the first half second of someone's body language and adjust the sentence you are already saying.

That skill has no name on a resume. It shows up as pace. It shows up as knowing when to stop explaining.

Language is not translation, it is register

The same pitch in Malay and in Chinese is not the same pitch translated. Different jokes land. Different objections come first. In Chinese the question was usually about ingredients. In Malay it was usually about whether it works in this heat. Switching languages meant switching the whole order of the pitch, not just the words.

I do this now in client meetings for Orion Automation, and it barely feels different. A business owner who wants to stop copying WhatsApp orders into a spreadsheet is a customer at a booth. The product is just harder to hold.

Thirteen states is a lot of driving

It is also thirteen versions of the same country. What sells in Johor is not what sells in Kelantan, and the difference is not something you would ever learn from a dashboard. Malaysia is small enough to drive across and varied enough that you should.

I would not trade those weekends for a better analytics stack. The analytics tell you what happened. The booth tells you why.

January 2024. I joined HYGR, a Malaysian brand making natural deodorant and tinted lip balm, as a video editor intern who talked his way in with one multimedia class and a folder of college club videos. By June they offered me full time, and the role grew into content creator. The job description was short. The job was not.

Script, shoot, edit, post, read the numbers, repeat. Two product lines, every platform, no crew. By the time I left in August 2025 the counter said 261 videos and 38 million views.

Learning the algorithm by feeding it

You cannot read your way into understanding distribution. I tried. Every article says the same six things and none of them tell you why your video died at 40% retention on a Tuesday. The only teacher is volume with attention: ship, watch where people leave, change one thing, ship again.

After a few hundred cycles you stop thinking about the algorithm as a thing to beat and start thinking about it as a very fast, very honest audience research tool. It is not mysterious. It is just brutally literal about what people actually watched.

The part nobody sees

Behind the videos was a pile of unglamorous infrastructure I built because the alternative was drowning: posting schedules, a tracker for which hook variant went where, campaign notes, performance logs. None of it was impressive engineering. All of it was the reason the creative work stayed possible.

That is the seed of everything I do now. I was already automating my job before I knew that automation was a job.

Then they put me on a booth

HYGR also sent me to sell in person, across all 13 states. Standing in front of a stranger with a product in your hand is the highest resolution feedback that exists. It permanently changed how I write, how I pitch, and how I open a client call.

I left in August 2025 with a skill set that looked, on paper, like a creator. Four months later I was writing Python at 2am.

College Community Pasir Salak, September 2022. Information Technology. If you are picturing a glass campus with a startup incubator, adjust downward considerably.

What it did have was a syllabus wide enough to touch everything: web development with HTML, CSS and PHP, game development in Unity and Unreal, mobile apps, a semester of IoT where we wired sensors to boards and argued about why nothing lit up.

Breadth beat depth, and that was lucky

Nothing we learned went deep. In hindsight that was the point. I got to touch a game engine, a web stack, a mobile toolchain and a microcontroller inside two years, which is four chances to find the thing that makes you lose track of time. For me it was always the moment something I typed showed up on a screen and did what I said.

I was a mediocre student in the parts that required memorising and a much better one in the parts that required building. That gap told me something I did not act on for another three years.

The habit that survived

The specific technologies aged badly. PHP is not in my stack. I have not opened Unreal since. What survived was the reflex: when I do not understand something, I build a small version of it. That reflex is doing all the work in my career right now, and it started in a computer lab in Perak with a project deadline I was going to miss.

In my final semester the internship hunt began, and I found my loophole: one multimedia class on an IT syllabus, plus the videos I had been making for our club. That portfolio got me into HYGR as a video editor intern in January 2024, which is how the next chapter ended up being a camera instead of a keyboard.