Rediscovering My Craft: Layoffs, Mental Health, and Frontend UI

For roughly the last eight years of my career — about four years at JPMorgan and four years at Praetorian — I lived and breathed React. It was my main tool, my daily environment, and the lens through which I thought about most frontend problems.

At JPMorgan, I worked across a bunch of UI ecosystems: React with Bootstrap, React with Material UI, and various custom component systems. I spent a lot of time wiring components into large organizations’ existing design patterns and expectations. At Praetorian, the story shifted over time. We eventually moved into Tailwind because trying to force MUI into designer-driven layouts became its own daily battle. Tailwind gave us creative freedom again, and honestly, it felt good for a while to build UI without constantly pushing against a library’s constraints.

But React, as a long-term day-to-day environment, comes with a unique kind of mental overhead. Prop chains, memoization, rerenders, custom hooks, subtle state bugs, a hundred components at varying “definitions of done,” design systems that are evolving while you’re implementing them — it all adds up in your head.

In a high-pressure startup, that weight gets multiplied. Every feature needs to look good, behave correctly, meet business requirements, scale reasonably, and be delivered yesterday. The technology itself was fun and genuinely interesting. The pace and mental load on top of it, over time, was not.

I found myself going to bed thinking about edge cases, half-finished refactors, or some awkward state flow I wasn’t fully happy with. Being the lead on the frontend meant carrying all of that context more or less continuously. We did produce great work — genuinely high-quality UI delivered quickly — but that doesn’t mean it was easy to carry.

And then, all at once, it stopped: my entire department was laid off.

The Layoff

The layoff was a genuine shock. We were being praised constantly. Customers were happy. Internal demos and “company celebration” calls went well. Our work kept getting held up as an example of what a small team could do.

That’s part of what makes layoffs so disorienting: the stories you hear (“You’re doing great, we love this!”) and the decisions being made (“Your entire team is gone now.”) exist in completely different layers of the company.

It took a while to sit with that and realize something simple but important:

A layoff is not a judgment of your ability — it’s a budget line.

There were absolutely things we could have done better. Every team has gaps, edge cases they miss, miscommunications, last-minute surprises nobody accounted for. But even when I questioned myself (as every engineer does eventually), I never doubted the quality and work ethic of my team. They were excellent. For a mid-sized startup, we shipped an enormous amount with very little.

Once the initial shock faded, a more grounded perspective started to show up. As a business, a company is allowed to decide who to hire and who to let go. That doesn’t make it painless, but it does mean I don’t have to interpret every layoff as a moral verdict on my work or my worth.

That realization opened the door to something more interesting: if this wasn’t about my value, then I had the freedom to treat this as an inflection point instead of a failure.

Human Connection After the Layoff

One of the most unexpected things that happened after the layoff was how many people reached out. Not managers trying to soften the blow, but actual peers—engineers, designers, people I collaborated with casually or deeply over the years. Folks I had helped with a bug once, built a feature with, or even talked through an idea during a random afternoon.

Their messages weren’t transactional or political. They were simply human. People wrote to say they were shocked, or that they appreciated working with me, or that something I built made their job easier. Others shared projects they were tinkering with and genuinely wanted my thoughts. These were conversations without pressure—no sprints, no deadlines, no obligations. Just people talking to people, remembering the good parts of working together.

It reminded me how much of this industry is built on real human relationships, not performance reviews or JIRA boards. And it made me realize that if so many people still valued working with me, then I had more options than I thought. I didn’t need to wedge myself back into the first structure that would take me. I could build something on my own terms.

That realization—more than the layoff itself—nudged me toward something that had been quietly sitting in the back of my mind for years: freelancing.

Why I Love UI (and Why I Haven’t Left It)

Underneath all the noise, I’ve always been a frontend engineer for one simple reason: I love building things for people.

It’s the working-class part of me:

• A chef wants to see someone’s face light up when they taste the food.
• An artist wants someone to feel something when they see the work.
• I want someone to feel clarity and relief when they use a UI I built.

Cybersecurity as an industry is important and genuinely fascinating. But for me, the real joy was never the domain-specific acronyms — it was taking a complex idea and shaping an interface that made it understandable and usable by someone who didn’t live inside that complexity every day.

That’s the through-line in my career: I keep ending up between highly technical systems and the humans who need to use them. When I do my job well, those people don’t have to think about your internal architecture. They just get to do their work more easily.

The Switch to Freelancing

Over the years, I’ve worked with a lot of different teams, personalities, and leadership styles. That’s one of the hidden benefits of being a frontend engineer in different domains: you get to see how people in finance, security, internal tools, and product all think about problems, and you see where interfaces either amplify that thinking or get in the way.

One pattern kept showing up: a lot of extremely talented backend or security engineers build interfaces that work but aren’t enjoyable or intuitive. The craftsmanship is there on the inside, but the surface is unapproachable. You can feel the intelligence of the system and the awkwardness of the UI at the same time.

That’s the gap I like to fill. I make complex systems feel simple without dumbing them down.

