ABOUT
About the pace
the pace started with a question most product teams learn to live with: why do design and engineering still break apart so easily? After more than a decade building products, I stopped accepting the answer and started building the fix.
The problem I kept hitting
the pace started with a frustration. After more than a decade of product design — across iGaming, fintech, SaaS, e-commerce, and telecommunications — I kept hitting the same wall: design and development don't speak the same language.
Designers specify in pixels. Developers implement in rem. Accessibility gets flagged in QA, weeks after it should have been built in.
Design tokens vanish between Figma and the pull request. Component specs live in six places, and none of them agree.
Why the pace exists
I stopped waiting for someone else to fix it. the pace exists to build the tools I wish I'd had — products that sit at the intersection of design and engineering, bridging the gap with precision rather than process.
Parlance is the contract layer between design and development — components, tokens, and interactions verified against W3C standards. Lexicon is the shared design system. More tools will follow. The best tools don't add steps to your workflow — they replace the ones that weren't working.
A design contract should be as precise as a code interface. An accessibility check should happen at design time, not after launch.
BELIEFS
What I believe about this work
These are the principles behind every tool, service, and decision at the pace.
Design and engineering need shared language
Not more meetings. Not more documentation. A precise, agreed vocabulary that both sides can verify against.
Accessibility is a design decision
It should be built into the system at design time — not flagged as a bug after launch.
Tools should reduce friction, not add ceremony
The best tools replace the broken steps in your workflow. They don’t add new ones.
Standards over assumptions
Every decision should be validated against real specifications. Opinions are not a foundation.
Precision over speed
Shipping right matters more than shipping fast. Maintainability, consistency, and correctness compound.
Systems thinking over surface output
The visible UI is the smallest part of the problem. Tokens, contracts, logic, and structure are where quality lives.
I stopped waiting for someone else to fix the handoff. So I built the tools myself.
— Jonathan Pace, Founder
FOUNDER
Jonathan Pace
Design Systems Architect
I work in the space most teams overlook — where design decisions meet technical implementation. After more than a decade building products across iGaming, fintech, SaaS, and telecommunications, I started the pace to fix the problems I kept seeing from the inside.
Every product, service, and system at the pace is shaped directly by me. You're not handed off to a team. You work with the person building it.
Let's work on something that matters.
If you're building a product where design and engineering need to work better together, I'd like to hear about it.
Get in touch