Design and build in one small team: what four products taught me.

For most of my career the slowest part of a project was not the design. The research was done, the designs were approved, the developers had the documentation and we had talked through every screen together. What they built matched what had been designed. The problem was time. When it could be built, and when it could go live, depended on so many variables outside the project: other priorities, release windows, who was available and when. Good work waited.

When Ana and I set up Syntaxa Studio (opens in a new tab) this year, the premise was simple: remove the waiting. I lead the research, UX and UI; Ana leads the engineering. We sit in the same conversation from the first brief to the release, and the person who decided why a screen works a certain way is the same person who checks it in the build. Four products later, this is what I have learned.

The gap between designing and building is mostly waiting

Every in-house designer knows the pattern. A piece of work is finished, tested and signed off, and then it joins a queue. The build depends on a sprint that is already full, a release that is already planned, a developer who is already on something else. By the time it goes live the context has moved on, and the chance to learn from it quickly has gone with it.

In a two-person studio there is no queue. The design and the build are planned by the same two people, so when a screen is ready it is built next, not when a slot opens. If Ana hits a constraint, I hear about it the same day and we decide together whether the design changes or the build does. Decisions stay attached to their reasons, and they stay attached to a date.

How we actually work

Each product starts with the same first week: I look hard at what already exists in the category, map the competitors and pull out the gaps and patterns worth borrowing or avoiding. I use AI tools to speed up the collection and synthesis of that research, which leaves more of the week for judgement about what it means.

From there I build a small design system for the product, not a generic one. Each of the four products has its own type scale, colour system, spacing and components, so the product feels like itself rather than like a template. I design the interfaces at high fidelity and hand Ana working HTML and CSS, not static pictures. She builds the application behind it.

Heading order, focus states, contrast and keyboard behaviour are in the design files from the start, and they survive into the build because the build starts from those files.

Four products, four different briefs

ZenRoll is a booking platform for Jiu-Jitsu coaching, online and in person, with trainer search, scheduling and payments. The hard part was giving trainers and students different journeys through the same product without it feeling like two apps.

NeonBoard is a collaborative kanban task manager for small teams. The design brief was speed and clarity: a board that loads instantly and makes priorities legible at a glance, with as little chrome as possible.

Zura coordinates dental care: booking, insurance verification and treatment records shared between patients, clinics and dentists. Three audiences, one record, and a strong need for trust in how information is presented.

RC Bench is a showcase and marketplace for custom radio-controlled car builds, with a guided build submission so that hobbyists can present their work well without design skills of their own.

Four different categories, four different audiences, and the same two people across all of them. None of these would have been possible on that timeline with a designer and a developer who had never worked together.

What this means if you are deciding how to build something

A two-person design-and-build team is not the right answer for everything. It suits a founder or a small organisation with a clear idea and a real deadline, who wants a product that is considered rather than assembled, and who would rather talk to the people doing the work than to an account manager. It is not the shape for a large programme with many workstreams, where a bigger team and more process earn their keep.

If you are in the first group, the question to ask any studio or freelancer is simple: who decides what happens when the design and the build disagree, and how quickly? In our case the answer is the two of us, usually the same afternoon.

I still take on senior interaction design work in my own right, and the thinking in my Shelter case studies is the same thinking that goes into Syntaxa’s products. If you would like to talk about either, get in touch or have a look at what Syntaxa Studio (opens in a new tab) is building.