Agentic systems, where multiple AI agents collaborate through decision-making and handoffs, shine in specific scenarios but add operational complexity.
In this post, we'll explore the scenarios where agentic systems are most effective and the challenges you may face when using them.
Imagine: you run a busy online shop where every moment matters.
Your customers expect the fastest page loads, yet you still require dependable analytics to understand user behaviour and drive informed business decisions.
Relying solely on client-side tracking with tools like PostHog can be fraught with challenges. Many users have ad blockers or privacy extensions that prevent tracking scripts from running, and even when these scripts do execute, they can slow down page rendering and affect conversion rates.
In this post I'll go over how you can use Next.js 15’s next/after API to handle analytics and events without slowing down your site.
Getting event names right in event-driven architecture and Domain-Driven Design (DDD) is essential for clarity, consistency, and scalability. A key decision is using singular or plural terms in event names.
Here's how I approach it, with examples and reasoning to help you make the best choice.
Building a TypeScript library that is both maintainable and optimised for modern bundlers requires careful consideration of exporting functions, types, and other constructs from your modules.
With several strategies available, from wildcard re-exports to namespaced exports, explicitly named re-exports have emerged as the clear winner. This post explores the alternatives with examples based on an order management system.
We'll discuss the benefits of exporting types, how to organise multiple entry routes (such as in /src/orders and /src/users), and review the necessary TypeScript configuration options (such as verbatimModuleSyntax) and package.json tweaks. Additionally, we'll explain how this approach helps prevent circular dependency challenges by enforcing a clear dependency graph.
I love Next.js. It's been my framework of choice since my first tiny contribution in 2017.
Yesterday, I joined a team discussion about which React framework to choose. In 2025, that decision is harder than ever, with so many excellent alternatives available.
While Next.js is recommended by React themselves, and is a very popular choice, the not-so-good parts are often left out on platforms like LinkedIn and YouTube.
I plan to write about the good things about Next.js 15 in the future, but here are some challenges I still face using it today.
31 Jan 2025
Designing a payment system is like any other software solution I've worked on.
At first, it appears straightforward, but real-world factors like currency conversions, fees, payee validations and external APIs quickly add complexity.
Read More →
It's like a new diet pill has hit the market, promising instant weight loss with no effort, and now everyone's scrambling to get their hands on it because it's all over their TikTok.
Some folks are talking about DeepSeek as if it's the second coming of AI.
The clamour might be because it's the first serious open non-US model with reasoning capabilities from China.
Most people are confused about which version of DeepSeek they're using.
Most providers offer a distilled, watered-down version that'll run anywhere, so you're not getting the actual full fat version people are talking as to really see its magic, you'd need a small fortune in computing power.
It's like being promised a rare vintage white wine, only to find the bottle filled with slightly grape-scented water. Same brand, same label, but all the depth and character stripped away, leaving you with a hollow imitation.
The hype suggests it can keep pace with anything OpenAI does, which might sound thrilling if you're already tired of whatever ChatGPT or its siblings spit out.
But here's where the alarm bells should start ringing.
Building AI products with stakeholders requires a fundamentally different approach than traditional software development.
From my experience working with AI, success depends not only on technical implementation but also on bridging the gap between AI capabilities and stakeholder expectations.
In this post, I’ll share lessons from guiding stakeholders through AI’s possibilities and limitations.
Defining clear boundaries is essential to building clean, scalable, and reliable architectures.
In my experience, organisational demands often override the focus on boundaries and domain-driven design. This reflects the tension between following technical best practices and delivering business outcomes quickly. While theoretical approaches are widely discussed at conferences, in books, and in videos, the practical implementation of these ideas is often shaped by cultural dynamics, resource constraints, tight deadlines, and internal politics.
In this post, we'll explore the challenges of maintaining boundaries and potential solutions, using a payment system as an example. This system facilitates transactions between clients and payment providers, such as PayPal or Stripe, highlighting the distribution of responsibilities within its architecture.
The goal of creating something "predictable," reliable, and consistent is a shared principle across all the teams I've worked with throughout my career.
Knowing that the same code would always return the same output when given the same inputs was the foundation of everything we built.
We aimed for no surprises, no matter how complex a workflow might be.
Whether implicitly or explicitly using finite state machines, this determinism enabled us to build testable, monitorable, maintainable, and, most importantly, predictable workflows.
We read and shared ideas at conferences, promoting patterns and principles like SOLID and DRY to create functional, composable, and extensible software.