Many were in fact easily translatable, some had wrong definitions, a few were duplicates, one was Latin, and some were recently coined Greek-sounding words! I emailed the site’s owner and it’d be cool if they updated it, but this seems like an old side project, so we’ll see.

In any case, I didn’t want to feel like I might have completely wasted my effort, so here I am sharing the words, with the correct definitions, and my favorite wrong ones.

Context

Eunoia.world is an online directory of “untranslatable words”, AKA words without a direct, single-word translation in most other languages.

Anyone can “suggest” a word for the site’s owner to add to the list.

What I found fascinating is that, apparently, some people suggested common Greek words, but with highly romanticized, fancy definitions that are simply untrue.

The romanticized ordinary words

Volta

• Greek: βόλτα
• Real meaning: walk, stroll. As in, “I’m going for a walk”.
• Eunoia “definition”: “During certain hours of the early evening, around dusk, everyone in the town who might feel like going for a walk takes a saunter or stroll up and down the main street”.

Just… what? That’s not a definition! It’s a description of a behavior. Someone tried to make this standard Greek word (of Italian origin, actually) sound like a profound tradition, when it’s just a word. Some people just like to go for walks, some around dusk. It’s not deep.

Parea

• Greek: παρέα
• Real meaning: friend group, clique.
• Eunoia “definition”: “A group of friends who regularly gather together to share their experiences about life, their philosophies, values and ideas.”

All of that additional stuff is completely invented out of thin air. Again, someone was trying too hard to make a standard Greek word sound much deeper than it is.

Andria

• Greek: ανδρεία
• Real meaning: courage.
• Eunoia “definition”: “Both valour and courage, expressed in actions in front of the face of danger”.

Whoever wrote this was trying too hard. Incidentally, this word’s root is the Greek word for “man”. So it literally means something like “the essence of masculinity”…

Eunoia

• Real meaning: favor, goodwill.
• Website “definition”: A well-mind; beautiful thinking.

Ironically, despite being the domain name of the site, Eunoia itself is translatable. It means “favor”, as in “he invited the one he favors”. It’s used in figures of speech like “to be favored by luck” (έχει την εύνοια της τύχης).

It does literally mean “good mind” (ευ + νους), but that’s not what it actually means. Not even in ancient Greek. “Good mind” (or “good thinking”) was meant metaphorically, as in “my thoughts towards you are good” → you have my goodwill, my favor.

The made-up ones

Anemoia

• Eunoia “definition”: “Nostalgia for a time that you have never lived”.

I was confused because I first read this as “Anemia” (lack of hemoglobin). But it’s actually not a Greek word at all. It was coined in 2012 by John Koenig for his project The Dictionary of Obscure Sorrows. In other words, not a real word.

Euneirophrenia

• Eunoia “definition”: “The peace of mind that comes with having pleasant dreams.”
• It was also misspelled as “Eunoirophrenia”

This isn’t a real Greek word. It looks like a blend of ευ (“good”) + όνειρο (“dream”) + φρήν (“mind”). Someone must have “coined” it recently, although I can’t find out who. Listicle writers (as usual) didn’t do their research and started presenting it as a real Greek word.

But if you search for this word on Google in Greek (“ευνειροφρένια”), there are literally 0 results — what a rare sight! It’s only in English that you get results. So much for being an untranslatable “Greek” word ;)

I suppose after this post gets indexed, there’ll be a single result. 🤔

The love types

In the 20th century, writers like C.S. Lewis and John Alan Lee borrowed Greek and Latin words as the names for love styles they came up with. Years later, online listicles started presenting them as ancient Greek concepts, but they’re not.

Understandably, some people came to believe that the meaning of those Greek and Latin words = the love type the writers described. I don’t mind the oversight because it introduced me to John Alan Lee, who has done quite a few interesting things in his life.

Agape

• Greek: αγάπη
• Real meaning: love.
• Eunoia “definition”: selfless love to all, universal loving kindness

Nope, it’s just “plain” love. A great concept indeed, but decidedly not untranslatable.

Philia

