"I was never trying to build a startup. I was trying to build a life."

When people hear that I have been self-hosting my own infrastructure for more than five years, they often assume this is a story about cloud architecture, Linux, or scaling systems.

It is not.

This is a story about curiosity.

More specifically, it is a story about slowly realizing that you cannot spend your entire life standing on someone else’s shoulders.

Looking back today, every chapter of my journey seems to have quietly led me toward that realization.

I still remember a season of my life in 2018 when a friend and I were building a small coffee shop together. During the day, we physically built the place with our own hands. At night, we returned home and continued writing software.

Then one night, everything stopped.

Our product was ready to launch when Firebase released an update. I stayed awake the entire night trying to solve a problem that wasn’t even caused by my own code. Around ten o’clock the following morning, another update arrived, the deployment worked again and I finally went to sleep.

The issue disappeared, but the lesson stayed with me.

That was probably the first time I understood what dependency really meant.

Returning Home and Learning to Build Again

In 2019, I wrote Golang for my first real-world project and was introduced to Ubuntu Server. I learned my first CLI commands and slowly fell in love with the feeling of operating infrastructure with my own hands.

Life eventually introduced me to friends like Lychee and Parker. Together, we started a startup and built DIMODO, an application that shipped products from South Korea to Vietnam.

Then the pandemic arrived.

Everyone went their separate ways.

I returned to my hometown with almost nothing.

During the day, I worked as a delivery driver.

At night, I rewrote libraries.

Like many Go developers, I started with mux and later discovered Fiber. Then the first customers arrived, followed by the first payments.

Without realizing it, I had quietly become an indie developer.

Six Months for a Single Identifier

There was a period when I spent almost six months building a DNS routing feature to manage tenants for customers.

Six months.

Just to make a single identifier appear on a screen.

It sounds ridiculous now, but those six months eventually led me to build Samdy, an experiment to validate my ideas.

At one point, it reached the Top 100 largest websites in Vietnam.

But reality always catches up.

The entire system was running on 1 CPU, 1 GB of RAM and 20 GB of storage.

Revenue existed, but payment cycles were slow.

Infrastructure costs never stopped.

Eventually, the rankings collapsed alongside the system itself.

That period taught me another lesson.

Dependency is comfortable until it becomes expensive.

Curiosity Became Infrastructure

After that, I stopped thinking like an application developer.

I started thinking like an infrastructure builder.

Cache systems.

Traffic routing.

Rate limiting.

Recovery mechanisms.

Data management.

Then curiosity took me deeper.

I wanted to understand tunnels, protocols, network layers and runtimes. I wanted to understand where a request goes after pressing Enter, who forwards it and who eventually executes it.

The deeper I went, the more I realized something.

I was no longer learning how to write code. I was learning how software itself works.

Kitwork: The Product of a Dreamer

Kitwork was never the destination.

It was simply the inevitable outcome of years of accumulated curiosity.

After building systems for so long, one question kept bothering me.

Why do we still rebuild entire binaries just to ship tiny features?

That question eventually became my first Eureka moment.

Logic can be separated from binaries.

Then another idea appeared.

Logic can move between servers through bytecode.

That idea fascinated me.

If logic could move, perhaps infrastructure was simply an environment where thoughts could execute.

I initially thought I was building a programming language.

Then I realized the world already has enough programming languages.

We do not need another one.

We simply need better ways to express logic.

The Life I Was Chasing All Along

Eventually, I shared these ideas online.

Some people liked them.

Some people did not.

Some people said I was delusional.

Others told me to find experts.

Maybe they were right.

Maybe they were not.

But I remembered a teaching from Buddha.

“If someone offers you a gift and you choose not to accept it, the gift still belongs to them.”

Today, I no longer feel the need to prove anything.

I simply enjoy building.

Because after all these years, I have realized something very simple.

I was never chasing startups.

I was never chasing titles.

I was never even chasing technology itself.

I was chasing freedom.

The freedom to wake up in the morning, buy breakfast, eat with my wife, water my plants, write code, sit at a coffee shop, build products I genuinely love and live peacefully in a small town.

Maybe that is the illusion people keep talking about.

But if it is an illusion, I would happily spend my entire life living inside it.

I was never chasing technology.

I was chasing the freedom to quietly build what I believe in while living an ordinary life.

About 6 months ago, I started sharing about Kitwork and why it was born inside a README file. Many people laughed at it and saw it as something unrealistic. But I don’t understand why, the more that happened, the happier I felt. Because I knew it was right, and there were still a few people who supported me. I’m really grateful for that.

Maybe a few months ago I went back to my wife’s hometown to rest and think about what Kitwork and this journey really are. I kept asking myself why I should build it, and what makes it better than the stack I spent 5 years of my youth building and then replacing.

That question stayed with me for a long time.

Until the first runtimes started to take shape.

And then I began to understand why I am building it.

Just like the first sentence I wrote about Kitwork: “Logic living.”

While many people are still asking: “what’s the difference between microservices and monolith?”

I was asking a different question:

How can logic move across cloud infrastructures?

Maybe in the past, that was impossible, or extremely hard to implement, or even if possible, it came with too many trade-offs.

But then AI arrived.

And human intelligence is no longer bound by simple traditional constraints, which made me start thinking differently about all of this.

I used to ask very naive questions like: why do we need Docker, why do we need node_modules, why do we need k8s, why do we need Redis.

I’m not rejecting technology. I just want to understand the “why” behind it.

Programming doesn’t feel like it used to anymore.

It’s no longer just code and deploy, or infrastructure deploying systems.

Now code becomes a conversation between code, cloud infrastructure, and AI.

AI is slowly penetrating many industries in society. It no longer feels like a “ledger system”, but more like a new notebook that everyone has to start using, just like when we first adopted the internet, then smartphones, and now AI.

I used to know someone who said AI was stupid. Now that same person is using AI every day because they think it has become smart enough.

We are not meant to be attached to any fixed belief. We have to adapt it into our daily life.

Just like how we code, build software, write web apps… vibe coding is fine, AI engineer is fine, loop engineering is fine.

What matters is that we keep learning new things every day to adapt to this world.

I’m not saying you must chase everything. I’m just saying you either slowly adapt, or you get left behind.

And I just hope people don’t say things like: “I just generated a website, developers are going extinct…” please, don’t say that.

And don’t look down on vibe coding that produces a localhost:3000 app, because we still need to learn and grow through it.

If one day I really become “obsolete”, I will probably go back to my hometown, raise chickens, grow vegetables, and live a simpler life.

And don’t be afraid that job titles will disappear, like front-end developer, back-end developer, full-stack developer… new roles will always replace them.

What does not change is often what stops evolving.

It sounds painful, but it’s probably true.

As AI grows rapidly and spreads into every corner of life, localhost on a phone is no longer just a technical story. It becomes a challenge for both people who already know it and those who don’t.

Connecting through a LAN IP and running it on a phone is easy, simple, straightforward.

But actually running a real localhost-like experience on a phone is not just a journey, it is a path full of trials, failures, and retries.

Localhost on a phone makes me think about a new way of programming, where space, devices, ideas, and infrastructure are no longer separated as “developer concerns.”

People often ask me: how can a developer write such long writing like a writer?

So what should I write instead? System design? Bytecode on cloud? Runtime internals? Things you already know?

What I want to write about is not loop engineering or implementation details, because AI can already teach you those, and maybe even better than me.

What I want to talk about is how small things slowly enter and reshape our daily lives.

And why should anyone trust me more than AI anyway?

Multi-tenancy on cloud infrastructure together with AI is what I’m currently exploring and learning every day.

That’s also why I’ve started liking Claude Code and AI agents, because I believe that in a few months, or a few years, we will reach something like autopilot code.

Localhost:3000 on a phone looks simple.

But building it is not as simple as you think.

Lately, I’ve noticed a familiar pattern in many tech communities.

Whenever someone, especially a group of students, shares a new project, the same comment often appears:

“Another person reinventing the wheel.”

Honestly, I don’t know how successful those people are or how capable they truly are. But one thing I do notice is that many of them choose to hide behind anonymous accounts, using invisible identities to judge the efforts of others.

Every time I see a group of students struggling to build an early-stage project, I’m reminded of my younger self — a version of me filled with dreams, energy, and a fair amount of naivety.

It also reminds me of something I once wrote:

“Young people, effort, dreams, and the price we pay for them.”

No one is born talented.

No one is born knowing everything.

No one enters life already holding all the answers.

Everything we know today is built upon a very simple process:

Experiment → Fail → Learn → Repeat.

We keep moving and eventually we’ll make mistakes.

We keep making mistakes and eventually we’ll get things right.

But if we never dare to begin, perhaps we’ve already failed from the very start.

From Loop Engineering to Life Itself

Recently, I’ve been exploring a concept called Loop Engineering.

In the AI world, things are changing.

For a long time, people tried to make AI smarter by writing longer prompts, adding more context, and providing increasingly detailed instructions.

But now, the leverage has shifted.

Instead of manually typing every instruction, people are building systems that allow AI to work through loops.

AI receives a task.

AI executes it.

AI verifies the outcome.

AI learns from its mistakes.

AI repeats the process until it reaches its goal.

And then I realized something fascinating.

Human beings are living inside a very similar loop.

Perhaps life itself is one giant Loop Engineering system.

Learn.

Experiment.

Fail.

Correct yourself.

Grow.

Then enter a new loop at a higher level.

We are not wrong.

We are simply in the middle of a loop that’s making us better.

Creativity has never fallen from the sky.

It is built from hundreds of small failures, dozens of small successes, and thousands of continuous iterations.

Steve Jobs didn’t appear on day one as a legend at Apple.

No one starts life with a complete map in their hands.

The only difference between those who leave a mark and those who stand outside criticizing others is this:

They dare to start their own loop.

Reinventing the Wheel Isn’t Always a Bad Thing

So whenever I see an early-stage project, an imperfect product, or a group of young people trying to build something, instead of asking:

“Why are they reinventing the wheel?”

Maybe we should ask:

“Do you need any help?”

Because sometimes, the value doesn’t lie in creating something that has never existed before.

The value lies in walking the journey yourself and understanding why it exists in the first place.

Only those who have built something with their own hands truly understand this:

Every time we reinvent the wheel, we gain a deeper understanding of how the world actually works.

Maybe that’s why I never underestimate early projects.

Because everything great in this world was once an awkward first version.

A startup was once just an idea.

A product was once just an experiment.

A system was once only a few lines of code.

An expert was once a beginner.

The Greatest Lesson Loop Engineering Has Taught Me

The most beautiful thing Loop Engineering has taught me is not how to build AI.

It is how to rethink life itself.

In software engineering, there’s a mindset I really like:

“The repo remembers, the mind forgets.”

Repositories remember.

Human beings forget.

Life works the same way.

Every failure.

Every wrong decision.

