you are at bobd.tech

How I built in 2025

techaibuilding
Also published on: medium.com

Never in my career has the foundation of software development felt as fluid as it has in 2025. Karpathy summarizes it well in this tweet.

I’ve realized recently that I’m strong and in some cases thrive on incremental improvements. I like creating capabilities that are just enough, and then iterating on them until they’re great.

The flip side of this is that I often don’t spend enough time thinking big or for lack of a better term, thinking outside the box; to ensure the problem is actually worth solving, or that there isn’t a fundamentally different approach that could have a longer-lasting, perhaps 10× impact. I’d like to think I have this kind of vision, but my track record over the past few years doesn’t offer much evidence of it.

For me to be successful at that kind of thinking, I need goals, checkpoints, and a healthy amount of focus time to plan things out (scheduled fun anyone?!).

As is also my pattern, I use the downtime and symbolic reset of the new year to reflect and look for opportunities to improve. I don’t have regrets from this year, and this post isn’t an intention-setting piece for 2026. It’s a deeper look back. An attempt to document my flow, and some of the tones and harmonies that emerged from being so independently and deeply invested in building product throughout the year.

This is not intended as a flex by any means. I know I’m far better when I’m surrounded by smarter people, and I’m looking forward to a time not too far off when that’s the case. What follows is an open kimono for critique, a bit of guilty rabbit-holing, and an invitation for input that might help make things meaningfully better in 2026.

Here goes.

The Shape of my Work

For the past 2.5 years, I’ve been a solo developer working alongside my business partner, who handles sales and the broader business side. This setup has given me an immense amount of agency, freedom, learning, and joy.

The work I do on any given day generally falls into one of these buckets:

  • Customer learning and feedback: communication, synthesis, and understanding what customers actually need
  • Product roadmap: managing ambiguity, deciding what to do, what is worth doing, what comes next, and what does not
  • Building product software: “writing” code (more on this later), designing features, iterating, and occasionally dealing with toil
  • Operations: tallying time spent, writing updates, checkpoints with the team, and updates for customers and investors

While this setup offers a lot of freedom, it also means constantly shifting between very different modes of thinking.

I’ll get into each of these in more detail in the sections that follow.

Mechanics and Time-based Rhythms

I thrive on routine, and over the past year I’ve worked hard to maintain a stable one in the midst of a generally chaotic but wonderful home life. For a small team like ours, just two people with me as the only developer, this has meant settling into a steady weekly cadence for tasks, along with quarterly reflection and larger goal setting, plus broader product and investor updates.

Routine matters to me. Without it, I struggle to do deep work and tend to drift into reactive mode. With it, I’m calmer, more focused, and far more effective. That structure creates the conditions where meaningful progress can actually happen.

Specifically, on Monday mornings I:

  • Tally my hours worked in a large Google Doc, using a combination of my Mac screen time, GitHub PRs, and Google Calendar
  • List out accomplishments and deliveries from the previous week
  • Look ahead at the week to come and decide on the direction my work will take, usually a list of two to six outcomes I hope to deliver
  • All of this is captured in a Google Doc and shared in Slack

I’m reasonably happy with this weekly process. There is room for improvement in being more critical about what makes the list, spending more time deciding what truly matters, and reflecting more honestly on how well we delivered against the previous week’s goals.

With some customers, we also have weekly check-ins. These are incredibly valuable, and much of our week is shaped by the sharing and learning that comes out of those sessions.

On a quarterly basis, this process has evolved from a relatively heavy FigJam template into a simpler review of the previous quarter’s metrics and a clearer set of goals for the quarter ahead. Heft on this varies quarter to quarter, tending to start the year heavy and be pretty light by Q4.

Customer Learning

