Skip to main content

3 posts tagged with "Web Development"

Building for the web

View All Tags

The Day I Found Out Vercel Was Lying to Me (In the Best Possible Way)

· 6 min read
Ashish Kapoor
Software Engineer

Or: how I stopped renting a cargo ship to deliver a sandwich.


For about a year, if you'd asked me how to run a side project, I'd have said something vaguely impressive like "well, you spin up a cluster, define your deployments, set up an ingress controller…" and somewhere around the word "ingress" my friends would start looking at their phones.

I was a Kubernetes guy. I knew pods. I knew services. I knew the particular shade of despair that comes from a YAML file that is 94 lines long and wrong on line 73.

And I loved it. Kind of. The way you love a very complicated board game that takes four hours to set up and your friends have stopped coming over to play.

Here's the thing nobody tells you about K8s when you're learning it: it's a beautiful machine designed to solve problems you don't have. It's like buying a forklift because you occasionally need to move a box of cereal. The forklift is magnificent. The forklift is also parked in your kitchen.

The small embarrassment

So I had this side project idea. I always have side project ideas. The graveyard of my GitHub is a monument to them.

This one needed a tiny backend. Maybe twelve lines of Python. Something that takes a request, does a thing, sends a response. That's it. That's the whole backend. A child could draw it on a napkin.

And I sat down and started writing a Dockerfile.

I want you to really appreciate this. I had a twelve-line function, and my first instinct was to containerize it, push it to a registry, define a deployment, attach it to a service, configure the ingress, set up TLS, wire up the DNS…

At some point I stopped and looked at what I was doing and thought: I am a crazy person. I am a completely crazy person.

Enter the Lambda (stage left, chewing gum)

About two months ago, I finally sat down and learned AWS Lambda. Properly. Not the "I read a blog post once" kind of learned, but the "I actually shipped a thing" kind.

And the whole idea is so stupidly, gloriously simple that I almost got angry. You give Amazon a function. A function. Like the thing you wrote in your first programming class. You say "here is my function." And Amazon says "cool, I'll run it when somebody calls it."

That's it. That's the product.

No server. No cluster. No pod. No Dockerfile (unless you want one). No little YAML goblin whispering at you from your terminal. You write a function. Somebody hits a URL. Amazon runs your function. You pay for the microseconds it was actually running.

When nobody is using your app — which, let's be honest, for most of my side projects is most of the time — you pay nothing. Zero. Free. The meter isn't running. The forklift is in a warehouse somewhere and I'm not paying storage fees.

I think what bothered me, once I understood it, was how much of my K8s knowledge turned out to be solutions to problems I had created by using Kubernetes. Like being really good at untangling necklaces because I kept putting all my necklaces in one pocket.

The plot twist (and this one really got me)

Here's where it gets funny.

I'd been using Vercel for years for frontend stuff. Next.js, static sites, "I'll just throw it on Vercel." Beautiful. Fast. Easy. A delight.

And I always thought of Vercel as this frontend thing. Like, oh, Vercel is where the website lives, and then for any actual computation I have to go build a real backend somewhere grown-up, like AWS.

Then one day, poking around the Vercel docs, I noticed these things called Vercel Functions. Little API routes. You drop a file in a folder and suddenly you have a backend endpoint.

And I looked closer.

And I looked closer.

And I realized — Vercel Functions are AWS Lambda functions. Like, literally. Vercel's own engineering blog writes about this openly. They take your code, they wrap it up, they run it on Lambda, and they put their own clever routing and streaming layer on top. The whole "serverless" half of Vercel is just Lambda wearing a very nice suit.

This is like finding out your favorite neighborhood restaurant is actually getting its bread from the bakery next door that you've walked past a thousand times. It was here the whole time.

(Small honest footnote: Vercel also has something called Edge Functions, and those are a different beast — they run on a lighter, V8-based runtime at edge locations, not Lambda. But the regular Vercel Functions? Lambda, top to bottom.)