Every time we have to start over.

None of them truly disappear.

They become data for our next iteration.

They allow us not to start from zero, but to inherit and optimize the previous version of ourselves.

Only insecure people use failure or someone else’s inexperience to define their worth.

Truly strong people understand that they were once beginners too.

We don’t lack creativity.

We don’t lack ideas.

We don’t lack people capable of building extraordinary things.

Sometimes, what we lack is simply the courage to begin, because we’re surrounded by self-appointed judges who are always ready to criticize those who are trying.

Don’t just react to life.

Design your own loop.

Accept imperfections.

Accept failures.

Set your own standards.

And keep moving forward.

Because in the end, the most important question remains:

If you never try, how will you know what’s right or wrong?

But perhaps there’s an even more important question:

If you never begin, how will you ever have the chance to enter the loop that turns you into a better version of yourself?

The shortcut to success isn’t avoiding failure. It’s failing early, learning fast, and continuing to iterate.

Build the loop. Stay the engineer.

This morning, I went to Highlands Coffee like I always do.

I ordered my drink and immediately noticed something unusual. Instead of using the ordering system, an employee was writing orders down by hand.

I asked, “Is the system down?”

She smiled and replied, “Yes.”

For most people, this would simply be a small inconvenience. They would get their coffee a few minutes later and move on with their day.

But years of working on infrastructure have permanently changed the way I observe the world.

I no longer see incidents.

I see systems under pressure.

Then I remembered something.

Yesterday, Highlands Coffee celebrated a remarkable milestone: 1,000 stores across Vietnam. To celebrate, they launched a free coffee campaign and I happened to receive one of the vouchers.

What caught my attention wasn’t the coffee itself.

It was the one hour expiration window.

Marketing teams see engagement.

Customers see a reward.

I see synchronized demand.

Because infrastructure has a funny way of revealing itself.

The biggest challenges are rarely created by massive numbers alone. They appear when large numbers of people decide to do the exact same thing at the exact same time.

Open the app.

Claim a voucher.

Authenticate.

Pay.

Synchronize data.

Repeat that tens of thousands of times within a short period, and suddenly a normal day stops being normal.

That is when systems reveal who they truly are.

For a long time, I thought growth was the hardest challenge companies faced.

I eventually realized I was wrong.

Growth is easy to celebrate.

Growth is difficult to survive.

Opening another store is a business achievement.

Making 1,000 stores behave like a single system is an infrastructure achievement.

Those are entirely different problems.

People often associate infrastructure with technologies.

Cloud providers.

Kubernetes.

Containers.

Distributed systems.

But the longer I work in this field, the less those words matter.

Infrastructure is not technology.

Infrastructure is trust.

It is the invisible layer that allows millions of ordinary moments to remain ordinary.

We only notice roads when traffic stops moving.

We only notice electricity when the lights go out.

We only notice infrastructure when it disappears.

That is the strange beauty of this industry.

Success creates pressure.

Pressure exposes assumptions.

Assumptions expose systems.

And systems eventually expose the truth.

While I was thinking about all of this, I overheard someone sitting nearby say:

“Every time Highlands launches a campaign, something happens.”

I don’t know whether that statement is fair or unfair.

But I immediately understood why it matters.

Because users don’t experience architecture.

Users experience confidence.

Confidence that the application will open.

Confidence that the payment will succeed.

Confidence that a promotion will work exactly as promised.

Confidence that a company can handle its own success.

People don’t care how elegant your architecture is.

They don’t care how many engineers are working behind the scenes.

They don’t care how much money has been invested in technology.

They only care about one thing.

Will it work when I need it?

This morning, I saw an employee writing orders down on paper.

Many people saw a small outage.

I saw something else.

I saw a company that had just reached 1,000 stores collide with one of the oldest truths in infrastructure.

Growth doesn’t break systems.

Growth reveals systems.

And somewhere between a nationwide celebration and a handwritten receipt lies the real challenge that infrastructure builders quietly solve every day.

Not how to build systems that work.

But how to build systems that continue to work when success arrives all at once.

As a platform grows

As a platform grows, we naturally start adding more technologies:

• Redis for caching

• RabbitMQ for queues

• Kafka for events

• Consul for service discovery

• Nginx for gateways

Each technology solves a specific problem extremely well.

But when combined together, they often create a system that becomes increasingly difficult to understand, maintain, and operate.

At some point, I began asking myself:

Can we build a system where every component is born from the same philosophy?

That question became the foundation of Kitwork Cluster.

One Runtime

In Kitwork, there is no such thing as:

• Gateway Server

• Cache Server

• Queue Server

• Worker Server

There is only one thing:

Kitwork Runtime

Every node in the cluster runs the same engine.

Every node is capable of:

• Execution

• Caching

• Proxying

• Workflow Processing

• Scheduling

• Event Handling

• Queue Processing

The only difference is role priority.

For example:

• Gateway Runtime

• Coordinator Runtime

• Worker Runtime

These are not different server types.

They are simply different responsibilities assigned to the same Runtime.

Database Cluster – The Single Source of Truth

The entire cluster trusts one thing:

Database Cluster

It stores:

• Business Data

• Cluster State

• Tenant State

• Jobs

• Events

• Metadata

• Configuration

The database is not merely a storage engine.

It is the collective memory of the entire platform.

Any Runtime may fail.

Any Runtime may be replaced.

But the state of the system remains intact.

That is why every node ultimately revolves around the same source of truth.

Gateway – The Guardian

In most modern architectures, a gateway is little more than an entry point.

It receives requests.

It forwards requests.

And usually does little else.

In Kitwork, the Gateway is the first line of defense.

Its primary responsibilities include:

• Routing

• Authentication

• Security

• Rate Limiting

• Load Balancing

However, the Gateway is not just a proxy.

If Coordinators become unavailable.

If Workers become overloaded.

If the entire cluster is under pressure.

The Gateway can step in and execute workloads itself.

It is the platform’s final survival layer.

Coordinator – The Commander

The Coordinator is the brain of the cluster.

But it is not a proxy.

It is not a mandatory hop for every request.

It is not a bottleneck.

The Coordinator exists for one purpose:

System Orchestration.

Its responsibilities include:

• Leader Election

• Node Discovery

• Health Monitoring

• Tenant Assignment

• Job Scheduling

• Cache Coordination

• Cluster State Management

The Coordinator knows:

• Which nodes are alive

• Which nodes have failed

• Which nodes are overloaded

• Where tenants should reside

• Which workloads should be assigned next

It does not fight.

It commands.

But when necessary, it can step onto the battlefield itself.

Worker – The Executor

Workers are where value is created.

This is where the actual work happens:

• API Processing

• Rendering

• Workflow Execution

• Job Processing

• AI Inference

• Business Logic

Under normal conditions, the majority of requests are handled by Workers.

They consume most of the resources.

They generate the final outcomes users interact with.

Workers are the workforce of the platform.

No Node Is Completely Useless

This is perhaps the most important principle behind Kitwork.

In many systems today:

Node A fails → System degrades.

Node B fails → System degrades.

Node C fails → System degrades.

Kitwork takes a different approach.

Every Runtime can assume the responsibilities of lower-priority Runtimes.

For example:

Gateway can become:

• Gateway

• Coordinator

• Worker

Coordinator can become:

• Coordinator

• Worker

Worker can become:

• Worker

This means:

No node becomes completely useless simply because another node fails.

Progressive Degradation

Rather than pursuing perfection,

Kitwork is designed for survival.

Normal Operation

Gateway → Coordinator → Worker

Worker Overloaded

Gateway → Coordinator Execute

Worker Unavailable

Coordinator takes over execution

Coordinator Overloaded

Gateway Execute

Coordinator Unavailable

Gateway takes over

Severe Cluster Failure

Gateway can still communicate directly with the Database Cluster

Performance may decrease.

But service availability remains.

The system continues to operate.

Cluster Bus – The Nervous System

To coordinate Runtime communication, Kitwork introduces the Cluster Bus.

The Cluster Bus carries:

• Heartbeats

• Elections

• Job Dispatches

• Cache Invalidations

• Tenant Migrations

• System Events

• Configuration Synchronization

It acts as the nervous system connecting every Runtime into a unified organism.

Every Runtime can listen.

Every Runtime can respond.

Every Runtime can participate in the life of the cluster.

The Ultimate Goal

Kitwork is not trying to become another framework.

Nor is it trying to replace every existing technology.

Its goal is to build a platform capable of:

• Self-Organization

• Self-Coordination

• Self-Healing

• Self-Adaptation

Where:

• Every node is a Runtime

• Every Runtime can execute

• Every Runtime can support others

• Every Runtime serves the same mission

And all of them trust a single source of truth:

Database Cluster

Because a strong system is not a system that never fails.

A strong system is one that continues to operate when failure inevitably occurs.

I slowly realized that some things cannot truly be explained through ordinary language.

It feels like a technological dream that a foolish dreamer has spent years searching for.

At some point, the world seemed to forget bytecode.
People became obsessed with frameworks, tooling, ecosystems, AI wrappers, and cloud abstractions… but very few still talked about execution, instructions, or how logic truly lives inside machines.

I chose to walk backward toward the origin.

I chose Golang.
I chose to build something that feels like JavaScript, but is not JavaScript.
No NodeJS.
No endless node_modules.
No thousands of abstraction layers just to execute a simple flow of logic.

Someone once asked me:

“If JavaScript had no NodeJS, how would it even work?”

I could only smile and say:

“Maybe you should read the Kitwork Engine.”

It is not trying to replace JavaScript.
It is simply another way of thinking about logic and machine execution.

When I went deeper into compiler design, I began to understand something:

Programming languages are merely humanity’s attempt to explain to machines that our thoughts are alive.

A compiler does not simply compile code.
It compiles thought itself.

And bytecode, to me, is no longer:

Intermediate Representation

but rather:

Compiled Thought.

Perhaps that is why I became obsessed with it.
I love watching logic transform into instructions.
I love how a virtual machine can make invisible ideas begin to “live.”
I love how runtime execution feels like the heartbeat of a machine civilization.

Most people see code.
I see the flow of thought.

Sometimes I feel modern frameworks are slowly pushing us away from the essence of programming.

They make developers better at “using,” but not necessarily better at “understanding.”

The deeper I go into low-level systems, the more I realize:

• logic is the soul,

• runtime is the body,

• and bytecode is the bloodstream of machines.
  

AI will eventually exist everywhere.

Machine intelligence will become part of human life the same way electricity and the internet once did.

And perhaps what we are building today are merely the first stones of a future civilization:

A civilization of humans and machines.

Will KITWORK become a bridge toward that future?

I do not know.

But I know that I am no longer dreaming.
I am living inside my own technological dream.

There were nights debugging VM loops until sunrise.
Moments where ideas appeared like lightning after months of exhaustion.