There isn’t a lot of tooling involved here, but a few pieces stand out.

  • Google Meet with recordings and Gemini enabled has been excellent. Gemini has come a long way, and the meeting summaries remove much of the need for me to take detailed notes, aside from specific callouts or follow-ups I want to capture myself.
  • For in-person meetings, I still record audio with voice memos, with consent, like a caveman. I then use the AssemblyAI API, still on the free tier, to generate a diarized transcript. From there, I feed it into ChatGPT to pull out summaries and action items. Even so, I often find myself going back to the raw recording to catch nuance, tone, or small details that matter more than I expect.
  • Linear is the product tracking tool of record around here, all bugs and improvements entered here with customer tags. More on this later.

Building Things

Boy, this has been quicksand this year.

I think the most useful way to frame this section is through an example of a medium-sized feature. I’ll use one I worked on toward the end of the year while it’s still fresh: enabling AI to update event fields automatically.

We already had AI in the event loop for status changes such as Booked, Not Booked, or Cancelled. But when a guest shifted something like party size from a fuzzy “around 20” to a more concrete “we’ll only be 17,” it became clear that automatically updating those event fields was both desirable and, frankly, expected by our customers.

Here’s what that work looked like in Linear:

Let’s walk through the process and the tools involved.

Foundation: Repo Structure & Architecture

The foundation of the platform and DX was laid well over a year ago. I initially started with separate frontend, backend, and tooling repositories, but quickly brought them together into a monorepo and haven’t looked back.

There are still fewer than ten packages, with the backend and two frontends living as top-level packages.

There is also a top-level docs folder that many of the agent .md files point to. This has effectively become the living documentation for the platform. It contains specs, important (non-PII) customer configuration fragments, as well as runbooks and postmortems for service incidents and operational processes.

This structure works well because it reduces cognitive overhead for me, and for the LLMs. I can reason about the system in one place, trace decisions across layers, and move between product, infrastructure, and logic without constantly reloading context. As the system has grown, that coherence has mattered more than almost anything else.

I use pnpm to manage packages, and everything is written in TypeScript. I moved from Jest to Vitest earlier this year simply because it’s better, and I use Playwright for stable end-to-end testing.

The service runs on AWS, which remains my default choice for new infrastructure. I try to introduce new technologies sparingly, since much of the foundation already exists. The stack today looks roughly like this:

  • React, Tailwind, and shadcn
  • Clerk for auth (dashboard only, guest facing is all anonymous)
  • Next.js
  • AWS CloudFront, API Gateway, Lambda
  • AWS DynamoDB
  • AWS CloudWatch, EventBridge, and related services

I initially chose GraphQL but moved away from it this year when it became clear that it wasn’t helping customers, developer experience, or the system overall. I replaced it with simple REST APIs using shared Zod types in a package consumed by both the frontend and backend. This package originally lived as a local npm package that I watched via the CLI, but the iteration lag quickly became frustrating. Switching to a simple ../../packages/shared alias ended up being faster and easier to work with.

For deployment, everything is built on a CDK, CodePipeline and CodeBuild foundation. I invested in this early because I carry a lot of CI/CD trauma and wanted continuous deployment and clean environment separation to “just work.” Today, that mostly holds true, but there is still significant room for improvement. End-to-end production deploys currently take around 35 to 45 minutes, which is far from ideal 😭. The cost of this is not just time, but momentum. Slow deploys subtly discourage iteration and make even small changes feel heavier than they should.

All of the above has what I’d like to think of as a strong security foundation as well; clear boundaries, clear access rights, limited blast radii, and great observability.

While I can deploy individual services or targeted changes more quickly, the full pipeline still shapes how and when I take on new capability.

Each new GitHub branch is set up to deploy its own isolated stack. Because of the cost and overhead involved, I do this sparingly and tend to batch smaller feature changes onto existing branches. This is another area with a lot of potential for improvement.

Design and Thinking

Most features start with my whiteboard, which is still the single best tool I have for kicking off any moderately sized piece of work. I use it to piece together system intersection points, and reason about where and how new logic should live. Using a whiteboard with Expo markers still works best for me. I have a 4×6 board right next to my desk, and it often looks as scattered as my brain. But when I get a moment to clear it off and start fresh, the resulting clarity of work is the delightful and expected outcome.