• Greek: φιλία
• Real meaning: friendship.
• Eunoia “definition”: “‘highest form of love’; deep love between friends, brotherly love”.

This one is also just “friendship”. There’s no other word for “plain” friendship, as opposed to this supposed “deep love between friends”.

Pragma

• Greek: πράγμα
• Real meaning: thing, object.
• Eunoia “definition”: “longtime love, such as in long marriages”.

Pragma was John Lee’s nickname for “pragmatic love”.

Ludus

John Lee’s “playful love”. This one isn’t even Greek. It’s Latin.

The actually untranslatable ones

After this exercise, I was left with a list of actually untranslatable Greek words, which I present to you below.

• Akrasia
  • Greek: ακρασία
  • Acting against your own better judgment; lack of self-control. Literally “lack of power (over yourself)” (α- “not” + κράτος “strength, power”). Inability to “hold” oneself back (κρατάω = hold). Note: I’d never encountered this word.
• Charmolypi
  • Greek: χαρμολύπη
  • Joy mixed with sorrow; bittersweet. Literally “joy-sorrow” (χάρμα “joy” + λύπη “sorrow”). Note: I’ve never encountered this word. It’s apparently rare and literary.
• Evdaimonia
  • Greek: ευδαιμονία
  • Intense happiness; a state of flourishing and good fortune. Literally in “good spirits” (ευ “good” + δαίμων “spirit”).
• Filotimo
  • Greek: φιλότιμο
  • The inner impulse to act well and in line with the moral virtues of your society and upbringing. Literally “love of honor” (φίλος “dear, loving” + τιμή “honor”).
• Meraki
  • Greek: μεράκι
  • Doing something with soul, creativity or love; putting something of yourself into it. From Turkish merak (“curiosity, keen interest”).
• Nipenthes
  • Greek: νηπενθές
  • In the Odyssey, a fictional drug that makes you forget grief. Literally “no grief” (νη- “not” + πένθος “grief”). Note: had to look this one up. Not sure it qualifies as a real word, since it’s the name of a fictional drug.
• Polytropos
  • Greek: πολύτροπος
  • “Of many ways”: versatile, cunning, much-wandering. Homer’s epithet for Odysseus in the first line of the Odyssey. Πολύς “many, much” + τρόπος “way”.
• Ripsaspis
  • Greek: ρίψασπις
  • One who throws away his shield in battle; a coward or deserter. Literally “shield-thrower” (ρίπτω “throw” + ασπίς “shield”).
• Sofrosyni
  • Greek: σωφροσύνη
  • Self-control, moderation and sound judgment. Literally “sound mind” (σώος “sound” + φρήν “mind”).

When you’re in high school, ‘the adults’ love to tell you that these are the best years of your life. They say you’ll wish you could be 18 again; that being an adult sucks because you have a job and responsibilities.

Maybe that was true for them. It sounds like life was more linear and less free back then.

For me though, my 20s have been better than my teens in nearly every way. For example, today:

• I look forward to work instead of dreading school. No contrived exercises, seemingly designed to bore me out of my mind, but real problems I can solve to grow and build a body of work I’m proud of.
• I decide what I do with my day and how I live my life. Nobody dictates my schedule anymore. (Which I admit, can sometimes be a negative, but it’s mostly positive.)
• I’m stronger and healthier as a result of more knowledge around fitness and practicing strength training.
• I’m treated and respected as a person. I don’t see this getting discussed enough: when you’re a kid, most adults treat you more like a pet than a human. Your thoughts, ideas, and agency often get overlooked, if not trampled.

Teenage years do have one thing going for them: they’re full of firsts, and you can’t have those twice! That makes them vivid in memory and easy to be nostalgic about (I reminisce a lot), even when that period of your life was worse by objective measures.

School wasn’t for me. You’re told what to do and how to do it, then judged on standardized tests you never wanted to take. Some people thrive in that system and that’s amazing, but I couldn’t. I stopped caring about subjects like chemistry and spent class time drawing, which disappointed my teachers and quite a few other people. I spent all day on the computer, following my interests down rabbit holes. I didn’t know what I wanted yet, but I knew what I didn’t want, and that was enough to guide me.

