I'm embarrassed to say but over the last few months I've gotten in the habit of checking my GitHub contribution graph. And I can glibly say I've just had my biggest week yet.

Lots of recent talk about LOC (lines of code) as the (bad) measure of productivity. $500k engineers with $250k token budgets.

I keep circling around a few concepts — if there were two artists, one creates 100 paintings, and another 1, you wouldn't naturally assume the former was better.

We're reaching a point where you can almost build at the speed of thinking. But you certainly can't validate at the speed of thinking.

I recently bumped up to the 20x Claude Max plan, and still almost hit my budget for the first week. I'm getting used to handing off bigger and bigger tasks — it really shouldn't surprise anyone with product experience, but if you add horsepower, expectations increase, often at a greater rate than the horsepower added.

Are you a looper, or are you a crafter? Can you be both?

Like "number of paintings produced", we know LOC isn't a perfect measurement — but it is something, and its easy to quantify.

Moving up the "useful metric" ladder, we usually talk about the amount of value delivered as a better unit of measurement for software. Assuming our PM process with all its checks and balances is spot on, when that feature checklist wraps up, it's done done docs and all, validated value is in the market.

But then there is also adoption. Is that thing being used?

I view how these things are changing like this — and note I'm thinking mostly non gigantic B2B here:

Output is exponentially increasing, duh.

Speed of validation is pretty much flat, depending how you look at it. If you've got eyeballs and are able to run a/b or similar autonomously, good for you — but on net new products I'd view this as harder to know if you'll actually get paying customers.

And finally, our ability to get adoption, I'd argue is actually going down. There is so much more product out there, and the share of adoption you should expect to get is going down.

Not only that, there is definitely product, tech, AI fatigue and distrust thats dragging it down further. In some circles at least.

The more abundant supply is, the more scarce demand is. Distribution becomes the moat, yada yada.

There is another angle to building at this scale which I find interesting; in a more traditional org you'd be lucky to spend 20% of your time on tech debt or side quests. Now you can fling them out and have agents loop on them to your hearts content.

If you follow the fat skills model, and minus your CRUD and the hardened business value (which is only the repeated optimizations on prompts), so much of the time you're making optimization decisions, forcing a bake in of a lesson learning through an agentic exchange. And as we get better those basic lessons get baked in automatically, and we keep raising the bar.

You as the product leader need to be the one standing at the gate making quality and taste decisions, and knowing if all those PRs are net good, or net bad. It's a lot! In my case, a few PRs have gotten through that have affected customers (in minor yet surprising ways) and it's easy to become a tad gun shy about the absolute frenzy your agents are having in your codebase.

The size of task I can bite off is growing over time. But it still takes a long time to push out a boulder sized feature — and while that is ongoing, dozens of other things big and small are getting picked up, started, stalled, shipped. Even though horsepower has exploded, so has multitasking due to the latency on the responses and validation.

The same thing occurs with new staff of course, its just a bit more surprising when it's software. My feeling is creatives will yearn for tools that reduce the latency to let them continue to be in the loop and course correct frequently, essentially applying their craft and taste as often as possible, and factory workers and infantry will be perfectly content pushing their LOC to the moon.

I'm excited to get back to a point where I can essentially think it, and see the result. Get back to single tasking. Be actively creating the thing. And sure, I could paint the painting now but… we have some pretty big brushes we gotta test out first.

Pete Steinberger uses a VISION.md. Checking his commit graph he's had days with ~3k contributions in a single day.

Differnet projects. Different customers. Know what you're doing, who it's for, what's important to them. Serve them as best you can. Different strokes.

The recent piece on self replicating software is fascinating.

To me its a bit of a race to the bottom in terms of an optimization function that mindlessly rewards satisfying a need, delivering just in time solutions to problems barely articulated, vs purpose built software that has been vetted and thoughtfully designed by a human.

It reminds a little of the SEO game over the last 20 years. I have in the past piously scoffed at hearing of businesses spun up opportunistically on keyword gaps, google trends, or people mentioning problems on reddit. Building up website slop (before we called it that) just to get traffic to mine clicks. Essentially the web and it's ad economy (which in a lot of ways is it's business model).