Once I feel I’ve built enough of a mental scaffold, the next tool is often ChatGPT. With its basic memory of what I do and how I work, I like having that “clear-ish” slate to talk through details and edge cases in feature design. Whether I’m thinking through data structures, deciding between direct or event-based processing, or pressure-testing user expectations, it plays a critical role. When I’m mostly done, I drop in my spec or ADR template and ask it to produce a structured version of what we’ve discussed.

From there, I move into my IDE, typically Cursor in Auto or Opus mode. I drop the new spec into my specs folder, with each one numbered and named, for example 56_llm_event_field_updates.md. I pull up a chat and ask to have a read and build context, amend the data structures and references, but NOT write any code, always a challenge! It’s at this stage I do as thorough as i think necessary review of the data model, any schema changes needed, events, REST apis, and customer interfaces in play.

This feature was mostly event based, working in the background on incoming emails, and then making database changes autonomously. However, making sure there was enough user-visible signal of the value and reality was important. Existing half-baked schema changes where i foresaw this capability needed to be unwound and redone, but luckily due to no heavy UI-needs no indexing changes were necessary.

I will touch on UI building a bit. Many features DO start here, when its clear the primary value delivery is to customer eyeballs. These features usually run through a whiteboard to v0 workflow to get a feel for what they’ll look like, and often the initial draft of the actual code is made by v0 and pulled straight into my code base. I find it really important though when building UI to ensure you have a clear idea of what you want, otherwise you’ll end up with very typical outputs and extra features that your customers likely won’t use (and if they won’t use it, its a big net-negative).

Development

With the spec done to about 80% it was time to start writing code. I would have the work phased out from data, accessors, and with-aws and/or with-llm tests, and usually begin by having cursor write all those out. This first crack would usually take 10–15 minutes as I’d often realize gaps or misses, and then anoth 20–30 minutes running the tests, tweaking things, and making things were good enough for the next phase.

For this work I was already a lot of the way there in terms of prompt design, but work needed to be done on the inputs, outputs, and evals. I believe it was at least another half day on this part — I had decided my main email classify prompt would take in all context necessary to produce an updated set of actions, and some of these actions would be to adjust event fields. I had also previously decided the level of agency i wanted my agents to have was at the field / tool level (could write a whole post on this!) so build out the tools for the agent to adjust fields and add enough user-facing context so users in the dashboard have the background as to why various field adjustments were made.

Once I was confident enough in the data and prompt side, it was time to basically complete the feature by building out the APIs and frontend. This would usually happen in 1 or 1.5 shots, with the latter fraction being areas simply missed in the spec. There is a lot of feel here regarding how much design upfront is needed, for this feature and many others I felt I needed to have it run in production and see what it would/will do as quickly as possible as opposed to polish up the prompt and outputs on canned or historical data.

I’d then deploy the backend to my branch environment, test the frontend locally until it looked and felt good enough.

Deployment, Monitoring and Iteration

Given the risks of this feature making some changes to actual production data autonomously, it absolutely behooved a monitoring iteration phase, as many of my features do. For me this usually meant building it all out but then with a failsafe “don’t commit, just notify” on what would be done. I use Slack heavily for this purpose, often isolating specific channels for feature work. This way as customers do things in production I can monitor specific actions that would be taken and really get a feel if the data is right, edge cases not foreseen, etc.. in the future, building out a better pipeline for simply working on historical data will make a lot more sense from a delivery and effort standpoint, something that is really only now possible based on the amount of data our service has built up.

I monitored this feature for about a hundred triggers, made a few tweaks, and then engaged it. It was working reasonably well and was relatively low risk. The UI was designed to be super clear in terms of explaining when and why various fields had changed so I thought it best to get the value out and then get real feedback from users on what they thought about it (I already had some data to indicate that some customers believed the system already did this :upsidedown:).