Two moments of “eureka” nearly drained the life out of this body just to allow me a glimpse of something far beyond the present.

And strangely enough…
when I returned to the project after many personal struggles, I still found it beautiful.

Not startup beautiful.
Not commercial beautiful.

But beautiful in the way:

• execution flows,

• compiler architectures,

• machine instructions,

• and living logic can be beautiful.
  

Maybe, in the end, I am only a fool who loves programming.

A runtime-oriented engineer.
A compiler dreamer.
A lonely system builder trying to speak to machines using human thought.

And a man who loves flowers.

Amid machine civilization,
amid server spaces and execution flows,

I still believe a flower is the final reminder that:

logic may create machines,
but emotion is what creates civilization.

Is C++ faster? Is Rust safer?

However, this is not the core problem Kitwork Engine is trying to solve.

C++ and Rust are, at their core, languages designed around Developer Experience.

They help engineers write code more efficiently, control memory more precisely, and build safer systems.

Kitwork does not start from DX.

We start from a different question:

What actually consumes energy in a large scale serverless system?

Speed is not the final goal

High performance is a result, not an objective.

In serverless and cloud native environments, cost rarely comes from a slow instruction.

It comes from things like:

Repeated runtime initialization

Uncontrolled memory allocation and reclamation

Context switching across multiple abstraction ⁰layers

Scheduling instability under load

Garbage collection and runtime decisions at execution time

Optimizing speed at the language level only addresses the surface of the problem.

Kitwork Engine takes a different approach.

We treat system energy as a first class design constraint.

Energy computing: a different view of systems

In Kitwork, we model system behavior using a simple but foundational formula:

E = W × T × S

Where:

W (Work) is the actual logical work being executed

T (Time) is how long the system must remain active

S (State transitions) is the number of state changes such as allocation, initialization, context switches, garbage collection, or syscalls

Most engines focus on optimizing W.

Kitwork focuses on reducing T and especially S.

This is why we prioritize:

Ahead of time decisions instead of runtime heuristics

Memory layout as part of logic design, not an implementation detail

Minimizing or eliminating GC on hot paths

Treating every allocation as a unit of energy with real cost

Why an engine for serverless, not a framework

Frameworks are designed for developers.

Engines are designed for systems operating at scale.

Kitwork Engine does not aim to be a framework that is easier to use than C++ or Rust.

We build a core logic execution engine that can:

Run predictably in serverless environments

Scale by logical processes, not by instances

Maintain high throughput with low energy consumption

Align with how modern cloud infrastructure actually operates

If you observe core cloud systems today, from Kubernetes to container runtimes to control planes, you will notice that they are not being rewritten wholesale in C or Rust.

Instead, they evolve through architecture, scheduling strategies, and system level design.

When Kubernetes or cloud control planes are fully rewritten in C or Rust, then language level debates may become central again.

Until then, architecture and energy models matter far more.

What Kitwork Engine does differently

We do not chase isolated benchmarks.

We build an engine guided by a small set of principles:

Logic execution decoupled from traditional runtime models

Static slot allocation instead of widespread dynamic allocation

Memory treated as a structured resource, not empty space

High throughput achieved by fewer decisions, not faster decisions

This is why Kitwork can process millions of logical executions in extremely short time frames without increasing operational complexity

Kitwork Engine was not created to compete over which language is faster.

We are building an energy computing layer for serverless and cloud native systems, where performance, cost, and stability are addressed at the architectural level.

Speed is the outcome.

Energy is the problem.

“A screenshot doesn’t mean anything. It’s just virtual numbers.”

That comment ended the discussion.

Instead of arguing, I opened the profiler.

What followed was not optimization it was open-heart surgery on the Kitwork Engine: dismantling the execution loop, reworking the stack model, and rewriting the VM’s core assumptions down to the bytecode level.

The result:

1,000,000 operations executed in 58ms (0.058s)
A 20× speedup, pushing a Go-based virtual machine close to its physical limits.

Defining the 58ms Threshold ⚡️🔥

58 milliseconds is invisible to humans.
To a high-frequency system, it defines an entirely different performance class.

• Human blink: ~300ms
  → In a single blink, Kitwork executes ~5,000,000 instructions.

• Finger snap: ~150ms
  → Nearly 3 million operations completed before the sound propagates.

At 17,000,000 internal ops/sec, this stops being a discussion about “fast software.”
It becomes a discussion about reaction-time systems.

Under the Hood: The Engineering Decisions That Made It Possible ⚡️🔥

Achieving this throughput while maintaining Zero GC (0 B/op) required abandoning conventional interpreter design patterns.

Here’s what changed.

1. The Death of map[string]interface{}

Most scripting engines rely on hash maps for variable storage.
That convenience comes with a cost: hashing, pointer chasing, and heap allocations.

Kitwork’s approach: Static Slot Allocation

• During compilation (AST → Bytecode), every variable is assigned a fixed integer slot.

• At runtime, values are accessed through a flat slice.

Result:

• No hashing

• No dynamic lookup

• Constant-time access with cache-friendly memory layout

2. A Pure Stack-Based VM

Rather than emulating object-heavy runtimes, Kitwork commits fully to a pre-allocated value stack.

• PUSH / POP / STORE operate on a contiguous memory region

• Custom Value structs minimize pointer usage

• Data stays hot in L1/L2 cache, avoiding latency spikes caused by cache misses

This is where the VM stops behaving like a scripting engine
and starts behaving like a tight execution core.

3. Zero Allocation as a Non-Negotiable Rule

Zero GC was not a side effect.
It was a constraint.

• VM Context Pooling: Execution contexts are recycled via sync.Pool

• Stack memory is reset, not reallocated

• Capacity is preserved across executions

For host ↔ VM communication:

• Zero-copy data bridge

• Pointer swapping and unsafe headers where required

• A 1MB payload costs exactly 0 bytes to ingest

No allocation means:

• No GC pressure

• No pauses

• Fully deterministic execution latency

Performance as a Religion ⚡️🔥

Going from 1 second to 58ms wasn’t about “clean code.”

It came from a belief that latency is a bug, not a metric.

In environments like:

• Real-time bidding

• High-frequency trading

• Edge execution & smart gateways

Logic must execute faster than the network itself.

Kitwork Engine exists for that class of systems:
script-level flexibility with the behavioral predictability of a native binary.

Why This Matters ⚡️🔥

People can doubt screenshots.
They can doubt benchmarks.

What they cannot doubt is the experience of a system that responds before the request feels complete.

If your mental model still treats 1 second as “fast enough,”
you’re designing for the wrong decade.

Explore the engine:
👉 github.com/kitwork/engine

Kitwork
Precision in chaos.
Speed in silence.

⚡️🔥

As I begin writing these lines, I am imagining a future that does not yet exist in the present, one with no clear precedent in the history of software. In the past, whenever I shared ideas like this, many people assumed I was “relying on AI to write something fanciful.” But if something has never existed before, how could we possibly write about it in familiar terms? The answer is that we must imagine it before it becomes real. That is not fabrication. It is the nature of technical creation itself.

Kitwork emerged from such a moment. A moment when I realized that the core of programming does not lie in frameworks, nor in infrastructure, but in the ability to execute logic flexibly beyond the boundaries of the original program. It resembles eval() in spirit, but lifted out of a single process and expanded into a distributed entity.

There is no formal curriculum that describes this today. But that does not make it less real. Every large system in history began as an idea that seemed out of place. This essay is not written for the majority. It is written for core engineers, for those who build systems under real load, for those who have reached the limits of current models and begun to feel that they are no longer enough.

The Invisible Constraints of Modern Programming

We often believe that contemporary software is flexible. But that flexibility exists only before the build step. The moment a program is compiled and deployed, its logic freezes inside a binary. JavaScript is confined to the browser. Go, C, and Rust are locked inside data centers. To allow these frozen blocks of logic to communicate, we construct rigid pipelines called REST or gRPC, and we call that architecture.

The problem is that when logic changes, the entire pipeline must change with it. Versioning, backward compatibility, migrations, rollouts, rollbacks. Every small modification leaves a fracture in the system.

Kitwork asks a simple but uncomfortable question:
Why must logic stand still?

Instead of sending requests that describe what we want, why not send the logic that should be executed?

Logic Capsules and Bytecode as a Mobile Entity

Kitwork’s answer is the Logic Capsule. Instead of API calls or RPC messages, the client sends a capsule containing bytecode, permissions, and resource limits. This is not raw source code. It is logic that has already been snapshotted, pre-evaluated, and detached from any specific language or runtime.

For many developers, bytecode feels abstract. But for a Golang developer, it is almost self-evident. In the end, everything flows through []byte. Kitwork simply acknowledges this reality earlier.

To preserve a clean developer experience, Kitwork provides an SDK designed around DX. On the client side, the code may look like this:

const connect = await kitwork.connect({
  server: "asia",
  appId: "webapp",
  token: GuestToken
})

const logic = await connect(() => {
  return from("users")
    .where(u => u.active === true)
    .limit(10)
})

const bytecode = logic.serialize()

const res = await fetch("/kitwork/run", {
  method: "POST",
  headers: {
    "Content-Type": "application/octet-stream",
    "Authorization": "Bearer " + token
  },
  body: bytecode
})

const users = await res.json()
renderUsers(users)

Here, the client does not “query the database.”
The client defines intent.
That intent is packaged into bytecode and sent away. With server-side rendering, this process can even move from server to client and back again, without changing the nature of the logic itself.

Security Without Trust

An obvious question arises: if the client sends logic, what prevents it from sending something dangerous?

The answer is that Kitwork trusts no one, not even the server itself.

Before any bytecode is executed, it must pass through pre-evaluation. Each logic capsule carries a signature, explicit capabilities, and gas. It can do only what it is permitted to do, within the energy it has been allocated. There is no concept of unlimited admin power. No absolute authority.

Every action is traceable. No manual rate limits. No IP-based firewalls. This is the era of identity-based internet, where each piece of logic carries its own footprint of existence.

From Microservices to Logic Mobility

Compared to V8 or WebAssembly, Kitwork does not attempt to move databases to the client. It does the opposite: it moves logic to where data should be processed. This allows logic to be snapshotted, relocated, and resumed in whichever zone is most appropriate.

This is not just another framework in a familiar evolutionary chain. It is a jump:

Monolith → Microservices → Serverless → Edge Computing → Logic Mobility

When logic can move, the idea of a fixed backend begins to dissolve.

Regional Command, Consensus, and Intentional Control

Logic is not executed the moment it reaches a server. It enters the regional command layer. Here, leaders and followers use Raft to verify signatures, validate capabilities, and reach consensus. No single node holds absolute power.

Gateways at the edge operate under a zero-trust model. If one gateway is attacked or fails, worker nodes can replace it automatically. The system does not collapse because one point disappears.

Gas as the Physical Limit of Living Logic

Gas is not money.
Gas is energy.

