DEV Community: Sai Madhan

What Happened to Certainty at Work?

Sai Madhan — Sat, 08 Aug 2026 13:03:53 +0000

I have had a few friends come to me recently, complaining about their work.

It is not always about the work itself. It is more about not knowing what is happening. There are rumours about layoffs, processes ending, teams changing, and projects moving around. Nobody seems to have a clear answer, and I can see what that uncertainty is doing to them.

This whole thought started with one of my friends.

She works for a large organization in a non-technical role. It is a repetitive process, and she has been doing it for about five years now. Things have been going well. The job pays her well, she is comfortable with the work, and she has been able to build her life around the stability it gives her.

She did not feel the need to move somewhere else or completely change her career.

And there is nothing wrong with that.

Some people value career progression. They want to learn more, take on bigger roles, and constantly move towards the next thing.

Others value reliability. They value knowing what their work is, knowing what it pays, and knowing that they can make commitments based on it.

A job can simply be a job that gives someone a comfortable life.

It does not have to become their identity or a never-ending challenge. They do not have to constantly turn themselves into a different person just to prove that they are growing.

For years, the job gave her exactly what it promised. Nothing more, nothing less. Because of that, she could make promises outside the organization. She could plan her expenses, take on responsibilities, and build a life around the income and stability she had.

Now there are rumours that the process may be going away, and that one change has created a whole chain of uncertainty.

Nobody knows what will happen to the people working there. Nobody knows whether they will be moved, retrained, or asked to leave.

Everything is unclear.

I am not saying that an organization should never expect its employees to change, adapt, or learn new things.

That is a reasonable expectation.

Roles change. Clients move on. Projects end. Processes become outdated. Organizations restructure. Change is inevitable.

But the way an organization handles that change makes a huge difference.

When a role changes, the organization has to understand what the role is becoming. The manager has to know what is needed for the process to continue and what the employee must learn to continue contributing within it.

You cannot simply tell everyone to upskill and leave the rest to them.

Upskill into what?

What is the process becoming? What skills will actually be useful? What will the employee be expected to do six months from now? Is there a path for them to move from where they are into the new role?

Asking someone to adapt is reasonable. Keeping them uncertain about what they are supposed to adapt to is not.

What is one of the most valuable things an employee can offer an organization?

The first thing that comes to my mind is dependability.

I believe one of the most meaningful things you can do for your career, no matter what your role is, is make a promise and deliver it.

You tell your manager that you will complete something by a particular date, and then you complete it.

When you do that repeatedly, people begin to trust you. Managers can plan around your work. Timelines can be communicated to customers and clients. Other teams know when they can begin their part.

That predictability makes a meaningful difference to both the employee and the organization.

But if an organization expects certainty from an employee, should the employee not be able to expect some certainty from the organization too?

No company can promise that a role will exist forever or that nothing will ever change. Change is part of how organizations survive.

What employees should still be able to expect is some clarity about what is happening.

What is changing? Why is it changing? What does the organization expect from the employee? What can the employee do to adapt? Is the process ending? Is another role available? When can people expect an actual answer?

Even saying, “We do not know yet, but we will have a decision by this date,” is better than leaving everyone in silence.

Uncertainty does not lead to productivity.

Once someone begins wondering whether they will have a job next month, every conversation with their manager starts to carry a second meaning.

They begin wondering whether they should apply elsewhere, cancel a plan, or reconsider a financial commitment they have already made.

Their attention is no longer entirely on the work.

That is not because they suddenly became a bad employee. It is because uncertainty has entered every other part of their life.

Some people adapt quickly when things change. They enjoy learning new things, moving between roles, and figuring things out as they go.

Others need more time, clearer direction, or a stronger sense of stability before they can adapt.

A manager cannot assume that every employee will respond to change in the same way.

They have to understand the people on their team. They need to know their strengths, how they work, what kind of support they need, and where they may be able to contribute when the process changes.

An organization has the same responsibility.

People, process, and profit are tied together. They are not separate things that can be changed independently without affecting one another.

People keep the process working. The process allows people to deliver value. That value eventually becomes profit.

When a company ignores one of these and focuses only on the others, the whole system starts to weaken.

Most processes began as an answer to a real problem.

