The first thing I vibe coded was an app called viberunning.lol. It was a fancier version of a Google Sheet I maintained to track my running progress, which used Zapier to add a new spreadsheet row after every run posted to Strava. I originally created the spreadsheet to build custom visualizations for specific trends I wanted to track over time, but the format was ultimately limited.

When vibecoding tools like Bolt arrived on the scene, porting over my running spreadsheet into a “real app” felt like a great entry-level project to gain exposure to some new capabilities and ways of working.

At first, I was very impressed with Bolt’s power. Within a couple of hours, I got the app to ~80% parity with my existing “dashboard,” adding on some fancy new filters and visualizations that Google Sheets didn’t support. Then, frustratingly, I spent the next 3 days chasing the remaining 20%. Things stopped then restarted working with no rhyme or reason. Chart axes randomly inverted themselves. Instead of updating existing database columns, Bolt kept adding new, redundant ones that muddied the data and created conflicts. Eventually, it became more of a headache than it was worth.

That was mid-2025, so a lot has changed since then. I’m sure Bolt has gotten better and more powerful. And I learned a lot, which was the primary goal of the project. But my biggest takeaway from that experience was that the gulf between vibecoding a shiny prototype that works once and maintaining an app that works reliably over time remains pretty wide.

Defining vibe coding

To me, vibe coding is an exploration activity that uses code as a creative medium. You might be trying to get an idea out of your head, build a custom tool for yourself, or validate that an interaction pattern makes sense. If you work on a team, you might vibe code a prototype to rally others around a concept you believe in. I think of it as more intuitive and gestural than other kinds of design work, similar to a sketch. “Hey, we could go in this general direction and it might work something like this, what do you think?”

It only becomes a problem when you want your vibe coded prototype to magically metamorphosize into a standalone production app. For designers working at companies large enough to hire engineers (most companies!), this isn’t really an issue. Your engineering friends are going to be the ones in charge of the tool stack decisions I want to talk about today and your challenge is more around how to integrate your coded design work into their existing tech stack.

But what if you’re a designer who wants to create your own product from scratch, outside of your corporate job? In software engineering, this is called a “greenfield” project, meaning a project where migrating or integrating with legacy systems isn’t a concern. At established companies, choosing a completely fresh start can be inefficient and expensive, so true greenfield projects are often few and far between. When you’re making your own thing, though? It’s kinda the dream.

A patchwork tooling landscape

Today, I want to document some of the tools we’re using to build Al Dente and why we chose them. I’ll also include some reasonable alternatives if our pick doesn’t make sense for your project. My goal in sharing this is to highlight the types of decisions you’ll have to make if you embark on a similar adventure and some of the tradeoffs you may want to consider as you decide.

Generally speaking, tool selection will not make or break a product’s success. Al Dente’s tools are not objectively the “best” tools, nor are they the only tools in their category. Even so, it’s still fun and interesting to talk about, and I love reading similar breakdowns from other product makers to learn from their approach.

Another thing to keep in mind is how fast these tools are expanding their feature sets. Many of the tools I describe below started by focusing on one core problem and are now evolving to solve for adjacent problems. They tend to offer a very robust solution for their core problem, while the adjacent solutions might be nascent or incomplete. However, there is almost always another vendor whose entire focus is the first vendor’s adjacent area, resulting in a patchwork of overlapping options for different technical features with varying degrees of robustness.

In practice, this means choosing between fewer tools that work together “well enough” or choosing a powerful, specialized tool for each problem. To start, consider sticking with fewer tools and only reach for a new tool if you’ve hit a wall with a specific capability that you can’t achieve with your existing setup.

What we’re optimizing for

At Al Dente, we’re a small team of two building a cooking app primarily designed for mobile devices. When evaluating tools, we look for a few practical qualities:

• Work well with AI agents. We want to use popular, well-documented tools that agents already understand. If agents can access the same context and tools that we do, they’ll have enough information to do useful work and independently verify their own results