Each opcode consumes gas. Logic cannot run indefinitely. When gas is exhausted, the logic reaches the end of its life cycle.

This constraint creates a self-regulating market. Overloaded zones become expensive. Logic migrates toward cheaper regions. No central load balancer is required. The system balances itself like an ecosystem.

When Logic Becomes a Living Entity

At the execution layer, Kitwork uses JIT compilation. Bytecode is first interpreted to observe behavior. Once it becomes hot, it is compiled into native machine code. Logic remains mobile while achieving performance close to physical limits.

At this point, software is no longer a static artifact. It has identity, permissions, a life cycle, and a cost of existence. Developers no longer simply “write code.” They design logical organisms and decide how those organisms live, move, and disappear.

Kitwork is not a finished product. It is a different way of seeing programming. When logic is freed, the internet ceases to be merely a data transport layer and becomes a living execution space for computational entities.

If this feels unfamiliar, it is because we are standing at the edge of a new way of thinking. And every edge in the history of technology has always begun this way.

When logic is trapped

Back in the old days, programming was: write code → compile → deploy.

Everything was static. One small change – increasing a discount from 5% to 10% – meant a full rebuild, redeploy, restart.
Logic was locked in the binary. You couldn’t push it to the client, run it on another server, or update it without preparing everything carefully.

Operating systems have processes, threads, mailboxes, IPC… but all of that is low-level, complex, and hard to scale.
Modern languages try to simplify by creating concepts closer to natural language, but in the end, they return to the technical basics: memory, concurrency, synchronization.

Kitwork exists to solve a problem most frameworks never touch: logic that’s free, portable, instantly updateable, and safe.

Logic as dynamic data

Kitwork’s philosophy is simple but powerful: logic is no longer trapped in a binary; it becomes living data – dynamic data.

You can compile logic from Go, Rust, JS… into bytecode, running on the same VM, whether on server, edge, or browser.

This creates dynamic applications. Server pushes new logic → client receives it → VM executes it → UI updates instantly.
No reloads. No extra requests. No rebuilds.
Logic moves, clients and servers stay synchronized in real-time, and the system reacts instantly to every behavioral change.

Multi-threaded and task contexts

Kitwork’s VM doesn’t execute logic as a single thread. It splits tasks into isolated contexts, like a network of mini-VMs:

• Commands run in parallel across multiple threads/cores.

• Results are collected quickly and safely, avoiding memory conflicts or crashes.

• Imagine turning a regular CPU into a set of mini NPUs, each operating independently but still harnessing the full power of the CPU.

This is crucial for complex logic, large computation pipelines, or multi-rule engines. Kitwork optimizes concurrency, boosts performance, and still keeps absolute safety.

Logic as a protocol

Here’s the subtle but powerful part: server and client exchange logic directly, not just data:

• When logic changes, the server pushes new bytecode.

• The client receives it, VM executes immediately.

• Logic pushes in real-time, client-side execution, applications always stay up-to-date, no redeploy needed.

Compared to V8 Engine (single-thread JS engine) or wasmCloud (static WASM modules, microservices), Kitwork maximizes freedom and dynamic logic.
It’s not just about code running fast – it’s about logic moving freely, updating continuously.

Dynamic applications

Kitwork enables dynamic applications:

• Logic updates instantly across all clients.

• Client/server remain synchronized in real-time, no extra requests needed.

• Developers just design the flow of logic, instead of redeploying static binaries.

Example: a retail app.
A customer is browsing products. A discount campaign goes live.
The server pushes new logic. The browser receives bytecode → VM executes → UI updates immediately.
Computation pipelines run in parallel, results are collected fast.

Logic flows, the application is dynamic, and developers only steer the flow.

The philosophy of flow

Think of Kitwork as water flowing:

• Logic is data, moving continuously between server and client.

• Multi-threaded, results collected quickly and safely.

• Cross-platform, compile from Go, Rust, JS, all running on the same VM.

• Logic-as-a-Protocol, logic exchanged directly between nodes.

Developers are no longer “building static houses.”
You design the flow of logic, directing application behavior without redeploying or rebuilding everything.

A vivid example

A financial application:

• Interest rate formulas change.

• The server pushes new bytecode logic to all clients.

• Browsers receive → VM executes → charts and tables update instantly.

• Multiple servers or edge nodes? Bytecode propagates, executes immediately, no system rebuild needed.

No reloads. No redeploy.
Logic runs dynamically, clients stay synchronized, results are accurate and safe.

The future of logic

Kitwork opens a new era of dynamic logic:

• Dynamic applications, logic adapts without developer intervention.

• Universal language, Kitwork bytecode becomes the “common tongue” between services.

• AI Ready, AI generates Kitwork bytecode → system receives and executes safely, instantly.

A world where logic moves continuously, pushed in real-time, servers and clients stay in sync.
Applications are no longer static → dynamic apps, updating with new logic.
Developers become the orchestrators of logic flow, no longer redeploying static code.

Why Kitwork stands apart

In short:

• Mobile logic: pushed in real-time, client/server synchronized.

• Multi-threaded: isolated task contexts, parallel, safe.

• Cross-platform: compile from multiple languages, run on one VM.

• Dynamic execution + hot updates: no rebuild/redeploy.

• Logic-as-a-Protocol: exchange logic directly, not just data.

Kitwork doesn’t just make logic run fast – it makes logic free, moving, and instantly updateable.

Wrapping up the journey

Kitwork is not a regular framework.
Not a V8 engine, not wasmCloud.

It’s a dynamic logic system, where:

• Logic flows, pushed in real-time from server to client.

• Applications become dynamic apps, updating according to new logic without rebuilds.

• Developers become flow designers, steering behavior instead of redeploying static code.

Kitwork opens a new era of programming, where logic is dynamic data, free to move, and applications are continuous flows, always ready to adapt.

NOTES

• Originally posted in 2026 and reposted

• AI-powered translation

• Read the original Vietnamese version here: https://hnq.vn/blog/kitwork-mo-ra-ky-nguyen-lap-trinh-dong

More about me

• Blog: huynhnhanquoc.com

• GitHub: github.com/huynhnhanquoc

• Open Source: github.com/kitmodule

• Buy me a Coffee: buymeacoffee.com/huynhnhanquoc

• Keep me Dreaming: ko-fi.com/huynhnhanquoc

I used to think programming was simple.
Write code. Build. Deploy. Done.

Logic was wrapped inside an executable file, running exactly what was written, and that was the end of the story.

But the longer I worked, the deeper I went into systems, the more I realized a fundamental truth. The most important thing has never been the lines of code themselves. It lives behind them. In the logic. In how logic flows through data, moves across systems, and quietly creates real-world effects.

Code is what we see.
Logic is what actually moves.

“Code is static. Logic is alive.”

When the way you see systems changes

When I started working more with bytecode, pipelines, and virtual machines, my view of programming slowly shifted. Software stopped feeling like solid blocks that you build once and try to preserve forever.

We live in a constantly changing world, yet the way we write software is still painfully static. A small behavior change requires rebuilding, redeploying, and monitoring everything again from the outside. Over time, that friction starts to feel unnatural.

Logic should not be rigid like concrete.

At that point, programming no longer felt like construction.
It felt like orchestration.

Logic as a flow

That was when I began to see logic as a flow. Bytecode stopped being a lifeless sequence of instructions. To me, it became logic compact enough to move.

It can be generated on the server, pushed to the edge, or executed directly on the client. The system does not need to know where it came from. It only needs to understand and execute it.

Code stops being fixed.
It bends with the environment and the data it touches.

Architecture changes quietly when this happens.

“The most powerful architectures don’t look rigid. They flow.”

Performance makes ideas real

What convinced me was not theory, but performance. When I experimented with virtual machines, bytecode, and low-level optimizations, a clear pattern emerged.

Logic does not need to live entirely on the server. It can be distributed and computed where it makes the most sense. Clients can process on their own. Edge nodes can make decisions locally. The server becomes an orchestrator instead of a bottleneck.

The system is no longer stretched around a single center.
Logic flows.
Data computes itself.
The structure becomes lighter and more stable.

When programming stops being instruction

Sometimes I think further ahead. What if one day AI stops returning explanatory text and starts returning bytecode?

A complete piece of logic that can run directly inside a pipeline. No human translation step. No waiting for deployment. Logic is generated and executed almost at the same moment.

At that point, programming is no longer about instruction.
It becomes execution.

That is real automation, not a cosmetic one.

“True automation begins when intention and execution collapse into one.”

Small foundations still matter

Nothing I build starts with a grand idea. Every compiler, every VM begins small. A few opcodes. An experimental pipeline. A simple execution loop.

I constantly remind myself that if the foundation is small and clear enough, logic can grow without breaking. The smallest bytecode today can become the core of much larger systems tomorrow.

When logic truly feels alive

There were long periods where I did nothing but test. I tested speed. I tested deep parsing. I tested how data moves through the system without reflection.

Over time, I realized the joy was not in making code run. It was in watching logic come alive. Seeing data and bytecode merge, flow through pipelines, touch different parts of the system, and change behavior instantly.

That moment changes how you think forever.

Why I keep walking this path

Programming, to me, is no longer about rigid step-by-step control. It is about creating an environment where logic can operate on its own, where change is not a fear but a natural state.

That is why I continue working with bytecode, virtual machines, and pipelines. Not because they are trendy, but because they are structurally honest.

Trends pass.
Flows remain.

“Trends fade. Execution models shape the future.”

I didn’t start with bytecode

I started with doubt.

I didn’t come to bytecode because it looked cool or because someone said it was fast. I came to it because I was tired.

Tired of every request being parsed, reflected, dispatched, and cast again.
Tired of frameworks promising speed while keeping the same runtime model underneath.
Tired of optimizations that only added more caches, layers, and assumptions.

So I asked myself a simple question. What if we dropped the assumptions?

Not optimizing code.
Not switching languages.
But changing how we think about executing logic.

The real problem is the runtime model

The problem is not Go, Node, or Rust.
It is the runtime model.

Most backend systems today follow the same path. Text is parsed into an AST, interpreted or dispatched, and then cleaned up. No matter the framework, logic is reinterpreted every time it runs. We accept this as a truth.

I don’t.

Bytecode is not low-level

To me, bytecode is simply logic that has already been prepared to run.

No re-parsing.
No reflection.
No type guessing.
No runtime branching scattered everywhere.

It is the moment you tell the system:
“I already understand this logic. Don’t ask again. Just run it.”

“Bytecode is not about being low-level. It is about being done thinking.”

Writing my own engine

I did not look for tricks.
I did not tweak compiler flags.
I did not abuse unsafe or CPU hacks.

I removed assumptions and rewrote the execution model so logic runs like a small program, not like text that needs to be interpreted again and again.

The result was a drop from roughly one second to around four hundred milliseconds for one million expressions. Not because I am smarter, but because I stopped believing the old model was mandatory.

