We spend a surprising amount of time thinking about the tools we use at Segment. Not in a let's spend all afternoon comparing productivity apps kind of way, but because when you're a small studio, the tools you choose have a disproportionate effect on how you work. The right ones make things feel simple and disappear into the background; the wrong ones create admin, add friction and somehow become another thing you have to manage.
So our stack is fairly small, and fairly deliberate.
Most of Segment runs on a handful of tools that we've chosen because they do their jobs well. Notion does most of the heavy lifting for project management and internal knowledge, Claude Code has become a useful part of our toolkit, our websites tend to be built with Astro, Sanity and Netlify, and Make handles the bits that are repetitive enough to be worth automating.
There is a lot to be said for finding tools that are good enough at what they do and then leaving them alone.
But we also really like building things.
Not as a service, and not because we're secretly trying to become a software company. We are a marketing studio. The things we build are mostly small, practical experiments that make our own work a little easier, or occasionally give us an excuse to see if we can make an idea work.
That distinction matters, because there is a big difference between building a useful internal tool and building software that somebody's business depends on.
The "boring" answer is usually Notion
Most of our project management and internal knowledge lives in Notion.
Projects, notes, meeting agendas, content plans, client information, checklists, bits of research and all the half-formed thoughts that may or may not turn into something useful later.
It works because it is boring, and we mean that as a compliment.
Work with technology all day and you start wanting to build a system that perfectly represents how you think a business should work. We've fallen into that trap before, creating increasingly elaborate databases with carefully considered properties, automations and dashboards that looked excellent and were used enthusiastically for approximately three weeks.
Notion is good at stopping us doing too much of that.
A page can just be a page. A list can just be a list. If something changes, we can change it without having to rebuild the underlying system, and if we decide that a particular workflow isn't worth maintaining, we can simply stop using it.
For most client work, that is exactly what we need.
We don't want to spend our time maintaining the system that helps us maintain the work.
Then Claude Code changed what felt possible
We've always been interested in the technical side of things, but there is a difference between thinking "someone could build a little tool for this" and thinking "I could probably build a little tool for this this afternoon."
Claude Code has moved us much closer to the second.
Neither of us would describe ourselves as developers, and we're certainly not pretending that Claude Code turns a marketer into a software engineer. But having learnt enough CSS to understand how a page is put together, and enough JavaScript to understand what is happening when something needs to interact with something else, turns out to be surprisingly useful when you have an AI coding assistant sitting beside you.
You can read the code, make a reasonable guess about what might be causing a problem, explain what you want to happen, try something, see what breaks and ask for help understanding why.
That has opened up a whole new category of experimentation.
A few years ago, an idea for a tiny internal tool would usually die somewhere between "that would be useful" and "we'd need someone to build it." Now we can get much further before deciding whether an idea is actually worth pursuing.
Sometimes it takes an hour. Sometimes it takes a weekend. Sometimes we build the whole thing and realise the spreadsheet was better, which is fine too.
The interesting part is being able to find out.
None of which makes us a development company. We build small things for a clear purpose, and when a project turns into software that a business depends on, we say so and introduce someone who does that properly.
The Think and Drink exception
Think and Drink is probably the best example of where our curiosity gets the better of our sensible instincts.
It is a monthly event in Guernsey, which means there are speakers, attendees, venues, sponsors, emails, tickets, follow-ups and a growing list of people we'd like to invite to future events.
Notion could handle most of this.
In fact, Notion did handle most of it.
But over time we kept wanting little things that weren't quite worth turning into another complicated Notion workflow: a better view of attendees, an easy way to see who had been to which event, somewhere to keep track of speakers and sponsors, and a few small automations that would save us doing the same admin every month.
Eventually we reached the point where we could either keep adding things to Notion or build the little system we actually wanted.
So we built it.
It is a small custom CRM for Think and Drink. It isn't revolutionary software. It is simply a tool that fits the way we run this particular event.
And, importantly, we enjoyed making it.
That is probably the least rational part of our approach to technology.
We could have bought something. We could have configured an existing CRM. We could have spent an afternoon comparing software products and choosing the one with the nicest dashboard.
Instead, we spent longer making our own.
Because sometimes the point isn't efficiency. Sometimes you just want to make the thing.
Building for ourselves is a useful kind of playground
There is another benefit to all of this, which is that our own little experiments give us somewhere to learn without pretending that every experiment needs to become a client service.
This is something Sophie learnt at Cortex: building is fun, and building for fun is important. Not everything you make needs to have a business case, become a product or save you three hours a week. There is something useful about making things simply because you are curious about how they work, or because you have an idea and want to see if you can bring it to life.
We can try an automation, break something, change the interface, learn how an API works, discover that our original idea was terrible and start again, without needing to justify every experiment as a sensible investment.
That curiosity feeds back into the actual work, but we don't need to turn every experiment into a product.
In fact, we think it is healthier if most of them stay small.
The best internal tool is often the one that solves one annoying problem and then quietly disappears into the background. But sometimes the value is simply in having made it, learnt something from it, and remembered that building things can be enjoyable in its own right.
The stack, for anyone who is interested
So, roughly:
- Projects and knowledge: Notion
- AI and development: Claude and Claude Code
- Websites: Astro
- CMS: Sanity
- Hosting: Netlify
- Automation: Make
- Design: Figma and Affinity
- Experiments: whatever seems appropriate at the time
- Think and Drink: an increasingly over-engineered custom CRM
There are other things around the edges, of course. Every small business accumulates software.
But the list itself isn't really the interesting part.
We don't particularly believe in having a stack for the sake of having a stack. Tools earn their place by being useful, dependable or, occasionally, by giving us the chance to build something that makes our own work more enjoyable.
Most of the time, that means using Notion and getting on with the work.
Sometimes it means opening Claude Code and saying, "I wonder if we could build this."
We're trying to get better at knowing which one to do.