Someone before the current manager made a decision based on the problems they faced at that time. A person may have stayed in the same role for five years because they understand the work and remain valuable there.

This is where I think the answer to most complicated problems begins with one simple question.

Why?

Why does this process exist?

Why does this person work in this role?

Why have they remained there for so long?

Why was the system designed this way?

Why is something no longer working?

Ask those questions before taking a sledgehammer to the whole thing.

Companies sometimes dismantle teams and processes, only to realise later that the work still needs to be done. Then they recreate similar roles, rebuild the same systems, or hire different people to solve problems that the previous employees were already handling.

Moving fast and breaking things may work in some situations.

It should not become an excuse to stop thinking.

Layoffs are part of this conversation too.

I understand that layoffs are not always avoidable. Projects end. Clients leave. Revenue changes. An organization may no longer need a certain process or may not be able to afford the number of people it currently employs.

A difficult decision may have to be made.

But how the company handles that decision still matters.

Cloudflare’s recent layoffs are one example of a company at least trying to reduce the damage. In the company’s announcement, affected employees in the United States were offered base pay and continued healthcare through the end of 2026, giving them more time and space to decide what came next.

That does not make losing a job easy. It does not remove the pain or uncertainty that comes with it.

But it recognises that people cannot rebuild lives they planned around their income in a few weeks.

People may have dedicated years of their time and energy to a company because the company made them feel comfortable and secure. That comfort allowed them to make promises outside the organization.

They may have taken a loan. They may be supporting their family. They may have planned an education, a marriage, a move, or something else that depends on the income they were told they could rely on.

Giving someone a short notice period and telling them to use it to find another job is not much of a transition plan.

AI has now become part of this conversation too.

I understand the value it can bring to an organization. It can improve productivity, automate parts of a process, and change how certain work is done.

But the existence of AI does not mean everything has to be replaced with AI.

Before replacing a person, a role, or an entire process, the organization has to understand why it exists. What problem does this person solve? What knowledge will disappear when they leave? What looks simple only because someone has spent years making it work smoothly?

Can the employee use the new tools instead of being replaced by them?

Can the process evolve without throwing away everyone who currently understands it?

I still believe dependability matters. Employees should make promises they can keep and deliver what they say they will.

But that relationship has to work both ways.

No organization can guarantee permanent employment. It can still be honest about what is happening, clear about what is expected, and considerate of the fact that employees make decisions about their lives based on the stability their jobs provide.

People can handle change. They can learn, move, adapt, and begin again.

Keeping them uncertain does not prepare them for change.

It only leaves them standing in the same place, wondering when the ground beneath them is going to move.

Why I Waited to Publish

Sai Madhan — Sat, 08 Aug 2026 13:00:56 +0000

It has been a long time since I published anything here.

I have wanted to write for a while now. There have been plenty of ideas, half-finished drafts, and moments when I thought, “I should probably publish this.” But somehow, they always remained drafts.

Over time, I realized it was not because I could not write. It was because I cared about what I was writing.

The internet has no shortage of words. Every topic has already been written about in a thousand different ways, and I do not want to add another page to that pile simply because I feel I should keep publishing.

I want to write about things that stay with me. Ideas I have wrestled with for days, sometimes months. Things I have learned while building software, problems that changed the way I think, questions that do not have simple answers, or observations that refuse to leave my mind.

I could probably publish much more if I lowered that bar. I could turn every passing thought into a post, polish it until it looked finished, and move on to the next one.

But I know myself.

A week later, I would read it again and wonder why I published it in the first place. Eventually, I would probably delete it.

I would rather have a small collection of things that genuinely mattered to me than hundreds of posts that exist only because I felt I should keep publishing.

So, that is what this space is.

A place for ideas that I believe are worth remembering.

I do not know how often those ideas will arrive. But when something stays with me long enough, I think this is where it will end up.

Building a Tech Startup: Why Your Tech Stack Should Follow Your Business Model, Not the Other Way Around

Sai Madhan — Sun, 09 Nov 2025 16:00:01 +0000