It's not all that different from the Greg Isenberg kind of problem mining — amazing schemes to find opportunities but… for a business to be durable and trustworthy, it takes heart, passion, and vision. The inception story matters a lot too, at least to me.

In the age of software factories, the craftsmen become the nudgers, they become the filters on the content being created.

We still seek out humans with taste. Humans want human judgement, to suggest and advocate for things that might be of some benefit. Or now, we all can build for ourselves.

The craft is in some way becoming the validation and curation of an endless sea of code.

Is this agent fatigue? Or is this… just what you do when you run out of your weekly token budget, knowing it will reset by Monday night! Apologies for the lack of references, but I mostly wrote this whole damn thing (I did bounce around the ideas with Claude yesterday, but now I've REALLY borked my budget, and don't want to miss the momentum and let it rot). Most references can be found by searching X and Threads, like em or love em it is where the latest stuff bubbles up.

Apologies for the lack of editing, I'm sure there are some wrinkles. I do miss writing. But building software right now has never been more fun, and for this I am grateful, and curious. And thanks for reading!! Onwards!!

Moments ago, I pulled out a blue expo whiteboard marker, and wrote up a nice tidy todo list on my 4' x 6' whiteboard. A tiny section of an otherwise large and chaotic sea of scribbles. All the things I must get done today.

I do this most days. But lately, completion rates have tanked.

It is just too damn easy to be productive. With tools like Claude Code, I'm never more than a few minutes before an idea or feature or improvement comes to life. As quick as I can think it, I can get started on it, and feel like I'm 80% there.

But then, often enough, I end up with a handful of giant PRs, unclear GTM or "how is my customer actually going to discover this value" strategy, and the unsexy items on my todo list are still sitting there.

How did this happen? Well, let's just call it buildcrastination.

I have made a habit of always returning to that familiar Claude "chime" when it's done a task — and I've become more intentional about declaring which zed window is the one that is housing my most important Claude task.

But the strategic reach out, the updating the TOS, the proactive customer outreach — often times, those things require my attention, my pen, and my time more than that next feature or fix. The hard part now is doing the thing Claude can't do for you.

Anyways, I'm reminded about John Zeratsky's "One Big Thing" method (from Make Time). I'm not actually sure if my version of it has morphed, but the idea I have retained is simple; write down the one big thing you must accomplish today. You can jot down a few other things that are nice to have, but the framing is, if I don't get anything else done, what MUST I get done? What will I be stressed about if I don't get done? Out of all the task lists and strategies for efficiency I've gone through, this one has stuck with me through thick and thin. Simple, analog, easy to measure, and it works.

And I'm writing this, which is perhaps write-crastination, to reinforce and remember this. Now… back to setting up a laptop for a new hire 😊

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.

He had recently released an album called Benji, which was featured in Pitchfork to high acclaim. That’s how I really got to know him.

Also notable that year, it was, as far as I’m concerned, the peak of Ottawa Folk Fest itself. Neutral Milk Hotel also played. I got to see them as a full band for the first and only time, and it was a dream come true; it lived up to all expectations.

Anyway, back to Sun Kil Moon. He came across as having quite a personality on stage. He was making fun of various people in the crowd and generally being rather belligerent. Still, an extremely talented musician; a wildly prolific storyteller. It was an incredibly engaging show.

He mentioned where he was going after the set, and a friend of mine, a much bigger fan of Mark than I was, planned to go and meet him. My friend was an artist and had even brought a painting to show one of his idols. He did get to meet him, and was basically ridiculed.

Mark has a long history of being a jerk; of not caring what anyone thinks. He even writes about it in his songs. He’s clearly troubled, and sure enough, probably had a hard life.

As I age it becomes clearer, you are what you consume. To some degree, you become the people you spend time with.

This applies widely, including to the bands you listen to. What makes a “guilty pleasure” song or band? That feeling of guilt when you listen to it, it’s knowing that maybe it’s not the best thing for you. Maybe you’re wallowing a bit, maybe you’re grieving in your own way, and that’s okay some of the time. But if you aspire to be more, maybe don’t listen to people you wouldn’t aspire to.