When it’s engaged, i still used slack, but had the engagement of the capability conditional on high confidence changes only, and then could review those in Slack as they occurred.

Task Parallelism

Worth noting is that while all of the above feature development was happening, I was often also working on at least one other, less cognitively heavy task in another git worktree and Cursor window. These would occasionally be kicked off via a Linear Cursor agent, but I haven’t yet gotten autonomous agents working well in my environment. That’s mostly due to the scope and complexity of building and deploying independent environments, a lack of confidence, and the agents’ current inability to test things comprehensively (I framed this as an agent’s inability, but conversely could be viewed as a platform testability limitation :halo:). Coming back to the Karpathy tweet, this feels like a critically important area to invest more time in as the product and team grow.

Parallel work is chosen carefully, ideally in non-overlapping areas like infrastructure, dependencies, or isolated frontend components. Over time, I hope this distinction matters less.

Fast-forwarding a bit, this often means I’m reviewing and merging multiple PRs at the same time. I try to group these to minimize deploys to production, partly due to cost, but mostly because of customer impact. There are still a few quirks around redeploys that affect dashboard users, though nothing that impacts actual service delivery. Again, this minor balk is one of toil and I’d surely like to minimize in the future.

Feature Wrap up

Usually, once a feature reached a monitoring phase, I’d move it to In Review in Linear. When it was fully enabled, it would move to Done, with follow-up sub-tasks spun off if there were additional checkpoints I wanted to hit. I’d then share an update in Slack to signal that it had shipped, write a short blurb in the weekly update, and record a brief internal video or screenshot showing what it looked like in practice.

Full disclosure, I did not include a demo video for this feature, but arguably should have! Here is a quick snap of what all of this can look like in an individual inquiry/event.

Tool-ography

I was initially thinking I’d do a full dump of all tools I use in my workflow, why, how useful, how much they can be improved, etc.. well, that’s not going to happen! It was too vast and likely not useful. Instead, I’ll focus on a few that are worthy of praise or review for reasons that will hopefully be self-evident.

Each tool is scored across three dimensions:

Value — How much leverage, clarity, or momentum the tool gives me.
Opportunity — How much unrealized potential I think still exists, either in the tool itself or in how I’m using it. This could apply to the area itself, and a possible outcome here is scrapping the tool.
Cost — The total cost, including money, time, attention, and cognitive overhead.

Each category is scored out of three:

  • ⭐ = meaningful
  • ⭐⭐ = strong
  • ⭐⭐⭐ = foundational
  • 💲 = minimal, possibly zero
  • 💲💲 = noticeable
  • 💲💲💲 = significant

Linear

When i first signed up by myself well over a year ago i assumed free tier would be fine. I quickly surpassed the issue limit for free and have been a happy paying customer ever since. At ~140 a year its a steal imo. I don’t know how much of this is malaise with how Jira worked and how Linear just works, but its great at capturing ideas quickly, and working through weekly progress. Prioritization could be much improved but i’m sure i have lots i could improve on here.

Value: 🌟🌟
Linear is foundational place to capture roadmap, but arguably I could live without it

Opportunity: 🌟🌟
I find simple sorting and prioritizing is not intuitive so while there should be a simple “here are the priorities” view, I still have a long way to go to have this always ready and up to date

Cost: 💲💲
At 140 a year this is a drop in the pan, but still not as cheap as free

Cursor, IDEs, and Coding Agents

It’s interesting to think back on how sticky VS Code was in the beginning. I had heard about Cursor and a few other IDEs I can barely remember now, but it took a fair amount of inertia to move away from VS Code. I’d give Cursor a try, but basic things like different default layouts and the discomfort that came with them would push me back. Once I stuck around long enough to understand the power of the tab, though, I was hooked. It was a real “aha” moment, and I’ve stayed through the ups and downs ever since.

