Introducing ApexKit

Pradhumna Pancholi — Wed, 15 Apr 2026 11:56:17 +0000

Hello everyone! I have something to share today. Last year, I spent a lot of time helping with side projects. All of those projects needed the same foundational pieces - authentication, component library, and a database connection - regardless of the product.

Now, I know starter kits exist but most of the ones that I came across had a few issues that didn't quite work for me. One of my biggest issues was learning a lot of new things just to do things in a certain way even though I was already well versed in the frameworks. I needed something where I could get moving fast with the least amount of friction. So, just like every other stubborn developer, I decided to build my own.

On a side note, while researching all the starter kits, I figured that there are quite a lot of them out there in the wild from half-baked ones to amazing. So, I documented my project and released it in a way that it can be used by others. Check out the website, docs, and repo. Feel free to share your thoughts.

Core Philosophy

A. Avoid vendor-locking

This is one of the biggest reasons why I needed to make my own. A lot of starter kits out there were using tools that get developers locked into a vendor. Don't get me wrong, I see the point behind them. A lot of these starter kits are made by some vendors as a way to easily onboard new developers and companies onto their platform. That being said, it's not often the best idea for a project. Supabase might be perfect for someone whereas Neon would be better for others. And many times developers do not have enough data during the initial stage to make that call. So, a starter kit without vendor-specific SDK was critical for me. You can see this in the ORM choice of ApexKit. It doesn't matter if you want to use Supabase, Neon, Heroku or Aiven, it just works with a connection string as long as you're using Postgres.

B. Progressiveness /Flexibility

A progressive set of tools is always helpful when you are working on a side project or testing an idea. For me, this is design systems. I am not someone who wants to spend a lot of time configuring my theme, design system, and styles before figuring out if this is a good idea.

However, this doesn't mean that I want to ship products that look like every other website or have no branding. Branding is crucial for marketing and first impressions (remember when you could just look at a website and see that it was made using Bootstrap?). I found this balance for me with TailwindCSS and DaisyUI. They allow you to get started quickly with built-in styles and themes to give a little personality with the flexibility to customize it at a granular level when you're ready.

C. Stability

Now, "modern" might as well be a dirty word in web development — and honestly, can you blame anyone for thinking that? It feels like every few months there's a shiny new front-end framework or meta-framework dropping, each one promising to be the last one you'll ever need.

It started simply enough with Angular, React, and Vue. Once React found its footing and took over, we rolled into the Gatsby and JAMstack era, which slowly but surely led us to Next.js becoming the go-to React-based meta-framework. Now it's got some healthy competition from Astro, which has been turning heads for its flexible approach to deployments. And if that weren't enough, Solid and Svelte showed up as leaner, refreshing alternatives. These days, the cool kids are talking about HTMX and Alpine.js — a bit of a "back to basics" rebellion driven by JavaScript fatigue.

The same pattern plays out in databases — or at least in the hosted solutions that bootstrapping web developers tend to reach for: MongoDB → Firebase → Supabase → Convex, each riding its own wave of enthusiasm before the next thing arrived.

CSS tooling followed the same arc: Bootstrap → Material UI → Chakra UI → Tailwind CSS, which has since spawned an entire ecosystem of component libraries built on top of it.

I won't pretend this is an objective history — a lot of this reflects my own experience. But I've seen these sentiments echoed widely enough across the developer community to feel confident they resonate. This starter kit is opinionated, and I make no apologies for that. My hope is that it helps you find the same balance between maintainability and momentum that it gave me.

The Choices

Ease of maintenance is what led me to choices that sit comfortably in the widely-adopted middle ground. Take Pocketbase, for example — I genuinely love what that project is doing, and the idea behind it is brilliant. But if you're trying to move fast, hunt for product-market fit, and juggle it all as a side project, it might not be the smoothest ride. And just to be clear, this isn't a dig at Pocketbase or any other up-and-coming library — not even a little bit.

One more thing worth mentioning: Apex Kit is not a framework, and it's intentionally kept that way. Here's what I mean — maintenance is a huge part of actually shipping and sustaining a project, and I didn't want this to become a burden. Right now, the most "vendor-locked" thing in the entire stack is Resend for email, and even that's a straightforward swap if you need it. No big scary refactors, no tightly-coupled spaghetti code holding you hostage. Every feature that's been added — and everything coming down the road — is built with readability and maintainability in mind.

So if any of this is clicking for you, I'd really encourage you to just give it a shot and build something with it. You might be surprised.

Forem: ApexKit

Introducing ApexKit

Core Philosophy

The Choices