I help startups with the UX/UI and web design of their products. This includes web apps, websites, landing pages, copywriting, and I can assist with frontend development where needed. My background of launching my own products and being a full stack developer helps me create practical designs that balance usability, aesthetics, development effort, and performance. I work to fixed price quotes for self-contained projects.
---
The best live example of my work is Checkbot (https://checkbot.io/), a browser extension that tests websites for SEO/speed/security problems. The entire project is my own work including coding the extension itself, UX/UI design, website design (the homepage is optimised to load in 0.7 seconds, 0.3MB data transferred), marketing, website copy, and website articles on web best practices.
[ Rated 4.9/5, 80K+ active users, 100s of paying subscribers ]
---
I have 10+ years of experience, including a PhD in software verification and 5+ years working for myself helping over 25 companies including Just Eat, Triumph Motorcycles and Fogbender (YC W22). See my website for testimonials, portfolio and more: https://seanw.org
Note: For large projects, my partner usually assists me in the background (I’m working on starting a design studio with her in the future)
---
Email sw@seanw.org with a short description of 1) your project 2) how you think I can help 3) the business outcome you’re looking for and 4) any deadlines. I can get back to you in one working day to arrange a call to discuss a quote and how we can work together!
There's also the significant cost to climate change because growing crops to feed to animals instead of eating crops directly loses the majority of calories, but it gets ignored because doing something about it is going to be unpopular:
> More than three-quarters of global agricultural land is used for livestock, despite meat and dairy making up a much smaller share of the world's protein and calories.
> Despite the vast land used for livestock animals, they contribute quite a small share of the global calorie and protein supply. Meat, dairy, and farmed fish provide just 17% of the world’s calories and 38% of its protein.
> Livestock are fed from two sources – lands on which the animals graze and land on which feeding crops, such as soy and cereals, are grown. How much would our agricultural land use decline if the world adopted a plant-based diet?
> Research suggests that if everyone shifted to a plant-based diet, we would reduce global land use for agriculture by 75%.
In the US 8 out of the top 10 environmental organizations with most membership oppose nuclear power broadly and the majority oppose wind and solar locally so I think we can safely conclude that climate change is not important to US environmental causes.
The primary work by US environmentalists (or at least the popular ones) is in ensuring rich people’s homes abut publicly-maintained parks.
Not really; but talking about it more also seems like it will have approximately zero marginal benefit, and trying to insinuate that other people are immoral is probably net counterproductive.
If the goal of the post is to pick terminal colors that contrast on both white/light and black/dark backgrounds, it means you're stuck with midtone colors (between light and dark). This is really limiting for color choice (there's no such thing as "dark yellow" for example), and lowers the maximum contrast you can have for text because you get the best contrast when one color is dark and the other is light.
Ideally, instead of the CLI app switching to "bright green", it would pick a "bright contrasting green". So if the terminal background was dark, it would pick bright green, and for light background it would pick a darker green. There isn't CLI app implementations for this? This is similar to how you'd implement dark mode in a web app.
> Ideally, instead of the CLI app switching to "bright green", it would pick a "bright contrasting green". So if the terminal background was dark, it would pick bright green, and for light background it would pick a darker green. There isn't CLI app implementations for this? This is similar to how you'd implement dark mode in a web app.
The responsibility for this lies with the color scheme not the terminal program.
It's not recent, and most terminals support it. You send an escape sequence to the terminal, and get back a sequence that tells you the exact background color.
That's called `\e[0;92m`, aka the ANSI terminal espace sequence for bright green. You have 15 others, that will be displayed however the terminal's user wants. They're already available in most terminal color libraries, too.
I wish one of those regex libraries that replaces the regex symbols with human readable words would become standard. Or they don't work well?
Regex is one of those things where I have to look up to remind myself what the symbols are, and by the time I need this info again I've forgotten it all.
I can't think of anywhere else in general programming where we have something so terse and symbol heavy.
It’s been done. Emacs, for example, has rx notation. From the manual:
35.3.3 The ‘rx’ Structured Regexp Notation
------------------------------------------
As an alternative to the string-based syntax, Emacs provides the
structured ‘rx’ notation based on Lisp S-expressions. This notation is
usually easier to read, write and maintain than regexp strings, and can
be indented and commented freely. It requires a conversion into string
form since that is what regexp functions expect, but that conversion
typically takes place during byte-compilation rather than when the Lisp
code using the regexp is run.
Here is an ‘rx’ regexp(1) that matches a block comment in the C
programming language:
(rx "/*" ; Initial /*
(zero-or-more
(or (not "*") ; Either non-*,
(seq "*" ; or * followed by
(not "/")))) ; non-/
(one-or-more "*") ; At least one star,
"/") ; and the final /
or, using shorter synonyms and written more compactly,
(rx "/*"
(* (| (not "*")
(: "*" (not "/"))))
(+ "*") "/")
In conventional string syntax, it would be written
"/\\*\\(?:[^*]\\|\\*[^/]\\)*\\*+/"
Of course, it does have one disadvantage. As the manual says:
The ‘rx’ notation is mainly useful in Lisp code; it cannot be used in
most interactive situations where a regexp is requested, such as when
running ‘query-replace-regexp’ or in variable customization.
Raku also has advanced the state of the art considerably.
> They act as stand-ins for actual users and will flag all sorts of usability problems.
I think everyone on the team should get involved in this kind of feedback because raw first impressions on new content (which you can only experience once, and will be somewhat similar to impatient new users) is super valuable.
I remember as a dev flagging some tech marketing copy aimed at non-devs as confusing and being told by a manager not to give any more feedback like that because I wasn't in marketing... If your own team that's familiar with your product is a little confused, you can probably x10 that confusion for outside users, and multiply that again if a dev is confused by tech content aimed at non-devs.
I find it really common as well that you get non-tech people writing about tech topics for marketing and landing pages, and because they only have a surface level understanding of the the tech the text becomes really vague with little meaning.
And you'll get lots devs and other people on the team agreeing in secret the e.g. the product homepage content isn't great but are scared to say anything because they feel they have to stay inside their bubble and there isn't a culture of sharing feedback like that.
There's millions of tools that try to autogenerate colors for you using algorithms and AI, but they usually ignore WCAG accessible contrast requirements, don't let you customise the tints/shades, don't let you create a full palette of colors, and the colors often don't look right on actual designs.
This tool is meant to make customising tints/shades intuitive and quick enough in a few clicks via a hue/saturation/lightness curve editing interface that you won't want to rely on autogeneration. There's also a live mockup showing how your palette looks on a UI design that checks pairings pass contrast requirements, to guide you as you tweak your colors and to teach you the WCAG rules.
You can then export your palette to regular CSS variables, Tailwind, Figma or Adobe for use in your designs.
Really open to any feedback on features that would be useful! I think the only way I can make it simpler to use is to make it more opinionated about how your palette should be designed so interested in any thoughts about that too.
ChatGPT recommended this to me recently when I was trying to get some assistance with a usable Tailwind palette. I ended up not needing it right away but it's first in line next time I need to make one.
Any details about what problems you were having getting a usable Tailwind palette? There seems to be lots of different use case so I'd love to hear more.
That's awesome, I haven't kept up in what helps to get into AI recommendations. Guessing it's related to search result rankings? Not sure if the site would be in the training data. Curious if you asked about accessibility as that's my focus.
Content should come from your database, Markdown, JSON, models etc.
Presentation is determined by the HTML and CSS together.
So your content and presentation is already separate enough to get the benefits. Breaking up the presentation layer further with premature abstractions spread over multiple files comes at a cost for little payback. I'm sure everyone has worked on sites where you're scared to make CSS file edits because the unpredictable ripple of changes might break unrelated pages.
Styling code near your semantic HTML tags doesn't get in the way, and they're highly related too so you want to iterate and review on them together.
I've never seen a complex website redesign that didn't involve almost gutting the HTML either. CSS isn't powerful enough alone and it's not worth the cost of jumping through hoops trying because it's rare sites need theme switchers. Even blog post themes for the same platform come with their own HTML instead of being CSS-only.
> If you were writing a blog post you would want to be able to change the theme without going through every blog post you ever wrote, no?
Tailwind sites often have a `prose` class specifically for styling post content in the traditional CSS way (especially if you're not in control of how the HTML was generated) and this is some of the simplest styling work. For complex UIs and branded elements though, the utility class approach scales much better.
> I'm sure everyone has worked on sites where you're scared to make CSS file edits because the unpredictable ripple of changes might break unrelated pages.
CSS gives you multiple tools to solve this problem, if you don't use any of them then it's not really CSS's fault.
> Styling code near your semantic HTML tags doesn't get in the way
It does. When I'm working on functionality I don't want to see styles and vice versa. It adds a layer of noise that is not relevant.
If I'm making e.g. a search dropdown, I don't need to see any information about its cosmetic appearance. I do want to see information about how it functions.
Especially the other way around: if I'm styling the search dropdown I don't want to have to track down every JSX element in every sub-component. That's super tedious. All I need to know when I'm styling is the overall structure of the final element tree not of the vdom tree which could be considerably more complex.
> I've never seen a complex website redesign that didn't involve almost gutting the HTML either
Perhaps for a landing page. For a content-based website or web app you often want to adjust the design without touching your components.
> I've never seen a complex website redesign that didn't involve almost gutting the HTML either. CSS isn't powerful enough alone
I recognize your experience. But I would also like to argue that good semantic CSS class names require active development effort. If you inherit a code base where no one has done the work of properly assigning semantic CSS names to tags, then you can't update the external stylesheet without touching the HTML.
https://csszengarden.com/ shows how a clean separation between HTML and CSS can be achieved. This is obviously a simple web site and there is not much cruft that accumulated over the years. But the principles behind it are scalable when people take the separation of content and representation seriously.
See https://gohugo.io/tools/search/. Not sure how well they scale to thousands of posts, but they work by statically generating multiple static search index files at build time that are queried via client JavaScript when hosted. The search UX is actually really good because they tend to respond instantly as you type your query and allow complex queries.
I've used https://lunrjs.com/guides/getting_started.html briefly and it has lots of options for things like different fields, complex queries, fuzzy searching and wildcards. Didn't notice anything specific about dates but you could always add date as a field then filter out a date range manually at the end. I'm sure there's better libraries now as well.
We've gone from SSGs for ease, speed and reduced resources, to talking about implementing search with multiple megabyte client side indexes and hundereds of thousands of prerendered search result pages.
When does this become 1 step forward with the SSG and 2 steps back with search solutions like this?
You don't pre-render the search pages. You generate some search index files on the build step (something like a map of keywords to matching post URLs), and then client side JavaScript requests the search index files it needs on demand and generates the search results on the page. For a modest blog, I think the compressed index can be a few 100K. A single large image can be bigger than that.
Nothing is perfect, but the above is really simple to host, is low maintenance, and easy to secure.
This is just server side search with more steps, since the index needs to be selectively split and returned, and then search results page generated from the index.
Sorry, I don't mean to come across as disagreeable. You're right, nothing is perfect, and this is obviously a workable and usable solution. My issue is if we analyse it beyond "it looks like it works", it starts to look like a slightly worse solution than what we already had.
Nothing wrong with moving backwards in some direction, as long as we can clearly point to some benefit we're getting elsewhere. My issues with SSGs is most of the benefits they offer end up undermined if you want any interactivity. This is a good example of that, as you end up compromising on build time and page load time compared to an SSR search solution.
> it starts to look like a slightly worse solution than what we already had
You don't see how the server based solution is an order of magnitude more effort to maintain, monitor, optimize, and secure compared to hosting static files? Especially if search is a minor feature of your site, keeping the hosting simple can be a very reasonable tradeoff.
Lots of blogs/sites also do fine with only category and tag filtering (most SSGs have this built in) without text search, and users can use a search engine if they need more.
My point the entire time has been that an SSG is not good for sites that want interactivity.
I agree with you, lots of blogs/sites do fine with just tag/category. Those sites don't have interactivity and so you could SSG them and use free static hosting. We're in agreement on this. But I have explicitly been talking about sites that want interaction. Still - how many personal sites that "do fine without interactivity" are actually "interactivity was too much of a technical/maintenance challenge"?
I completely see how a server based solution is an order of magnitude more effort. We agree on that too. Running any servers efficiently typically has fixed overhead for server infra and processes. Running 3 pieces of server software or even 3 servers is harder than 1, but significantly less than 3x harder.
If you want interactivity, a server is needed. This means you are already maintaining, monitoring, optimising and securing a server solution. Adding SSG processes alongside your existing server solution does not remove any problems relating to servers, because you still have servers. It does add complexity though because you're running servers, and some SSG pipelines. These architectures clash and create more work. Running 2 conflicting architectures can be a lot more more than 2x harder than running 1 architecture.
If you want interactivity and don't want to run a server, then you must use a 3rd party service. This brings its own issues, especially if you have a personal website because you want to own your own stuff.
I feel like you're repeating to me "servers are hard, SSGs are good" - you can't have an SSG without a server, and you definitely can't have interactivity. If you have a server anyways for comments or search, then by using SSGs, you're not removing your need to deal with servers, you're adding an extra picky new thing to your servers. And what complex feature of a personal website does the SSG solve specifically? Generate the text/HTML. Compared to comments and search, generating html from markdown is so painfully easy. SSGs tie our hands behind our backs for the hard interactivity problems to solve the easy text rendering problem.
This seems like a really, really crystal clear point to me. But you, Jeff and Susam have all tried to say that SSGs are generally better, easier, safer or faster. I felt like that from 2016 - 2024. But when you've been pressed, all of you have ended up saying variations on:
- SSGs are great for sites without interactivity (agree, you know and I know though, most personal websites do want some form of interactivity, even just search or comments, and the only reason not to is technical hurdles.)
- Comments and Search are doable with SSGs, but not trivially, or without compromising on things which were traditionally seen as crucial for an open and accessible web (agree, see jeffs comments and search tickets)
- You use SSGs not to solve any particular problem, but just for fun. (agree, that's fine, but if that's your only reason, that's probably a sign there's virtually no technical advantages.)
- The problems you used the SSG for originally have been solved with compute power, storage, connectivity and bandwidth becoming more available over the past decade
I really appreciate and respect your's, Jeff's and Susam's time to respond, I want to be in agreement with you, as you all have the experience and reputation in personal websites. I just can't see it though. I mean this whole HN topic is about Jeff's post "Jeffgeerling.com has been migrated to Hugo" which on the surface looks like a success for the ease of SSGs, but when you probe deeper, it's the text that's been migrated, and comments and search have been disabled.
Why are we here if SSGs are so obviously the easiest, most reliable way to run a personal website? Jeff's site is currently working less than it did before and the fixes are future TODOs are essentially "pick a compromise" (sorry, no offence Jeff - I still think you're great!)
> But you, Jeff and Susam have all tried to say that SSGs are generally better, easier, safer or faster.
I'd just like to clarify that this is not what I was trying to say. In fact, once a website needs server-side programming to support interactivity (comments, subscription, etc.), I don't think SSGs are necessarily better. I think we both agree there to an extent. I think there are tradeoffs.
There is a certain inherent complexity in addressing concerns like performance, portability, etc. that, as waterbed theory suggests, just gets pushed to different places depending on whether we choose an SSG-based solution or non-SSG-based solution. What I have been trying in my other comments is to explain my reasons for why I made the arguably questionable choice to use an SSG for content pages while relying on server side programming for comments and subscriber forms.
I certainly see the appeal of serving the entire site, including both content pages and comment forms, using server side programming. It does simplify the 'architecture' in some ways. However, since I maintain my personal website as a hobby, I need to make the tradeoffs that feel right to me. I realise this is not a very satisfying answer to the question of whether a hybrid solution like mine (SSG plus server side programming) has merits. But I was never trying to argue its merits in the first place.
This is all entirely fair, thank you, I understand, I didn't mean to misrepresent.
> However, since I maintain my personal website as a hobby, I need to make the tradeoffs that feel right to me. I realise this is not a very satisfying answer to the question of whether a hybrid solution like mine (SSG plus server side programming) has merits. But I was never trying to argue its merits in the first place.
Hey, I'm a firm believer in the idea that the best solution for a personal website is the one that's the most fun for the owner to maintain! The reminder that it's not all about technical merit makes yours one of the more satisfying answers - thanks again for the considered responses:)
Sounds like we agree! There's no perfect solution and I'm not saying SSGs are always the best fit. It really depends on the project and what the people involved value.
For my own solo projects, the ease of hosting for static sites is often such a big win for me that I'm willing to forego some interactivity even though more interactive features would be nice. Knowing that I can upload several static sites and they'll run themselves without any maintenance for years and without potential security problems keeps my life nice and calm. It depends what you want to prioritize.
I agree, nothing is perfect, there's a time and place for everything - I just think the coverage and advocacy of SSGs is disproportionate to the number of places where they improve things. I'm going to summarise the discussions I've had in this topic in a post over the next few weeks and I'll post it here. Thanks for humouring and challenging me :)
I still do feel there's something not quite right. Hopefully I'll be able to get it out in the summary as I think we're all done with walls of text here. But I think you actually captured it perfectly in your last remark:
> For my own solo projects, the ease of hosting for static sites is often such a big win for me that I'm willing to forego some interactivity even though more interactive features would be nice.
They make the web worse for the world by tempting the developer to take the easier, less interactive route than what would have been taken in the pre-SSG world.
I think I'm troubled by this because the idea "it makes it easy to do the lazy, worse thing" seems completely at odds with the fact that it seems to be what the people I would consider leaders in the field are doing. That's why I still wonder if this view might be a me problem, or maybe the field is just moving backwards? I don't know.
> They make the web worse for the world by tempting the developer to take the easier, less interactive route than what would have been taken in the pre-SSG world.
If I didn't have the static site option though, I might not host a project at all because I don't want to have to deal with the maintenance burden. I haven't kept up but it would be nice if there were more options between a no-maintenance static site hosting, and a high-maintenance dynamic site.
Would be amazing if the web/browsers had standardized ways by now of easily adding common website features like authentication, search, comments, votes, and saving user data (via bring your own storage) that didn't require everyone to host and maintain a custom stack. Email is a solved problem that you don't have to host yourself for example, why is it still such an effort for the other common website features?
> I haven't kept up but it would be nice if there were more options between a no-maintenance static site hosting, and a high-maintenance dynamic site.
This is essentially my position in fewer and less argumentative words, including the "I haven't kept up bit", really:)
Your last paragraph was also really thought provoking. I'm torn on that though. I agree it's an almost off-putting amount of time for anyone who wants a personal website to reinvent the wheel when the client browser could help.
The main issue with that for me is that browsers require organisations to build and maintain, so I think we should always be careful about removing responsibilities from website creators and giving it over to browsers.
I guess the SSG and the browser points are both freedom vs convenience type tradeoffs where everyone has their own personal preference. It's all Web stuff though, so we should probably try keep it all open, flexible and resilient IMO.
Assuming 500 bytes of metadata + URL per blog post, a one megabyte index is enough for 2000 blog posts.
As already mentioned, you don't generate search result pages, because client side Javascript has been a thing for several decades already.
Your suggestion of converting markdown on every request also provides near zero value.
Writing a minimal server backend is also way easier if you separate it from the presentation part of the stack.
Based on https://news.ycombinator.com/item?id=46489563, it also seems like you fundamentally misunderstand the point. Interactivity is not the point. SSGs are used for publishing writing the same way PDF is used. Nobody sane thinks that they need a comment section in their PDFs.
I'm sorry, I find your post insulting. I wasn't engaging in bad faith discourse intentionally, but your assumption that I am - ironically - doesn't feel like appropriate etiquette here either. Despite that, I'll try answer sincerely.
Your 1 megabyte index file has just added over 2 seconds to your page load time in 30 different countries based on average internet speeds in 2024. Chuck in some pictures, an external comment library and your other SSG hacks, and you've just made your website practically unresponsive to a quarter of the planet and a bunch of other low powered devices.
Value is relative. The benefit of rendering markdown on every request is it makes it easier to make it dynamic, so you don't need to do SSG compromises like rebuild and reupload multiple pages when a single link changes.
You're replying in my thread here, to my original points. My original points were that SSGs don't make sense for sites with interaction, which is why were were discussing the limitations of SSG search approaches.
> SSGs are used for publishing writing the same way PDF is used. Nobody sane thinks that they need a comment section in their PDFs.
Thank you! We're in agreement, it doesn't make sense to use SSGs for sites that require interaction. When you do, it forces the rest of your site to do the compromising search stuff like we're discussing here.
Remote: Yes (I’m used to time zone differences and async work)
Willing to relocate: No
Technologies: Figma, Sketch, TypeScript, JavaScript, Vue, Hugo, Jekyll, WordPress, Django, HTML/CSS, Bootstrap, Tailwind, OCaml, Java, Python, C, analytics, WCAG accessibility, website SEO/speed optimisation.
Résumé/CV: See https://seanw.org/ for portfolio, and https://checkbot.io/ and https://inclusivecolors.com/ for live example projects
Email: sw@seanw.org
---
SEEKING FREELANCE WORK | UX/UI & web design
I help startups with the UX/UI and web design of their products. This includes web apps, websites, landing pages, copywriting, and I can assist with frontend development where needed. My background of launching my own products and being a full stack developer helps me create practical designs that balance usability, aesthetics, development effort, and performance. I work to fixed price quotes for self-contained projects.
---
The best live example of my work is Checkbot (https://checkbot.io/), a browser extension that tests websites for SEO/speed/security problems. The entire project is my own work including coding the extension itself, UX/UI design, website design (the homepage is optimised to load in 0.7 seconds, 0.3MB data transferred), marketing, website copy, and website articles on web best practices.
[ Rated 4.9/5, 80K+ active users, 100s of paying subscribers ]
---
I have 10+ years of experience, including a PhD in software verification and 5+ years working for myself helping over 25 companies including Just Eat, Triumph Motorcycles and Fogbender (YC W22). See my website for testimonials, portfolio and more: https://seanw.org
Note: For large projects, my partner usually assists me in the background (I’m working on starting a design studio with her in the future)
---
Email sw@seanw.org with a short description of 1) your project 2) how you think I can help 3) the business outcome you’re looking for and 4) any deadlines. I can get back to you in one working day to arrange a call to discuss a quote and how we can work together!
reply