When it comes to auto mode versus choosing a specific model, I usually stick with auto until I start seeing undesirable results, either in quality or latency. Toward the end of the year, latency became the more common issue. A classic example of “don’t be frustrated, solve the problem” is when you’ve maxed out your parallel workstreams and still find yourself waiting on meaningful results. In those moments, switching models is often the quickest way to regain momentum.

Given the parallel nature of my work, I usually keep two or three worktrees open across different Cursor windows, each with its own workspace theme. I’ll often use other IDEs for side projects as well, most commonly Zed. I really love Zed, and I could see myself moving to it long-term if I can get a similar workflow going, possibly with Claude Code if its built-in context handling improves enough.

This is probably the area most likely to change in 2026. I can’t imagine reviewing code full-time outside of an IDE, so parallel workstreams will likely remain important. That said, I can see things shifting toward a more pull–review–tweak–push–instruct loop, especially if agents aren’t running locally. And maybe, by the end of 2026, with an M5 Max or Ultra, at least one of those agents will be running locally.

Value: ⭐⭐⭐
This is core to how I work day to day. Without a strong IDE for development and review, as well as good agent support, I wouldn’t be able to build.

Opportunity: ⭐⭐⭐
I group in all the agent-esque possible improvements here, especially around agent autonomy, local execution, and smoother context sharing across tasks.

Cost: 💲💲
The financial cost is noticeable but reasonable. The bigger cost is cognitive overhead, which I’m increasingly conscious of managing. I’m still on the standard+usage based plans, but could see a Claude or Cursor MAX plan in my very near future.

AWS

I have a long history with AWS and naturally chose it as the backdrop for the service from day one. There’s a guilty pleasure in spinning up services and instantly getting elasticity and scale in one of the most battle-tested environments imaginable. I know their support process, their quirks, and their depth, and I know enough to know that while almost every service imaginable exists on AWS, many of them are not best of breed.

So how do I feel about it? I love the control, its absolutely the right elevation for me — many people would prefer to run a server on DigitalOcean and deal with scale when it comes, and avoid the cloud costs altogether. Good for you, that’s not me. I didn’t think that was the product needed at the time, nor is it now. I need the safety net of scale, support, and capability, and I’m happy to pay cloud costs for that, even if those costs have come under fire from the 37signals crowd in recent years.

That said, some parts are genuinely painful. A simple AI workflow, like running a chatbot on Lambda, still feels surprisingly awkward. API Gateway’s lack of streaming support makes certain things feel like the dark ages. But there are bright spots too, and DynamoDB, once you get the hang of it, is genuinely excellent. Overall, I mostly love AWS and appreciate its generally customer-centric mindset.

But some of it, ya, is a complex pain. For example, a simple AI workflow, running a chatbot on Lambda, is still really wonky in that APIGW does not support streaming, making it feel like the dark ages. But there are bright spots too. DynamoDB, once you get the hang of it, is genuinely excellent. SES for email gives you an insane level of control, which I ended up really relying upon. Overall, I mostly love AWS and appreciate its generally customer-centric mindset.

Value: ⭐⭐⭐
The control, scale, and breadth of capability are exactly what I need for this product.

Opportunity: ⭐⭐
There’s still a lot I’m not using, Bedrock being the obvious example, and plenty of room to simplify and modernize parts of the stack.

Cost: 💲💲
I’ve been on the AWS credit gravy train for a while, but that’s coming to an end very soon. Even so, at under roughly $200 a month for some admittedly irresponsible service usage, I’m completely fine with it. CodePipeline and CodeBuild are the biggest cost and toil offenders, but I’m not convinced other tools would have meaningfully better power-to-effort ratios.

aws-vault

aws-vault is a simple command-line tool for operating as a specific AWS account and principal. With a setup like mine, spanning multiple AWS accounts, it’s essential for safely running integration tests or, in some cases, operating directly on production data (index backfills, anyone?).

Value: ⭐⭐
Very valuable. Without it, working safely across environments would be at least more annoying and more error-prone.

