DEV Community: Boby Santoso

How I Built a Multi-Tenant Static Site Engine with Next.js, Nginx, and Coolify

Boby Santoso — Sat, 13 Dec 2025 12:00:00 +0000

Over the past few months my Sister started this Embroidery business, and as a good brother I was eager to help her. I really wanted to help her get more visibility online. Naturally, my first thought was: let's make her a simple landing page.

But, here's the thing:

As a Software Engineer who uses coding agents a lot and understands how powerful automation can be, I had zero interest in building landing pages using drag and drop tools. Not with Wix, Wordpress, not with Lovable, not even with V0.
I already pay for Claude Code, and I want the most optimized, scalable, and developer friendly solution I can build.

That’s what led me to this idea:

a Multi-Tenant Static Site Engine with Next.js.

But Boby, Next.js? Static? What are you talking about?

Let me explain.

High-Level Overview

Before diving into the technical details, let me show you what the system looks like from the top.

Most landing pages today are built manually or with drag-and-drop tools.
I wanted something different:

Automated
Config Driven
Super Fast
SEO Optimized
Super Cheap to Host
And able to host hundreds of sites without breaking a sweat

Architecture

This is the “bird's-eye view” of the entire system:

A single engine built with Next.js
A Config Driven system for each tenant
A Component Factory that assembles pages
A Static Export that generates pure HTML
Automated output (sitemap, robots, analytics, Nginx configs)
Deployment handled by Coolify, assigning subdomains or custom domains

One engine -> unlimited landing pages.

Build Pipeline

Business Config

Each tenant has a JSON config with branding, colors, services, copy, etc.

Component Factory

The engine picks from a library of reusable section templates. For example, you can build commonly used sections like this:

hero
|- default
|- split

features
|- grid
|- list

footer
|- default
|- multi-columns

gallery
|- default
|- scrolling

Static Export (`Next.js`)

Next.js compiles everything into static HTML.

const nextConfig: NextConfig = {
    output: "export",
    images: {
        unoptimized: true,
    },
    trailingSlash: true,
};

Auto-Generated Assets

The system produces sitemap.xml, robots.txt, analytics, OpenGraph metadata, etc.

Nginx Configuration

The generator builds the routing + subdomain config for each tenant.

Deploy via Coolify

Coolify picks up the output -> reloads Nginx -> site goes live.

What this means in Practice

Instead of building landing pages one by one, I can:

onboard a new business
fill out a config
pick the sections
run the generator
instantly deploy a fully functional, SEO-ready landing page.

It’s fast, cheap, scalable, and extremely flexible.

Why Static > SSR for This Kind of Project

For a Multi-Tenant system where I want to host tens or hundreds of small business sites, SSR can be overkill:

Every request needs a Node.js process to run the app
You usually have middleware, auth, data fetching, layout logic on each hit
You need to think about concurrency, memory, cold starts, scaling

With static export:

Each page is already rendered to HTML at build time
Nginx (or any simple web server) just reads files from disk and sends them
There's no React/Next.js code running on the server per request
No per-request rendering = less CPU, less RAM, less that can break

For my use case (small businesses, mostly “read-only” marketing pages), static wins:

First byte is faster (no render step)
Less complexity to scale
Way easier to reason about performance
Much cheaper infrastructure

If I ever need “dynamic” behavior, I can still add:

Small API routes, I have one already
Client-side interactivity
Webhooks or background workers

But the core of the site remains static.

Why I Can Host Hundreds of Pages on a “Cheap” Server

So how much is "cheap"?

A basic cloud server (like a small DigitalOcean/Vultr/Linode instance) typically costs around:

USD $4–7 / month for:

1 vCPU
0.5-1 GB RAM
~10-25 GB SSD
500 GB - 1 TB outbound bandwidth per month

That kind of machine is not great for heavy SSR apps with databases and background jobs.
But for pure static hosting with Nginx, it's actually kind of overpowered.

Rough math:

Let’s say one page (HTML + CSS + a bit of JS) is ~300 KB
With 500 GB outbound bandwidth, you can theoretically serve:

500,000,000 KB / 300 KB ≈ 1.6 million page views per month

With 1 TB bandwidth, that’s ≈ 3.3 million page views per month

