Cyrillic is not simple

The first requirement was simple yet very important: the font had to properly support Bulgarian Cyrillic. But then again - what is proper in this context? I’ve been vaguely aware for a while that there’s a difference in the typesets for Bulgarian and Russian Cyrillic, but never read up on it. Until now.

A good starting point with an overview of the history and the main visual differences is the page made by the foundation organizing Вulgarian Best Website Awards (BG Web). The most important thing I remembered from it was the striking difference between the lowercase letters. The Bulgarian ones are so much more diverse in shape and height than the Russian ones. The more varied shapes make words easier to recognize at a glance because each letter contributes more to the overall silhouette of a word. More in-depth analysis can be read in a post by Cultura magazine.

So with that knowledge, I was off to look for fonts that support Bulgarian Cyrillic. A good starting point is this page with a large selection of Bulgarian fonts.

To serif or not to serif

My next decision was a more aesthetic one - should I use a serif or sans-serif font?

I’ve been aware of the common belief that serifs are more comfortable for extended reading, but wanted to see how much truth there is to this statement. A recent study found that font preferences are highly individual. Much like glasses, it can be tailored for any person. Other studies confirm that any difference between them is at most insignificant. So I was left with a personal choice. That gave me an excuse to ask: “Why not both?”

So I decided to let readers choose whichever they find more comfortable: serif or sans-serif.

Technical implementation

After selecting the fonts for my site - Sofia Sans and Veleka - I only had to implement a way to switch between them and remember the reader’s preference for future visits.

The downloaded font files contained dozens of glyphs my website would never display, yet they would still be downloaded and stored on the devices of every visitor. Years ago in my WordPress days, I was using Tranfonter to convert and compress fonts for web use. I left only Latin and Cyrillic subsets, while dropping their extended ones along with the Greek.

This reduced the size of a single font from around 400 KB to just 28 KB - a reduction of more than 90%.

I wanted to see exactly which characters remained after subsetting, and I used Wakamaifondue. Upload a font and it shows you everything from supported glyphs to OpenType features, along with visual previews of what they do.

After comparing the original and subsetted fonts, I wasn’t entirely happy with the default glyph selection. So I built a custom list of all Unicode code points for the characters I wanted, and provided them as a Unicode ranges parameter to Transfonter. This resulted in an even smaller size of about 24 KB and the exact selection of glyphs I plan to use.

If at any point in the future I need more, I can simply rerun the process with an expanded list of Unicode code points.

Future optimization

One thing that I didn’t implement is automating the font optimization during the build process. There’s a webfont tool called Glyphhanger, that can scan an HTML file or even a webpage, get the unique set of characters used and then subset a font with only them. This will make each font grow only when new characters are introduced and further reduce bandwidth usage.

Conclusion

In the end, it turned out that fonts are not as simple if you care for every step of their deployment and use. And this is another example of the same principle that motivated this project in the first place. Spending a little more effort during development can remove a surprising amount of friction for every future visitor. Whether it’s choosing typography that feels more natural to read or trimming hundreds of kilobytes from every page load, the details matter.

Giving users the option to choose between serif and sans-serif fonts is a small UX improvement, but one that’s well worth the effort.

Learning Through Building

I’ve never been the type to jump headfirst into a new problem. I preferred taking my time, reading documentation, understanding the landscape, and making informed decisions before writing any code.

Over the past few years, though, that changed. Maybe “impatient” is the wrong word, but I increasingly found tutorials and documentation jumping off point rather than final authority. They’re great for learning syntax or passing an exam, but they rarely provide the understanding that comes from building something real.

Experience certainly played a part. After solving enough similar problems, you develop confidence that you’ll figure things out along the way. Add to that the recent rise of AI-assisted development - and the unexpected influx of free time - and I decided to challenge myself: pick a project, learn some new technologies, and finish it in under a week.

Picking a Tool to Build

The project basically chose itself. My personal website had been sitting unfinished for years.