Opportunity: ⭐
It does exactly what it needs to do. There’s not much room or need for expansion here. It looks like it might be mostly an abandoned OSS tool at this point so I may need to adapt, but has worked perfectly up til now so I’ll stick with it until it doesn’t.

Cost: 💲
Free, likely forever, with very little cognitive or operational overhead.

Slack

I have a mostly love relationship with Slack, with just a sprinkle of hate mixed in. I’ve been a long-time user, but this is the first time I’ve used it with such a small team. Its primary role for me is as an event sink: a place where the system sends updates about interesting activity, and where the wider team can stay aware of what’s happening.

I have roughly six activity-focused channels covering things like frontend and PostHog events, user activity, service activity, and a dedicated activity-urgent channel for warnings or errors that need attention. This structure helps keep noise manageable while still surfacing what matters.

Slack is also how our small two- to three-person team communicates day to day. The “sprinkle of hate” mostly comes from the freemium model. I’m looking forward to growing the team and becoming a paid customer, because we absolutely get value out of it. As with most tools, the real value comes from norms and shared understanding. When new people join, patience and guidance go a long way in helping them use Slack in a healthy, sustainable way.

Value: ⭐⭐
Slack is central to how observability is done in our system, as well as team communication. Super valuable, but somehow doesn’t feel essential.

Opportunity: ⭐
I’m happy to just stick with Slack more or less as is, keep expanding it’s use for observability and communication. I don’t see a lot of reason to look elsewhere.

Cost: 💲💲
The cost is still free, but will soon become a pretty big monthly build as our team grows and we move to the paid plan for access to historical data.

Github + Git

I’d be remiss if I didn’t mention GitHub. It’s mostly ambient at this point, but clearly an essential and de facto part of modern development. Much like the electrical grid, it’s something you rarely think about until it’s not there. Having such a stable and reliable foundation that rarely demands attention is a quiet luxury.

I’d rate my git-foo at around a 5 out of 10. It’s more than enough to get things done, and I don’t feel much pressure to deepen it further at this point in my career. It works, it’s predictable, and it stays out of the way, which is exactly what I want.

Value: ⭐⭐⭐
Completely foundational. Everything else depends on it, even if it fades into the background most of the time.

Opportunity: ⭐
There’s always more depth to Git, but I don’t feel a strong need to go there.

Cost: 💲
Essentially free, with very little ongoing cognitive or operational overhead.

PostHog

The first observability tool I integrated was a now-defunct product called Flywheel. When they announced they were sunsetting, PostHog was the obvious next choice, especially since I’d used it successfully on other projects. It was a breeze to integrate, and I was immediately blown away by the fidelity of the session recordings and the flexibility of their usage-based pricing.

PostHog has been incredibly valuable in shaping the product. Being able to see exactly what users are doing as they interact with our guest-facing widgets has revealed patterns and friction that would have been impossible to spot otherwise. A lot of what now feels like a reliable, get-out-of-the-way UX is a direct result of those insights.

It’s not perfect, particularly around service reliability and event lag, but it’s still worth its weight in gold. We’re mostly on the free tier for now, though I’m happy to pay as usage grows. Interestingly, PostHog includes a number of customer-friendly features that reduce data volume and cost, which arguably work against their own revenue. Still, it all makes sense in context. As their AI capabilities mature and can analyze more data than a human ever could, the potential for insight feels enormous. Like all logging and behavioral data, though, it only matters if you actually look at it, which I make a point to do weekly.

Value: ⭐⭐⭐
Deeply informative. It consistently surfaces insights that materially shape product decisions.

Opportunity: ⭐⭐
Lots of features to explore, and plenty of upside as their AI tooling matures, but for the most part delivers well on what we need it to do.

Cost: 💲
Currently very reasonable and mostly free, especially given the depth of insight it provides.

langsmith

