Selecting a toolkit isn’t a design decision—it’s a strategic one. Here are four things to consider before choosing a design system toolkit—even if it’s free.
We spent two years building it. With one of the best agencies. A design system that looked like it could outlive us all.
Then the budget vanished. The agency walked. A polished Figma file—and a codebase starting to fall apart.
The code was unmaintainable. Designers got stuck. Adoption stalled. The backlog exploded.
So I kept the Figma file and swapped the code. I turned to Kendo UI. Paid for the license because I needed something stable, well-documented and fast to implement.
And it worked. We shipped again.
Now? That same React kit has a solid free version!
That’s when it clicked: “Free” isn’t always better—but sometimes, it’s exactly what gets you back on track. And if adoption is the real goal? Free just might be your smartest move. How better to see if a library will work for you than to sample it first?
Designers love the crafting of design systems. We dream of the beautiful product we’ll build once our ideal design system is in play.
But decision-makers don’t buy aesthetics. They buy speed, clarity, predictability. To make a real case, speak their language. And that means knowing the tradeoffs.
Before you push a single pixel, you’ll probably hit:
Even a relatively inexpensive tool might take months to get approved.
If your company already uses a toolkit from a known vendor like Progress Kendo UI, lean into that. Stick with a system that’s already passed legal, compliance and procurement.
That shortcut might be the reason your proposal gets approved.
A design system doesn’t live in Figma—it lives in code.
If your engineers can’t use it, or if it clashes with your stack, you’re not choosing a system. You’re creating a future headache.
You might use Angular
today, but you’re one reorg away from React
. Big orgs don’t run on a single strategy.
I’ve seen managers actively push Angular because their C and C++ devs could get up to speed faster. Meanwhile, another project was locked into React—by top-down mandate, no discussion.
You won’t control every decision. Pick one that supports multiple frameworks.
And don’t forget documentation. No dev adopts what they can’t debug. Docs win.
Enterprise teams avoid change. Not out of laziness, but out of self-preservation.
The safest move? Stick to the status quo. And that means ignoring your proposal.
So when you introduce a new system, you’re not just bringing in components—you’re introducing risk. A existing toolkit lowers that barrier. Skeptics trust what they’ve seen before. A known name helps.
And if it comes from a vendor with a track record? Even better. If it’s already used inside the company? That’s your foot in the door.
Design systems need love. Someone has to update, support and maintain them. That takes time, money and often, it won’t be you.
Before pushing for something custom or new, ask:
Getting stuck with a beautiful, broken system happens more often than you think. I’ve been there. That’s why I choose tools that cut overhead, not add to it.
When leaders review a design system proposal, they don’t ask how it looks. They ask:
Getting buy-in isn’t about visual polish—it’s about business alignment. Free is the hook. Adoption is the catch.
Long-term success doesn’t come from picking the prettiest system. It comes from picking the one your team can live with, ship with and grow with.
Try KendoReact Free now, and explore the Progress Design System Kit.
Teon Beijl is a business designer and founder of Gears & Ratio, with over a decade of experience in enterprise software for the oil and gas industry. Formerly Global Design Lead for reservoir modeling, remote operations and optimization software at Baker Hughes, he now helps organizations deliver high-quality user experiences for industrial products through knowledge sharing, design leadership and implementing scalable design systems. Connect with Teon on LinkedIn or Substack.