As a software engineer, I've had the privilege of working alongside some of the smartest people I know in both technology and business. Through these experiences and my own study, I've developed the ability to evaluate product development through dual lenses: technical feasibility and business viability. Recently, a conversation with an aspiring founder illustrated something I've been thinking about: how easy it is to let AI-generated technical advice override critical thinking and domain expertise.

When Tools Replace Critical Thinking

Someone recently approached me with what they described as a revolutionary idea—a fashion and lifestyle e-commerce platform combining AI, VR, and AR capabilities. They presented an extraordinarily complex tech stack document featuring custom infrastructure, self-hosted ML operations, multiple database engines, and microservices architecture.

For someone with no technical background, this list was suspiciously comprehensive. It became clear they had assembled this entire technical strategy using AI tools. The architecture looked impressive on paper but revealed several critical misjudgments:

No business validation - When I asked about market research, vendor relationships, or supply chain, the answer was minimal: two local shop conversations.
Technology before business model - They wanted to build custom ML infrastructure and complex microservices before proving anyone wanted the core product.
Misunderstanding of costs - They claimed their AI-generated stack would be "less expensive" than my recommendations, despite requiring custom development of everything from scratch.
Dismissing domain expertise - When I suggested starting with e-commerce validation first, then layering features, they became defensive. The AI had provided a complete vision, and expertise that contradicted it wasn't welcome.

The Real Problem

Here's the issue: AI tools generate technically plausible architectures, but they lack context about your business stage, constraints, and actual needs.

An AI will recommend enterprise-grade solutions because it's trained on successful companies' architectures. But those companies didn't start there—they evolved to those systems after proving their business model and generating revenue.

Business First, Technology Second

When I asked about market validation—existing retail relationships, customer research, vendor partnerships—the answer was thin. No established supply chain, no customer base, no vendor network.

This is critical because in e-commerce, your app is not your business. Your business is:

Your supply chain
Your vendor relationships
Your customer acquisition strategy
Your fulfillment capabilities
Your margins and unit economics

The technology is simply the tool that enables these core competencies. Companies that succeed in this space don't win because of their tech stack—they win because they understand operations, logistics, and customer needs.

The Right Way to Build: Start With Your Core Value

My recommendation was straightforward: build the e-commerce foundation first. Here's why:

Validate your business model - Can you actually move products? Do customers want what you're selling?
Build your user base - Real users engaging with real products
Generate revenue - Prove the business fundamentals work
Then layer on features - Once you have traction, add AI recommendations, AR try-ons, social features

This isn't about lacking ambition. It's about structured iteration. Every successful super app started as a focused product. They expanded once they had proven their core and built a user base.

The Cost Conversation

Despite having no technical background, this person claimed their proposed stack would be "less expensive" than my recommendations. Let me share some hard-earned wisdom about tech stack decisions:

Start With Leverage, Not Control

For a pre-revenue startup, services like WorkOS for authentication make perfect sense. They offer up to 1M users free. That's not vendor lock-in—that's business leverage.

Here's the math: If your business is good enough to get 100,000 paying users, you'll have revenue. At that point, migrating to a custom system becomes a planned business expense—a calculated investment funded by actual income.

Migration is Part of Growth Strategy

This is something non-technical founders often misunderstand: migration, refactoring, and technical evolution are normal parts of successful businesses.

When you're established with revenue:

You have resources to hire specialized engineers
You have actual usage data to inform optimization decisions
You have business metrics to justify infrastructure investments
You have operational margin to fund technical improvements

The cost of migrating 100K users from WorkOS to a custom auth system might be $50-100K in engineering time. Sounds expensive? Not when you're generating revenue. That's a manageable business expense.

Building that custom auth system from day one? That's $100K+ spent before you know if anyone wants your product. That's not being cost-conscious—that's burning money.

The Reality of "Vendor Lock-in"

When I suggested Cloudflare for CDN and edge services, the response was concern about vendor lock-in. This perfectly illustrated the disconnect between AI-generated fears and business reality.

Real vendor lock-in is when switching providers is technically impossible or prohibitively expensive relative to your business scale. Using Cloudflare's CDN isn't lock-in—your content is portable, and migrating to AWS CloudFront or similar services is straightforward when you have the scale to justify it.

Building Custom vs. Leveraging Services

The proposed stack implied building machine learning infrastructure from the ground up. This deserves scrutiny.

