cybernetically enhancing my brain with vendor lock-in
just how quickly can you build and deploy a site in 2025? if you ask Guillermo Rauch he’ll probably say instantly, or something, before muttering to himself about state-sponsored propaganda and the free market. sure, i could flash nixos on to the spare machine sitting on top of my guitar amplifier. battery swelling, insurance adjusters frothing at their thin-lipped mouths, but what if i just paid someone else to do that for me? and what if i gave two billionaires money in the process?
in the age of Claude 3.7, gps ads, algorithmic feeds, and robot-on-robot violence why would i do anything myself, including setting up my own aws environment? what am i, a caveman?
so, instead of doing the logical thing i’ve been doing most of my life and making a Ruby on Rails app, i decided to see how many npm libraries i could weave together into a digital trammel. perhaps, i’ll even catch something good, and not just some endangered turtles.
over the course of approximately 3 hours and 27 commits, i threw together
one of the most simple crud apps one could design. it has auth, a postgres database, edge functions… for some reason, and uses shadcn and tailwind for styling.
those three hours were 2 hours and 10 minutes of reading docs, resolving npm conflicts, and consulting the oracle stack overflow with 50 minutes of hamfisting garbage typescript into webstorm via my keyboard. indeed, who doesn’t enjoy reading year old release notes to find slight changes in type names. now, granted, its my own fault for trying to use an orm, and quickly reading through some older implementations. i, like most modern developers, don’t believe in personal responsibility, so, i’m choosing to blame the geist of modern computing. the greater foundational spirit of the lightning boxes that dominate our lives.
the irony isn’t lost on me: i’m tracking the substance that wrangles the post-modern, meme-riddled, goop floating in my skull, using tools that deteriorate my cognitive abilities. with every sip of caffeine i ingest, i wedge myself further into the wallet of vercel. i’ve become codependent. i need caffeine to understand modern web dev, and i need modern web dev to track my caffeine.
i’ve completed my transformation. completely locked in to next.js, vercel, neon — but not only this, i’ve locked my biochemistry in too. who needs neural implants when you can run a cli tool to deploy your EDGE COMPUTE FUNCTIONS™️. this is cybernetic enhancement for the terminally online: we’ve ditched the chrome hardware for subscription-based digital services that save us potential minutes of work.
the full recipe for this digital monstrosity? start with a fresh next.js 15 app. add a sprinkle of drizzle orm (appropriately named, as it's just enough database to make everything damp enough to mold). toss in nextauth so you can scapegoat the library for your misunderstanding of pbkdf2. layer on shadcn components since something good had to be developed from the primordial ooze of tailwind. and finally, drown the whole thing in classes until your jsx looks like the xanga page from your xRawrxMonsterx era.
after battling npm dependency hell – where "react-dom": "^19.0.0" somehow conflicts with a package that requires "react-dom": "^19.0.0" – i finally deployed to vercel. why? because i've developed stockholm syndrome for platforms that promise to handle infrastructure for me. i am done. i am happy. :)
as i sip my fourth espresso, washing it down with a sugar-free red bull and watching the caffeine counter tick upward on my shoddily deployed app, i realize i've created the perfect metaphor for modern development: an over-engineered solution to a simple problem, temporarily satisfying but ultimately creating more dependencies than it resolves. the difference between caffeine and cloud services? at least caffeine is honest about its half-life.