I should say I was also very lucky. I had my family’s support then and still do, so I never had to worry about putting food on the table. That gave me far more room to maneuver than many: I could say no to things that weren’t a good fit, trusting that something better would come along later.

In my 20s so far I’ve had five jobs and changed careers twice.

My first career was operations management in intra-community imports and exports. (I wonder, does that sentence mean anything to anyone reading this?) I got good at it: built my own systems in no-code databases, became the person who could figure anything out, and set things up so everyone around me worked more efficiently. Within that little bubble, I was in demand. The problem was that I was bored and saw it as a dead end. Couldn’t imagine myself in that industry long term.

I’ve always been into computers (my parents love to tell people I knew how to type before I knew the alphabet), so that ended up leading me to web design and development. It’s a long story and one day I’ll write a blog post about it. The short of it is that I found work at a web design agency but the pay wasn’t good, so I quickly left to do operations again. This time though I had my own website and took on design gigs on the side. That eventually landed me a role at a Greek startup, and later led me to my current role at a US startup, which allowed me to spend a full month traveling across the US—a literal dream trip!

I’ve made some good friends in my 20s (mostly online) who support me personally and professionally, and whom I can have long, interesting conversations with. I’m also still close with friends from elementary and middle school, even if I rarely see most of them.

There’s plenty of room to improve, plenty of surface to build on, and I’m optimistic. I still have moments where everything feels pointless, but then I look back at how far I’ve come and imagine how much further I can go. These are turbulent times, in tech and in the world at large, and the only thing to do is keep moving forward.

Here’s to the next 10 years.

TL;DR

Clue started getting on my nerves, so I made my own alternative, Hema. It’s a free, open-source web app that works offline. You can export and import your data as a JSON file.

What I made

A super simple progressive web app called Hema (from the Greek αίμα, aima → hema, meaning “blood”).

You can quasi “install” it and use it offline, even though it’s technically a website. You can export and import your data as JSON. Thankfully Clue also exports JSON, so all my periods from the past 9 years are already in it. You can’t import Clue exports directly into Hema (yet), but it’s trivial to hand the file to an LLM and ask it to convert it to Hema’s much simpler format.

It has everything I need and nothing I don’t:

• A calendar where you log your period with a single tap. No menus, no save buttons.
• Optional flow heaviness (tap again to adjust), shown as taller and shorter bars.
• A log page to see previous periods and visually compare their duration.
• Fertile window prediction you can turn off.
• Monday as the default start of the week (or Sunday, one tap).
• The ability to exclude atypical periods so they don’t mess up predictions.

What’s the catch?

• No notifications. I haven’t found a reliable way to make PWA notifications work (even though it’s supposedly possible).
• You have to remember to back up your data; it can’t happen automatically.

Why I made it

I’ve been using Clue for almost 10 years. When I first started, it was pretty good. What stood out at the time was the neutral styling: red for blood, blue for ovulation, no flowers, stickers, or cutesy pink graphics. Every other period app looked too childish for my taste.

The deterioration of Clue

But over the years it slowly became enshittified.

Full-screen premium pop-ups every time I opened the app were one thing (devs have to make money after all, that’s fair). But then came a “content” tab with articles like “Where is the clitoris?” (which, considering the target audience, I find infantilizing), constant promos for new features I didn’t want, surveys, and partnerships with hardware I wasn’t using.

But what really made me think “I’m gonna make my own fucking app” was the notifications like “It is now your luteal phase! Find out what’s happening”, which you can’t turn off without also disabling the period prediction reminders.

Meanwhile, every few updates, features I liked disappeared. For example, flow intensity used to be represented by taller and shorter bars in the calendar—now it’s color-coding that’s harder to parse at a glance. You used to be able to compare cycle lengths visually; that vanished too. And still no way to set Monday as the first day of the week!

All in all, I was getting more and more frustrated with Clue, until this weekend, when I told myself enough is enough and got to work with Cursor.