Production-grade ML systems require training data you don't have at launch, specialized engineering talent, expensive compute infrastructure, and ongoing operational overhead.

Modern AI APIs—offering vision, language, and recommendation capabilities—exist precisely to remove this burden. You get to offer sophisticated features without the infrastructure complexity.

The question isn't "can we build this?" It's "should we build this now, or focus resources on validating our business model?"

What Actually Reduces Costs

Here's what genuinely keeps startup costs down:

Use generous free tiers - Supabase, Vercel, WorkOS, Cloudflare offer incredible free tiers
Managed services over self-hosted - Your engineering time is your most expensive resource
Monolith before microservices - A well-structured monolith scales to millions of users
Proven tech over bleeding edge - Pick boring technology; it's boring because it works
Buy don't build - Unless it's your core differentiator, use existing solutions

And crucially: Plan for migration as part of business growth. It's not a failure to start with managed services and migrate later—it's smart capital allocation.

The Real Expense

The real expense isn't Cloudflare or managed services. The real expense is building the wrong thing—spending months building a complex system with self-hosted infrastructure before validating if anyone wants the core product.

Every dollar and hour spent on custom infrastructure is a dollar and hour not spent on:

Understanding your customers
Building vendor relationships
Refining your product-market fit
Acquiring users
Generating revenue

Where Guidance Falls Short

This experience highlighted something I've been observing: the risk of making decisions in domains where you lack expertise, without consulting those who have it.

Modern tools provide unprecedented access to information. You can research technical architectures, best practices, and industry standards with ease. But information without context can be misleading.

The challenge isn't access to knowledge—it's knowing what applies to your specific situation.

My Advice to Founders

If you're technical:

Resist the urge to over-engineer
Your goal is to validate assumptions as quickly as possible
Pick tools that let you ship fast, not tools that look impressive on a diagram
Build from experience, not from AI prompts

If you're non-technical:

Find a technical advisor you trust, then actually listen to them
Understand that comprehensive technical plans need business context
"Complete" tech stacks don't guarantee successful products—solving real problems does
Question technical decisions you don't understand, but respect domain expertise
The best architecture is the one that gets you to validation fastest

When evaluating technical approaches:

Treat AI-generated advice as input, not direction
Validate recommendations with people who have relevant experience
Understand that optimal and practical are different things
Remember that successful companies evolved their infrastructure—they didn't start with it

The Bottom Line

Your tech stack should be the last thing you optimize, not the first. Start with:

Validate the business model
Build the minimum product that proves value
Get real users
Generate revenue
Scale and refactor what works

Migration, refactoring, and technical evolution aren't problems—they're signs of success. They're the "problems" you want to have, because they mean your business is growing.

The mistake is spending months building comprehensive systems for unproven concepts, guided by impressive-sounding advice that lacks business context.

Building Full-Stack Apps with Bun, React, and Hono: A Modern Approach

Sai Madhan — Fri, 11 Jul 2025 16:08:12 +0000

I've been exploring Bun lately and I'm impressed by its capabilities. When I decided to try building a full-stack application using Bun with React and Hono, I discovered a surprisingly elegant pattern that I wanted to share.

If you're looking for a modern, performant way to build full-stack applications, this combination might be exactly what you need.

Why This Stack?

Bun: Blazing fast JavaScript runtime with built-in bundling and excellent React support
React: The frontend framework we all know and love
Hono: Lightweight, fast web framework with excellent TypeScript support and middleware ecosystem

Setting Up Your Full-Stack App

Let's start by creating a new Bun application with React support:

bun init --react=shadcn

This gives us a React application with shadcn/ui support out of the box. But here's where it gets interesting—Bun's routing system allows us to seamlessly integrate a Hono API server.

The Setup: Combining the Best of Both Worlds

Here's how we can set up our server to handle both API routes and React serving:

import { serve } from "bun";
import { Hono } from "hono";
import index from "./index.html";
import API from "./api";

const app = new Hono();
app.route("/api/", API);

const server = serve({
  routes: {
    "/api/*": app.fetch,  // API routes handled first
    "/*": index,          // React app serves everything else
  },
  development: process.env.NODE_ENV !== "production" && {
    hmr: true,
    console: true,
  },
});