Real traffic will be lower, and you'll have images etc. But even if you divide those numbers by 10, you still get hundreds of thousands of page views comfortably.

For a multi-tenant scenario:

100 tenants × 1,000 page views/month each = 100,000 views/month

That’s nothing for a static Nginx box with 500 GB+ bandwidth

And because:

There's no SSR
No per-tenant backend
No database queries per page view

Your main bottleneck becomes bandwidth, not CPU or RAM. And cheap servers already give you a lot of bandwidth for this use case.

So when I say "cheap", I literally mean:

One small cloud instance in the $4–7/month range

If I later outgrow that, I can:

Add a CDN in front
Scale horizontally (more small boxes)
Or move to a slightly bigger instance

But the core benefit stays the same:
Static + Multi-Tenant = a lot of sites on very little infrastructure.

Frontend to Fullstack - Mastering the Architectural Mindset

Boby Santoso — Sat, 31 May 2025 14:39:27 +0000

I spent 6 years working as a frontend developer.

Today, I find myself responsible for building and maintaining fullstack systems. Frontend, backend, deployment, scaling, all of it. Not because I mastered everything, but because I learned how to think architecturally.

Becoming fullstack isn't about learning backend code. It's about changing how you think.

Most frontend devs already know how to solve problems. Architecture is just solving bigger problems but more intentionally.

If you've ever designed a clean component tree, you’re already halfway there.

Architecture starts with the problem, travels through trade-offs, and only then lands in code.

In this post, I'll share what I've learned about developing that mindset, especially as someone coming from a frontend background stepping into fullstack development.

Start with the Problem, not the Tech

Before writing any code, ask:

Who the user is
What pain they have
What "success" looks like
What constraints exist (budget, time, team)

If there's a PRD, read it, analyze it, ask questions, break it down.
This gives you clarity and keeps your decisions aligned with real needs.

Identify Requirements

Write out what your system should do.

Functional requirements

"User uploads a file and the user gains XP"

Non-functional requirements

"Upload speed must be under 2 seconds for 80% of users."

This will help you make technical decisions, like storage, caching, load handling, etc.

Visualize the Flow

Draw the data or interaction flow:

Sequence diagram: user -> frontend -> API -> service -> database
Component diagram: boxes for auth, cache, external services
Entity diagram: tables or document structures with relationships

This step is very important and most likely will always be used.
There's no need to over engineer this though. The idea is to visualize the flow and interaction between services.
As time goes by, you'll most likely going to spend more time here than writing the code.

Separation of Concerns

Architecture thrives on separation of concerns.

As a frontend dev, you already apply this: components handle UI, hooks handle logic, and API calls are abstracted away.

Backend works the same way. Routes handle HTTP, services contain business logic, and database functions take care of persistence.

This kind of layering keeps your code clean, testable, and easier to grow.

Balancing Trade-Offs

Every architectural choice has trade-offs. Whether you realize it or not, you're constantly adjusting performance, complexity, cost, and team velocity.

Here are some of the common decisions you'll face:

Monolith or microservices?
A single codebase is easier to ship, but services give you flexibility and scalability. But there will be cost of complexity.
SQL or NoSQL?
Relational databases like PostgreSQL are strict and structured. NoSQL like MongoDB is more flexible, but harder to validate and model at scale.
Self-hosted or platform-as-a-service?
Platforms like Vercel help you move fast. Self-hosting gives you more control, but also more DevOps to manage.
Simple logic or scalable abstractions?
Hardcoding something might be faster now. But abstracting it into a reusable service or module might save you pain later.

. . .

The key is:

Don't chase "the best." Choose what's right for your current problem and constraints.

Another example, say you're building a small internal dashboard. You could set up a full microservice architecture with Docker, Kubernetes, and separate auth services. Sounds impressive! But why? Is it necessary?

Probably not.

A simple monolith with a single backend repo and an SQLite as the database might serve you better. It's faster to build, easier to deploy, and simpler to debug.

Later, if the app grows or becomes critical, you can refactor and scale. But making the right trade off now saves you time and complexity without sacrificing quality.

Architectural thinking is not about chasing perfect. It's about being deliberate.

Final Thoughts

If you're transitioning from frontend to fullstack, or if you want to level up as Frontend Engineer, remember this:

The most important skill isn't backend, frontend, or any code syntax. It's architectural thinking.

This mindset is what makes the difference between a regular and a great engineer.

AI can help you write code, explain concepts, and fill gaps in your knowledge. But without the right mindset, you'll still struggle to make decisions, design scalable features, or solve real problems.

You don't need to become an expert overnight. Just start asking deeper questions, structuring your solutions with care, and solving problems with intent.

The code will follow.

Crafting a Real-Time Virtual Desktop for Gamified Onboarding

Boby Santoso — Tue, 20 May 2025 14:53:01 +0000

4 years ago we started RiddleStory, now Enboq. The idea was simple: Create an Online Escape Room that remote teams could play together. What was a simple idea has evolved into a Gamified Onboarding Platform. Helping companies turn dull training into immersive, story-driven experiences.

How it started

We started off with an idea for an Online Escape Room. This was during Covid and everyone were forced to stay inside and do stuff remotely.
The vision was to simulate a digital escape room where players could explore, uncover clues, and solve challenges. All inside a custom built desktop environment.

What makes a Great Escape Room

An escape room needs two things to work:

A believable Environment
A compelling Story

Building the Environment

The Environment of the escape room that we built was to give experience of a mix of Mac and Windows desktop. It has most of Mac essentials, like the Dock, Filebrowser, Email, Notes, and Chat.

Dock to hold all applications, such as Filebrowser, Email, Notes, and Chat.
Filebrowser let users open files, draw on top of images, read pdfs.
Email delivers in-game messages and updates.
Notes to write and jot down clues.
Chat to chat and connect with a live moderator.

Our goal was simple: make it feel as real as possible, not just another web page.

. . .

PS: We also built the same Environment in Enboq's blog. Check it out!

Crafting the Story

Story is the core of an Escape Room, its the engine. We represent it as a flow that drives each player's journey:

The game kicks off with a chat message…
Then an email arrives with new context…
Players hunt for clues, in-app or IRL…
They submit answers via chat…
Our bot (or moderator) judges correctness…
Onward to the next puzzle (or branching ending!)

Over time, we evolved from a straight path to branching narratives with multiple endings. Kinda like a mini RPG where your answer may affect the ending

Under the Hood

Building a fully interactive, real-time virtual desktop inside a browser isn't exactly standard web dev work. Here's how we tackled it.

Frontend (React)

The desktop environment was built in React from the ground up. We wrote our own window manager to handle:

Opening and closing apps like Filebrowser, Email, Notes, Chat
Custom window manager for dragging, resizing, stacking
Shared state via Context + hooks, synced in real time
Dynamic theming for white-label clients
PDF rendering (react-pdf) and canvas overlays for drawing
Mini-games: crosswords, word searches, quizzes… you name it

Backend (Node.js, Express, Redis, MongoDB)

REST APIs for sessions, progress tracking, story management
WebSocket layer (socket.io) for instant updates
BullMQ for in-game event scheduling and queue
A story engine that triggers events (emails, chats) based on your choices

Real-Time Magic

The WebSocket layer was the core of the game room:

Incoming messages triggered new story events (emails, chat replies)
Moderator responses were pushed live into the chat app, powered by LLM
Live updates on the progress of the escape room

Moderation System

Moderators played a big role in early versions of the game. However, due to limited personel, we built our own Chatbot powered by nlp.js. We trained the Chatbot to do basic responses like recognizing player's intent in the chat, whether to submit an answer, ask for a hint, or just regular chat with other team members.
Eventually when ChatGPT came out, we also powered the Chatbot using ChatGPT to be able to guide the user through the game.

The Evolution of Our Story Engine

Linear flow: One path, one ending.
Branching choices: Your answers shape the narrative.
Multiple endings: Like an RPG, every decision matters.

This provides lots of possibilities for the Story creator to provide fun and engaging story. Especially, in our case, for Onboarding.

What's Next?

We're always pushing Enboq forward. Our big focus now is utilizing LLMs into every step of the story building process. Soon, you'll be able to generate entire Story Flows on the fly, customized to your company's unique profile (check out how we're summarizing org data here).
That means every puzzle, email, and branching path adapts not just to your team's choices, but to your brand, your culture, and your goals. Imagine escape rooms that feel handcrafted for your business..

