We use a small, consistent set of technologies across our projects. That is intentional.
Working with the same tools repeatedly allows us to build deeper expertise, establish better patterns and carry what we learn from one project into the next. When we solve a technical problem, improve a workflow or find a better way of doing something, that knowledge does not stay isolated inside a single project. It becomes part of how we work.
A shared stack also reduces unnecessary decisions. We spend less time choosing between tools that solve the same problem and more time understanding the product itself.
Every project should make the next one easier to build.
Our stack is a default, not a constraint. We prefer tools we know well, but we are always willing to step outside of them when the needs of a project justify a different approach.
Next.js is our default foundation for digital products and interfaces that we actively develop and maintain.
We use it when the frontend is closely connected to product logic, user interactions, authentication, data or other dynamic functionality. It gives us a predictable environment for building applications while still leaving enough flexibility to adapt the architecture to the needs of each project.
Using the same foundation across products also means that patterns, components and technical decisions can move between projects more easily. We are not starting from zero every time.
Consistency gives us a better starting point, not a fixed destination.
We use Hono when a project needs a lightweight, dedicated backend layer.
It is our preferred choice for headless APIs and services that need to exist independently from the frontend, and we also use it alongside Next.js when backend requirements grow beyond what makes sense to keep inside the application itself.
What we like about it is that it stays relatively close to the problem. It gives us the structure we need without forcing unnecessary complexity into smaller services.
That distinction matters to us: not every backend needs to become a large system.
Tailwind CSS is our default styling approach across projects because it keeps the relationship between design and implementation close.
It allows us to move quickly from visual decisions to working interfaces while keeping styles near the components they belong to. Over time, that creates a shared vocabulary across the team and reduces the amount of project-specific conventions we need to invent and maintain.
The value is not simply speed.
It is consistency in how we translate design into code.
When the same spacing, typography, states and layout decisions are expressed through a familiar system, it becomes easier to reason about the interface as a whole.
We use Payload when a project requires structured, editable content.
We value its developer-first approach, flexibility and open-source foundation, but more importantly, we like the level of control it gives us over both the content model and the editing experience.
A CMS is not only a place to store content. It defines how people create it, how information is structured and how easily the system can evolve later.
That is why we prefer tools that let us shape the CMS around the project instead of forcing the project into a predefined editorial model.
Content structure is part of the product architecture.
The direction of Payload, including its closer relationship with the broader design ecosystem, also fits well with the way we think about reducing the distance between design, development and content.
We host our projects on Vercel because a consistent deployment environment removes a large amount of operational friction.
Preview deployments, production releases, domains and collaboration all happen within the same environment, which makes it easier for design, development and client teams to review work throughout the project rather than only at the end.
We prefer infrastructure that stays out of the way when it can.
If managing infrastructure does not create meaningful value for the product, we would rather spend that time on the product itself.
We do not choose technology because it is new.
New tools are interesting, and we pay attention to them, but novelty alone is not a good reason to introduce another dependency, workflow or architectural decision into a project.
We prefer technologies that:
That last point is particularly important.
A shared stack means a better component in one project can influence another. A deployment issue solved once becomes a pattern. A better CMS structure becomes something we can recognize again. Technical decisions become knowledge instead of isolated solutions.
This compounds.
At the same time, the stack should never become more important than the product. If another technology is clearly better suited to the problem, the team, the infrastructure or the long-term needs of the project, we use it.
The goal is not to protect the stack.
The goal is to make good technical decisions with as little unnecessary complexity as possible.
Having defaults makes us faster because we do not need to reconsider every technical decision from first principles.
But defaults are useful only while they continue to serve the work.
So we keep a simple rule:
Use what we know when it fits. Change it when there is a good reason.
We want our technology choices to create continuity between projects without making every project the same.
The tools may evolve.
The principle stays the same: choose technology deliberately, understand it deeply and make sure it earns its place.