Step 1 — Hand the redesign to Repaint

I used Repaint as a design reference for the visual direction. It helped establish the typography pairing (Inter / Newsreader / JetBrains Mono), a calm light/dark colour palette, a card-led project layout, and the eyebrow + numbered section pattern used throughout the site. The implementation and content remain tailored to our studio.

Step 2 — Implementation: Jekyll, the boring static-site generator

The codebase is plain Jekyll. No Node build step, no React, no hydration. It compiles to static HTML and ships.

I think jekyll is a very good alternative to js heavy sites for the simple portfolio like mine so I opted for jekyll, also I had worked with it a lot ever since I started working at Biralo Studio, so this was a good option for me to rebuild with jekyll.

Step 3 — SCSS for the design system

All styles live in _sass/ as modular SCSS partials — one per concern: _card.scss, _button.scss, _typography.scss, _grid.scss, _post.scss, and so on. A single index.scss pulls them in. Jekyll compiles it inline into <style> via the scssify filter.

The design tokens (colours, spacing, type ramp, breakpoints) live in _variables.scss and _breakpoints.scss, so light/dark mode and responsive rules are one source of truth rather than scattered media queries.

Step 4 — GSAP for motion

I’m not good with designs and animations so animation is minimal. The small bits of motion across the site — the subtle reveals, the things that animate as you interact — run on GSAP. Loaded once from a CDN, used sparingly enough that you’d barely notice it’s there until you tried to remove it. The goal was for the site to feel alive without feeling busy.

Step 5 — Decap CMS so I can write from anywhere

I didn’t want to be SSH-ing into a laptop every time I wanted to add a blog post or update a project description. So the site has Decap CMS (formerly Netlify CMS) wired up at /admin/.

It’s a tiny SPA that authenticates against GitHub, lets me edit the markdown files through a friendly form UI, and commits the changes straight back to the repo. The schema lives in admin/config.yml — collections for blog posts, projects, skills, plus file collections for every _data/*.yml (hero, footer, CTA, etc).

Net effect: I can update the site from my phone in five minutes if I want to.

A few extras the design didn’t ask for

The Repaint design covered the visual side. I layered a few engineering decisions on top:

• Two engineers, one repo. The site keeps the content model simple so a small team can maintain the design, projects, and writing together.
• Minimal SEO. Pure-Liquid sitemap.xml, robots.txt, RSS feed (no plugins, no Gemfile), og: and twitter: cards on every page, JSON-LD structured data (WebSite + Person on the home, CreativeWork on each project), and per-page meta_title / meta_description overrides.
• Cloudflare hosting + ccTLD. sujatachaudhary.com.np runs behind Cloudflare’s global CDN. Total monthly cost: $0.
• Auto-TLS on the apex domain via Cloudflare. No certbot rotation, no nginx config to babysit.

What’s next

Now that the site exists in a shape I’m happy with, the writing can start. The next few posts will be the engineering side — backend systems, agentic AI infrastructure at Biralo Studio, and the things that surprised me along the way.

If you want to work with us, the about page has more about the team and how we work.

Every microservices article on the internet is written by someone who either runs Netflix or really wants you to think they do. The version most of us actually need is much smaller, much saner, and almost embarrassing to admit out loud.

Most teams do not need microservices. Some teams do. And almost no team needs the version they read about on Hacker News.

The version we actually run

In one of our software systems, we run a small microservices setup for an agentic content platform. Here is the practical version of it.

gateway        — public HTTP, auth, routing
agents-api     — orchestrates the agent runs
agents-runner  — does the heavy LLM stuff
writer-svc     — drafts and rewrites
review-svc     — critiques and edits
storage-svc    — Postgres + S3 wrapper
queue          — RabbitMQ
infra          — Docker + Coolify on a couple of VPSes

That is the whole map. No service mesh. No Kubernetes. No 100-page README. The team is small, the services are small, and the boundaries are picked to match how the work actually flows — not how a textbook says they should.

What earned its keep

1. Queues, not chains

Every long-running step goes through RabbitMQ. The agents-api does not call the writer-svc directly; it drops a job on a queue, the writer-svc picks it up. If the writer crashes mid-job, the message comes back. If we need to scale writing, we add another writer. The rest of the system does not need to know.

2. gRPC for the boring stuff

Inside the cluster, services talk over gRPC. Strict contracts mean breaking changes scream at us at build time, not at 3am. Outside, the gateway still speaks REST, because nobody wants to debug Protobuf in a browser.

3. Coolify as the platform team

We deploy with Git pushes. SSL, env vars, restarts, logs — Coolify handles the boring parts so I can spend my brain on the system, not on YAML.

What we skipped, on purpose

No Kubernetes. No service mesh. No event store. No CQRS. No saga framework. No bespoke message envelope schema. Every one of these is a fine tool — but every one of them is also a tax, and we cannot afford the tax yet.

The actual rule

Split a service when keeping it together hurts more than splitting it will. Not before.

That is most of it. The rest is just paying attention to the seams. Real posts go up here as I find time, but if the agents AI platform is the thing you want to read about, that one is coming next.

The moment it clicked

I had spent two days chasing a payload-shape bug between two of our services. JSON, no schema, “we agreed on it in Slack.” A colleague rewrote both ends in gRPC over an afternoon. The bug class disappeared. The conversation moved from what shape is this? to what should this do?

When I reach for gRPC

• Service-to-service calls inside the cluster.
• Anywhere streaming or backpressure actually matters.
• Cross-language calls where the type system is the contract.

When I still pick REST

• Anything a browser will touch.
• Webhooks and public APIs.
• One-off scripts and admin tools where curl matters.

The rule that finally settled it for me: use gRPC where the consumer is a program you also own; use REST where the consumer is the rest of the internet.