Bytecode as an attitude

I am not saying bytecode will replace everything. But it forces us to rethink how we design systems. Do we really need to deeply parse JSON every time? Do we need constant reflection? Do we need runtimes to guess developer intent?

Sometimes, the answer is no.

My vision is not about being faster.
Speed is just a consequence.

What I care about is correctness of intent.

A runtime that is faithful to what the developer actually meant.
No guessing. No interpretation. Just execution.

Bytecode, to me, is not a technology.
It is an attitude.

It reflects how deeply you understand your own code.

When you stop sending the machine prose to interpret and instead hand it logic you have already fully understood, the runtime becomes honest. And when that understanding reaches its deepest point, everything starts to flow.

Naturally.
Clearly.
Like water finding its way back to the sea.

“When understanding is complete, execution becomes effortless.

Midnight Conversations

Lately, I’ve started connecting with fellow tech enthusiasts and developers like myself. Those late-night exchanges about ideas, small bugs, or just how to approach a tricky problem have made me realize one thing: genuine connection doesn’t come from ads, trends, or online hype. It quietly exists when two programming minds stumble upon each other through shared work and stories. I love the feeling of sharing a mindset and realizing my way of thinking is not alone. Even when we don’t fully understand each other, these conversations open up perspectives I had never imagined.

As a founder, solo or otherwise, and more recently as an indie hacker, I’ve come to trust this path. For the past five years, it’s been just me, my laptop, and lines of code and words written from emotion. And I often ask myself: what am I truly searching for? Is it a dream within a dream, something still blurry, not yet formed?

When Code Becomes Inner Poetry

Once, a younger developer asked me: “How many domains do you actually manage?” I guessed around eighty but wasn’t certain. I’ve been operating all of them on systems I built over the past five years. More importantly, those five years led me to KitWork, an engine I’m rewriting in Golang to solve scaling challenges I’ve faced. KitWork wasn’t born out of idealism or a desire for fame. It emerged from real needs, from thoughts I couldn’t yet articulate, from the desire to collect and organize ideas into a system where every module, script, and data flow reflects my thinking and aspirations.

In the quiet of the night, alone in front of the screen, all that remains is the rhythmic tap of the keyboard. Darkness surrounds me, the faint green glow of the monitor the only light. At first, solitude weighed heavily on my chest, but each line of code stretches out, filling the silence inside. Every keystroke, every module built, I step deeper into my own world, a quiet dialogue with myself. No one is beside me, only me and the code, but in that stillness, I’ve never felt myself more clearly.

On the surface, it’s just lines of code, closed modules, functional systems. But looking deeper, I see myself in them. Every new feature I build, every small bug I fix, teaches me more about limits, desires, and hidden truths I hadn’t yet realized. The technical journey is just a thin shell; underneath, it’s how I arrange and understand the pieces of my own inner self. Technology, with all its rules, turns out to be a mirror reflecting the thoughts and emotions I keep hidden.

True connection doesn’t come from the latest frameworks, hot technologies, or viral posts. It happens in moments when two developers share a snippet of code, debug late into the night, or simply read each other’s work. I’ve realized we’ve all been alone with code at midnight, sharing our own unique view of the world. These moments form a shared language among system builders, a quiet empathy that only code can connect.

Dream Taking Shape with KitWork

KitWork exists because of that need. It is more than a tool—it is a place where I collect and arrange ideas that aren’t yet spoken. Each module, each script, each data flow reflects my mind and soul. Through KitWork, I give voice to hidden dreams while maintaining a system that works, scales, and is ready for reality.

Dawn is still far away, but I know I’ve found something. Lines of code under dim light become a form of empathy. KitWork gathers dreams and ideas that haven’t yet found words. The late-night silence is no longer lonely; it is a space to hear my truest self and realize that dreams don’t have to be solitary if you know where to let them start.

My Journey with Golang

After exploring paths as a Frontend Developer, self-taught UX Designer, learning Golang, working in Affiliate, becoming a Full-stack Developer, and self-hosting small cloud services, I realized Golang is my core language. When I first encountered Go in 2018, I wasn’t very interested. After a project ended and I returned to my hometown, Tam Ky, I decided to self-learn and commit to Go. A senior invited me to work remotely from Da Nang, and since then, Golang has been the language I trust for building sustainable platforms.

Golang satisfies three essential criteria: speed, simplicity, and lightness. Building, deploying, and running is easy, efficient, and flexible. With Golang, I can develop websites and services modularly, where each module can be a standalone website or serve a specific goal. I control every line of code, don’t rely on external services, reduce manual tasks, prevent errors, and ensure stable operation. What I love most is holding every line of code in my hands, understanding every behavior and connection, and maintaining total control over the system. Golang lets me build systems that are fast, lean, and stable while remaining highly scalable.

Philosophy and Style

Through years of self-running and building systems, I’ve realized technology is not just lines of code or the latest framework. It is the way I think, organize, and choose to build lasting value. I learned to think independently, not following hype or trends. Every product I create, before considering marketing, I ask myself: is the architecture solid, can it operate reliably, can it scale and be maintained easily?

I aim to automate repetitive tasks, not to showcase technology, but to reduce operational cost and prevent mistakes. I strive for clarity, simplicity, and controllability, avoiding redundancy, because a messy system will fail no matter how brilliant the idea is. For me, depth always matters more than superficial shine. A solid module, well-structured code, properly arranged data flow—these are the real values I pursue. I build KitWork this way: quiet, stable, and sustainable.

Seeking Fellow Dreamers

I am an Indie Hacker, building products alone, no investment, no team, no loud marketing—just me and my own challenges. I choose Golang and Vanilla JS to develop deep solutions. KitWork, KitModule, and my other tools are efforts to collect, organize, and turn ideas into functioning, sustainable systems of real value.

My projects are not loudly publicized; they focus on real problems: affiliate, marketing tech, internal tools, and infrastructure. KitWork is not just a product—it is a foundation to build services from small modules, forming coherent, manageable systems. It allows backend logic for SaaS apps to be deployed in minutes instead of weeks, with automation requiring minimal rewrites.

Now, I want to find fellow travelers. People who value simplicity in design, control over architecture and data flow, care about automation, backend, system design, and building lasting value. No need for loud fundraising or flashy titles. Just build solid systems, operate them reliably, and create real value together.

Silent Nights and Realized Dreams

Looking back at my life, at the days spent with code from ideas to modules and data flows, I see reflections of the deepest parts of myself. My dream does not walk alone. I am connected with friends sharing career stories, learning and growing together. I walk with KitWork, with modules, scripts, data flows, and companions who share my technological ambitions, realizing my dreams.

If you’ve read this far and feel a resonance with how I view technology, if you believe building real, sustainable value matters more than hype and trends, know that somewhere in the world, someone is still saying hello to you = hello world.

NOTES

• Originally posted in 2025 and reposted

• AI-powered translation

• Read the original Vietnamese version here: https://hnq.vn/blog/giac-mo-di-tim-giac-mo

More about me

• Blog: huynhnhanquoc.com

• GitHub: github.com/huynhnhanquoc

• Open Source: github.com/kitmodule

• Buy me a Coffee: buymeacoffee.com/huynhnhanquoc

• Keep me Dreaming: ko-fi.com/huynhnhanquoc

Indie hacker simply means solo founder.
A person who builds alone.
A person who carries both the idea and the weight of it.

In a previous essay I wrote that if someone asks what I do and they truly want an honest answer, I would say that I am an indie. I have never liked being defined by the term Indie Hacker because the word hacker carries too many misconceptions in the minds of non technical people. They assume that if you work in IT you must know how to hack Facebook or fix a washing machine or some other strange fantasy they imagine.

I am simply a programmer.
Someone who helps the world operate through code.
So an indie hacker, to me, is just a solo startup or sometimes only a solo coder on a journey toward becoming a solo founder. That is exactly who I am after ten years of writing code and five years of turning strings into systems quietly running somewhere inside the Internet.

Dreams Carried From Failure To Failure

When a startup fails, you start again. Often alone.

Recently I have been building KitWork and received many conflicting opinions. Strangely, I feel happy about it. Because KitWork is a dream to me. A blossom in my mind. A personal vision of technological independence that I built with my own hands. That is why I always keep my tagline as Dreamy Indie stack Developer. It reminds me where my dream lives.

The Price Of A One Person Journey

Not everyone has the strength to walk this road.

When you have nothing, money and status and titles become weapons. People belittle you. Mock you. Sometimes they even humiliate you without hesitation. Yet in those dark moments something quiet begins to shine. A small light similar to the moon glowing on an empty road when not a single street lamp remains.

Sometimes the poorest moments are when the mind feels the purest.

Once you walk past the mockery, you begin to see the real shapes of people. The warm and the cold. A spring rain falling on a foolish wanderer. Yet that same rain taught me that a developer does not need to write poorly. Programming does not need to be complicated. Technology does not need to be emotionless or forbidden to dream. And I have always tried to bring these things together.

Beginning And Opening The Mind

Nothing is impossible in this world.
There is only what you do not do.

Success is fine. Failure is fine. What matters is that you begin. That you act. Or at least open your mind to the world. Do not be the birds inside a cage mocking the frog at the bottom of the well while worshipping the circle of a wheel as the only shape of creativity.

A Small Perspective On Mind, Dharma, And Technology

What is emptiness. What is selflessness. What is impermanence.

When we are born, we see the world through the eyes of the body. As we grow and understand more, we begin to see through the lens of the mind. The world appears through whatever lives inside that lens.

Spring rain still allows flowers to bloom. Spring snow makes the petals even brighter. When the mind breaks through its own boundaries, we start to understand that everything is born from it.

Returning To Tam Ky

When I returned to my hometown Tam Ky, I had nothing except my hands and reality. I wandered through quiet streets thinking about technology and startups and the reason I keep going. Whose voice is heard when people judge a person by money and status and position.

Dreamlike flowers or wild rain are both only perceptions. A coin has two faces and so do people. Everything has its shape. There is no true nothingness. So what is the mind. Is it nothing. If it is nothing, why does it influence everything. Or is it a place where the path of the heart meets the logic of the head.

My journey as an indie is a search for a humble heart. If the heart is the mind, then it is a humble mind. And if the mind is emptiness, perhaps humility is also a kind of emptiness. Questions kept flowing through me.

There are days when writing code helps me understand the Dharma. And there are days when understanding the Dharma helps me write better code.

Where does Gen AI come from. Does it have a mind. If not, what controls it at the core. If humans and machines both have a core, where does the human core begin. These are the questions I carry every day.

The Indie Path

A solo founder like me is not searching for fame or status. I want to answer the questions in my heart by experimenting and learning and facing myself. I search for a peaceful dream in a world full of noise.