• Support preview environments. We look for tools that give each pull request or agent session an isolated place to run, such as its own preview URL or database. This lets us work in parallel and makes QA easier

• Offer reasonable pricing and stability. Tools don’t need to be free, but they should be affordable for a small team that’s just starting out. They should also be popular enough that we don’t need to worry about them going under any time soon

Your criteria may be different, but thinking about what’s important to you upfront will make it much easier to evaluate the overwhelming number of options available.

The minimum stack

We started with the basics: Expo for our frontend, Convex for our backend and Cloudflare as our cloud provider.

Expo

Expo is a tool built on React Native that makes it easier to build and distribute one app across iOS, Android, and the web. It’s better than using React Native directly because it handles much of the complicated setup and app store distribution for us.

Another key feature is its ability to deliver “over-the-air” updates, which means we can ship many types of changes to users directly, instead of getting stuck in the app store review process or waiting for users to download the latest version.

Lastly, Expo has a large ecosystem of ready-made tools and packages, so it’s easy to find existing tools for common features. And because it’s so widely used, coding agents are already very good at working with it.

Expo might not be for you if you only need a website, or if you want to build a deeply native app for a single platform. In that case, consider using platform languages like SwiftUI for iOS and Kotlin/Jetpack Compose for Android directly. If you’re only focusing on web apps, Next.js could be a good option.

Convex

Convex is a backend platform with a database and other essential services built in, offering smart but opinionated defaults that help prevent common mistakes. Some of the common mistakes Convex helps us avoid are showing users out-of-date information or leaving data in a broken state when only part of an update succeeds.

In our opinion, you can get really far with just Convex because the included services all work together pretty well. In addition to using Convex as a database, it also handles basic user authentication, file storage and recently introduced an AI gateway feature, which I’ll cover more below. We don’t personally use Convex for those things, but it’s a great place to start.

Because Convex is opinionated and bakes in more than just the database, its main drawback is vendor lock-in. When you’re getting started on building your own thing for the first time, you probably don’t need to worry about that too much. Supabase is also a good option with similar offerings if you want to explore an alternative.

Cloudflare

Cloudflare is a cloud provider, offering a large collection of services for hosting and running products on the internet. It’s infinitely powerful, which comes with the tradeoff of added complexity… you probably won’t need 99% of the things that it offers. We use it for:

• File and photo storage

• Hosting Al Dente’s marketing site, developer documentation, and web app

• Buying and managing Al Dente domains

• Routing Al Dente’s AI usage through its AI gateway

AI gateways are super helpful because they provide a middle layer between your product and the AI models you want your product to use. Instead of connecting separately to Google, OpenAI, and other providers, your product connects to the gateway once. The gateway then acts as a router, sending each request to the right AI provider and giving you one place to manage and pay for your AI usage. When companies introduce new models, like TypeSafe’s Jev, you can easily incorporate them without any additional setup or overhead.

Overall, Cloudflare is probably overkill for designers starting out, as it’s similar to AWS in terms of complexity. Vercel is the more approachable alternative for cloud services and also offers an AI gateway.

Extras we use for Al Dente

The stack above, or its alternatives, will get you pretty far when you’re starting out. When you’re ready to layer in additional tools as you grow, you might find some of these interesting.

PostHog

At its core, PostHog is an analytics product. You can think of it as a much more powerful and less annoying-to-use version of Google Analytics. It’s also done a good job expanding into adjacent areas like error logging, session replays, A/B testing and feature flags. Having all of those features in one place is very powerful, because your product context is all together and you don’t have to wire up ten different tools to do those jobs.

Another thing that sets PostHog apart is just how deeply it integrates with other tools through its MCP server. None of your data is locked up behind interfaces, dashboards or APIs, so your AI agents can access all of the same information that is available to you as a normal user.

Brand-wise, I can also appreciate that PostHog is doing something unique with their hedgehog mascot and operating-system-inspired marketing site. For me, the visual language does get old kind of quick, though.

