DEV Community: Sai Madhan

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!