For LLM observability, the first tool I used was Helicone. After running into issues twice during library upgrades and feeling increasingly misaligned with their roadmap, I switched to LangSmith and have been mostly happy ever since.

LangChain has always given off a slightly janky, unpolished vibe to me, and LangSmith is no exception. That said, it’s been reliably functional over the past year. I now generate enough volume to be a usage-based paying customer, and I’m comfortable with that. Still, I’m cautious about coupling too deeply to a tool like this and tend to avoid adopting advanced features unless they’re clearly necessary for the product.

There’s a lot of competition in this space, and consolidation feels inevitable, whether that comes from AWS or from tools I’m already using, like PostHog. For now, LangSmith does the job well enough, and that’s often exactly what I need.

Value: ⭐⭐
It provides meaningful visibility into LLM behavior and has become a useful part of my debugging and evaluation workflow.

Opportunity: ⭐⭐
The feature set here is really growing and I can see lots of opportunity to explore this, the right opportunity just hasn’t come up yet. And again, seriously concerned about coupling.

Cost: 💲
Usage-based pricing feels fair for now, though it’s something I keep an eye on as volume increases.

NextJS

There are currently two (soon to be three) frontends for Paloma, each backed by its own Next.js instance. I use cdk-nextjs to deploy these on AWS, which gives me a fairly high degree of control. The Next.js layer doesn’t have direct access to DynamoDB. It’s responsible for rendering the frontend and, when needed, making server-side requests to backend REST APIs using a JWT provided by our auth service, Clerk.

The security vulnerabilities that surfaced late in 2025 forced me to seriously question why I’m using Next.js at all. I spent a fair amount of time going back and forth on the value of server-side rendering and the way I’ve structured things. In many ways, it feels like an anti-pattern that’s overdue for a rethink. I originally believed the caching benefits of the server-side layer would be significant, but in practice that hasn’t really been true except in a few narrow cases. When it’s not pulling its weight, it mostly adds complexity without much upside.

Running this layer on Lambda adds yet another layer of cost and complexity, especially in build times, which have become meaningfully slower than I’d like. In hindsight, some of this feels obvious. At the same time, Next.js does provide a lot of value in terms of bundling, conventions, and overall developer experience, even if that value is easy to underestimate until it’s gone. If I was (and may consider) deploying directly via Vercel, and if that was the case the value would be a lot more apparent.

Value: ⭐
It provides structure and convenience, but not as much leverage as I once expected.

Opportunity: ⭐⭐⭐
There’s a lot of room to rethink how this layer works, by either trashing entirely or heavily optimizing.

Cost: 💲💲💲
Free to use, but build times, regular upgrades, operational complexity, and cognitive overhead all add up here more than I’d like.

Figma

Much of the original UI for the product was designed in Figma, but I don’t think I’ve opened it in design mode in over a year. For the kind of work I’m doing now, it’s often too slow and too detailed for what’s needed. That may change in the future as design systems mature or consistency becomes more important, but for now it rarely sits in my daily flow.

I’m genuinely excited by what Figma Make promises, and I’ve heard great things from others using it. That said, the initial paywall was enough to slow me down, and I haven’t gone back to explore it further yet.

Value: ⭐
Historically important and still useful, but no longer necessary for how I build day to day.

Opportunity: ⭐
Maybe with Figma Make, but as a design tool I can’t see use of it expanding much until we need a really well defined design system.

Cost: 💲
Still free tier so all good.

v0

I use v0 as my primary mockup and early UI exploration tool. I’ll usually start with requirement clarification, then move into v0 to generate drafts that explore tradeoffs and tensions, often by asking for “3–5 versions” of a concept. I’ll sometimes even ask it to reflect those tensions directly in the UI itself.

Once I have a direction, I’ll fork the result into something more streamlined and make small refinements. When things start to feel solid, I’ll often bring real data structures from my codebase into v0 and ask it to adapt the UI accordingly. That usually gets me close enough that I can pull the output directly into my IDE and finish the work there.