Alternatives to PostHog are tricky because any reasonable alternative would likely require signing up for multiple services. You could check out Vercel’s basic analytics product, though it’s limited to web offerings and can’t track iOS or Android data yet.

Clerk

Clerk is the product we use to handle creating and managing user accounts. It’s narrowly focused and it does that one thing really well, though they have recently been expanding into the payments space.

As I mentioned above, Convex also does this and is a great place to start. We moved away from Convex because we wanted Al Dente users to be able to access their data in Al Dente through MCP and Convex’s authentication offering wasn’t mature enough to handle that.

In other words, when an Al Dente user wants to connect their recipe library to Claude, Clerk handles creating the page where they can authorize their access to get connected. Thanks, Clerk!

Resend

Resend is the tool we use to send Al Dente emails. It can handle both marketing emails and transactional emails. We haven’t sent any marketing emails yet, but we do use it to handle communication around things like account creation and password reset.

We chose Resend because it’s nicely designed and allows you to use the React Email library to design your emails. Traditionally, email design has been a very hard thing to do because email layouts are notoriously finicky, and there are a lot of weird old-school HTML techniques you have to use to get the email to format properly.

If Resend isn’t right for you, Postmark is a reasonable alternative that also supports React Email.

Putting the basics together

If you already have an idea, try using this prompt as a jumping off point to get your project started. If you already have designs or a vibe coded prototype, that’s helpful context to add in as well.

I want to build [describe your product idea, who it’s for, and the main thing it should help them do].

Here is an existing prototype to use as a starting point: [Paste a link or attach files here].

For my initial stack, I want to use:

• Expo for the iOS, Android, and web app

• Convex for the backend and database

• Vercel for hosting the web app

Create a new Git repository for the project and walk me through setting up each tool. Start by proposing a short implementation plan and a sensible project structure. Then guide me through the setup one step at a time, including the commands I need to run, the accounts I need to create, and any configuration or environment variables I need to add.

Pause whenever I need to sign in, authorize access, make a decision, or complete a step outside the codebase. Explain what each major choice does in plain language, and don’t add extra services or complexity unless they’re necessary for the first working version.

Once the foundation is set up, help me build the smallest end-to-end version of this idea: [Describe the first core user flow]. Make sure it runs locally and explain how to preview it on mobile and web, deploy the web version to Vercel, and verify that the app can read and write data in Convex.

Interview me before getting started to make sure all of your clarifying questions get answered.

Part II

Beyond vibe coding is a huge topic and picking the right tools is only part of the job. In the next installment of this series, I’ll talk about how to use AI coding tools effectively within a codebase to follow engineering best practices.

Lunch

This week for lunch, I made Kat Boytsova’s Chicken and Rice Soup with Garlicky Chile Oil from Bon Appétit.

See you next week!

We’re building a cooking app! It’s called Al Dente and we’re pretty excited about it.

Broadly speaking, the goal of Al Dente is to organize your cooking life. And, as I’ve learned from all of the people who have so generously allowed me to interview them on this topic, no two cooking lives are quite the same.

Cooking is such a fun space to explore because it’s both universal and highly individual at the same time. Everyone has to eat, everyday. Beyond that, the variables are basically endless:

• Some people cook multiple times a day, while others avoid it at all costs

• Some people cook exclusively from recipes, while others cook intuitively

• Some people prioritize efficient cooking, while others cook as an artistic or creative pursuit

• Some people are creatures (eaters?) of habit and others strive for variety

There are nutrition goals, dietary restrictions, household preferences, substitutions, budget considerations, seasonality, leftover potential and more.

Starting narrow

First and foremost, my goal is to create an app that I love to use and is valuable to me. It’s sort of a foreign concept, focusing so narrowly on my own priorities and preferences as user after almost a decade of working at a scaled megacorp designing for audiences of 150+ million. Which isn’t to say that I’m not refining and iterating on the app based on research and feedback from others. But it’s nice to be in the driver’s seat, deciding if something meets my own personal bar first.

