escape from neubrutalism
Published on February 17, 2025
Escape from Eden is a blog written by someone who was raised in a very strict evangelical Christian home and eventually deconstructed their beliefs and rebuilt their life. In some ways, it was the perfect project for me as I was leaving the rigid constraints of evangelical Firebase and transforming to the more flexible, scalable world of Prisma. The same thing (kind of)!
When the author came up with the idea for the site, he had a few requirements around it:
It needed to be minimalist
It needed to be distinct
No comments – this needed to serve as an outlet, not a conversation
No WordPress. He had used WordPress in the past but just didn’t want all the bloat and wanted to have customization available.
The scope was relatively simple. It needed to be accessible, fast, and able to drive traffic. But more than anything, it just needed to exist, ready for the moment when he finally had time to write again.
That’s the kicker: the site’s still unfinished. It’s technically “soft launched” because the author’s too busy to write. Which has given me time to move on to other projects…but not to finish this one.
So, Escape from Eden is my Second Death Star – you can behold the power of this fully operational battle web app, but it’s still somehow pretty incomplete. It lacks an RSS feed and the subscription model isn’t fully functional. Still, the author can make posts and readers can read posts, and for a blog that fits every “MVP” standard, so we’re good!
friends don't let friends use wordPress
In reality, WordPress isn’t that bad. I used it for a decade before I knew how to code. But if you don’t need a lot of functionality, if you want a style you can choose and that isn’t dictated by a template, if you want something that stands out but doesn’t have a ton of bloat, WordPress just isn’t the way to go. Plus, from the developer’s perspective, it’s not exactly the easiest thing in the world to work with.
When the author put a hard no on WordPress, they won my heart.
But, without WordPress, what’s the solution? I looked at other headless systems. Many of them were great, but all of them were overkill. The reality is a system that comes with its own backend already built-in is usually the smarter choice in a freelance project.
But:
I’m not always smart.
I don’t think it’s always the smart move – especially when you don’t need that much complexity
And if you do need complexity but you’ve got the runway, why not just build it yourself?
So…I did. I built the system myself.
All I needed was a clean publishing workflow. No comments meant no moderation, which meant no need for user roles or access control. Just optional features: subscriptions, tags, categories, related posts. That’s it.
The core idea behind it was to remove the fiction between writing and reading – the whole point of the blog is to just let the author vent. The author logs in, clicks once to write a post, clicks twice to edit one. For the reader, the homepage is the blog – no splashy intro, no landing fluff, just straight to content (even if this will eventually change).
No big header, no prompting to create new unnecessary pages, no unnecessary overhead in the toolbar that he’ll never use. Everything in the toolbar is exactly what he knew he would need.
For the backend I opted for Prisma because
I’m not a backend developer, so I’m always going to pick the best-known tools with a lot of support even if they’re not ideal and
there was no way in hell I was going to repeat my mistake of using Firebase for complex relational backends. Even the dumbest animals learn from pain.
Architecting the backend was probably the easiest part of the project. I mean, it’s a blog, there’s only so many ways to organize a blog table. What was nice is it was the first live project I was working in where I was using PostgreSQL and Prisma instead of falling back on Firebase.
Look, I’m a UI/UX-focused developer. The backend has always been to me what CSS is to most backend developers: a confusing, slightly magical layer I’d love to offload. But since I’m a solo developer, I don’t get that luxury. I have to do both.
When I was working on smaller, throwaway apps, Firebase was perfect. Easy to use, fast to set up, and great for beginners. Read the docs, do a couple tutorials, and you’re up and running.
But when you start building real projects that are meant to function – not just exist as portfolio pieces – Firebase starts to collapse under its own simplicity.
I learned this lesson the hard way with one project and vowed to never repeat that mistake again.
Looking at this blog, even though a small project, it was heavily relational. I might’ve overreacted a little – this backend is 100% Prisma, no Firebase at all. If the project grows and we need real-time features – site stats, lightweight document data, etc – I’ll pull Firebase back in for that. But for now, Prisma gets the job done. Cleanly. Reliably. Sanely.
Minimalism With Soul
With the backend sketched out, it was time to figure out the design. Since this was meant to be a quick MVP, the plan was always to revisit the design later. So, I skipped Figma and opened up Tailwind, built the basic components I knew I’d need, and just got to work.
Originally, I wanted to bring in some neubrutalist elements. That’s my usual style; bold borders, big box shadows, oversized fonts, intentional chaos. But in this case, it didn’t make sense. The author wasn’t asking for a design that pushed against convention, he was asking for one that stripped everything down. Minimalism wasn’t a trend here. It was the point.
That ruled out neubrutalism completely. For those unfamiliar, neubrutalism is a reaction to the tech-forward minimalist movement of the 2010s. It intentionally breaks from the uniformity we see across modern design systems. It exaggerates box shadows, sharpens border radii, and embraces weirdness – much like the early internet if it had a style guide.
I love it. But it had no place here.
This blog is about deconstruction. About removing layers, not adding them. The author is telling stories about how he stripped everything away in order to figure out who he was. That demanded minimalism, not just in aesthetic, but in structure.
So that’s what I delivered…kind of.
Tailwind, being opinionated toward minimal design, helped speed things along. There’s no hero section. No storytelling header. You land on the page, get a short message and a CTA, and you’re immediately at the most recent post. The homepage is the blog. There’s no page intro, exactly how the author wanted it.
Color-wise, the palette is restrained. Light/dark modes are fully accessible. It’s clean. It’s functional. And…it’s kind of boring.
It hits the target in terms of minimalism, but it doesn’t hit it well. It’s not distinct, it doesn’t carry the soul we were aiming for. It works, but it doesn’t say anything.
Phase II will change that. I’ll be ripping the Tailwind styles out and rebuilding in SCSS. Tailwind, while technically customizable, comes with strong opinions. SCSS lets me start with my own opinions and scale them outwards. I’ll also be building a proper Figma layout, which will help rethink spacing, hierarchy, and interaction design from the ground up.
Right now, I’m leaning toward an even more limited color palette, with one or two sharp accent tones that stand out. I’m also looking forward to using pseudo-elements for some lightweight hover flair and maybe a more expressive visual rhythm.
I’m not sure exactly where the design will land yet – and that’s kind of the fun of it. The site is about transformation. It’s okay that it evolves over time.
Vibe Coding & TipTap
As mentioned, I didn’t use Figma before jumping into the design. To be fair, if I’m starting with Tailwind I usually don’t have a high-fidelity Figma mock-up; at best, I’ll have a wireframe. That’s the power of Tailwind, but also its drawback. It means you’re making design decisions with incomplete information.
For a small, minimalist MVP that’s not a huge drawback; for a larger build it’s detrimental and prevents scalability.
In short, this is kind of “vibe coding,” isn’t it? You’re looking at what’s on the screen and shifting your my-4 to my-6 because it just “feels” right. But this also allowed for a rapid build and any design decisions were seen live by the client rather than static in a Figma file. For an opening phase MVP, Tailwind was the best approach.
This approach made life more of a struggle than it needed to be when it came to the admin panel.
I opted to build a fully custom admin panel instead of using a headless CMS. That meant designing it on the fly, which technically went fine, but was still frustrating. Would I do it again? Is vibe coding worth it?
Lol, no.
While everything looks great and works, the experience itself was frustrating and resulted in me essentially refactoring code that should have been clean from the get-go. Not a dealbreaker, but it drained more time and energy than it should have.
Thankfully, the one thing I did plan worked out incredibly well: the rich text editor.
I’ve used a few RTE’s in Next.js and, I gotta say, they all suck. If you’ve ever found yourself googling how to build your own RTE from scratch at 3am – and seriously considering it – you know how bad the options are.
Thankfully, TipTap exists.
If I were to make my own custom rich text editor, it’d look and function exactly like TipTap. It’s one of the only RTE’s I’ve found that’s actually built for React, understands props and components, and respects state. It’s design-agnostic, incredibly flexible, and shockingly easy to customize.
In fact, its extendibility is probably my favorite part.
TipTap has no citation editor out of the box – so I made one. And it was easy. Like, 20 minutes easy. The author just clicks “citation,” this brings up a modal that uses a mini-TipTap editor allowing for underlining, bold, italic, and other common citation formatting. Once submitted, the citation shows up next to the text and when clicked on brings up a modal displaying the citation.
This will allow the author to write academic articles and cite things that aren’t just hyperlinks. It’s intuitive, clean, and required no extra setup. The magic of TipTap is that it does all the hard work without being hard to work with.
Other Cool Features
There’s a few other cool things I threw in here:
Custom-built subscriptions. No library dependencies. Also unfinished, because the author’s still undecided on whether he wants subscriptions at all.
If it can be server rendered, it’s server rendered.
No comments, no external analytics tool, no CMS layers, because the client didn’t want any of this
Post progress tracker, a little bar at the top shows how far along you are in the post – because if you’re anything like me (sup my ADHD people), you like to know exactly how much is left before you commit.
Fully accessible light and dark mode
As I’ve mentioned – probably too many times – the blog isn’t done. It’s soft-launched and waiting on the author’s schedule to clear up so he can write. The backend is stable, performant, and built to scale. The visual identity has a Phase II already in mind, currently being worked out in Figma.
Still, I don’t foresee features being added to this beyond an RSS feed and finishing the subscriptions. The blog as it is (other than the search feature, also incomplete!) is set.
The unfinished nature of the site frustrated me. But from the author’s perspective, it kind of makes sense – he likes that it feels incomplete, because he feels incomplete. He’s a philosopher by trade, and philosophers have always been annoying like this (the Greeks killed Socrates).
But hey, when the time comes, I’ll be ready. And it’ll be fun.
A Blog That's Becoming
As annoying as his philosopher instincts are, I do see the beauty in it. In some ways, this site isn’t just about the author’s writing, it’s about the process of becoming. It’s a space that intentionally avoids completeness. There’s no need for perfection when the whole point is to express, reflect, and rebuild. It’s a project that mirrors the author’s journey and maybe mine too – a moment of shedding what no longer fits, not just in content, but in code.
From a development perspective, Escape from Eden is both a finished product and a prototype for the future. It’s a lean, fast, relational blog powered by Prisma and PostgreSQL, not Firebase. It embraces accessibility, avoids bloat, and ditches the admin-heavy CMS tools we’ve all come to tolerate. It doesn’t aim to compete with medium or Ghost – it’s meant to be lighter than those.
And yeah, the subscriptions aren’t done. The RSS feed is missing. The styling’s still a little bland. But that’s okay. It’s not broken, it’s incomplete but breathing. It’s something we’ll come back to when the time is right, when the writing picks up again and the author has more to say. Until then, it stands as a functioning, living framework – a reminder that not everything needs to be complete to be meaningful.
Because sometimes, the most honest builds are the ones still under construction.