Value: ⭐⭐⭐
This is one of the fastest ways I’ve found to move from idea to something tangible, especially for UI-heavy work.

Opportunity: ⭐⭐
There’s still room to tighten the handoff between design and implementation, but it’s already doing a lot of heavy lifting.

Cost: 💲💲
At around $20 a month, it’s an easy yes given the time it saves and the clarity it provides, but often sits idle when I’m not doing UI so feels a bit wasteful.

Chrome

Where would I be without Chrome. Where would the web be!

Building web apps with DevTools, multiple profiles, tabs, and extensions would be nearly impossible without it. I also use Dia and Safari alongside Chrome to maintain different contexts and mental separation depending on what I’m working on.

Value: ⭐⭐⭐
Absolutely foundational when building a web app.

Opportunity: ⭐⭐
There’s always room to improve how I approach web development, particularly through better use of tools like Playwright or visual agents to support testing across small and large features.

Cost: 💲
Only costly in terms of number of tabs and memory 📈

Notable Mentions

Obsidian — used for note-taking and life tracking, more for personal than work. File over app, always and forever 🫡

Perplexity — I used this more toward the beginning of the year for quick web search, but now only reach for it when I need a truly webby second opinion.

BrowserStack — an expensive but necessary tool if you ever have browser-specific bugs on a particular platform that you can’t easily access (Edge!).

Framer — our website is hosted on Framer, mostly due to our initial designer’s choice. No real regrets here, and once we have a marketing person onboard, having them able to make edits will be helpful. That said, I’d still prefer the landing page to live fully in code.

ScreenStudio — tool of choice for recording product-use videos. I’m on the yearly plan and mostly happy.

ElevenLabs — used for voice agent customer data gathering and likely to become a deeper part of the product workflow as onboarding at scale ramps up.

LinkedIn — a necessary evil. I use it to publish things like this and keep up with the broader business ecosystem.

Medium — not at all essential. I plan to sunset my use of this now mega-cringe service this year.

Where to Improve

The ability to knock off product improvements faster and more concurrently is the opportunity area by far. The tools are all in front of us; it’s a matter of experimenting more, thinking bigger, and iterating.

I view the modern software stack like an iceberg, with customer-visible capability above the water and AI plus backend systems below it.

AI, in particular, feels a bit like a malignant tumor that could easily occupy the whole ocean if left unchecked. There’s so much potential value to unlock, but it’s up to the engineering side to build the scaffolding to measure, react, and ensure that value is actually delivered. I can’t wait to do more here and get to a point where that value truly emerges, while keeping in mind that, depending on what you’re building, customer attention is the scarcest resource. Workflow automation is mostly where the leverage lives, and communicating that value clearly, both to customers and prospects, is essential if a product is going to reach its full potential rather than get squeezed out by competition.

In referencing Karpathy, this tweet is a great summary of the many areas that still need improvement, and I expect to come back to it often over the next year.

Closing Thoughts

So much to do. I can’t wait to get started.

We started Paloma to make it easier for people to plan private parties and events. Over time, that evolved into helping the venues and teams who host those gatherings operate more smoothly. It’s a deeply human problem space, hospitality always is, where people need to be in the loop, but where technology can help ensure those humans show up with better context, better tools, and better attention to detail at every moment that matters.

Oh, and we’ll be hiring soon. Founding developer, designer, and marketing roles to start, with customer success and other GTM roles to follow. I can’t wait to build with people who are as excited as I am on the technical side, but even more excited about building something real, with great people, that real people actually use and are quietly delighted by every day. A product that helps them gather in real life.

If you think you might be a fit in the weeks before formal job descriptions are published, feel free to reach out at [bob@palomaparties.com](mailto:bob@palomaparties.com).

I’d also love to hear what you think of any of the above. If something smells a bit funny, I’d genuinely appreciate hearing how your experience compares.

Yes, I used AI, ChatGPT specifically, to help me edit and brainstorm this piece. You’re welcome.