My Journey as a Freelance Web Developer for Etugi

TL;DR

Built a full e-commerce website for Etugi Bình Dương — pure HTML, CSS, JS, zero backend.
Blog stored as Markdown files. Products stored in JSON. Shopping cart stored in cookies.
Orders sent via EmailJS. Three separate accounts for three different forms.
UI came out beautiful. SEO was a disaster. Self-score: 7.25/10.
First real freelance project. Hardest thing I've ever shipped. Wouldn't trade it.

I had no portfolio. No past projects to show. No track record of any kind.

So when Etugi Bình Dương — a water filtration company in my hometown — reached out and asked if I could build their website, I said yes before I fully understood what I was agreeing to.

Their requirement was simple:

"We need a website to showcase our products and brand."

I told them I'd build everything from scratch. No WordPress. No templates. Pure HTML, CSS, and JavaScript.

I genuinely believed it would be straightforward. It was not.

1. What Etugi Needed

Etugi Bình Dương sells water filtration systems — residential, industrial, whole-house setups. Their customers are local, so the entire site needed to be in Vietnamese.

The structure they wanted wasn't small:

Homepage
About (company overview + showroom)
Products — six categories: Dân Dụng, Bán Công Nghiệp, Công Nghiệp, Thiết Bị Lọc Tổng, Vật Liệu Lọc Nước, Phụ Kiện Máy Lọc Nước
Technology page (MOFs water filtration)
Blog / News
Shopping Cart & Checkout
Contact

That last one — Shopping Cart & Checkout — is where things got interesting.

2. The Stack I Chose (and Why I Regret Nothing)

I had one rule going into this: no backend.

Not because it was the smart choice. Because I didn't know backend at the time and I wasn't going to admit that to a client. So I made it work with what I had.

I took visual inspiration from HKAngles Freshter — a clean, modern product layout that matched Etugi's vibe. I didn't copy it. I studied it, pulled apart what worked, and adapted it into something my own. Classic "steal like an artist".

The architecture ended up being:

Product catalog → JSON files fetched dynamically
Blog → Markdown files fetched and rendered on the fly
Orders → EmailJS
Cart persistence → browser cookies

Every single one of these decisions came back to haunt me in different ways.

3. The Blog System

I thought storing blog posts as .md files would be elegant. Lightweight. Developer-friendly.

What it actually was: a maintenance nightmare.

Every new article meant manually creating a file, configuring the path, writing metadata by hand. There was no dashboard, no CMS, no way for the client to touch it themselves. Every update went through me.

Worse, from an SEO standpoint it was essentially invisible:

No dynamic metadata per article
URL structure that Google couldn't make sense of
Search Console constantly struggling to index anything

The blog worked. But it worked the way a car with no windshield works — technically functional, deeply unpleasant.

4. The Product Pages

Six categories. Dozens of products. All living in a single JSON file.

Fetch it, loop through it, render it — clean in theory. In practice, the file grew unwieldy fast. Editing anything required opening a JSON blob, finding the right entry, making the change carefully, and hoping nothing broke.

The client couldn't touch any of it. Every product update was a support ticket to me. That wasn't scalable for either of us.

5. The Shopping Cart (or: How I Invented a Backend Without Having One)

This is the part I'm most proud of and most embarrassed by at the same time.

The client wanted a full order flow: browse → add to cart → fill in shipping info → both parties get email confirmation. Standard stuff. Trivially easy with a backend.

Without one, it took me weeks to figure out.

Persisting Cart Data

The problem: how do you keep cart state when a user navigates between pages with no server involved?

My solution: cookies.

When someone clicks "Add to Cart", JavaScript writes the product name, price, and quantity to a cookie. When they open the cart page, JavaScript reads those cookies and renders the list. It's fragile. It's not scalable. Clearing cookies wipes the cart. But it worked, and at the time I was genuinely proud of figuring it out.

Sending Order Emails

No backend means no way to send emails from a server. So I used EmailJS — a service that lets you send emails from frontend JavaScript.

Here's the part that still makes me wince: I created three separate EmailJS accounts because I didn't realize you could have multiple templates under one account. One for the homepage contact form. One for the contact page form. One for the order system.

The checkout flow ended up looking like this:

[Customer] → Add to Cart → [Cookies]
[Cart Page] → JS reads cookies + collects shipping info
[EmailJS] → sends order summary to Etugi
          → sends confirmation to customer

Built entirely from scratch, with no framework, no reference implementation. Just me staring at documentation at 2am trying to make it work.

6. SEO Was a Disaster

I won't sugarcoat it. The site had essentially no SEO.

No dynamic metadata. No schema markup. No sitemap done properly. Google Search Console was confused by the architecture from day one.

But it got worse. Cloudflare analytics started showing thousands of daily hits from random countries — countries that had no reason to visit a Vietnamese water filtration website. The site was being DDoS attacked. And the SEO agency Etugi hired turned out to not be doing real SEO at all — just generating fake traffic, which hurt more than it helped.

The site never ranked the way it should have. That wasn't entirely my fault, but the SEO foundation I built made everything harder to fix later.

7. Final Score: 7.25/10

The website launched. It ran. Etugi used it.

Strong points: the UI was genuinely beautiful — clean, modern, fast. The shopping flow worked end to end. Customers placed orders and received confirmation emails. For a pure frontend build with no backend, it was a real accomplishment.

Weak points: everything that came after launch. The SEO. The maintenance burden. The fact that no one on Etugi's team could update anything without calling me. The cart data living in cookies. Orders existing only in email inboxes with no database record.

7.25 because I delivered what I promised — a working, beautiful website. The 2.75 missing is honest acknowledgment that "working" and "production-ready" aren't the same thing, and I learned the difference the hard way.

8. What I Actually Learned

Not the generic stuff. The real things:

A beautiful UI without SEO is a tree falling in an empty forest. No one finds it. No one uses it. The hours you spent on hover animations don't matter if Google can't index the page.

"No backend" is not a philosophy, it's a constraint. I framed it as a design decision. It wasn't. It was a limitation I worked around creatively, and while I'm proud of the creativity, I should have been honest with myself about the tradeoffs.

Clients can't maintain what they can't access. Every time Etugi needed a product update, they had to call me. That's not a product — that's a dependency. Real tools give clients ownership of their own content.

Your first client is the hardest to get. Once I had Etugi, getting the next one was meaningfully easier. Before Etugi, I had nothing to show. That first project — imperfect as it was — changed everything.

Most importantly: this project is the reason I can write HTML and CSS in my sleep. Every frustrating limitation forced me to understand the fundamentals deeply instead of reaching for a library. That foundation is still with me in every project I build.

This was my first real project. It was messy, imperfect, and genuinely difficult. But it shipped. And shipping something imperfect is worth more than never shipping something perfect.

Start before you're ready. Learn while you build. Ship anyway.