Jest is the first marketplace for messaging games—a real alternative to the app store model.
As the team’s Product Designer, I help shape how the platform looks, feels, and behaves. My work spans early concepting, product flows, UI design, and product management.
The issue arises because, when designing for the web, we need content to have a maximum width. Otherwise, if someone has a wide monitor, the layout looks broken or they have to move their head all the way from left to right to read it.
When we give containers a maximum width, anything that doesn’t fit inside them gets cut off and becomes invisible. In a carousel, that means as you scroll, the content disappears abruptly before the end of the window. (Unless the window is narrower than the max width you set. In other words, this isn’t a problem on mobile.)
Everything on a website is a box. The carousel is also a box. When you put something in the box, it appears on the leftmost side. If you want it to show up more to the right, you can add padding on the left. So hypothetically, we could add padding to align the first book with the left edge of the other sections! Alas… the padding would need to be different depending on the window’s width!
So for a long time, I thought this was an unavoidable problem. But then I saw a carousel that worked right on Apple’s website! So… there was a way!
Thankfully, because this is the web, you can right-click → Inspect Source on any website to see exactly how it’s built. I then adapted it for my website, and ta-da!
The code ↴
$container: 1240px; /* Yes, I use Sass. Yes, I know we have CSS variables now, but I like it and the pre-processor is built into Jekyll, which builds my site anyway! */
$container-padding: 32px;
.book-carousel {
padding: 0 calc(50% - min($container, 100%) / 2 + $container-padding); /* [Half the screen] - [half the container] + [container padding * 2] */
overflow-x: auto; /* makes it horizontally scrollable */
scroll-snap-type: x proximity; /* so you can’t stop in between books: it “snaps” to the closest element in the X axis */
}
The magic part is:
calc(50% - min($container, 100%) / 2 + $container-padding);
We’re basically saying:
And the coolest part is that this is all just CSS! Which means, if scripts don’t load (bad connection, on the train, unknown error, browser that blocks scripts), the carousel still works the same (progressive enhancement 😎).
Did you notice the custom scrollbar? Don’t ask me how that one works because I asked Cursor to build it. You can see the code on GitHub though.
]]>
I’ve been building websites for over 7 years, but until now I’d never shared my entire process online.
Everyone is talking about Framer and Webflow, and most build with WordPress. I do things differently. Not to be contrarian, but because I prefer having more freedom.
The post gets a bit technical at times, but if you don’t consider yourself technical, it’s still very much worth reading (regardless of whether you’re thinking about working with me). It’ll give you a practical understanding of how the web works.
I hand code websites using HTML, CSS and a bit of JavaScript.
If you’re new to this, just know that HTML is a file type and websites are just folders with files that are linked to each other. You know how you open .docx files using Word? Well, you open .html files using a web browser, like Chrome!
I use Jekyll, a Static Site Generator (SSG), to ‘sandwich’ together (“bundle”) parts of my code (e.g. navigation bar, footer, etc.) into a full website. Jekyll, like other SSGs, runs on my computer and I control it via terminal commands.
The reason I do that instead of just making one HTML file per webpage is that some elements repeat across pages (e.g. head, nav, footer) and some pages look exactly the same but have different content (think individual articles in a news site, or the same pages in different languages). I don’t wanna do duplicate work and risk creating inconsistencies. Even if a website has a single page at first, I might add more later. And even if I don’t, it’s often helpful to have separate files for different sections because it’s easier to find where to make changes when needed.
Jekyll creates a folder within my project folder called _site and in it it puts the sandwiched version. That version works completely independently and offline (as all sites do), unless I have built any dependencies into the code itself (for example, if I embed a YouTube video, it’s not gonna play offline).
To put the website on the internet, I use Netlify, a Content Delivery Network (CDN). They offer free hosting, and since they’re a CDN, that means they put a copy of my website (_site folder) on many servers across the globe, and they serve from the one closest to the visitor for increased speed.
Netlify can actually use Jekyll (among others) on their side to ‘sandwich’ (bundle) the code I upload. So I don’t have to upload the finished _site folder; instead I connect it to GitHub directly and Netlify rebuilds the site every time I push a change.
Note: Since Netlify builds the site independently from me, I might occasionally run into issues where the site gets built fine on my computer, but Netlify runs into errors. These are usually because of different Ruby versions (the language powering Jekyll) running on Netlify’s servers vs locally on my machine. To resolve them I typically have to make changes to the “Gemfile”, a text file that tells Jekyll which version of what to use.
But how does a non-technical person (e.g. my client) edit their website if the content is stored in the code?
Well, Jekyll & Co. let us “pull in” data from text files (Markdown and YML, a more human-readable way to write JSON) to put into our code. It’s still confusing for most people to edit YML files though, and more importantly, they might accidentally change the formatting (it takes just adding or removing a single space!) and break the whole thing. Thankfully there exist programs called Git-based Content Management Systems (CMS). They let people edit specific sections within files on GitHub through a simple interface, without letting them change parts we don’t explicitly allow.
I’ve successfully used Pages CMS a bunch of times. It looks good and works well, but it’s missing many features. In the past I’ve used Decap CMS back when it was Netlify CMS, but the interface was not as intuitive for editors.
To set up a Git-based CMS, you typically need to create a text file to tell the CMS what inputs (text, dropdown, etc.) to present to the user and what information these should alter in which file. (It’s a tedious process but ChatGPT can help.)
Git-based CMS is not the only option. There are also API-based CMSs, and they work by letting us store data (text, images…) on their servers, and then making that data available to us via an API. Think of it like asking Jekyll to pull in data from a remote server, instead of a YML file in the same parent folder. We can pull in data each time I build the website so it’s part of the shipped code (good), or inject it into the live website each time somebody visits it (bad if it can be avoided, because we introduce latency and need JavaScript for it to work).
The upside of API-based CMS is that you can use the same data to power multiple “clients” (e.g. a website, an iOS App, an Android app, a POS…). The downside is that your data is not yours; if the CMS company goes away, so does the data. Or they might increase their prices and you’ll be almost forced to start paying them more, because changing an older project to use a different CMS is often cumbersome.
And a third option is traditional “monolithic” CMS, like WordPress.com. Monolithic because they take care of both the website generation and the content management (think of it like Jekyll + Pages CMS into one). All-in-one might sound practical, but it forces you to use certain patterns you might not like or need for a project because you can’t cherry pick the parts you like—it’s all or nothing.
For example, let’s say I like Wordpress’ content editing part because it’s easy for clients to use (not really—it’s terrible, but let’s pretend) but I don’t like writing PHP to create my page templates, nor do I want to rent server space and install and manage Wordpress updates. If I want to use Wordpress, I have to do all of these together. But with “decoupled” CMS (whether Git- or API-based), I can switch each part individually. I might be using PagesCMS and then switch to Decap by changing a single text file (configuration) without having to give up Jekyll. Or the opposite! I might switch from Jekyll to, say, Hugo, without giving up PagesCMS.
This decoupling can go even further, as many SSGs let you choose which templating language you want to use. Jekyll uses Liquid, but other SSGs, like Eleventy, let you choose between many, including Liquid, Handlebars, Mustache, and more. Templating languages generally all work the same way. They have an opening and closing symbol combination (often {{ and }}, hence names like “Mustache”) that are not natively part of HTML. That way, the templating language can recognize its parts and replace them with the thing you specify. For example, I might use Liquid inside HTML to write:
<a href="{{ site.data.links.search.url }}">{{ site.data.links.search.title }}</a>
The part inside the brackets is Liquid, and the rest is HTML. Assuming I’m using Jekyll to build the website, for the above to work, there needs to be a file called links.yml inside a folder named _data inside the parent folder that includes all the website’s files (site). Inside that links.yml I need to have
links:
- search
title: Google
url: https://google.com
Then Jekyll will know to replace the Liquid snippets above and produce:
<a href="https://google.com">Google</a>
And that will be the code in the outputted HTML inside my _site folder.
All that is great, but how does someone visit my website on the internet? I want them to type something like example.com into their browser and see my page. To do that, I need to buy the domain name “example.com”. I buy domains from companies known as domain registrars. iwantmyname.com is one such company and while I appreciated their no-nonsense minimalist approach for years, their prices have gone up significantly lately. So I switched to buying from Porkbun!
After I buy a domain, I need to point it to where my website is stored (‘hosted’). I do that by adding a DNS record in the domain registrar’s software platform. What does the record say? Depends on where the site is hosted. In my case, that’s usually Netlify, so Netlify gives me some IP addresses to copy-paste and they take care of the rest.
What if I want to receive email in an address like me@example.com?
First, I need an email service provider. Gmail is such a provider, but to use it with a custom domain, you need to buy a “Google Workspace” subscription. Most email services ask you to pay to use a custom domain email.
The only reliable free solution that I know of is Zoho Mail, but that too has a catch: when using the free version of the service, you can only view your emails from their website or their mobile app. Good enough, considering it’s free! But for just 12 € per year (not per month), you can use any email client you like (for example Apple Mail, Outlook, or even Gmail—yes, Gmail can be used as an email client for other services!) via the protocols IMAP (receiving email) & SMTP (sending email) or POP3 (both).
And now you know how I make websites! Of course the process is subject to change. I love trying out all the latest tools, but I’ve been loyal to Jekyll for so long because it just… works.
The Git-based CMS landscape on the other hand changes constantly, so every few years I need to switch to something else. It’s not a huge deal, because the data always remains accessible and editable (remember the YML files?), since it’s decoupled from the CMS.
And that’s the whole point of this approach: you’re never locked in. If a tool stops working for you, you can swap it out without losing your content or starting from scratch. And that flexibility benefits everyone: clients get sites that will last, and collaborators get a flexible stack that’s easy to work with!
Questions? Suggestions? Reach out—I’m all ears!
]]>
Like many tech workers, I have a complicated relationship with to-do apps. On one hand, I’ve spent countless hours trying them all—and even making my own. On the other, they just. Don’t. Work.
I’ve literally tried them all: Todoist, Microsoft To Do, Sunsama, Trello, Superlist, Taskade… and I’ve built at least two fully custom, complicated task management systems in Coda, with features like automatic prioritization based on parameters and warnings when there aren’t enough hours in the day to finish everything I’ve scheduled.
They all meet the same fate. It doesn’t matter how much I like them at first, how motivated I feel, or how productive I get—eventually I’ll miss a day or two. Then, when I come back, I’m greeted by an overwhelming list of overdue tasks—exactly what I was trying to avoid in the first place.
I’ve seen the second-brain systems. They make so much sense: capture every idea, throw it into your inbox for later review, spend five minutes at the end of the day deciding what goes where, and once a month review everything to prioritize what matters. Human memory is fragile, but the app never forgets.
Sounds great!
Except I never look at my inbox. I never feel like looking at my inbox—the thought alone overwhelms me. It’s exciting for a few days (“think how much my future self will thank me!” Not…), but the motivation always fades. Before long, I’ve left behind another digital graveyard of things I once thought I should do.
The promise of these apps is that they’ll let us capture everything so we can rest easy knowing we won’t forget. But that’s the problem: they never let us forget! The constant reminder of unfinished tasks clutters my brain.
Forgetting is a feature of memory, not a bug. You let the unimportant stuff fade so you can focus.
I know, you don’t have to see all your tasks at once. You can focus on what’s due today while everything else sits in the backlog. But I know it’s there, and it stresses me out. What if I missed a few things two days ago, and then another yesterday? I open the app and see a growing list of overdue tasks. Some people can calmly sort through them—decide what’s still important, move things around, delete the rest.
I’m not one of those people. I’m a hoarder. I have a hard time throwing things away—or removing apps from my phone—and that extends to tasks. What if I need them again someday?
You know what’s actually worked for me, for years?
A paper notebook. 1
I write tasks down as they come. When I finish one, I check it off. A single page usually lasts me a few days or weeks. When it fills up, I turn the page and I’m forced to make decisions: which uncompleted tasks do I bring over?
That friction of having to manually re-write incomplete tasks forces me to ask whether they’re actually worth doing. And that’s what to-do apps have been missing!
On paper, the default is that incomplete tasks “disappear” when you turn the page. In digital apps, the default is that they become “overdue” and haunt you. Even if they get hidden in a backlog, I still know they’re there—and that knowledge alone creates guilt. I end up browsing through old tasks, resurrecting ultimately useless ones just because I feel bad for not having done them.
I built my own to-do app where, at the end of the day, unfinished tasks just… vanish. They go away! Better yet, they don’t just vanish. When you open the app in the morning, it shows you the list of tasks you didn’t finish yesterday. There’s only one possible action: delete the list! You can’t roll tasks over to the next day.
If you see something important—something you actually want to do—you have to remember it for a few seconds and re-write it yourself. How many unimportant tasks survive that process? Not many, maybe none! And that’s the point: no backlog, no guilt.
It’s surprisingly freeing. You should try it—and you can! Right here.
There’s a link in the settings to email me feedback if you’d like.
Note: it’s a Progressive Web App, not just a website. You can “install” it and use it offline! Here’s how.
I recently switched to an E-Ink writing tablet—the Onyx Boox Go 10.3”. Highly recommended if you’re into that sort of thing. 
↩
The design of the platform was mostly complete, and I turned the designs into reusable components and responsive styles. I also created some tricky internal pages and flows using the newly established design patterns.
I was initially brought on for UI Design, but over time my role evolved into what we now call Product Design, spanning everything from visual design to component systems and behavior analytics.
I can’t share details due to the NDA, but here’s the gist of my 2.5 years at Shopflix:
I spent most of my time patching up existing designs as they were being implemented, and rushing to design new features using problematic components in the name of speed and consistency. Alongside that I was creating ad-hoc marketing assets while building a component library in Figma and laying the foundations of a design system on the side.
Due to the replatforming taking place at the same time, rethinking flows was off the table. I hated adapting work I believed was poorly thought-out, but I developed something unique:
I turned complete pages into components (with variables) that I could drop into any flow, ensuring all user journeys would always display the latest version. This solved a major issue: developers would often start working on a feature many months after I’d designed it, and by then there were updates to pages within that flow. Before this approach, they kept accidentally rolling back each other’s work because each person was looking at a different version!
Here’s the component system in action:
With a major deadline gone, I finally had the freedom to explore and pitch improvements. But most of my usability-focused proposals initially got shelved.
That phase taught me as much about organizational dynamics as it did about design at scale. I gradually built stakeholder buy-in by consistently shipping good work, sharing honest opinions, and pushing back when needed. I also got involved with anything I could help improve, even outside my defined role.
My persistence paid off because on Year 3 an organizational shift allowed me to work on the kind of projects I wanted to from the beginning: remaking core flows from scratch.
As of writing this, the bulk of my design work has not been implemented yet (so I can’t show it here 😮💨), but it includes major updates for the:
We’d long been aware of the shortcomings, but conflicting priorities did not previously allow the time to address them. I can’t describe the satisfaction I felt seeing the enormous usability improvements and it goes without saying that I can’t wait to see them live!
I left Shopflix knowing it’s on a much better trajectory than when I joined, and I’m confident that the team will continue doing great work to bring the platform to the state we know it can reach!
]]>
I wanted to create a single variable in my CSS, e.g. --brand: #ff6800;, and have an entire color scale (with variables like --brand-10: #ffe4d3; --brand-20: #ffd2b2; and so on) automatically “generated” for me. Like this! ⤵︎
Similar to what you get from sites like uicolors.app’s Tailwind CSS Color Generator, but locally, in your CSS file.
Why? When playing around with a new design, not yet sure which colors to go with, being able to tweak a couple of values directly in my CSS and preview my own design in different colors would be super practical.
Now, you might be wondering:
These people have done a much better job explaining than I could at the moment:
OK, OKLCH: a color picker made to help think perceptively, by Evil Martians
“OKLCH is a new way of encoding colors (like HEX, RGBA, or HSL). It always has predictable lightness after color transformations (compared to HSL), it’s capable of encoding a wider range of colors, it offers native browser support, and unlike LCH and Lab, it has no hue shift when chroma is changed.”
It’s Time to Learn oklch Color, by Keith J. Grant
“In HSL, 100% saturation is simply as saturated as that particular color can be in the sRGB gamut. In OKLCH, the values aren’t based on technical limits or a mathematical definition, but rather on perceived equality. The amount of lightness indicates exactly how bright the color is, and the amount of chroma indicates exactly how vivid it is. The human eye perceives some colors like green or yellow to be brighter than others, like blue or purple, and OKLCH takes these details into account.”
The gist of it is that, similar to HSL, you can keep the Hue constant while adjusting the Lightness and Saturation (Chroma, in this case) independently. What sets OKLCH apart is that, unlike HSL and the others, all colors with the same hue actually look like they have the same hue! You know how making a vibrant blue lighter makes it look purple? Well, in OKLCH it still looks blue!
You can also use oklch(from…) to convert HEX, RGB, etc. colors into OKLCH and then mess with their Lightness, Chroma, and Hue.
Firstly, I used the numbering format from the Tailwind color scales for familiarity.
Then I tried using oklch(from…) and adjusting the Alpha value to create a scale. But then colors on the scale could not be darker than the original. And if they ever overlap (think, text color with 80% opacity + background at 30%) then the color on top will be a mix of the two!
So I switched to using calc() instead of L and C values within oklch() and keeping the hue value the same.
I first created a color scale using an online generator, then converted to OKLCH and used a spreadsheet to calculate the difference between the Lightness and Chroma values of each color. I rounded those up and created variables in my CSS to represent the Lightness increment and the Chroma increment separately.
:root {
/* Base color */
--brand: #0d1bbd;
/* Lightness and Chroma increments */
--l-increment: 0.075; /* UP: Lighter*/
--c-increment: 0.028; /* UP: LESS saturated*/
/* Some of the resulting color tokens */
--bg-brand-50: oklch(from var(--brand) calc(l + calc(var(--l-increment) * 8)) calc(c - calc(var(--c-increment) * 8)) h / 1);
/* … */
--bg-brand-800: oklch(from var(--brand) l c h / 1); /* This is the base color */
/* … */
--bg-brand-950: oklch(from var(--brand) calc(l - calc(var(--l-increment) * 2)) calc(c - calc(var(--c-increment) * 2)) h / 1);
}
That seemed to work exactly how I imagined!
For that specific color…
Obvious in hindsight: that method only works if the base colors all have similar Lightness and Chroma. There’s no way to create conditional statements (“if this, then that”) in CSS, so a base color would always have to occupy the same step on the color scale.
That can be sorted by spending a bit of extra time choosing base colors. Problem solved? Not so fast! Because of the way OKLCH works, some HEX/RGB/HSL colors do not have an OKLCH equivalent!
oklch(from…) works by converting, say, a HEX value into OKLCH. But that means if you’re using HEX for your base variables, some colors are bound to look less saturated than the rest even if you max out their saturation in the HEX color space.
Switch to OKLCH for the base color variables. Then you can make sure the lightness and chroma of each color are the same, or close enough. Now, you do miss out on a couple of things when you do that…
But hey—it works! :D And changing a single number to get an entirely new color scale is kinda fun, like a design nerd’s slot machine. I figured this technique might be useful (and/or fun) to someone, so why not share.
Here’s the CSS you can use:
:root {
/* Base colors */
/* Change the HUE (last number) for different colors. */
/* You might wanna change the Lightness and Chroma slightly too in some cases. */
--brand: oklch(0.40 0.30 265.71);
/* add more variables here */
/* Adjuts scales */
--l-increment: 0.075; /* UP: Lighter*/
--c-increment: 0.028; /* UP: LESS saturated*/
/* Color tokens */
/* Use them in classes like this: var(----bg-brand-600) */
--bg-brand-50: oklch(from var(--brand) calc(l + calc(var(--l-increment) * 8)) calc(c - calc(var(--c-increment) * 8)) h / 1);
--bg-brand-100: oklch(from var(--brand) calc(l + calc(var(--l-increment) * 7)) calc(c - calc(var(--c-increment) * 7)) h / 1);
--bg-brand-200: oklch(from var(--brand) calc(l + calc(var(--l-increment) * 6)) calc(c - calc(var(--c-increment) * 6)) h / 1);
--bg-brand-300: oklch(from var(--brand) calc(l + calc(var(--l-increment) * 5)) calc(c - calc(var(--c-increment) * 5)) h / 1);
--bg-brand-400: oklch(from var(--brand) calc(l + calc(var(--l-increment) * 4)) calc(c - calc(var(--c-increment) * 4)) h / 1);
--bg-brand-500: oklch(from var(--brand) calc(l + calc(var(--l-increment) * 3)) calc(c - calc(var(--c-increment) * 3)) h / 1);
--bg-brand-600: oklch(from var(--brand) calc(l + calc(var(--l-increment) * 2)) calc(c - calc(var(--c-increment) * 2)) h / 1);
--bg-brand-700: oklch(from var(--brand) calc(l + calc(var(--l-increment) * 1)) calc(c - calc(var(--c-increment) * 1)) h / 1);
--bg-brand-800: oklch(from var(--brand) l c h / 1);
--bg-brand-900: oklch(from var(--brand) calc(l - calc(var(--l-increment) * 1)) calc(c - calc(var(--c-increment) * 1)) h / 1);
--bg-brand-950: oklch(from var(--brand) calc(l - calc(var(--l-increment) * 2)) calc(c - calc(var(--c-increment) * 2)) h / 1);
}
I originally planned to name this post “What I learned making an OKLCH color scale generator in CSS” and it was gonna have a section titled “Why it failed”. While writing that I realized… I had not failed. I just needed to tweak some Chroma values (and mention some caveats)! ;)
…to Dragos for nagging me about how cool OKLCH is for months, until I checked it out. 😁
]]>Καμία φόρμα επικοινωνίας. Αντί αυτού, γραπτές οδηγίες για το τι να γράψεις στο email που θα στείλεις για να ζητήσεις μεταφορά.
Χωρίς analytics, χωρίς φόρμα, χωρίς τρόπο να μετρήσει αν το site δουλεύει.
Κάνε μια αναζήτηση για “free bootstrap marketing templates” και θα σου φανούν πολύ γνώριμα.
Δες παραδείγματα από το portfolio μου
Πριν το web development δούλευα σε supply chain και operations. Έχω δει πρώτο χέρι πώς κακοσχεδιασμένα συστήματα σπαταλούν χρόνο και χρήμα. Το ίδιο ισχύει και για website — αν δεν δουλεύει, κοστίζει.
Δεν έχω στόχο να φτιάχνω «ωραία» site που δεν κάνουν τίποτα, αλλά όμορφα και χρηστικά εργαλεία που δουλεύουν.
Αυτό περιλαμβάνει:
Θα μπορούσα να φτιάχνω copy-paste sites με template, να τελειώνω γρήγορα και να πληρώνομαι το ίδιο. Αλλά δεν μπορώ να το κάνω με ήσυχη συνείδηση.
Αν θες ένα site απλά για να υπάρχει, δεν είμαι η σωστή επιλογή. Αν θες ένα site που να δουλεύει για σένα, θα χαρώ να μιλήσουμε.
And the model makes sense! Especially for early-stage startups who need ongoing design support but might not want to hire someone full-time for a variety of reasons—including not knowing whether the business will still be around five months down the line. (Which probably explains why this setup is more common in the US, from my limited perspective, where startups come and go by the minute.)
A lot of these are solo designers calling themselves an “agency.” Now, sometimes a single freelancer has a network of collaborators they bring in as needed. Or they’re just starting out and looking to grow soon. That’s a bit of a gray area, and in that case “studio” or “agency” might make sense.
But that’s not what I’m referring to here. I’m talking about people who proudly say, “When you work with Studio XYZ, you work only with me. No other collaborators.” So far, still fine!
What’s not fine, in my opinion, is writing—on the same landing page—something like:
“Ditch unreliable freelancers today and work with Studio XYZ instead!”
But… you are freelancer too! 😅 You’re just hoping prospective clients won’t notice. Sure, it’s technically stated that they’ll be working with you alone, but then why present yourself as an agency in the first place?
That’s what bugs me. Not the model itself, but the almost dishonest positioning.
Then there’s the way the service is often structured: You pay → You get a Trello board → You add cards → You get “deliverables”
Simple. Transactional. Trello becomes a prompting box and the designer becomes ChatGPT.
Maybe there’s more going on behind the scenes though. Maybe the designers hop on calls, ask thoughtful questions, and push back when needed, and Trello is simply their project management tool of choice! But that’s not the idea you get from the landing pages. They pitch the service as a UI vending machine, so I’m inclined to believe that’s what it is.
That messaging shapes expectations; not just those of the given clients, but of the entire industry. It reinforces the idea that the value of design lies in how many mockups you can produce, and how quickly.
Another pattern I’ve noticed: almost every one of these sites has an FAQ section that starts with: “Why not hire a full-time designer instead?” And the answer is always some variation of: “Because a full-time hire costs $100K+/year, and I only cost $5K/month.”
Which might sound like a deal for a sec; until you remember that $5K month is $60K/year—for part-time availability. Not such a dramatic difference.
Of course, not everyone needs a full-time designer! In many cases, working with a freelancer or a small studio makes more sense. But if your selling point is “I’m the same but cheaper” (and that isn’t even entirely accurate) I don’t think you’re doing anyone a service.
To be clear: I love the idea of making good design more accessible, and retainer models are great. Also, sometimes a client simply needs some mockups, shipped fast. Maybe to show them around and validate an early idea; perhaps to put a fresh coat of paint onto a legacy app that they don’t have the resources to fully remake just yet. And that’s totally fine! But these subscription services are often presented as the ideal setup for every company, and that’s just misleading.
Basically: you wanna sell design subscriptions? Totally fair and welcome! Just don’t be sleazy about it and be mindful of what expectations you’re creating.
Curious to hear from you:
You know where to find my email ^-^
]]>This isn’t a critique of Tailwind or utility classes as a concept—they’re great, especially for solo developers or very small teams. But in larger organizations, like when you have a frontend team of 10+ developers, Tailwind can cause just as many problems as it solves.
Let me explain.
Speed and perceived simplicity.
Tailwind’s big selling point is that developers don’t have to write custom CSS. You see a design in Figma, and you translate it directly: p-4 for 16px padding, bg-white for a white background, and so on. This can help avoid situations where different developers name similar classes differently—like one using .card-padding and another using .tile-padding for the exact same spacing.
So far, so good.
But what happens when a design calls for 15px padding? One dev might round up to p-4 (16px), another might round down to p-3 (12px), and yet another might use p-[15px], effectively creating a new class.
Now, you might say, “If the team agreed to use Tailwind, then designs in Figma shouldn’t use 15px padding in the first place.” Fair—but it’s not that simple. (See “Consistency through code” below.)
Say you want to change all card backgrounds from white to grey. You search for bg-white, but now you risk changing buttons or other sections too—because utility classes don’t tell you where they’re used. Tailwind doesn’t distinguish between a card, a section, or a button. That knowledge lives in the developer’s head (or in documentation, which starts to defeat the purpose of using Tailwind. More on that below.)
Many teams adopt Tailwind because it’s “flexible.” You can build “anything” with it. But that’s exactly the problem. You’re not building anything—you’re building a very specific thing. So you don’t need flexibility—you need consistency.
Tailwind’s verbose syntax becomes more unwieldy when you factor in dark mode and responsive design.
Want a background that’s light red in light mode and dark red in dark mode?
bg-red-200 dark:bg-red-800
Want card padding to adjust between mobile and desktop?
sm:p-2 lg:p-4
That’s fast to write—you don’t need to create custom classes or media queries.
But… where does the mapping between
red-200andred-800live? Or betweenp-2andp-4?
In the developer’s or designer’s head!
Unless you document it. But once you’re writing docs to enforce consistent use of utility classes, are you really saving time? You’re actually building your own design system on top of Tailwind.
Compare that with using a semantic class like product-card, which already handles different themes and viewports behind the scenes.
Figma designs should aim for consistency, but ultimately, code is the final product. A perfectly consistent Figma file is irrelevant if the implementation isn’t. Likewise, inconsistencies in Figma don’t matter as long as they don’t carry through to production code.
The idea that Figma should be the single source of truth for consistency falls short. Figma has helpful tools like components, styles, and now variables—but it’s still easy to accidentally “detach” things, especially during experimentation. Code, on the other hand, requires deliberate effort to introduce inconsistencies. Accidentally typing p-13 is far less likely than detaching a style variable in Figma.
Often, the push to create a super-flexible CSS system stems from a lack of collaboration between design and dev teams. A dev might think, “Who knows what the designers will change next? We need something that can handle anything.” But imagine if both teams worked together to define naming conventions and constraints from the start!
A well-defined system can live in both CSS and Figma. It helps both sides stay aligned. Naming variables semantically—like padding-card or padding-section—provides a built-in check. If someone tries to use padding-section on a product card, it raises red flags.
grid grid-cols-2 sm:grid-cols-3 over one-off CSS classes any day.padding-card, padding-section—you can apply them consistently across components and breakpoints.The issue isn’t utility classes themselves. It’s relying on an enormous set of them without any guidelines.
You pay for shortcuts down the road. Tailwind’s flexibility becomes a liability when you’re trying to build something consistent with a team.
The ability to build “anything” is less valuable than the ability to build one thing well. And doing that requires adding constraints—not avoiding them.
]]>