all blog posts

Building in Public as a Full Stack Engineer

·5 min read
EngineeringOpen SourceSystem DesignWeb Architecture

A large portion of full-stack engineering is inherently invisible. When microservices scale effortlessly, databases maintain sub-millisecond query latencies, and edge workers cache static assets worldwide, nobody notices. But when a cache key collisions trigger a stampede, or a payment webhook drops a signature header, everything is suddenly critical.

Building in public is my deliberate strategy to bring those invisible engineering decisions to light. It is not about marketing hype or vanity follower metrics—it is about documenting real architecture under real constraints.

Why Build in Public?

The tech industry is flooded with synthetic “portfolio tutorials”: identical clones of Twitter, Netflix, or Todo apps built by following a step-by-step video. While tutorials teach syntax, they fail to demonstrate how an engineer actually reasons through ambiguity.

Building in public shifts the paradigm in three concrete ways:

  1. Enforces Architectural Accountability
    When your Docker configurations, database migration scripts, and Redis cache strategies are public on GitHub, you cannot cut corners with hardcoded secrets or lazy error handling. You write code as if production traffic is arriving tomorrow.

  2. Demands Systematic Documentation
    If you cannot clearly explain why you chose an Alpine-based Nginx reverse proxy over a standalone Node container, you probably haven’t thought through the security and memory tradeoffs. Writing crystallizes technical decisions.

  3. Transforms Failure into Shared Knowledge
    Production systems fail in interesting ways: race conditions under concurrency, edge runtime limits, SSL certificate renegotiations, or third-party API rate limits. Documenting post-mortems and remediation steps provides tangible value to other engineers.

[!NOTE] Building in public is less about proving what you built, and more about articulating why you built it that way and what tradeoffs you accepted.

What I Focus On Building

My engineering work spans the entire lifecycle of modern distributed systems and high-performance web products:

  • Edge Computing & Ephemeral Routing — High-throughput Cloudflare Workers, real-time WebSocket/SSE channels, and sub-50ms email routing engines.
  • Backend Microservices & Distributed Workflows — Go microservices, NestJS enterprise templates, gRPC interfaces, and Kafka-backed event streams.
  • Fintech & Payment Pipelines — Idempotent order processing, webhook signature verification with HMAC-SHA256, and automated reconciliation flows.
  • Hardened Infrastructure & DevOps — Multi-stage Docker containers, zero-trust Content Security Policies, and automated CI/CD deployment pipelines.

One of my core initiatives is PortfolioPilot, a developer-first platform designed to allow engineers to deploy high-converting, SEO-optimized portfolio websites in minutes with automated AI copy generation, Razorpay billing, and real-time performance analytics.

Another ongoing initiative is AliasMail (formerly Devmail), an edge-powered privacy email infrastructure featuring instant ephemeral burner inboxes and masked webhook delivery.

My Core Engineering Principles

When building systems that need to withstand real user traffic, I adhere to a strict set of operational principles:

1. Operational Reality Over Tutorial Theatrics

If an application cannot gracefully handle network dropouts, corrupted database payloads, or malformed JSON headers, it is not production-ready. I treat input validation, graceful degradation, and structured logging as first-class citizens.

2. Zero-Trust Security by Default

Security is an infrastructure concern, not a developer afterthought. From enforcing Content Security Policies at the Nginx edge to hashing webhook secrets using Web Crypto primitives, every endpoint should be hardened against SSRF, XSS, and payload tampering.

# Example: Quick verification of strict response headers on production endpoints
curl -I https://anshu.uk

3. Ephemeral by Design When Privacy Matters

If data does not need to persist, it should not touch a hard drive. For privacy-centric services, volatile memory with aggressive TTLs (Time-To-Live) and automatic RAM purges guarantees privacy far better than lengthy privacy policy disclaimers.

Key Takeaways

           ┌────────────────────────────────────────┐
           │      Engineering in Public Loop        │
           └──────────────────┬─────────────────────┘
                              │
         ┌────────────────────┼────────────────────┐
         ▼                    ▼                    ▼
   [Ship Code]        [Measure Metrics]    [Document Tradeoffs]
   Real deployments   Latency, memory,      Post-mortems and
   under load         cache hit rates       architectural logs

If you are an engineer considering building in public, start small:

  • Publish your nginx.conf and explain your caching headers.
  • Write a short post explaining why a database query caused high CPU utilization and how an index fixed it.
  • Share your architecture diagrams before writing the first line of code.

Consistency beats announcements. Everything I build is live, open, and observable at anshu.uk.