What this actually means for a person with bad ideas

And I have a lot of bad ideas. This is important. Most of my ideas are bad. I don't know which ones are bad until I build them. That's the whole point.

The old way to find out an idea was bad:

  1. Have idea.
  2. Spend a weekend setting up infrastructure.
  3. Spend another weekend wiring up CI/CD.
  4. Spend a third weekend actually building the thing.
  5. Realize the idea was bad.
  6. Pay $18/month forever for the cluster because you're too lazy to tear it down.

The new way:

  1. Have idea.
  2. Drop a file in api/ on Vercel.
  3. Push to git.
  4. It's live. In the world. At a URL.
  5. Realize the idea was bad.
  6. Pay $0.

The cost of being wrong has collapsed. And that's a really big deal, because being wrong is mostly what I do. It's mostly what everybody does, if they're being honest. The question isn't how do you avoid being wrong — it's how cheaply can you find out?

Lambda (and therefore Vercel Functions, and therefore the little backend for every dumb thing I now build on a Tuesday night) makes finding out almost free.

The moral, if you want one

I don't really believe in morals at the end of blog posts. But here's something I've been thinking about.

A lot of what we call "learning" in this industry is actually learning what not to reach for. When I was a beginner, I reached for whatever tool looked most serious, because I thought seriousness equaled correctness. Kubernetes looked very serious. So I reached for Kubernetes.

It turns out that the real skill — the one people with gray hair keep trying to tell you about — is knowing when the smallest tool will do. A function. Literally just a function. Running somewhere you don't have to think about. For pennies, when it runs at all.

Anyway. I have another bad idea I want to go try. I'll let you know how it goes.

The Full-Stack Blueprint for Reliable Enterprise Software

· 3 min read
Ashish Kapoor
Software Engineer

Engineering perspective

Building enterprise-grade software requires more than choosing popular tools — it demands a coherent system where every layer reinforces the others. After years of delivering complex projects, we've converged on a full-stack architecture that is productive, maintainable, and scales gracefully with business complexity.

This post walks through that architecture: what it is, why each component was chosen, and what makes the sum greater than its parts.


A foundation built on maturity

The most costly mistake in enterprise projects is building on immature foundations. When the underlying framework isn't battle-tested, teams spend engineering cycles working around the framework rather than solving business problems.

Our stack starts from the opposite premise: choose tools with deep lineage and proven reliability, then build on top of them with confidence.

Backend: Django + Django REST Framework

Django is one of the most mature web frameworks in existence, with over two decades of production use across industries where reliability is non-negotiable.

Its "batteries included" philosophy means:

  • Authentication
  • Admin tooling
  • ORM
  • Migrations
  • Security hardening

…all come out of the box.

Django REST Framework extends this into a principled, highly configurable API layer.

The result is a backend capable of expressing sophisticated business logic without constant custom scaffolding.


Frontend: Opinionated React Framework + ShadCN

On the client side, we use a React framework that takes strong positions on:

  • Routing
  • Data fetching
  • Server integration

Drawing inspiration from:

  • Next.js
  • TanStack Start

This reduces decision fatigue and keeps teams aligned.

ShadCN provides:

  • Accessible components
  • Composable UI primitives
  • A flexible design system

…without locking teams into a rigid component library.


The secret sauce: OpenAPI as a contract

If there is a single architectural decision that elevates this stack above alternatives, it is treating the OpenAPI specification as a first-class contract between server and client.

This is not documentation. It is a live, machine-readable agreement.

The principle:
Define the contract once, derive everything else from it.
The server owns the spec; the client consumes it.
Discrepancies become compile-time errors, not production incidents.


Backend: drf-spectacular

drf-spectacular:

  • Introspects Django REST Framework code
  • Generates OpenAPI 3 specs automatically

It captures:

  • Endpoints
  • Request/response schemas
  • Authentication rules
  • Error contracts

No manual maintenance. No drift.


Frontend: Orval + React Query