That’s exactly how I came to look at Sun Kil Moon. He’s a jerk. He’s an asshole. I have contempt for him, at least based on what he’s shown to the world, which he controls completely. I wouldn’t want my family or friends spending any time around him. And honestly, I wouldn’t want to be associated with anyone who celebrates that behavior.

Maybe he uplifts people musically; maybe he inspires. But from a humanity perspective, it’s in the opposite direction of anywhere I’d want to go.

I’ve been experimenting a lot with this recently. Multiple agents helping me tackle up to 4 tasks at once across different git worktrees.

For instance, yesterday I was working on:

• Adding in fallback logic for associating emails with incomplete References headers with the correct inquiry, and sending debug slack notifications with diagnostics
• Updating the UI around our Inquiry’s Date question to help narrow the guest to specific available dates when availability is low, to reduce email back and forths
• Sending de-normalized event statuses on usage records when the status changes, to improve analytics and exclude certain events
• Adding playwright to do full E2E tests to my CDK pipeline (pulled out the big gun Claude Code for this one 👊🏼)

Feels like having a small team working in parallel. Obviously, there are zillions of differences between this and a team, but one gigantic one I want to harp on;

Those agents have no responsibility for what they’re writing.

When you’re a lead or a senior on a team, code review becomes in many cases your primary responsibility.

But for any well-functioning team I’ve been a part of, the individuals creating the PRs are the ones that continue to own their changes. The reviewer will do their best, but generally could never own all the context associated with the area that is being changed to think of “all the things”. The checklists help embody the due diligence required to ensure this, but the biggest guarantee is the experience and reputation of that developer.

This is obviously tweaked a bit for open source. And will continue to be tweaked as devs now put forward 100% AI coded work (and be praised for it), but that responsibility piece is still real.

And fundamentally, this is a context problem. For developers and code reviewers, the reason why that responsibility is important is you trust the author to have held the codebase’s context in their head to the best of their known ability, and therefore trust the quality of their work (in conjunction with the testing methodology, as we know this is impossible in the absolute sense).

With LLMs, it is also a context problem, one that they’re getting better and better at solving at a rate that staggeringly better than humans ever could. So when you see an AI produce a silly result working on one of your 4 worktrees, you _can_ say “silly Claude, how could you,” but ultimately, the better way to think about this is how you could have fed it more complete context to produce a better result.

I mean — I could see a world or specific repos that are so well covered by tests and evals that the responsibility piece is less important, and the PR’s quality is purely based on fitness scores. This would obviously have some huge advantages…

The fun thing about all of this is that traditional agile thinking would dictate to minimize work in progress, even across an entire team. I love having this turned upside down. I’m sure PMs do too! Provided delivery is still occurring for your customer, of course. I could talk a lot more about barrels vs ammo here, but that’s for another day.

This type of work is great for the non-customer-related features, like the E2E test tasks for instance. Your PM really doesn’t want you to spend time on this, and it’s obviously not for free, but if you can use a bit of extra horsepower to do more multitasking, while still delivering on the PM features, that’s win-win. Provided the quality is there of course.

But for now, basically, you can’t delegate responsibility to LLMs. Not yet at least.

Barrels vs Ammo — Keith Rabois Stanford talk: https://www.youtube.com/watch?v=6fQHLK1aIBs

https://blog.cloudflare.com/content-independence-day-no-ai-crawl-without-compensation/

The TLDR is that on July 1st, 2025, Cloudflare flipped the switch and started blocking AI crawlers by default. Crawlers can no longer freely train their models on Cloudflare’s hosted sites.

Cloudflare sits in front of about 20% of the web. This is definitely enough of an arm twist to the crawlers to force a behaviour change.

They cite they are building a marketplace to enable crawling the traffic, a sort of pay-per-crawl microtransaction undercurrent to the web.

In theory, this would enable people that write original content that _furthers knowledge_ to be paid when that content is going to be leveraged by the “front door of the web” (be it Google, ChatGPT, you talking to siri on your phone, etc.).