Actually, it’s mostly nice. Sometimes, in an Ira Glass “taste vs. work gap” way, it’s kind of hellish because I’m out of my comfort zone in this 0-1 space. Onward!

So, if I’m the user, what are my pain points?

• I enjoy cooking, but I don’t like meal planning or trying to figure out what to eat

• It’s hard to remember all of the different meals and recipes in my cooking repertoire

• I read a lot of food publications and follow my favorite chefs on social media, but their recipes are scattered across the Internet

• I don’t cook from my cookbooks as often as I’d like

• Collating the grocery list each week is a lot of admin work

• Food tasks (meal planning, grocery shopping, and cooking) are household duties that I share with my husband and details get lost in the shuffle when we handoff parts of the process to one another

• I often tweak recipes to suit our household preferences or kitchen equipment, but it’s hard to track the changes and iterations over time

In addition to some of these “problems to be solved,” I also think there’s a lot of room to layer in interesting, well-crafted product experiences that make cooking more fun and joyful.

Where we are today

Not that far! We’ve barely scratched the surface of what we think is possible to explore. But, for the sake of documentation, I’ll capture what the app looks like for our household today as a milestone.

Library

Right now, the Library view is at the heart of the app. We really wanted to make this view feel like an accurate representation of the mental model people have when they think about their recipes, which often involves metadata like where the recipe came from or who wrote it. Users can also organize their recipes by grouping them into collections.

Organizing

Within each of those organizing lenses, there are detail pages that allow people to explore all of their recipes that fit a particular category. As you can see, our household loves both NYT Cooking and Kenji López-Alt.

Cookbooks

Cookbooks get a special detail page that showcase book specific information like the cover and subtitle.

Our hypothesis is that having digital representations of cookbook recipes sitting next to all of the other recipes we cook will encourage us to cook them more. Scanning the recipes into our library keeps them top of mind and discoverable, making it easier to incorporate them into our weekly meal plans and grocery lists.

Saving a recipe

There are quite a few ways to get recipes into your library, and the easiest one actually doesn’t even involve opening the app… it uses the built-in share sheets on iOS and Android. But, if people want to build out their library without ever leaving the app, they can add recipes via in-app search.

MCP

As tech nerds, we wanted to make sure we were building in an AI-native way from the start. We dogfood every feature we build in Al Dente as an MCP tool first, which allows us to explore the data model and use cases before we ever commit to building UI.

It’s also led to a lot of discussions about whether a feature actually needs UI or can just be handled by an agent. None of these discussions have resulted in decisions that are set in stone yet, but writing about our MCP-driven development process is definitely in the queue for a future post.

What’s still to come

There’s so much left to do. Some of the things coming sooner rather than later:

• More ways to organize and interact with recipes

• Grocery lists and meal plans

• Onboarding and first time user experience

• Household collaboration features

• Visual design, branding and marketing site

• Design system (!!)

We’ve taken some first passes and iterated on all of these items but none of them currently meet our internal bar. I hope to write about the process of working on all of them here over the next few months.

It’s still early, but if you’re curious to check it out, you can sign up for our waitlist here.

Lunch

This week for lunch, I made Ali Slagle’s Orzo Salad With Lentils and Zucchini from NYT Cooking.

See you next week!

Among other things, March 2020 changed my household’s food habits.

Before Covid, I often shopped at the Trader Joe’s across from my office on Market Street. On Monday nights, it was so packed and busy that the checkout line snaked through every aisle of the store. Half-browsing / half-queueing, I followed the emergent store protocol of getting on line straight away and adding items to my basket as I passed each section. On weekends, my husband Dan and I would stroll through Whole Foods, Mollie Stone’s or the farmer’s market, picking up whatever looked good that week.

As college students, neither of us especially enjoyed cooking but as adults, it’s grown on us. Over time, we were exposed to more delicious food and more approachable cooking education. My dad gave me Salt Fat Acid Heat as a gift. Dan got The Food Lab from a friend. My college roommate introduced us to the zany (and later, as we learned, problematic) world of the Bon Appétit Test Kitchen on YouTube. After we expanded our palates (I admit I arrived at the very basic “vegetables can be delicious, too” realization embarrassingly late) and learned the foundations, we started to actually enjoy our cooking routine.

