~/about

who is this guy and why should you care?

$ career --short software engineer who came to code the long way round. backend at motogp by day, building side projects and documenting the journey by night.
$ career --long | head -3 double degree in physics and chemistry at the uab, then molecular-dynamics simulations at icmab-csic. turns out building things scratched an itch that running simulations never did. no regrets, mostly.
$ history | grep outage hired at adidas for a 3+ years position with less than one. broke the worldwide product exchange service for a weekend. good times.
$ which language go. simpler than javascript, faster than javascript, basically better than javascript in every way that mattered to me.
$ pwd motogp sports entertainment, race management tech. go, at speed. still here, still learning from people much smarter than me.

what’s with this blog?

this is my engineering journal — partly to document what i learn, partly to share with others, and partly to keep myself accountable as i build in public. the longer version of how it came to exist is in the meta post .

you’ll find deep dives into go, apis and distributed systems, the unfiltered journey of building a saas from scratch, the occasional rant about technology choices, and zero content about the oxford comma or capital letters. if you’d rather start from a subject than a date, everything is gathered by topic .

why lowercase?

because shift keys are overrated and i’m lazy. also, it looks kinda cool. i think.

faq

who’s behind krtffl.dev?

dídac pérez escrich — a backend engineer in barcelona who came to code the long way round, via a double degree in physics and chemistry. backend on the race management tech team at motogp sports entertainment (dorna sports, before the rename); adidas’ order api before that. nights and weekends go to my own products, documented here, failures included.

what does this blog cover?

go, rust, postgres, and the infrastructure underneath — all of it written from projects that actually run somewhere.

there is one argument under most of it. the bugs worth writing about do not announce themselves: a vote handler that lost 79% of every rating change and let me sleep fine for weeks, a compose key that docker stack deploy silently ignored while every pre-flight gate went green, an authorization check i wrote in thirteen files and forgot in the fourteenth. none of those threw. and the reason is usually the same — an invariant a person has to remember is not an invariant, it is a hope. so the posts tend to end in the same place: move the rule somewhere it cannot be forgotten, and write the test that would have ruined you.

if you want a route through it rather than the reverse-chronological feed, start here .

is krtffl the same person as dídac pérez escrich?

yes. krtffl is the handle this blog writes under — dídac pérez escrich (dídac, for short) is the name on the passport. same person, same entity, just the technical-journal voice. the cv version lives at didacperezescrich.com ↗ .

what’s krtffl working on right now?

mojodojo ↗ , a management saas for martial-arts academies, in production at a real gym. vivvia ↗ , a crm for estate agencies, which i cofounded and am cto of. and a drawer full of rust tools — logmole ↗ , tablero ↗ , stintlab ↗ — that exist because i wanted to know how the thing worked. still early, still figuring it out in public: the posts are the real-time version of that story.

can i email you? and what do you actually want to hear about?

didac@krtffl.dev , and yes. what i want most is the counter-example — the invariant you moved somewhere it could not be forgotten and it was still wrong, or the silent bug that cost you more than mine cost me. the best mail i get opens with: your post is wrong, here is why. if you would rather read than write, the topics are the map.