The previous mode of pay per impression had bad incentives that led to to seas of AI slop, and now tools to “quickly create content”. I am excited to see this come to an end.

One nuance is Google’s AI summaries are driven from their main Googlebot, not their Google-Extended used for Gemini training. So the above changes actually favour Google in their current incarnation in that they’ll still have access to Cloudflare’s hosted sites. I’m sure this will change over time.

The article sites “major publishers” and sure enough I found reference to 9 articles publicly applauding the move (link below). Interestingly enough, I found them via Perplexity, and had no luck finding anything via Google!

It is all cyclical though, I’m sure this will morph and be gamed, and evolve, but the slop creators and their aggregators have had it coming to them for years.

My moral here — do something useful. If your game is grift, it is short. If you’re building something that will try to game an algorithm or a bot, or a person, maybe think again. If you don’t think your mom would be proud of you for it, it’s probably a short game with a really short time horizon.

Attribution: I derived a lot of my above thoughts from listening to Ben Thompson’s thoughts on this: https://stratechery.com/2025/cloudflares-content-independence-day-googles-advantage-monetizing-ai/ (paywall)
Reference: Perplexity’s list of supporting publishers: https://www.perplexity.ai/search/cloudflare-recently-announced-BuCv02IhRp2._R9_ZL2Dlg#0
Reference: Cloudflare’s 20% of the web: https://www.cloudflare.com/about-overview/

So, I had to have a tooth extracted this past weekend.

That’s a story in and of itself. But this isn’t about that. This is about brand marketing. And I’m no marketer, so this is all going to be pretty basic for any marketing folks out there, but I’d love your critique or additional present day insights.

Leading up to my tooth extraction, there were moments when I longed for an instant solution to the pain. A magic bullet that would make it go away. And then it hit me: Ambysol.

Well not exactly Ambysol. Anbesol.

If the name rings zero bells, then you’re probably not the same vintage or didn’t grow up glued to ‘80s and ‘90s TV ads like I was.

Anbesol is an on-touch pain relief product targeting gums and teeth. They ran several memorable ad campaigns in the 80s and 90s, the one that stuck with me was this one:

https://www.youtube.com/watch?v=watk0EXIvd8

How fast does Anbesol start to relieve toothache pain? Before you can say Anbesol!

Surely that product no longer exists… or perhaps it does?

I circled the pharmacy aisles and asked around. The senior pharmacist directed me right to it.

The box didn’t look how I thought it might, and I had the spelling wrong, but sure enough, it was the thing. In all its pain curing glory, straight from the hall of fame of lasting ads in my brain. And now, finally, the moment my marketing-naive brain assumes they were all waiting for: conversion.

Then vs Now

All this to say — I think the days of a single brand marketing campaign sitting in someone’s brain for 30 years are behind us. Probably actually have been behind us since 2000 or so, I’m just only noticing now.

We used to have shared ad culture. The same jingles on TGIF and the radio, the same commercials before cartoons. Ads became a part of a cultural vocabulary. Today it’s all personal algorithms that are optimized for clicks and attribution (although there is a trend of starting to share these views too).

Digital ads are optimized to be clicked, not remembered. They aim for instant action, and not long term recall. I

We’re rapidly approaching a world where tools like ChatGPT and Perplexity serve us exactly what we need, all in a measurable and attributable way.

And in this world, there is no room for a brand’s messaging to place a lasting memory for hedged conversion moment down the line. Now we need to search for it to find it —and if search stays authentic and un-gamed, this feels like a perfectly fine result (wishful thinking for sure, but Perplexity has touted their values here).

There is still a role for brand recall, but as far as I can see its mostly for physical products. Those Anbesol packages still need to stand out on pharmacy shelves, clothing brands need recognition in stores, restaurants need recall when you’re hungry.

But who’s going to pay for broad-reach, memorable campaigns when conversion is hard to quantify and CFOs want ROI for this quarter?

And even if they did… what does staying power look like in 2025?

The Long Game

Talk about playing the long game! That ad has been circling in my head for over 30 years, never even being considered by my frontal cortex, always consumed passively with a portion of my brain. But laid a deep foundation, with a keen hook and a unique set of words, and sure enough it was here to stay.