Of course, Covid upended that routine. Going to the grocery store, previously a frequent and somewhat absent-minded activity, now meant preparing to wait in long lines outside and to risk exposing ourselves to the virus inside. We’d never used face masks before and we couldn’t find any available in stock, so we improvised with T-shirt rags. Instead of wandering over whenever we were out of something or going out to eat, we suddenly had to be intentional and strategic. And we became more acutely aware of just how much work all of it was.

The dance

What are we buying? What are we cooking? What haven’t we made in a long time? Where did we find that recipe? Who wrote it again? What did we say we would do differently next time? Does it take a long time to prepare? How many dishes will we dirty? Which stores will we need to go to? How much do the ingredients cost? If we buy the ingredients now, how long will they stay fresh? Will we have extra produce? What else can we make with that this week before it goes bad? How much should we make? Can we stretch it into leftovers for lunch? Will it be filling? Healthy? Appetizing to look at? Delicious? Delicious to both of us?

Will it be worth the effort?

We rinsed and repeated this exercise until we had a week’s worth of meals planned and grocery lists collated, then trudged off for our socially distanced Sunday shop.

Food is a delight

In forcing us to mealplan and shop more intentionally, Covid explicitly highlighted something for us that we had grown to implicitly believe. If we were going to go to all of the trouble and expense of planning, shopping for, cooking and cleaning up after a meal, it better look and taste really freaking good. If it was good enough to make again, we wanted to improve our technique to be able to make an even better and more delicious version of it next time.

I’m a technically-minded product designer and Dan is a design-minded software engineer. Like many people who build software for a living, our first inclination was to search for an existing app to solve our problem. We wanted something to ease the mental load of organizing our food life so we could focus on the most enjoyable parts: cooking and eating. And sure, we found some options out there. But none of them did all of the things we wanted them to do and none of them matched our mental model of how we thought it should all fit together. So we decided to DIY our own.

Fits and starts

Sometime during the first Covid winter, we started exploring prototypes. By January 2021, we giddily brought our very first version to the farmer’s market. It did work… but it was just okay. We accomplished our planning and shopping tasks, but it was clunky and cumbersome to use. Recipe importing was difficult and extracting accurate grocery lists was unreliable. We drafted plenty of solutions (both design and technical), but they were very complicated and time-intensive to implement. So we it put it down for a while.

Every year or so since then, we’d pick it up again. We’d tinker, try it, pause, and try it again. Our idea of what “it” even was evolved and then evolved some more. For a while, it seemed that the juice of our little side project just wasn’t worth the squeeze.

An app for people who love to cook

A lot has changed since we first started talking about this idea. Covid brought us back home to be closer to our families in New York. AI is eating the world and dominating all digital product discourse. We finally got a pretty decent MVP working for ourselves earlier this year. And as of May, I unexpectedly have a lot of time on my hands…

So, we’re building the app we want to exist. An app for people who love to cook. An app that will organize your food life with the same care and consideration that you put into the actual act of cooking. An app that will help you plan, and shop, and experiment, and tweak, and track, and expand your cooking repertoire. And, if I do my job right, an app that will be beautifully crafted and a pleasure to use.

If you’re interested in checking out our private beta or talking to me about your food life, I would love to chat with you.

Lunch

This week for lunch, I made my favorite summer meal: “caprese salad” pasta.

See you next week!

“Then one Sunday morning, before winter break, Abby’s boyfriend, Whitney, materialized at their kitchen table, reading something called ‘Of Grammatology’. When Madeleine asked what the book was about, she was given to understand by Whitney that the idea of a book being ‘about’ something was exactly what this book was against, and that, if it was ‘about’ anything, then it was about the need to stop thinking of books as being about things.”