I Just Wanted to Code. Now I'm a CTO

Boby Santoso — Fri, 09 May 2025 14:00:00 +0000

I never planned to be a CTO. I just wanted to build cool things and solve real world problems.

Today, I lead a small team, manage our infrastructure, make technical decisions, and still write a lot of code every day.

My younger self would have never imagined this path.

How It Started

My first programming job came during my second year of college. I joined as a junior programmer building a school management system using ASP.NET Web Forms. The codebase followed a clean structure with multi-layer architecture, MVC, and solid naming conventions. It was my first exposure to how real software was built, and I loved it.

But I was curious about more. Web Forms felt outdated, and I kept wondering how modern web apps were built. That curiosity led me to discover AngularJS and React. It completely changed how I saw frontend development. I could finally manage UI behavior with JavaScript, and it felt powerful.

After I graduated, I became a full-time frontend developer working with React and TypeScript. Thanks to my C# background, TypeScript felt natural. At that time, React was on fire in the job market, and I was excited to dive in. I dove head first.

Becoming a Leader

In my first few years as a frontend developer, I stayed in my lane. I worked on UI components, dashboards, animations, anything visual.

Then I was given a chance to lead the web development team.

I still wrote code, but now I was reviewing others work, helping set priorities, and thought more about the big picture.

That shift taught me that leadership isn't a promotion. It's a new kind of responsibility. I started paying attention to communication, decision making, and how work flowed through the team. Soon I cared more about systems than single features.

That mindset prepared me for everything that came next.

From Side Projects to Full Ownership

The real turning point came outside my 9‑to‑5 job.

A client wanted to build an online escape room, called RiddleStory. I joined to help ship the first version. Then more feature requests coming, and I ended up shaping the architecture, discussing infrastructure, and even started interviews for new hires.

They eventually asked me to join full time and lead the technical vision. That is when I officially became the CTO. It felt less like a promotion and more like a natural extension of all those late nights spent solving problems end to end.

What Being a CTO Means to Me

People often picture a CTO announcing funding rounds, speaking at conferences, or managing several engineering teams. All those cool stuffs.

At large startups, a CTO focuses on aligning tech with business goals, managing directors, and talking to investors.

At big corporations, a CTO deals with governance, procurement, security audits, and compliance roadmaps.

For me, being a CTO is closer to the code. I set up CI and CD pipelines, review complex pull requests, spin up new services, and answer "What should we build next?" all in the same day.

It is wearing many hats and knowing when to put one down. It is not about being the smartest person in the room, it is about creating space for the right problems to be solved quickly and clearly. It is a lot of context switching, listening, and choosing what matters over what merely looks impressive.

It is a fun, frustrating, mind-boggling, and never-ending journey of thought. And I genuinely enjoy it.

Final Thoughts

I did not become a CTO by climbing a ladder. I became one by chasing curiosity, filling gaps, and saying yes to tasks that scared me a little.

It was not a straight path, and it was never planned. Looking back, patterns stand out:

Solve real problems.
Communicate with clarity.
Care about the outcome, not just the code.
Chase that "How to get to the next level" thing.

If you are a developer wondering what is next, do not wait for permission. Own problems outside your scope, help your team move faster, and think like a builder rather than just a contributor.

Who knows, leadership might sneak up on you, too.

LLM Agent Architecture for Scalable Company Summaries

Boby Santoso — Thu, 24 Apr 2025 14:06:40 +0000

At RiddleStory, we're building an online onboarding platform that helps new hires get up to speed faster and feel more connected from day one. But to create meaningful onboarding experiences, we need to deeply understand the companies we're working with. We need to know their values, culture, tone, and mission.

That's why we built a Company Profile Summarizer powered by LLMs. Here's how the idea evolved and what we learned along the way.

The Idea

Given a company's website URL, we wanted to scrape and extract the most important elements that define the company's identity.

The Approach

Naive Approach: Simple LLM summarization

Our first idea was straightforward: scrape all the URLs we could find on a company's website (using recursive crawling), combine the content, and pass everything to GPT-4o in a single prompt.

It kind of worked. But not really. We ran into 2 issues:

Token limits

Many sites have dozens of pages, and GPT quickly hits the limit.

Quality