Was a decade long lasting impression a requirement? Because they know people experience tooth pain infrequently, was it a design that their hook needed to be so good as to last years? Cause it worked.

If there are hallowed halls of my brain for these iconic ads, what is the equivalent in modern day ad space? Digital ads are hyper targeted and becoming more personalized — they play less on repetition, and more on A/B testing to evoke a click or conversion. Will they have the same staying power?

What will this look like for my kids in 30 years, that are sadly absorbing ad slop on YouTube. Maybe given the uniqueness of those ads, nothing will stick. Or maybe given the AI targeting, things will stick so much more and occupy space otherwise better used for creativity.

Whomp Whomp

And in the end? I didn’t find the product worked very well to relieve my pain! But the ad worked wonders. Good for them for sticking around all these years!

The conversation covered a lot, mostly Meta AI related stuff. About two-thirds in, Ben asked Zuck about Meta’s evolving content strategy:

BT: There is a question, why do you keep doing this? And you kind of look back, I remember back in 2017, you’re like, “We’re going to actually take down video a bit in our apps because we want people to feel good about this and to connect with people”, and then today we’re like, “Oh, there’s video everywhere and it’s getting bigger and bigger”.

MZ: Yeah. There were a lot of mistakes that I feel like I made during that period, in terms of deferring to some so-called experts about what was valuable for people. And look, obviously, there’s research that’s helpful, but one of my takeaways from that period is that by and large people are smart, they know what is valuable in their lives. When you have some expert who’s saying that something is bad and people are telling you that it is good, 9 times out of 10, the people who are experiencing the thing are probably actually right.

I take this as a pretty blatant admission of guilt, although not one he recognizes any wrongdoing in.

There’s a ton of evidence suggesting these platforms are too powerful for people to just “know what’s best”. Take YouTube’s algorithm and radicalization traits. Meta’s algorithms are no different, they are designed to keep people engaged to serve more ads. I’m assuming we all have at least one friend that has been radicalized and led astray by algorithms. Maybe this is the 1/10 he’s referring to, but he’s saying this is fine. That the people want this and know what’s best.

When he says this, he’s revealing that he isn’t thinking of the externalities.

Its engagement, its ad dollars. And that the people know what’s best, and they want his ads. I can’t interpret this any other way.

This flies in the face of the work the Centre for Humane Technology has done over the last decade, trying to define and create frameworks for technologists to recognize their part in affecting mental health and society at large with the experiences they build. And here is Zuck, a man whose direction guides what over a third of the world sees when they wake up in the morning, saying he doesn’t care about this.

If anyone is looking for evidence that Meta’s products have their best interest in mind, or will have your back… I think this is it. They don’t. They’re going to be designed to trigger dopamine response, and that’s that. AI or otherwise.

Sad. Not surprised, just sad.

The Snowblower Saga

Picture this; a charming couple moves into a small town in the far north, enticing the locals with promises of a revolutionary new snowblower (snow being very topical in Ottawa atm). Smooth-gliding, effortless snow excavation and evaporating the likes of which the town had never seen, who could resist? Many eagerly sign up to purchase the first model, excited to support these charismatic entrepreneurs and achieve a higher quality of life with more time to cozy up by the fire.

The much anticipated snowblowers arrive, but alas, they don’t quite live up to the hype. “No worries!!” say the entrepreneurs and their growing band of minions, “we’ll keep tuning them up, they’ll live up to the dream we promise”. The townsfolk are appeased even amidst some scathing criticism by the town Marques.

Nary a few months later, the tunings slow down, and then one day, abruptly the minions sheepishly inform all their customers that cruel outside forces have intervened. Not only will the promised tunings cease to continue, but the machines will cease functioning altogether in a mere 10 days! Pitchforks in hand, the furious customers run the swindlers out of town.

Humane’s Betrayal

This fable mirrors the unfortunate reality of Humane Inc, their AI Pin and the announcement they published today. I admit, I’m a bit raw. I was drawn in by the vision painted by their co-founders Imran Chaudhri and Bethany Bongiorno. I was an early believer, and still believe a future can exist with wearable tech that allows you to stay connected to the real world and the online world simultaneously.