― Jeffrey Eugenides, The Marriage Plot

Has this ever happened to you?

You check your messages and see that a long-lost friend or acquaintance has reached out. They have an exciting new idea for a company, an app or a business and they just need a liiiiiittle bit of specialized, unpaid labor from you to get started. They can’t pay you (yet!) but their idea is a surefire success. They will owe you big time, and as soon as this thing takes off, they will be riding off into the sunset with untold riches and they promise to carve off a slice for you.

Sitting at your desk, working your full-time job, you shake your head and laugh to yourself. “Congrats on the idea!”

Talk is cheap

I’ve always been a bit bored by the idea of ideas. They’re quick and easy to come by. Of course, I don’t believe in stealing, plagiarism or ripping anyone off. But people spend a lot of time debating idea credit and origin when having a truly original idea is very, very rare and not especially valuable in and of itself.

I’m much more interested in execution. What was your process? What tools did you use? Given these constraints, how did you actually break down the problem and solve it? How many at-bats did it take? What did you try, what did you learn, how did you reframe? What did attempts 3, 4, 5, and 6 look like? It’s why I liked being part of the design systems community so much: it wasn’t competitive and no one was precious about ideas. We were all trying to build roughly the same thing, just in different places.

So I’m sort of dreading the next phase of this project, which Very Much Involves Talking About “The Idea.” And to be fair, I think of it more as “Several Small Ideas Woven Together Well.” It does feel like important context... what we’re working on and why we’re passionate about it (we are passionate about it!). Plus, talking about the idea will also set the stage for all of the stuff I’m actually excited to share, which is Way Less About “The Idea” and Way More About All of The Fun New Ways to Build.

So where is this dread coming from? Why do I feel so small when I talk about it? I know I haven’t nailed the marketing pitch yet, the zingy one liner that sums the whole thing up neatly and cleanly. And the more I work on it, the thornier and more complex everything feels. As I uncover more complexity, the elegant solution I’m envisioning gets further and further away in my mind. It’s not good yet! It has the potential to be good, but it’s not good yet.

More binaries

Over the past couple of months, when I’ve shared what we’re working on to friends and family, I usually get one of two reactions:

1. Wow! That’s amazing! I can’t believe nobody has thought of that before! That sounds so useful!

2. Oh. Cool! Good for you. Is that ... a thing?

Both of these reactions make me uncomfortable.

The first one makes me uncomfortable because “The Idea” is not a new category of product. We didn’t think we had discovered a new problem that nobody else had ever noticed. We just had a pain point in our own lives, found the available options lacking, and started imagining a version that would work better for us. We have a specific perspective about why it’s hard and we think there is room to try to make something better.

The second one makes me uncomfortable because I spent so many years designing for 150+ million users at a major tech company. At that scale, the goal is to appeal to as many people as possible. So when people don’t immediately get it, doubt creeps in. Is this really a meaningful problem? Is our solution too niche? Too complicated? Have I explained it badly? Am I totally off-base?

This binary I’ve created for myself makes the stakes of simply talking about “The Idea” artificially high. If I describe it with any confidence, its feels like I’m taking credit for the whole category, because awareness of that category is low. If someone’s reaction makes me feel doubt, then I’m undermining my belief in the indie path that got me excited to pursue this project in the first place.

The algorithm is not my friend

In reality, we’ve actually been working on this idea on and off since 2021. Just as a little hobby app for ourselves, because we weren’t satisfied with anything else on the market. Until recently, it wasn’t even possible to create an account because we were the only ones using it. But now that I’ve turned it into my full-time job, I have a lot more time to dedicate to it. And my algorithm has caught up with me.

Many, many times over the last few months, I’ve gotten excited about a feature I’m building, only to be served an ad for an existing app that does the exact same thing. On the one hand: yay! The market and demand in this space is bigger than I thought. On the other, bigger, louder, hand: Is there still room for us in that space? If there are already so many players here, what’s the point?

In general, my mindset is constantly ping-ponging between “we can differentiate with better design!” and “badly designed products win all the time.”

