PRECISION
CORE
Precision Core began as an exploration of what an automotive software system could look like when the interface and component architecture are designed together.
The problem wasn't making one interface look coherent. It was creating a visual and technical language that could continue producing coherent interfaces as the product expanded.
Build the language before building every sentence.
Instead of designing isolated screens, the project starts from reusable foundations and moves outward into increasingly complex interface patterns.
A small set of rules can produce a lot of interface.
Real workflows, not just screens.
Underneath the design system is a platform that models its business processes explicitly: an RFQ moves from received to under review to quoted to awarded; a PPAP submission moves through review to approval; a corrective action stays open until it's closed.
A component library built without that context would drift — status colours invented per screen, empty states improvised each time. Building the tokens, primitives and patterns against the platform's actual state model instead means every interface tells the truth about where something really stands in the process.
The system has to survive outside the design file.
Components are evaluated inside the Partner Portal — the screens suppliers actually work from — rather than only in isolation in Storybook.
States, spacing, responsive behaviour and interaction are treated as part of the component itself, so a status card still reads correctly at four days overdue as it does on day one.
A design system only becomes useful when someone can actually build with it.
The interface is only the visible layer.
const Button = ({
variant = "primary",
size = "md",
children,
...props
}) => {
return (
<button
data-variant={variant}
data-size={size}
{...props}
>
{children}
</button>
);
};
The difficult part wasn't making the components look consistent. It was deciding where consistency should stop.