console.log(`🚀 Server running at ${server.url}`);

That's it! By mapping /api/* to app.fetch, we get a clean separation between our API and frontend, with both served from the same process.

Alternative Approaches

You could certainly build your API using Bun's built-in methods directly in the routes configuration:

const server = serve({
  routes: {
    "/api/users": {
      async GET(req) {
        return Response.json({ users: [...] });
      },
    },
    "/*": index,
  },
});

Or use Hono's JSX capabilities to build React-style components:

import { Hono } from 'hono'
import { jsx } from 'hono/jsx'

const app = new Hono()
app.get('/', (c) => {
  return c.html(<h1>Hello Hono!</h1>)
})

However, I prefer the approach outlined above because it gives us access to the full React ecosystem—Tailwind CSS, shadcn/ui, and countless React libraries—while still providing a powerful backend with Hono's extensive middleware collection.

Project Structure

Here's how I like to organize these projects:

├── index.ts          # Main server file
├── main.tsx          # React entry point
├── index.html        # HTML template
├── app/
│   └── App.tsx       # React components
├── api/
│   ├── index.ts      # API router
│   └── v1/
│       └── index.ts  # Versioned API routes

API Setup with Hono

api/index.ts:

import { Hono } from "hono";
import V1Routes from "./v1";

const API = new Hono();
API.route("/v1/", V1Routes);

export default API;

api/v1/index.ts:

import { Hono } from "hono";

const V1Routes = new Hono();

V1Routes.get("/", (c) => c.json({ message: "Welcome to V1" }));

V1Routes.get("/books", (c) => 
  c.json({ 
    books: [
      { id: 1, title: "The Great Gatsby", author: "F. Scott Fitzgerald" },
      { id: 2, title: "To Kill a Mockingbird", author: "Harper Lee" },
      { id: 3, title: "1984", author: "George Orwell" }
    ]
  })
);

V1Routes.get("/users", (c) => 
  c.json({ 
    users: [
      { id: 1, name: "John Doe", email: "john@example.com" },
      { id: 2, name: "Jane Smith", email: "jane@example.com" }
    ]
  })
);

export default V1Routes;

Adding Client-Side Routing

For a proper SPA experience, you'll want to add React Router:

bun add react-router-dom

App.tsx:

import { BrowserRouter, Routes, Route } from 'react-router-dom';

function App() {
  return (
    <BrowserRouter>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/about" element={<About />} />
        <Route path="/books" element={<Books />} />
        <Route path="*" element={<NotFound />} />
      </Routes>
    </BrowserRouter>
  );
}

The beauty of this setup is that Bun's "/*": index route serves your React app for all non-API requests, giving you client-side routing that works perfectly with React Router.

One Important Detail

When using app.route() with this setup, make sure to include the trailing slash:

app.route("/api/", API); // ✅ Works
// app.route("/api", API); // ❌ Won't work

However, individual route handlers work as expected without any special configuration:

V1Routes.get("/books", handler); // Works at /api/v1/books

What You Get

With this setup, you get:

API endpoints at /api/v1/books, /api/v1/users, etc.
React app served from / with full client-side routing
Hot module replacement for React components
Single process serving both frontend and backend
Type safety across your entire stack
Full React ecosystem: Tailwind CSS, shadcn/ui, and thousands of React libraries
Hono's middleware ecosystem for authentication, CORS, logging, validation, and more
Best of both worlds: Modern frontend tooling with a powerful, flexible backend

Performance Benefits

This approach gives you several performance advantages:

Bun's speed: Both your API and frontend benefit from Bun's performance
No proxy overhead: Everything runs in the same process
Efficient bundling: Bun handles all the heavy lifting for your React app
Fast startup: Your entire stack boots up quickly

Conclusion

Building full-stack applications with Bun, React, and Hono is remarkably straightforward once you understand how all three interact with each other. The combination gives you modern tooling, excellent performance, and a clean development experience.

Whether you're building a personal project or a production application, this stack provides a solid foundation with room to grow. The integration feels natural, and you get the best of all three technologies without any awkward compromises.

Give it a try—I think you'll be pleasantly surprised by how well these tools work together!