I love Buddhism though I do not know any full scripture. I love the simplicity of it. A simplicity I understand through the word Minh, meaning insight. Insight born from wisdom and awakening. Is that different from the Eureka moment in programming.

My wife knits yarn. I knit concepts. Sometimes I tell her she is coding in her own way.

Programming And Startups As A Piece Of Music

Am I building a startup alone or simply being romantic with life. I remember a song I once heard:

Please keep lying to me
Let me believe you love me too
I might still find a little joy
When the winter rain arrives
Farewell wandering days

These hands still hope
This heart still trembles
I love you with all the fated suffering
No complaints and no blame
Let me love for a lifetime

And in that romance I have woven programming and entrepreneurship into the everyday world. A song. A picture. A sudden rain. A tiny moment in life.

I search for simplicity within all these things. And I am grateful to those who taught me that. Steve Jobs. Leonardo da Vinci. And Golang.

There are roads without signposts.
But if you know why you are walking, you will not be lost.

Notes

• Article posted in 2025 and reposted

• AI-powered translation

• Read the original Vietnamese version here: https://hnq.vn/blog/ke-khoi-nghiep-mot-minh

More About Me

• Blog: huynhnhanquoc.com

• GitHub: github.com/huynhnhanquoc

• Open Source: github.com/kitmodule

• Buy me a Coffee: buymeacoffee.com/huynhnhanquoc

• Keep me Dreaming: ko-fi.com/huynhnhanquoc

Continuing from the previous post, many people asked what kind of stuff I was on that made me write like that. Today I will answer the question from the curious audience. And yes, this article is proudly sponsored by LLM, a small joke, so take it lightly and enjoy the read.

Last week I finished testing the first stage of cron scheduling and routing. Everything went well. The release v1 is almost ready and the roadmap is nearly complete. I do not call it an MVP. It is release v1.

Creative Rituals and Afternoon Inspiration

Every afternoon I sip a small 90 ml espresso or a latte from Highlands Coffee. When the first sip hits, the sunlight stretches across the traffic lanes, weaving through buildings, and the mind of a developer feels like neatly arranged strings helping the world move forward.

Cars flow past the intersection of Hùng Vương and Lê Lợi in Tam Kỳ. Inside the café sits a small soul carrying a dream of technological independence. Across the street is the digital library of Quảng Nam University, where that younger version of me once lived, studied and dreamed.

Almost ten years ago, when I first touched C#, DevExpress and WinForm, I woke up every morning without needing motivation from money or ambition. I simply sat at the desk and coded. Arrays, DevExpress, WinForm, everything was new and exciting. That dream was built from reading clean VB code rewritten into C# by anh Thảo Meo.

Ten years passed like a soft dream. Now at thirty, halfway through life, I have learned to stand back up after a fall, to know humility and respect, to know the vastness of the sky and sea. Everyone begins their dream somewhere.

Indie Projects and Growing Up

In 2020 my startup collapsed. I returned to Tam Kỳ with nothing but a dream of tech independence and Golang. I only knew how to use frameworks without understanding the foundations. I wrote code because the framework told me how.

So I decided to start over from the basics. From string to []byte to runes. Understanding references. Writing my own template engine. My own pipe functions. Every line of code and every small experiment became a lesson.

I built and tested more than twenty tiny websites, all running on a VPS with 1 core, 2 GB RAM and 20 GB of disk. Some sites reached top rankings with high traffic but failed just as quickly. Revenue was small and payouts were slow.

No project succeeded one hundred percent and no project failed one hundred percent. There was only fail, learn, get back up. That mindset became the foundation of KitWork.

The biggest lesson was simple: you only fail when you refuse to learn something new, like a bird staying inside its cage because the outside world feels unfamiliar.

Thoughts on Dev Work, SEO and Experience

I used to write a lot of things. People said do not reinvent the wheel. Others said your work is just a grain of sand in the desert. But we are not born understanding other people’s words. We only grow by falling and standing again.

SEO was another important experience. It is not just numbers. It is the ability to translate something complex into something simple so others can understand and pass it on.

KitWork: A Tool for Developers and Workflow Lovers

KitWork is not just a README file. It is a real tool for developers. If you are a dev, you might want a tool for

Workflow management
Fast template deployment
Deploying without Docker or complex environments

KitWork was born from ideas around serverless functions and GitHub Actions. I tested Vercel Functions, Cloudflare Worker, Firebase Functions, DigitalOcean Functions but they all felt too complex. My stack for deploying templates only required editing code or copying a file, just like serving a static file.

Why not build it that way? Why not make a system that anyone can use, lightweight, fast and easy to deploy?

Benefits of KitWork

Single binary that runs instantly without Docker, Node or a database
Config driven workflows, API, cron and scraping all in one YAML or JSON file
Great for indie developers, startups and SMEs who want fast and flexible deployment
Open source so anyone can contribute and extend

You can try KitWork now at kitwork.io or explore demos on GitHub.

The Market KitWork Serves

KitWork is built for
Independent developers
Small startup teams
Indie creators
Anyone who wants simple workflow management and painless serverless style deployment

This market is exploding. Developers need flexibility, accessible tools and solutions that do not require Docker or heavyweight cloud stacks.

Why the market needs KitWork

Many developers and small businesses are limited by complex stacks that make job automation heavy and slow
Indie devs, startups and SMEs worldwide need lightweight, easy to use, self host tools
KitWork helps developers move freely, build faster and reduce cost and overhead

You can download the binary directly at ./kitwork-win.exe or ./kitwork-linux and try immediately.

Imagining the Future

I imagine a world where every developer, whether solo or in a small startup, can automate everything scraping, cron jobs, pipelines, serverless API tasks with one config file and one binary.

KitWork is the tool I want to play with powerful, simple, free. It is a solution for indie devs, small teams and SMEs to deploy workflows freely with less overhead, more speed and more flexibility. It is strong and simple at the same time, suitable for both experimentation and production. kitwork.io

Notes

• Article posted in 2025 and reposted

• AI-powered translation

• Read the original Vietnamese version here: https://hnq.vn/blog/open-tu-duy-chi-don-gian-bang-file-readme

More about me

• Blog: huynhnhanquoc.com

• GitHub: github.com/huynhnhanquoc

• Open Source: github.com/kitmodule

• Buy me a Coffee: buymeacoffee.com/huynhnhanquoc

• Keep me Dreaming: ko-fi.com/huynhnhanquoc

For me, that was the beginning, not just of Kitwork, but of an indie path that I knew was worth pursuing.

Today, Kitwork is live at opens.vn with a small demo API available at https://opens.vn/api/price-gold/pnj.

If you do not see any results, it might be because you arrived late, the server is overloaded, or simply because I have not implemented caching yet.

This is also why I chose open-source. You can clone the repository and run it yourself at https://github.com/kitwork/kitwork. Just clone the repository, run the executable for your operating system, and Kitwork will run on port 80. No Docker, no environment setup, no dependencies.

Basic Structure of Kitwork

The folder ./tasks contains .work files. Currently, these files are static, so if you edit them, you need to restart the service. I plan to add a feature to automatically watch files and reload changes, similar to Git or nodemon.

The folder ./router can be edited directly and Kitwork will reload immediately.

Go code is optional. You can delete all .go files. Kitwork only needs the executable file and the configuration folders.

Many people think Kitwork is YAML that generates Go code. It is not. It is a combination of configuration and handler, similar to serverless functions and workflow engines, but extremely lightweight, self-running, and self-deploying. Kitwork allows me to deploy any service as quickly as possible.

The Story Begins with Kitstack

A younger sibling once asked me, “Why do you not open-source the things you have built?”

I had written a fullstack framework, which I call Kitstack. It is similar to Liquid, Django, or Spring Boot but written in Go. Kitstack sustained me for years and helped me deploy websites with just creating a profile, copying the template folder to the server, and the project runs immediately.

However, Kitstack contains many customer APIs and security functions, so I could not open-source it.

That is why I created Kitwork, where I extracted the essence of five years of work. It includes DNS systems, load balancing, proxy engine, template engine, plugin architecture, and a lightweight configuration experience similar to serverless.

All of this will gradually be incorporated into Kitwork.

What Kitwork Will Become

I do not want Kitwork to be just a repository. I want it to be the first platform for indie hackers or small startups starting their tech dreams.

You can clone a Git folder and run it. Instantly you have a backend, routing, workflow, and templates. No environment setup, Docker, or Kubernetes required.

Kitwork’s long-term vision includes running self-hosted serverless functions through .work files, building a low-code or no-code backend where APIs, workflows, and cron jobs can be configured without complex coding, creating a lightweight and maintainable microservice system that does not depend on the cloud or heavy infrastructure, integrating V8 using v8go to run JavaScript logic directly inside .work files without Node.js, querying the database directly in .work files without additional Go handlers if not needed, and rewriting the template engine to be more flexible and clean since Go templates are limited and do not support operators.

Opens.vn is a playground for Testing and Sharing

I will experiment with Kitwork at opens.vn and open everything to the community. Services, sample APIs, workflows, and templates can all be downloaded, edited, self-hosted, and turned into your own platform.

Others sell services. I share my dream.

To many, Kitwork may seem like just a website and a GitHub repository. But anyone who clones the repo and runs it will feel what I mean: a small platform with the potential to become very large, an indie tool that could spark an entire ecosystem.

You can also view and vote for Kitwork on Product Hunt at https://www.producthunt.com/products/kit-work.

Kitwork and I, as an indie hacker passionate about open-source, continue this journey. Every line of code, every workflow, is how I share my dream with the world as an indie hacker building in public.

Notes

• Article written and reposted in 2025.

• AI-powered translation available.

• Original Vietnamese version: https://hnq.vn/blog/xay-dung-mot-cong-cu-de-xem-lap-trinh-theo-cach-khac

More About Me

• Blog: huynhnhanquoc.com

• GitHub: github.com/huynhnhanquoc

• Open Source: github.com/kitmodule

• Buy me a Coffee: buymeacoffee.com/huynhnhanquoc

• Keep me Dreaming: ko-fi.com/huynhnhanquoc

Lately, I have been losing sleep because, for the first time in ten years, I can see my own path clearly. Last night, in a tiny nine-square-meter room, I listened to the wind outside, my mind wandering among clouds chasing dreams. In ten years, I have never seen programming so clearly. I realized I am standing at the edge of a turning point—a place where the world of programming can be seen differently.

“Programming is not only about solving problems. It is about understanding, dreaming, and shaping a world with your own hands.”

Roadmap = README

Today, I finished it. KitWork is just a README, a roadmap, but for me, it is the map of my life. It contains the essence of my thoughts, my exploration, and the dreams of a programmer chasing freedom and creativity. It brings me closer to the dreams I have pursued for years: technological independence and what I call my “flowering dream.”

I do not need a degree to prove anything; this README itself is proof of my journey. It captures knowledge, curiosity, and the heartbeat of a programmer chasing the edges of madness.