Think about it. Why does your gender have to be part of every single sentence that’s ever spoken or written about you?

Imagine a pronoun specifically for Black people. Imagine that, if talking about a Black man, you had to use “ze” instead of “he” for your English to be “grammatically correct”. I’m sure there would be people who’d say, “It’s not racist, it’s just grammar!” But you and I both know, it would be racist as fuck. Why else would you create a pronoun to refer to a specific group of people, grouped by an arbitrary characteristic that you decided is socially important?

Now, I know this isn’t a perfect analogy. In my hypothetical scenario, we’d be making a new pronoun out of the blue, but for all we know, he and she have been with us since the dawn of time. (Which isn’t true, by the way. And while many languages have gendered pronouns, many do not.)

It’s still worth wondering why personal pronouns came to be gendered in the first place. I don’t know the answer to that, and it’s likely nobody ever will. But my guess is that it had something to do with social status and hierarchy. I’m guessing that because of how we treat animate (he/she) vs inanimate (it) pronouns today: it would be offensive to call a human “it”, but it’s OK to call a dog that. He/she > it. Are he and she equal? Perhaps today. Is it a stretch to imagine it used to be he > she > it? After all, in many parts of the world, that hierarchy is still very much alive.

Are you starting to see my problem with gendered pronouns?

I still remember stumbling upon this experiment that found that simply asking female students to fill out a demographic questionnaire before a math test, thereby reminding them of their gender, negatively affected their scores.² Guess what gendered pronouns do? Remind people of their gender! And of the fact that their gender is so significant that it has to be mentioned, regardless of what is being said about them.

If I say “she is a doctor”, you know I’m talking about a female human. But you know nothing else. What is their hair color? Skin color? Age? Doesn’t matter! If it did, I could specify (“She is 32 years old. She has blond hair.”) But gender? Well, that one characteristic is so important for some reason that I just need to mention it to be “grammatically correct”.

Humans reproduce through a binary sex system: male sperm fertilizes a female egg. That’s not up for debate.³

But choosing to divide the population based on reproductive biology, and use different pronouns to refer to them, and making it a grammatical necessity that we use these pronouns in almost every sentence… well, those are arbitrary decisions our society has made, and can therefore undo.

I hope the current discourse around pronouns leads people to question why they are gendered at all. That’s the conversation I want to have.

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.

• We’re live in the US on Jest.com
• Learn more on our corporate website, about.jest.com
• If you’re a game developer or studio, check out the Jest Games Fund for up to $1M in support to publish your game on Jest!

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:

• Take half of the screen.
• Subtract half of the max-width container from it OR half the screen (in which case the result is 0), whichever is smaller. This gives us the effective margin on each side.
• Add the container padding. Now we have the exact distance between the content of the other sections and the edge of the viewport on each side!

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.

Table of contents

• My approach
• Going live: Hosting
• Making sites editable
• Templating Languages
• Getting a domain name
• Setting up custom email

My approach

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).

Going live: Hosting

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.

Making sites editable

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.)

Alternative CMS options

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.

Templating Languages

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.

Getting a domain name

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.

Setting up custom email

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.

Second brain, anyone? 🧠

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?

What works

You know what’s actually worked for me, for years?

A paper notebook. ¹

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.

The digital equivalent?

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.

Try it!

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 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:

Year 1

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:

Year 2

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.

Year 3

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:

• Checkout Flow
• Product Page
• Homepage
• Orders
• Cart

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!

The idea

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:

What is OKLCH?

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.

What I did

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…

Obstacles

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.

Solution

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…

• You can’t just enter any color you like and get a color scale. You need to find its OKLCH Hue and input that instead. The original color might not even be part of the resulting color scale.
• Design tools like Figma do not support OKLCH, so you have to figure out the hue by other means.
• Code editors like VS Code don’t natively preview OKLCH colors like they do HEX, RGB, etc. You need to install an extension if you want that, but it can really slow down the app.

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);

}

Disclosure

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)! ;)

Special thanks…

…to Dragos for nagging me about how cool OKLCH is for months, until I checked it out. 😁