Part of the reason was time, but a bigger part was that I never wanted to commit to WordPress or some other feature-rich CMS just to publish an occasional post. I wanted something much simpler: write a Markdown file, run a command, and enjoy the newly deployed page.

I didn’t need a visual editor or a complex publishing workflow. I already had my IDE, or even the the Notes app on my phone. Reducing friction had always been the goal, remember?

More Than a Static Site Builder

I wasn’t trying to build the next great static site generator. The real goal was to learn while building it.

Building something from scratch forced me to make architectural and technical decisions that tutorials simply gloss over. Every decision led to another question, and every question opened another rabbit hole. I ended up learning far more than I would have by following a course or recreating a sample project.

Many of those rabbit holes deserve posts of their own. Over the next few articles, I’ll write about the decisions I made, the technologies I experimented with, and the unexpected outcomes I encountered along the way. The static site builder was never really the destination - it was simply an excuse to explore ideas I’d been wanting to play with for a while.

Final Thoughts

One of the biggest lessons DevOps taught me wasn’t Kubernetes, CI/CD, or infrastructure as code. It was that if a task feels repetitive or unnecessarily difficult, you don’t always have to look for a better tool - you can build one.

Almost all of the tools I create will never be used by more than several people, and that’s okay. Making something mass appealing requires very different skills and mindset and it very rarely, if ever, does it make people lifes easier.

The Cognity beginning

I am deeply thankful for the close, family-like environment I was lucky enough to join. The startup phase was long and often thankless for everyone involved, but the team more than made up for it.

I joined just in time to witness the 2008 market crash through the eyes of a highly knowledgeable financial team that helped me make sense of it all. We had to build our product during uncertain times, facing constant hurdles of every kind. The lessons learned during late nights and on tight (or sometimes nonexistent) budgets only made us more resilient for the years to come.

The enterprise switch

In quick succession during 2016 and 2017, I went from a 40-person startup to a 10,000-employee enterprise with more than 30 years of history. The transition did not happen overnight, but it certainly felt that way at the time.

This turbulent period was a watershed moment for me. I had to put aside my engineering hat and learn how to navigate unfamiliar waters. For one, I had to hire people. People I would trust and delegate work to. Getting to know a person in an hour is very different from building trust over years. I also learned that, in a large organization, the bottom line almost always takes precedence over personal connections. (That lesson would prove more relevant than I realized at the time)

The FactSet growth

Once the acquisition was complete and the old domain was no more, the challenges grew in both complexity and duration. Gone was the agility of making split-second decisions over a conversation by the water cooler. Gone was the freedom to pick whichever tools seemed best suited to a solution.

Now there were quarterly goals. KPIs. Performance reviews. Required frameworks.

The brightest part of that transition, however, was the managers. Somehow, I was fortunate enough to work for not one but two exceptional people. Not just great managers, but genuinely good humans.

They showed me that caring for your team is not merely a phrase repeated during interviews, but a real quality that some people possess. And it makes all the difference.

The lessons I learned from them were countless - not only in engineering, but also in becoming a better person. I cannot imagine being where I am today without their guidance and encouragement. In my early twenties, I sorely lacked many of the non-technical skills required to thrive in this field. They patiently helped me build that foundation and, in many ways, shaped the professional I became.

The letting go

I am not someone who let go things easily. Anyone who has seen my storage room - or my CV for that matter - can attest to that.

Nineteen years with the same product is an achievement in itself, but surviving every hurdle, acquisition, and financial downturn makes it even more meaningful.

So obviously, I did not envision my departure being so abrupt. But life can be strange like that sometimes.

Now, with all of that experience under my belt, I am preparing for a new beginning - one that I hope to help shape in a way that would make those managers proud. A chance to apply the lessons they taught me with the confidence and perspective that only a long and winding road can provide.

Future, reconsidered

So where to now? I’m definetly not taking a break. Staying with the same product for so long comes with its own downsides - I missed out on gaining experience with some of the technologies that much of today’s IT world runs on. So I have some catching up to do, which can only motivate me.

Hopefully, I’ll find a company that feels worth committing the next 19 years to.