Even when it stayed within the limit, the summarization and other outputs were too shallow. With so much context, the LLM struggled to produce high quality results.

Page by Page Approach

Our second approach produces better output. Each scraped page was summarized, so we have multiple page summaries. We then combined those summaries to generate the final output, including mission, vision, values, and more.

However, there are still some issues:

Token limits

Again, even with smaller summaries page by page, generating the final summary may also reach token limit.

Quality

LLM tends to hallucinates when given too much context. Thus the output may not be too accurate.

This approach works, and we thought it's production ready. But we knew there had to be a smarter way.

RAG Powered Agent

To solve the token limit and quality problem, we moved towards a Retrieval Augmented Generation (RAG) approach:

Scrape & Chunk the Website

We crawled the company's website and broke down the content into smaller chunks, in this case per 1 page. Each chunk was stored with metadata like the source URL and its page context.

Embed the Content

Each chunk was turned into a vector using OpenAI embeddings and stored in a vector database (MongoDB in our case). This allows us to later search semantically, not just by keyword.

Ask Only What's Needed

When we need to summarize, say, the company's mission or values, we run a vector search to retrieve only the most relevant chunks. These chunks are passed into a specialized GPT prompt that focuses on extracting just that one piece of information.

This approach dramatically improved the output. It was more focused, accurate, and easier to scale. The LLM had less to think about. And the output was more accurate.

. . . . .

But again, even though this approach is far more efficient and accurate than before, there are some issues:

Inaccurate scraped web pages

The scraped web pages were not accurate. Given the website url, we recursively scrape the web pages. Yes we can get all dozens if not hundreds of web pages from the url, but it isn't worth the cost to scrape hundreds of web pages blindly while we may not need all those web pages. So we decided to cap the scraped urls up to 50 pages.

Static search query for searching Vector DB

The vector search used fixed queries. For example, we'd always use the same phrase like "Company Values", regardless of the context.

Smart LLM Agent Approach

This is where things get really interesting.

Instead of manually controlling the flow or relying on static queries, we decided to build an autonomous agent using the ReAct pattern (combining reasoning and action). The idea: give the agent a clear goal, equip it with the right tools, and let it figure out the rest.

This is a smarter approach. Make an agent, give it a ReAct prompt, give it some tools. Then simply ask what you want it to do. It will do all the research for you, and generate the outcome for you.

Here's how it works:

Ask the Agent with an Objective

For example: "Summarize this company's mission, vision, values, etc"

Let the Agent Plan

The agent decides what it needs to find first. Maybe it needs to scrape specific pages, maybe it needs to search the vector DB, maybe both.

Tool Driven

It uses available tools like Web Scraper, Vector Search, and Web Search.

Reasoning Loop

The agent uses a ReAct loop:

Thought → Action → Observation → Repeat

until it's confident in the output.

Final Output

Once done, the agent produces structured summaries for mission, vision, values, culture, etc just like a human researcher would.

This approach gave us maximum flexibility and minimal manual tweaking. It also unlocked the potential for scaling. We can now give it different objectives for different use cases, and it will adapt accordingly.

Conclusion

There are so many ways to utilize LLM, from Naive approach to a more Smart and Advanced Agentic flow.

Each iteration taught us something:

The naive approach was quick build, but the output was not good
The page-by-page approach improves structure but still struggles with scale
The RAG based flow brings precision, relevance, and performance
The autonomous agent was more flexible. It can dynamically deciding what to look for and how to get it

In the end, we learned that using LLMs well isn't just about the model.

It's about how you guide it. What you feed it, what tools it has, and what goal it's trying to reach.

Smarter people than me had done research and written papers about this. Check it out:

Optimizing My Dev Workflow in 2025

Boby Santoso — Thu, 17 Apr 2025 02:19:46 +0000

Every Software Engineer has a development setup. Some keep it clean and minimal. Others turn their machine into a digital spaceship and a terminal that looks like it's from The Matrix. Either way, your development setup is personal and built around your role, your habits, and your tools.

This is how mine evolved. What started as a solid full-stack setup slowly turned into a mess. Instead of buying new hardware, I decided to fix the way I work.

My Daily Workflow

Most days look like this:

Writing code in VSCode. I usually have to juggle between 3 to 5 projects daily
Running local services with Docker
Managing multiple Node.js, React, PHP apps. Frontends and Backends
SSH, lots of it
Using Studio 3T or DBeaver for databases
Keeping a bunch of browser tabs open
Communicating via Discord and Teams
Listening to Spotify
Taking notes in Obsidian
Drawing flows in Excalidraw

It all works… until one day, my MacBook decided it had seen enough.

The Problem

Memory Overload

I'm using a base model MacBook Pro M2 with 8GB of RAM. It's a very capable machine, but my workflow was pushing it to the edge.

RAM hovered around 90%, with swap memory kicking in constantly. Everything started to lag. App switching, typing, even simple tasks like scrolling through files.

A few seconds of delay here and there might seem minor, but when you're in the flow, it breaks focus fast. I couldn't listen to music while coding. Even opening the browser could spike things. It got frustrating enough that I had to rethink how I worked.

What I Changed

From VSCode to NeoVim

I've used VSCode for years. It's great, no doubt. But when you have to juggle up to 5 projects daily, you'll find that it's going to block you away.
Mine feels heavy, especially with multiple windows and extensions. This is why I decided to find an alternative, until I started using NeoVim instead.

It's fast. With built-in LSP support, I still get syntax highlighting, autocompletion, and linting. The Vim keybindings are taking some time to learn, but the speed and responsiveness make it worth it. Or you can say that I never quit NeoVim because I don't know how to quit.

Replaced Docker Desktop with Colima

I replaced Docker Desktop with Colima, a lightweight alternative that integrates with Docker CLI. It's easy to toggle on and off, uses less RAM, and doesn't drag down the system.

Offloaded Docker to an Old Laptop

I had 2 old laptops sitting around, both 10 years old. I turned both into a home server. Installed Ubuntu Server, set up Docker, and now I run all my containers remotely. With Tailscale, I can securely connect to it like it's on the same network. This way, my MacBook doesn't have to run MongoDB, Redis, or RabbitMQ anymore. That alone freed up a lot of memory. I can even run other services like HomeAssistant, MailHog, Immich, etc.

Simplified My Terminal Workflow with Tmux

Instead of opening a bunch of terminal tabs or windows, I switched to tmux. It lets me manage multiple sessions in one window, split panes, and run different services side by side. It’s lightweight, keyboard-driven, and fits perfectly with NeoVim.

Ghostty

Initially, I used the Mac's built-in Terminal, but encountered issues with font loading. This led me to explore alternative terminal options. I initially chose Kitty, but after the official release of Ghostty, I made the switch. It has been running flawlessly for me.

Aerospace

Aerospace is a tiling window manager like i3 on Linux environment. This way I can manage my application windows and put them into different keys. I can navigate through my app windows very quickly with a shortcut:

Terminal: option + 1
Browser: option + c
Obsidian note: option + o
Spotify: option + s
Discord: option + d
Teams: option + t

And many more..

Conclusion

With this setup, I have to adapt with a more keyboard-driven dev workflow. I have to get used to use tmux for switching back and forth between projects. Then I have to get used to NeoVim with its keybindings. I live in the Terminal now.

Coding is much more fun, and that's what matters to me!

You can checkout my dotfiles, still work in progress, I used it daily on my Mac and Ubuntu servers.

Done > Perfect: How I Built My Personal Website and Actually Shipped It

Boby Santoso — Wed, 09 Apr 2025 14:01:44 +0000

For years, I kept telling myself I'd build a personal website. Between full-time work, side projects, and life in general, it always took a backseat. But last week, I finally decided to stop overthinking and just build it.

Here’s how I built my personal website from scratch and some thoughts along the way.

Why Build Your Own Site?

Sure, there are plenty of platforms where you can spin up a portfolio, blog, or even an entire personal brand in minutes. But I wanted something that was completely mine. No templates. No boilerplates. No limitations.

I wanted full control. Design, Code, Content, everything.
Because at the end of the day, this is what gives me satisfaction as a programmer.

Over the years, I’ve built countless side projects in my free time, most of which never saw the light of day. They usually ended with a voice in my head whispering, “Someone must’ve built this already… so what’s the point?”