“A simple text file can hold the life and vision of a programmer.”

Inspired by Modern Tools

KitWork draws inspiration from GitHub Actions, n8n, serverless functions, and Docker. It reminds us that programmers often create solutions for clients, but when we solve problems for ourselves, everything else begins to untangle naturally.

I see a future where programming happens in the simplest files. There is no boundary between front-end and back-end, no separation between programming languages and machine languages. KitWork transforms the most complex systems into something readable, manageable, and deployable by anyone. Every action, every device, every chip can implement it—from the simplest task to the most complex microservices.

“The simplest tools often reveal the deepest truths.”

Programming from Simplicity

KitWork does not replace programming languages. It turns no-code and low-code ideas into a fully functional system. It allows people to design workflows, build backends like neatly arranged strings, and replace outdated methods. Logic becomes text that both humans and machines can understand instantly.

The idea came from a simple question: how to make a JavaScript file dynamic without Node.js. From GitHub Actions to serverless functions, I asked why not implement it in Golang—fast, efficient, perfect for microservices. I wanted algorithms and dynamic JS files self-contained, easy to read, easy to deploy.

“Imagine waking up to systems orchestrating themselves, a backend built in hours, a workflow running without manual intervention.”

Open Source and Vision

The name KitWork carries meaning: work in workflows, work in frameworks, and work sounds like my own name. It allows shipping projects independently, self-hosting services without relying on SaaS, and managing complex operations like load balancing in a few simple files.

I open-sourced it knowing someone may copy it, but that is a good thing. Open mindset is what improves the world, not just source code. KitWork simplifies complexity, makes systems readable and maintainable, and lays the groundwork for a new programming language: one of simplicity, clarity, and intentionality.

“Simplicity is not the absence of complexity. It is the art of making the complex understandable.”

The Awakening

KitWork is the first reality of the programming journey I want to follow. It is a tool to create a future where coding is simple, transparent, free, and full of inspiration. Even the most complex systems can become readable, maintainable, and deployable by anyone. It allows humans and machines to communicate seamlessly.

I can imagine mornings when systems operate automatically. I can see backends built in hours, landing pages in a few hours, entire workflows running seamlessly. This is the future I see—a world where programmers focus on ideas, not boilerplate, where logic becomes readable, and creativity flows without friction.

“Even the most complex ideas can become simple. The most intricate systems can be readable and maintainable.”

github.com/kitwork/kitwork

Notes

• Article written and reposted in 2025.

• AI-powered translation available.

• Original Vietnamese version: https://hnq.vn/blog/xay-dung-mot-cong-cu-de-xem-lap-trinh-theo-cach-khac

More About Me

• Blog: huynhnhanquoc.com

• GitHub: github.com/huynhnhanquoc

• Open Source: github.com/kitmodule

• Buy me a Coffee: buymeacoffee.com/huynhnhanquoc

• Keep me Dreaming: ko-fi.com/huynhnhanquoc

Years ago, I carried a dream I called “technological independence”. At the time, I had no idea what it really meant. Over the years, I realized that it was the dream of controlling my own code.

For a long time, I didn’t even know how to define the path I was on. Eventually, I discovered that I love writing code, creating something new, and understanding both the logic I’ve written and the product I’ve built.

From Zero to First Earnings

I started with nothing, working to earn my first tiny sums online. From 14,000 VND to hundreds of thousands, to a few million. I still remember the times when all I had was reality—the reality of a fool, someone who later learned to call himself a dreamer.

My journey began with ideas sketched on an A0 sheet, small diagrams, learning Figma to draw database schemas, and writing my first lines of code. It wasn’t just strings arranged logically. I designed DNS systems to organize domains, built templates with Golang template, explored frameworks, and poured the dreams of a naive mind into it all.

Eventually, I published a price comparison website like Samdy, then spent days seeding links, waiting for the first numbers to appear. Just a few thousand VND. Those were some of the hardest days—grueling, exhausting—but the struggle itself became fuel, teaching me perseverance. I often reminded myself:

Good books are written by those with experience. I am still gathering the material to write the story of my own dream.

A fool calls himself a dreamer.

Over the past year, I began to understand the definition of an indie hacker. In a vague, wandering way, I explored the concept through social media and chatbots, and slowly, I defined myself.

Dreamy Indie-stack Developer. It sounds elaborate, even amateurish, but for me, it tells a story.

I do not target SaaS or monthly revenue. I do not chase users for MRR (Monthly Recurring Revenue). I do not claim to be a full-stack developer because, in a world flooded with deployment tools, calling oneself full-stack feels diluted.

I call myself indie-stack because I take an idea, design a logo in Figma, write its story, and deliver it to users using anything I can. A chip, a browser, or even a full platform. While others deploy via Vercel, Firebase, Cloudflare, I deploy with a copy command or drag it to self-hosted cloud I control.

And dreamy? The dreamer. Once, I called myself a fool, clueless about the path I was on. Now I know: the code is mine, I control it, I develop it, and I understand it.

I do not tell this to boast. I tell it so you know: somewhere out there, fools and dreamers exist, chasing dreams that no one else can understand. Only the fool can see the beauty of their own dream.

Indie Hacker vs Indie Developer

I once asked a chatbot about the difference between indie hacker and indie developer. It said:

Indie hackers are like product builders who monetize, while indie developers lean more toward games.

Perhaps fools begin as gamers, obsessed with the game they built themselves, playing it alone before sharing it with millions. Stories like Nguyễn Hà Đông, the BK student behind Flappy Bird, Brendan Greene, or Hà Gia Bảo with Binsoo show massive success.

But what about the failures? We rarely hear about them. Still, one day, I found my life’s dream, a guiding star pointing toward open-source.

Open Source and Starting Now

Back in 2019, in a coworking space, I stumbled upon the Wolfram Language logo. Curiosity led me to Stephen Wolfram, and then TED’s talk on computational universe programming. It sparked a fire in this naive dreamer, chasing technological independence, just walking forward, believing tomorrow exists.

Famous figures like Linus Torvalds inspired me as well. The teachers I’ve never met, never spoken to, never learned a word from, yet their stories shaped me:

• Leonardo da Vinci taught me to love learning, exploration, and discovery.

• Steve Jobs taught me simplicity and creativity.

• Linus Torvalds taught me perseverance with code, loving what I do, and sharing it with the world.

I admire them not for wealth or fame, but for their journeys, the mindset they modeled, the experiences I could never have on my own.

Publishing, Sharing, and Open

I began taking parts of my code, refining it, and letting AI help polish it. I started publishing small packages and stories in English. It’s like Build In Public, but I prefer a word that feels truer: Open.

Years ago, I saw people in the industry guarding their work as a secret advantage, treating it as their ultimate product. I once did the same.

But openness changed me. Sharing stories, even if some disagree, reveals that fear holds us back: fear of the new, the strange, and others who may be better. My advice is simple:

Share. Every shared story is a milestone on the path of growth.

We are all fools in pursuit of happiness and inner peace. Life’s greatest gift is experience—the lessons we learn to grow.

Why I Write Code

I did not come into this world for money.
I came for dreams. Dreams of creating something meaningful, leaving a small mark in this vast world.

When I started, I had nothing: no capital, no connections, no foundation. Just a fragile belief that perseverance would make the world listen.

Then I discovered code.
Code is not just a tool for living—it is the language I use to tell my story. It bridges reality and dreams.

In every line, I see the logic of life. Understand the rules, and you can change them.
In every project, I feel the power of thought and creation: nothing is too far if you dare to start from zero.

But code alone cannot run without the fuel of reality.
Long, grueling days, failures, sleepless nights—they burn raw, honest energy into me. Reality, with all its dark corners, fuels my journey.

I do not code to escape reality. I code to understand it, to make it more beautiful.
And though money, fame, or success may come and go, the dream remains. It shines whenever I type the first line of a new idea.

I don’t know how far I will go. But I do know this: every line I write today is a small step connecting reality and dreams.

As long as I keep writing, creating, and living by my ideals, I am on the right path.

A Message for You

If you are starting from zero, remember:

• Every great journey begins with a small step.

• No one is born with light. It is created from falls, long nights without giving up, and moments when you tell yourself, “I can do this.”

• Do not fear reality. Turn it into fuel.

• Today’s limits become tomorrow’s strength.

When you look back, you will realize: the most valuable thing is not where you’ve reached, but who you’ve become on your way to your dreams.

Notes

• Article posted in 2025 and reposted

• AI-powered translation

• Read the original Vietnamese version here: https://hnq.vn/blog/nghe-indie

More About Me

• Blog: huynhnhanquoc.com

• GitHub: github.com/huynhnhanquoc

• Open Source: github.com/kitmodule

• Buy me a Coffee: buymeacoffee.com/huynhnhanquoc

• Keep me Dreaming: ko-fi.com/huynhnhanquoc

Lately, I’ve been revisiting my old writings. Some are from five years ago, lost among half-finished ideas. Some I never dared to hit Publish. Some I wrote and deleted because I didn’t know who I was writing for.

Now I ask AI to translate them into English, trying different versions, comparing every sentence, searching for what truly feels like my voice. They may be small pieces of writing, but for me, they are part of a quiet pilgrimage—a way to rediscover myself, line by line.

I no longer write to be read. I write to listen to myself.

When I first started coding, I didn’t know where I was going. I just knew I loved creating things. A piece of code that worked. A product that someone actually used. Something I could call my own. I never imagined I would one day become the Dreamy Developer.

I wrote small blogs in little communities about programming, side projects, and fragments of life. I built websites, wrote, and shared like someone trying to find a corner of the Internet to belong to. But nowhere truly felt like home.

I learned and worked with C#, then Angular. Then one day, I met Golang, and everything started to change.

Golang taught me neatness, pragmatism, and minimal thinking. It was not flashy or demanding, but it forced me to understand the essence of problems. No hiding ignorance. No masking code. It reflected my own growth, teaching me to live honestly with myself.

Starting from Nothing

I still remember those early days. Just an old laptop and a vague belief that I could make something happen.

I wrote my first lines of code for DNS, built my first template architectures, and got my first client. Then Samdy was born and reached the Top 100 e-commerce websites in Vietnam.

At one point it earned about 600 USD per month, even when barely running. Later, I moved into affiliate marketing. I wrote content, ran ads, and stayed up countless nights optimizing campaigns. At one point, I earned 2,500 USD per month with around 800 USD in costs.

I also received awards like First Prize in “Nhìn lại hành trình” and Second Prize in “Kể đi chờ chi.”

But I realized that numbers and titles cannot define me. They are experiences, checkpoints that help me understand effort, limits, and myself.

Even now, I earn a modest income each month.

More importantly, I still walk this path—to write, to code, to share, to live quietly and persistently with my dream.

Realizing I Am an Indie Hacker