I’ve worked with designers who create beautiful layouts but don’t have time or space to fully internalize the problem space, so the screens look amazing but don’t quite align with how users think. I’ve worked with engineers who build efficient flows with clean code but lack empathy for users who know nothing about the system’s internals. Those users don’t know what custom icons mean, or that a critical setting lives four levels deep in a drawer inside a modal inside a tab.

My instinct is always to design with empathy for the end user. I try to see the interface from the perspective of someone joining on day one, or someone using this tool once a month while juggling ten other responsibilities. I’m not trying to win design awards (most award-winning sites are a usability nightmare); I want apps that are performant, clear, and intuitive because they respect the person on the other side of the screen.

So I ask questions like: Where would they expect this to be? What are they already used to from other tools? What can we make obvious without a tooltip or a user manual? I lean on familiar patterns so users don’t have to build a brand-new mental model just to click a button.

That mindset — and those earlier conversations with people reaching out after the layoff — made freelancing feel less like a risk and more like a natural next step. Instead of building for a single company’s roadmap, I could bring that empathy and UI focus to whoever needed it most.

And that’s when something really encouraging happened: I landed my first full-time freelance client.

My New Chapter: A Graph Database IDE

A former colleague and I reconnected organically, and now I’m working with an incredibly smart team building a graph database IDE. They’ve already done the hard engineering work: connecting to Neo4j, JanusGraph, Datastax, Kùzu, RDF graphs, and a continually expanding list of other databases — all behind a single, unified interface.

My job is the part I love:

Make the UI intuitive, clean, powerful, and beautiful.

The tool lets people write queries, visualize results as tables or node/edge graphs, and eventually drive dashboards and deeper analysis on top. It’s the kind of product I naturally gravitate toward: highly technical under the hood, but only truly valuable if the UI feels approachable to someone who isn’t living and breathing graph theory all day.

They’re using Vue and Vuetify, which has been a surprisingly refreshing change of environment. After years of React, switching mental models forced me to slow down just enough to be intentional again. Vuetify provides structure and constraints in a way that feels supportive rather than restrictive. Instead of manually juggling one-off Tailwind combinations for everything, there’s a known, shared system I can plug into.

Mental Health and Rediscovery

Looking back, one of the biggest things I underestimated was how much the environment around the work affects how the work feels. I wasn’t burned out because I suddenly stopped liking software. I was burned out because I was operating in a context where speed, urgency, and “more” were the default settings all the time.

When everything stopped — the standups, the notifications, the constant sense of needing to catch up — it felt disorienting at first. But once the dust settled, there was this strange, quiet realization: I still wanted to build things. I still cared about UI. I just needed to do it in a different kind of environment.

Joining a different team, with a different belief structure around what success looks like, made a bigger difference than any single framework ever could. I moved from a place where “fast and more” dominated to a place where clarity, maintainability, and thoughtful pacing are actually valued. Where writing simple, well-structured software is seen as a mark of maturity, not a lack of ambition.

That shift gave me permission to cool down. To work at a human pace. To care about naming and structure and UX flows without feeling like I was falling behind just because I wasn’t pushing a new feature every other day.

Rediscovering my craft wasn’t about finding the “perfect” tool. It was about reconnecting with a community and a way of working that feels sustainable. I’m still writing code, but I’m doing it in a way that feels healthy and long-term instead of frantic and brittle.

To Anyone Else Affected by Layoffs

If you’re reading this and you’ve been through a layoff, or you’re in the middle of one, I won’t pretend it’s easy. It’s not. It hits your income, your sense of stability, and your sense of identity all at once.

But it can also be a forced pause that you never would have given yourself on purpose. And sometimes that pause is where you finally get a clear look at what you actually want your work to feel like.

Change creates clarity.
Rest reveals passion.
Space creates opportunity.

I still wish my former coworkers well — many of them read this blog — and I hope they land in places that are right for them. The work we did together is still real, still meaningful, and still something I’m proud of.

And if anyone needs a graph database IDE that works across many different backends, check out G.V(). I’ll be here on the other side of all that, improving the UI and learning from some brilliant people, trying to make complex graph tooling feel simple, fast, and actually enjoyable to use.

PageFoundry LLC

One thing I never actually wrote about on this blog is that I started my own company: PageFoundry LLC. You can find it at https://pagefoundry.dev.

PageFoundry is a small, UI-focused consultancy where I take everything I’ve learned from working across finance, security, data tooling, and product engineering, and apply it to building modern, intuitive interfaces. The focus is simple: clean design, fast workflows, and UIs that actually help people understand and use the technology in front of them.

Right now I’m booked on a full-time basis with my current client, but I always stay open to smaller projects, part-time consulting, or just talking through ideas. Sometimes the most valuable thing isn’t a full build; it’s a conversation, a sketch, or a different way of framing a UI problem.

If you’ve got something interesting you’re building and want to talk UI, or you need a fresh set of eyes on a product that feels clunky, feel free to reach out. I’m pretty friendly, I love learning about new projects, and I genuinely enjoy thinking up UI solutions even just for fun. You can always find me on LinkedIn.