But this time, the project was different. It wasn’t about trying to build the next big thing. It was about building my own thing: a small corner of the internet that reflects who I am, what I love, and what I’m building.

The Idea

I wanted to build something simple, quick, so that I have small wins which gives me the satisfaction and motivation to continue building. I know that if I pursue the perfect website, like 3D elements, animations, stylings, I will never publish this website and stop at the 2nd week.
That's why I kept things very simple for now. I know that I will improve this as time goes, but right now this is good enough for me.

The Stack

I kept the tech stack simple and familiar from my day to day use:

Frontend: NextJs
Backend: ExpressJs + Sqlite, to support my mini project like Zap (URL Shortener) and Image Squeezer
Styling: Material UI
Deployment: Dockerized, hosted on a DigitalOcean Droplet
CI/CD: Github Action
Blogs: Simple Markdown file

I containerized everything, set up CI/CD using GH Action, and used Caddy as a reverse proxy. This is something that I am very familiar with.

Challenges

Even with a minimal setup, I ran into a few bumps.

1. Overengineering

As a developer, it’s tempting to build everything from scratch, optimize everything, and make the perfect architecture. But I had to remind myself that this wasn’t a work project. This was for me. It’s okay to cut corners. It’s okay to leave TODOs. It’s okay to keep it simple.

2. Design paralysis

I spent way too long researching the perfect portofolio design. Debating between dark mode, minimal mode, grid layouts, and font choices. Eventually, I just picked one and stuck with it. I told myself: You can always tweak it later. This helped me move forward.

3. Writing content

Writing code? No problem. Writing about myself? Surprisingly difficult. I found myself rewriting the About page and landing intro multiple times. I wanted to be authentic, but also clear and concise. In the end, I just wrote like I talk, and that helped a lot.

Final Thoughts

This project reminded me why I love building things. Not for work. Not for metrics. Not for validation. Just because I enjoy it.

It’s easy to get caught up in the noise. Trends, AI hype, startup pressure, but this site is my way of slowing down and building something for myself. A place I can call home on the internet.

And the best part? It’s not finished. I’ll keep adding to it, improving it, and sharing more along the way.

If you’ve been putting off building your own site, let this be a sign. Start small. Make it yours. Ship it.

You don’t need a perfect design, a clever domain name, or a flashy landing page. You just need to start.

Originally posted at https://bybobyy.com

DEV Community: Boby Santoso

How I Built a Multi-Tenant Static Site Engine with Next.js, Nginx, and Coolify

High-Level Overview

Architecture

Build Pipeline

Business Config

Component Factory

Static Export (Next.js)

Auto-Generated Assets

Nginx Configuration

Deploy via Coolify

What this means in Practice

Why Static > SSR for This Kind of Project

Why I Can Host Hundreds of Pages on a “Cheap” Server

Frontend to Fullstack - Mastering the Architectural Mindset

Start with the Problem, not the Tech

Identify Requirements

Visualize the Flow

Separation of Concerns

Balancing Trade-Offs

Final Thoughts

Crafting a Real-Time Virtual Desktop for Gamified Onboarding

How it started

What makes a Great Escape Room

Building the Environment

Crafting the Story

Under the Hood

Frontend (React)

Backend (Node.js, Express, Redis, MongoDB)

Real-Time Magic

Moderation System

The Evolution of Our Story Engine

What's Next?

I Just Wanted to Code. Now I'm a CTO

How It Started

Becoming a Leader

From Side Projects to Full Ownership

What Being a CTO Means to Me

Final Thoughts

LLM Agent Architecture for Scalable Company Summaries

The Idea

The Approach

Naive Approach: Simple LLM summarization

Page by Page Approach

RAG Powered Agent

Smart LLM Agent Approach

Conclusion

Optimizing My Dev Workflow in 2025

My Daily Workflow

The Problem

Memory Overload

What I Changed

From VSCode to NeoVim

Replaced Docker Desktop with Colima

Offloaded Docker to an Old Laptop

Simplified My Terminal Workflow with Tmux

Ghostty

Aerospace

Conclusion

Done > Perfect: How I Built My Personal Website and Actually Shipped It

Why Build Your Own Site?

The Idea

The Stack

Challenges

1. Overengineering

2. Design paralysis

3. Writing content

Final Thoughts

Static Export (`Next.js`)