On the client side:

  • orval consumes the OpenAPI spec
  • Generates typed HTTP clients
  • Creates react-query hooks automatically

This means:

  • No manual API wiring
  • Built-in caching
  • Automatic invalidation
  • Type-safe integration

If backend changes → frontend breaks at compile time, not production.


Why this architecture accelerates delivery

Modern development is increasingly AI-assisted.

This stack works with that trend because:

  • Types flow end-to-end
  • Context is explicit and structured
  • Integration is automated

Result:

  • Faster feature delivery
  • Less glue code
  • Lower cognitive load

Teams focus on solving problems, not wiring systems.


The one thing technology cannot replace

Here's the uncomfortable truth:

No stack—no matter how good—can compensate for poor domain understanding.

If you don't understand:

  • Workflows
  • Edge cases
  • Regulations
  • User behavior

…you will build mediocre software with elite tools.

This architecture removes technical friction.

What remains is what actually matters: domain expertise.


Closing

If you are evaluating partners for a complex software initiative and want to understand how these choices translate to outcomes for your organisation, we would be glad to have that conversation.

Full Stack Development (Weekend Edition)

· 3 min read
Ashish Kapoor
Software Engineer

I have been a frontend developer in Mobile(iOS) and Websites for over a decade now. I crave to get the taste of the backend from the past 3 years over holidays and weekends.

Being in the front end I was always inclined towards javascript/typescript in the backend. I went from NodeJS to ExpressJS to Koa where I realised the developer experience(DX) was a lot demanding and did not appear like a weekend affair.

While recently working alongside a long-time friend Prakhar Shukla. I noticed him advocating for Django (Python-based framework) a lot. Where I noticed he was able to manage a team of 2 and lead multiple products swiftly with a happy face most of the time.

I started questioning my "tech-stack" ReactJS / Expo.dev, Node/ExpressDjango?, Postgres, Nginx.

All self-hosted! Oh yeah, I spent last two years in Computer Networks to accumulate practical knowledge from DNS, TCP/IP, cloudflare, Nginx Proxy Manager, wireguard, docker, docker-compose, grafana, and to ubuntu server, cockpit and proxmox.

Why? I ended up eventually streaming legally acquired videos on demand from anywhere across the globe for myself and friends using Oracle Cloud because JioCinema was a horrible OTT service back then.

Coming back on the search for a web backend framework which plays nice with a weekend’s worth of time. Since a lot of my time investment went into the node, express, koa, system design, and backend systems. I realised it was not a waste of time after all because the architecture was almost the same across all frameworks. I noticed unlike in the front end at least in the backend things were mostly the same with minor differences in philosophy and ways of doing the same things.

Then with a simple introduction to Django Rest Framework the promise of DX helped me double down on giving my all free time to devote to Python & SQL > Django > DRF. The major benefits of not having to worry about pointers and references in python were just a no-brainer. Special mention of the pythonic way of doing things.

Note: Having basic clarity of things like HTTP, IP, model-based ORMs, Virtualisation, Docker, and K8s. Then clarity through Budibase and Supabase with some technicalities of tables and relationships. I am super confident to invest my free time into Python land. Plus after witnessing my colleague fine-tuning and caching while we were scaling up our systems. It just makes sense that Django framework is the best way forward for me over weekends!

Also, statistically speaking JS/Python communities are top communities to learn and grow.

The pros of going through this process?

  • I might be able to write services on the web.
  • I might be able to fiddle with 3rd party Python AI/ML libraries which will make ML highly accessible to me.

On the similar lines (Weekend Edition), What about the state of front end?

  • I am still trying to figure out an easy way to solve the frontend overload in the world of NextJS, Svelte, VueJS, and SolidJS.
  • The idea of not being bothered about the performance too much rather delivering frontend quick is possibily the key.
  • I think since Vercel currently holds on to the top talents in the domain. They should be the ones solving this problem in the OSS way.

Here's what I built over weekend. An expense tracker. https://fintrack.sannty.in Go check it out!