At first, I thought I was just building software out of passion. Looking back, I realized I had been an Indie Hacker all along.

Indie Hackers build products and companies independently, without investors or big corporations. They bootstrap, work independently, and often share their journey publicly.

That is exactly what I have been doing. Creating small tools, tiny platforms, learning, sharing, and living alongside them.

I started with nothing but willpower, small lines of code. And now I build products that help others. I am not just coding anymore. I am creating a small world of my own.

Learning from Build in Public

Then I discovered Build in Public, and it clicked. Share.

When you are right, you guide others. When you are wrong, you guide yourself.

You do not need success to share. You do not need perfection. Being real is enough.

I began writing again about what I do, think, and try. Even failed projects, unfinished code, and half-built frameworks. The more I shared, the more I realized the journey is about understanding.

Understanding why I code. Understanding why I continue even when no one is watching. Understanding myself.

No Titles, Just Definition

I no longer chase labels. I am not just a coder, marketer, or indie hacker. I am someone who writes, codes, reflects, and dreams. Someone standing between technology and emotion, between logic and intuition.

I now call myself a Dreamy Indie Stack Developer. I build my own small technical universe in my own way, at my own pace.

I do not have a team. I do not have investors. All I need is space to experiment, fail, learn, and share.

I create small but genuine things like KitModule, KitJS, or other tools I find beautiful and useful. Maybe someone else will find them helpful too.

The Journey Is Home

This journey has never been easy. Some days I want to quit. Some days I look around and everyone seems ahead.

But I chose this path not because it is easy, but because it is mine. My dream.

Every line of code, every blog post, every idea is part of me. I no longer need to search for where I belong. The journey itself is home.

I write. I code. I dream. This is the life of a Dreamy Developer.

Notes

• Article posted in 2025 and reposted

• AI-powered translation

• Read the original Vietnamese version here: https://hnq.vn/blog/dreamy-developer-di-tim-noi-minh-thuoc-ve

More about me

• Blog: huynhnhanquoc.com

• GitHub: github.com/huynhnhanquoc

• Open Source: github.com/kitmodule

• Buy me a Coffee: buymeacoffee.com/huynhnhanquoc

• Keep me Dreaming: ko-fi.com/huynhnhanquoc

It’s been a long time since I talked to someone who shares the same wavelength.
Even though our conversation was only online, it felt as if we could clearly see each other’s path.

We met through a thread.
I don’t know what to call this relationship.
Maybe, since we first encountered each other in a BuildInPublic group, we could call ourselves indie hackers.

But why do I title this piece “The Dream of Indie Coders”?
Perhaps it’s because of where we come from.
We are young people chasing our own dreams, feeling alive when we code and follow our passion.

We might have to work harder than others to reach what we truly desire — that is, to live fully within our own dream.

Vanilla JS and Early Ambitions

Lately, I’ve met many developers still using Vanilla JS.
While most run after frameworks, we choose a different path.

Five years ago, I returned to Tam Kỳ and began coding the purest version of my dream — with Golang and Vanilla JS.
Recently, I started releasing a small library (or framework, depending on how you see it) called Kit JS.

Yet, I want to preserve the purity, the raw power of Vanilla JS, carrying it forward while combining it with SSR capabilities.

I didn’t write this library to compete or change the world.
I just wanted to reconnect with the original strength of these languages — a way to remember where I came from.

Like the story of backend languages trying their hand at frontend — it can work in some ways, like with WebAssembly — but it’s not everything, and certainly not a complete full-stack solution.

I once thought deep learning in programming meant mastering frameworks or flashy languages like TypeScript.
But the more I code, creating small libraries to solve simple tasks, the more I realize:

“Learning deeply is learning the fundamentals first.”

Today

Today is a rushed coding day.
I am expanding the core of Kit JS and deleting lines of code I spent hours writing — much like the ninth time I refactor my Golang system.

I used to ask myself:

“Who will recognize this? Who will pay for this?”

Now, I no longer seek an answer.
My heart has already answered.

Sometimes, a developer’s happiness is simply sitting in a café, amidst bustling people, yet keeping a heart fully devoted to passion.
Sunlight kisses the streets, and a foolish dream is guided by the heart.

We — Seekers of Tiny Happiness

We chase ambitions, smiles, and a small happiness in every line of code.
Every tiny snippet contributes to the world beyond our screens.

I’ve asked myself:

“Why do I exist in this world?”

Perhaps many coders have asked the same.
If we had a “platform” handed to us, would we still dare to dream?

Tomorrow, the sun will bloom again — like a flower spreading its fragrance across the sky.
Just like us, still seeking our own happiness.

That happiness might just be a small dream — of one or many indie coders.

Code, Low-Code, or No-Code at All

The world remains beautiful — beautiful because we can draw our dreams in code.

I will step outside and enjoy a sunny day.
The sun still dreams, and the code keeps flowing.

Clouds — true to their name — are just clouds.
And perhaps life, too, drifts along those clouds.

We are just small developers, seeking happiness in coding, contributing, and leaving a mark in the world.

Out there, some have fame, titles, and recognition.
We — the foolish ones — only have hearts that resonate and mutual respect for our craft.
I have always looked up to Linus as a giant in that sense.

Hearts of Laughing Fools

Today, the wind may not stir the trees, but sunlight peeks through after a sudden rain.
If we could, we would code for a lifetime.

He once told me:

“The happiest days are Friday and Saturday — the days I get to do something just for myself.”

I am luckier — I don’t “sell myself,” because I indulge my foolish heart and make it suffer sometimes.
But neither of us has another choice.
Because we have no “platform.”

Ah, yes — we do.
Our platform is the dream — the dream of foolish indie coders, delightfully naive.

I always hope that other builders will keep moving forward.
Step by step.

If you walk towards the sun, you will feel its warmth.
And if you walk against the sun, the light will still follow.

Every step has a reason to begin.
And perhaps, we all started somewhere — with a small dream.

— Written on a sunny morning, with keystrokes echoing in rhythm with the heartbeat.

NOTES

• Article posted in 2025 and reposted

• AI-powered translation

• Read the original Vietnamese version here: https://hnq.vn/blog/giac-mo-cua-nhung-indie-coder

More about me:

• Blog: huynhnhanquoc.com

• GitHub: github.com/huynhnhanquoc

• Open Source: github.com/kitmodule

• Buy me a Coffee: buymeacoffee.com/huynhnhanquoc

• Keep me Dreaming: ko-fi.com/huynhnhanquoc

I remember it clearly — sitting in a tiny café, looking at my own hands and asking:

“What am I really looking for?”

No one answered. All I knew was that if I had nothing to lose, then everything left was an opportunity to start over.

By day, I delivered packages. By night, I wrote code. Each delivery earned fifteen thousand dong — enough for a cup of coffee and a few more lines of clumsy code. Day after day, this loop repeated: deliver, code, deliver, code. Life was small, but it felt pure in a strange way.

Looking back, I realized that those days taught me the most important lesson: big dreams don’t begin with leaps; they begin with slow, small steps.

Golang and the Dream of a Fool

I dabbled in many languages — Rust, Python, JavaScript. But I chose Golang. Not because it was the most powerful, but because it was simple and honest. Within that simplicity, I saw myself — a fool believing in small things.

I started from scratch: learning syntax, practicing routers with mux, exploring fiber, writing a DNS, thinking about pointers and how they traveled through templates. Some nights I would lie on an old chair, staring at the ceiling, pondering how a pointer could maintain its value across page layouts. I didn’t know why I thought so deeply; all I knew was I wanted to understand everything to the core.

No mentors, no guides — just me and the computer. Every wrong line, every bug fixed, was a lesson. Gradually, I realized that the most important thing wasn’t the results, but the feeling of laying the first bricks of a dream yet to take shape.

SSR — Returning to the Original Dream

I started with the web. And perhaps the web is what kept me hooked on programming to this day. From the first HTML tags, a few clumsy CSS lines, copied JS snippets, to Angular, Firebase… I went in circles and eventually returned to the starting point, where everything boiled down to a simple function:

add(a, b) => a + b

I began building an SSR system using Golang templates, experimenting with pointer inheritance between pages and layouts. Once, I sat in a café, laughing and showing my brother the DNS system I’d just built. It only returned an ID, that’s all. Yet in that ID, I saw an entire dream.

I dreamed of a system capable of managing thousands, millions of websites — all connected, centralized, and SEO-optimized. I dreamed of a platform that could deliver content to everyone, gently and efficiently.

Working with SSR, I realized something many modern frameworks forget: the web isn’t about complexity, it’s about improving experiences. Programming doesn’t always have to be grand. Sometimes, it’s just the journey to rediscover the purity of “adding one thing” to a web page that already exists.

JavaScript and Dreams

I don’t recall exactly when I learned JavaScript. Maybe after Golang. Before that, I knew TypeScript, worked with Angular, but never truly understood JS — until I discovered Web Components.

I saw a different world. JS didn’t need frameworks to be powerful. Vanilla JS — simple and free — gave me a sense of true mastery. I sometimes wondered:

“Are JS frameworks just flawed versions of JavaScript itself?”

I grew tired of tiny programs requiring thousands of node modules. I began writing my own web components to enhance SSR-rendered websites. And eventually, I returned to an idea from my C# days: two-way binding.

From those nights, Kit JS was born.

Kit JS isn’t a framework meant to compete. It’s how I tell my story. It bundles everything I’ve learned, believed in, and lived through — from reactive programming, define, reference, to inheritance. To me, Kit JS is more than code; it’s a message:

“Understand technology before depending on it.”

Openness and the Indie Path

About a year ago, I heard the term “indie hacker.” I’m not exactly one, because making money wasn’t my goal. I just wanted to code, share, and connect with others who carried the same spark.

I like to call myself an indie-stack developer — someone walking an independent path, self-taught, building, and rewriting what I need. I started open-sourcing snippets from real projects, turning them into small packages that others could use.

I began blogging, sharing more. Every post, every line of code, every package is part of that dream — the dream that somewhere, someone might find inspiration in my journey and continue building their own.

If no one paves the way, our first lines of code become the path.

The dream of technological independence isn’t about creating a million-dollar product. It’s about understanding technology, being free with it, and letting it bridge passion with real value.

I’m still on that journey. Every line of code, every word I write, is a small but steady step. And I know, no matter how the world changes, I will remain a dreamer with an old laptop and a flower on the keyboard — a fool who believes that with a dream, we can create an entire world.

NOTES

• Article posted in 2025 and reposted

• AI-powered translation

• Read the original Vietnamese version here: https://hnq.vn/blog/con-duong-indie

More about me:

• Blog: huynhnhanquoc.com

• GitHub: github.com/huynhnhanquoc

• Open Source: github.com/kitmodule

• Buy me a Coffee: buymeacoffee.com/huynhnhanquoc

• Keep me Dreaming: ko-fi.com/huynhnhanquoc