Mindset practice

Mindset-wise, a few things are rising to the top for me this week:

• Ideas are fine, but truly great execution is still hard and still takes time

• The first version is just the first version

• Similar things can coexist. Not everything needs to be for everyone

• There is no single definition of “winning” a category or being the “best” product

• It’s okay to be new at things, or out of practice at old things

• Good design doesn’t speak for itself

That last one gives me deja vu. As a junior designer, I treated stakeholder questions as evidence that the design wasn’t good enough yet. I assumed there was a single “right” solution that, if uncovered, would sell itself to the project approver. Eventually, I learned that packaging the work was a crucial part of the job: that I needed to position my recommendations against the problem and tradeoffs with a compelling narrative to push it forward.

Somehow, now that I’m working on my own thing, I entirely forgot that lesson.

Lunch

This week for lunch, I tried to recreate my favorite brunch from Zazie in San Francisco: a mushroom / spinach scramble with toast, roasted potatoes, avocado and habanero hot sauce.

See you next week!

Working at a large tech company while AI crashed onto the scene was a strange experience. For the last couple of years, the drumbeat from the top was extremely clear:

• AI will fundamentally change the business

• AI will fundamentally change outcomes for customers

• AI will fundamentally change how we deliver products that enable those outcomes for customers

• We should all be using AI, all the time, for everything, to increase velocity

• And on and on and on...

None of this is terribly surprising. But the funny part, to me, was the huge gap between the stated mandate and operational reality. Transformation is easy to declare, but tricky to execute. The legal, security, finance and procurement departments all needed time to adapt. While they sorted out the logistics, people debated the merit and viability of using AI to transform their work. An adage emerged: “You won’t be replaced by AI. But you will be replaced by someone who knows how to use AI.”

As a design director leading an org of 17, I took this seriously. I didn’t want anyone on my teams to get replaced or left behind (Jules from the future side note: hahahaha). I was responsible for encouraging my org to increase their exposure to AI tooling and to model what experimentation and exploration could look like. I wanted to jump straight in to start building my own experience... but we didn’t yet have access.

Self-study

While I waited for the company to catch up, I decided to make headway on my own time. I’d long straddled the line between front-end development and product design, so it was fun for me to tinker on personal projects on nights and weekends with the extra set of hands AI provided. I built a tool to track my running progress, extracting Strava data and rearranging it into the exact configuration I wanted to see. I made Figma plugins to automate tedious aspects of personal design work I was playing around with. And then, during the 2025 winter break, I finally opened Claude Code and had my “oh, shit” moment.

It felt like a switch flipped.

Using a side project as a testing ground, I started building features that would have ordinarily required technical skill outside my grasp. After a couple of days, my ability to create increased by what seemed like a hundredfold. I was having a ton of fun, feeling both incredibly energized and incredibly rusty, deep in the weeds on product design details. I could squint at the future and see just how drastically these tools might change how designers approach their practice.

Having felt these possibilities, I dreaded going back to work in the new year, sitting in the same old meetings and working at the same old pace.

“The design process is dead”

In March, design leader went on ’s podcast to talk about her work at Anthropic. It’s a great episode and I recommend listening to the whole thing because Jenny goes into a lot of detail on how she sees the design process changing (or dying) with AI. But the part that stuck with me was her take on returning to IC work: that this particular moment calls for getting your hands dirty, picking up new hard skills, and building empathy for what it takes to evolve into an AI-native designer in this new era.

Her episode came up a lot in our design leadership meetings. We talked about the implications her conclusions might have for our team and how we, as leaders, could get closer to the work. Privately, I thought about my own experience during winter break and wondered if I should consider getting back on the IC track myself.

Sabbatical-ing

As it turns out, I didn’t have to wrestle with that question for long because I got laid off in May. The layoffs were bittersweet: after 9 years at one company, I was feeling burned out and ready for a break. Now, because of an “unbelieveable-to-everyone-in-my-life-who-doesn’t-work-in-tech” severance policy, I have the time and space to actually take a beat. While I’m planning to do. For at least the next six months.