But this announcement, to brick customers’ devices in a matter of days without reserving some olive branch of extended service is just a huge slap in the face, and speaks to their lack of control of the company they were leading.

As an early supporter, I feel duped and foolish. But more importantly, I’m disappointed that Chaudhri and Bongiorno’s actions will further erode consumer trust in visionary tech and embolden naysayers.

Aluminum Lining

I may be exaggerating a bit, the folks that bought an AI Pin are likely pissed, but they’ll get over it. Maybe an open source future hack will help it live on. I’m hopeful there is more to this story that comes out that helps explain these actions, ideally something better than “our hands were tied by the investors”.

My idea of success as an entrepreneur is one that is mission driven, absolutely. However, this situation is an unfortunate reminder that without your customers’ faith and trust, you’re nothing. It’s the most valuable asset you have, and if you want the ability to fail your way to success, you better place their trust above all else.

However, I don’t think they’re going to feel this lesson as I doubt they’ll be run out of any town. But one of the best things about being an entrepreneur is, I’m not them, and I can choose a different priority stack.

So then I thought, if LLMs had perfect knowledge of me and I was looking to maximize my education hours, could I ask them to pre-screen a handful of podcasts based on the transcripts, and ask which of the podcasts I would likely find most valuable from a learning perspective?

A current solution for this approach is querying LLMs that have memories. ChatGPT can be configured to store and summarize your conversation history over time and draw on it as needed. Here is an excerpt from mine:

This is all well and good for right now, but has two big drawbacks, it’s spotty and locked in. I like using the best tool for the task, whether that’s ChatGPT, Claude, Cursor, Perplexity, Google, etc.., and many times the queries are contextual (Project A vs Project B, and obviously would like to avoid problems akin to when your spotify wrapped indicates your most loved album is the Frozen soundtrack, yes I’m looking at your other parents).

My current strategy to counteract this is one of my favorite principles of the past few years that I’ve mentioned before; File Over App.

Essentially, File Over App means to prefer methodologies that don’t lock in your data, that store things in simple, flat files with universally recognized formats / protocols, such that the data is always free and accessible.

Applying this to todays multitude of tools and the arms race they’re in, and how none of them really feels the need to keep things open, I’ve decided to amp up my journaling intentions heavily this year. Mundane or poignant details, otherwise not captured or externalized, will be externalized into markdown and tags, all in Obsidian, for probably not that distant future consumption. Until we have Neuralink, this is the next best way to increase the changes of truly personal outcomes, and own my data.

For instance, here is an excerpt from today;

Listened to Lenny podcast today, with the guy from Gong. It was generally good and the guy knew his stuff. Talked about his pod approach, and how they work with design partners. Other than the design partner bit, i found the “pod” approach being spoken as though it was a brand new innovation, yet it’s really just a rejig/shaping of stream aligned teams, and then from scrum and agile. He did mention Marty Kagan books of which i’ve read zero, but didn’t tie anything together. It irks me when people talk about things as being the first and brand new, but don’t pay at least a bit of homage to systems of before. Maybe i missed it, still irked tho. …

If that was paired with another entry about how I really enjoyed something about some cool Data Science topic, or a delightful episode of Sharp Tech where I reacted more emphatically, and also paired with trends of learning and my interests, I bet it would have recommended a different podcast.

And in the off chance this makes sense; I’d like to think of my journal as a really large .cursorrules file to help with personal decision making when LLMs can perform tasks I clearly cannot (like looking ahead to tell me what I’ll likely vibe with the most). A .liferules file if you will.

What other outcomes might there be other than recommendation the podcast of most value? I obviously don’t know yet! But I do know I’d prefer to have this data in a file, outside my brain, not locked in to any one vendor or model, ready for ingestion, summarization, and then personalization with “AI Next” at a scale that will help me optimize my time, and life.

I’ll be ready for you, GPT-X, AGI-mini, or whatever is coming next.

This may be turning into a micro series, it has similarities with another piece that was focused on technical documentation.

In hindsight this feels like a bit of a step back from where I thought I would be by now… oh well.