There’s a lot I want to do with this time off. I want to travel, and become fluent in Portuguese, and run a marathon, and clicker train my cats, and relearn how to breathe (literally). I want to cook more and figure out how to feed myself in a sustainable and healthy way. I want to, for the rest of this sabbatical, never have a sad desk lunch.

And yet...

My severance check feels like a mini seed round burning a hole in my pocket. I’m curious, incredibly curious, whether all of the changes of this era might make it possible for me to work on my own stuff, winter break style, for the foreseeable future.

The Anti-Founder Founder Club

I’m lucky to have a few extremely talented founder friends, and I really admire their grit, vision and tenacity. But personally, I’ve never been attracted to entrepreneurship. Building your own product sounds fun, but raising money or starting a company to do it has never appealed to me.

So it’s very surprising to have arrived at the conclusion that building my own product is the natural next step. I’m hoping there’s room for a new kind of company: a tech small business that thrives with a team of 1 or 2. A sustainable, indie app where scaling to millions of users is not the goal.

It’s been hard and humbling already, but I can’t think of a better way to get back to being close to the work. In this next chapter, I’ll be closer to the work than I’ve ever been: designing everything from product flows to branding to emails, providing customer support and figuring out how to actually build a business. There’s are still a lot of blanks to fill in and I’m incredibly excited to be in Learning Mode rather than Founder Mode.

I plan to document that journey, once a week or so, for at least the next six months. While I’m working, I’m also going to hold myself accountable to my sabbatical cooking goal by sharing something I’ve made for lunch with each post. Maybe that’s an odd combo, but it makes perfect sense to me.

Holding many truths at once

On a personal note, I’m working on my ability to hold opposing truths at the same time. So here goes:

I’m happy I was laid off, and I’m still grieving the wonderful work community I was once a part of.

I feel incredibly grateful and privileged to have the resources to pursue this path, and I’m worried I’ll regret spending my time and severance this way if I’m not able to find a job if needed next year.

It feels amazing to have so much agency on how to work and what to work on, and I already miss working and bouncing ideas around with a team.

I’m spending more time building than I ever have, and I feel like I’m getting worse at the actual design part.

I’m nervous I won’t be able to pull it off, and I think I’ll regret it forever if I don’t try.

Lunch

This week for lunch, I tried to recreate the excellent Turkey, Bacon and Avocado sandwich from Heirloom Market at Comstock Ferre in Wethersfield, Connecticut.

See you next week!

Friday was my last official day at Credit Karma, two weeks shy of my ninth work anniversary. Back in May, I was laid off along with 3,000 others during Intuit's 17% reduction in force.

9 years is at least twice as long as I could have ever imagined staying at one job, but the thing that kept me there year after year was the community of people who joined, and more often than not, stayed. In what feels like a rarity in tech, I worked with many of my direct teammates for 5, 6, 7, 8+ years. It was an immense privilege to have the time and space to develop that kind of trust and shorthand with people. To be able to learn and grow together. To see our skills expand and flex as a team unit. To get multiple at-bats for our gnarliest problems.

Long tenures were the norm for a reason. Credit Karma really took care of its employees. During Covid, Credit Karma chose temporary paycuts and retraining those in non-essential roles instead of layoffs. Employee retention was strongly encouraged through internal mobility. Many people I worked with chose and were supported through transitions into entirely new roles or disciplines. It was not unusual for someone to experiment with their path, moving from the IC track to the management track and back again.

While I feel very grateful that I was able to experience it for as long as I did, I acutely feel the loss of the Credit Karma community and will be grieving it for some time as our paths now inevitably diverge. I'm telling myself that we'll all get the opportunity to work somewhere together again in the future. That being said, I know some kickass folks looking for their next role and I'd be thrilled to connect you.

As for me... I am incredibly excited and a little nervous to share what I'm up to next. More to come on that soon!