In what I call my “shadow bookkeeping”, I have a table with expenses.
In this table, I have various invoices with various currencies: euros, US dollars, British pounds and Mexican Mexican Pesos.
I pay most of my business expenses with a business credit card. If the expense is in a foreign currency, a transaction will happen where the foreign currency is converted to Euros.
The exact conversion amount is in my MasterCard transcript. However, I always want to know what I’m spending and where. It doesn’t have to be 100% accurate; but some accuracy is nice to get an overview of costs.
At some point I introduced a currency column to my sheet, which had a currency code – for example EUR, USD or MXN.
Then I would use the issue date and the Google Finance formula to find currency exchange info – to convert from US dollars to Euro, for example.
The formula looks like this (where G171 refers to a column with the currency code; B171 refers to a column with the issue date and F171 refers to an original amount):
This worked, but not always. Turns out that on weekends or on dates that the stock exchange is closed, the API returns N/A (not available) as a value.
Today I finally fixed this issue with a bit of a stupid “hack”: I take the same formula but repeat it with a fallback minus 3 days. So if it’s a Sunday, it will refer to a Thursday. It it’s a Saturday it will refer to a Wednesday. If the stock exchange is closed, it will refer to 3 days earlier (hopefully not a weekend day).
This seems to work for my cases. I am sure it can be more robust, but it works. If need be, I can change the 3 to a 2 or 1 or another number to be close to the right currency exchange.
if you want to replicate this on your end, here’s a screenshot of the setup of my columns:
I want to talk about six months of Obra Studio. Time flies while having fun, right?
I started work on the company after my honeymoon in December last year and I feel I didn’t really stop. People who know me personally will know that I have sort of personal deadline coming up in July, so I was driven to make the most out of the first six months.
I built most of the company here from Mexico, but I went to Belgium twice to see clients, to meet my colleagues, and network a bit.
A first highlight was contracting our first collaborator Nele in May. Nele is with us as a freelancer and has many years of experience as a designer.
We also have Emily working with us as a freelancer. Working with Emily again is a happy return after having worked with her for many years at Mono.
We’ve been having a great collaboration with Robert on the business development who is also doing design & analysis on some projects. He uses his startup experience to help us do the right thing in the early stages of our company.
As of last Friday, the about page is up on the Obra website so I guess this is my way to announce that we’re officially a team now.
Overall, you would think this is an outfit of just a few people, but if I would pull back the curtains you would see that there is an involvement of at least nine people.
Not everyone has the same type of full-time commitment, but I’ve got a few people to thank that I can continuously rely on when I need them.
First is is our web developer Bauke, which I would like to thank for listening to all my website needs, and developing our super nice Craft CMS-powered website. Working with this CMS has been great and I am glad I’ve made the investment.
There is our newest temporary member of the team – our marketeer Catalina, which I would like to thank to jump in for a marketing summer drive.
There is our freelance visual designer, Marina, which I would like to thank as well for helping us to reach a next visual design level.
Thank you Gavin for supporting some meta-work on Figma plugins and tools. If you’re from the UK – take a look to work with Gavin!
Thank you, J., for helping out with giving feedback on the business model and representing Obra at an industry conference.
Thanks you Simon for helping me with running our own Tacos y Tech event!
And thank you Willow, for being our trustworthy Svelte developer.
So, you know, it’s teamwork. My wife joked that teamwork makes the dream work – I think that’s how I feel today.
The dream is to have a nice boutique agency where we can do the best work.
At this point, I feel like I have enough assurances that I can breathe now, after working on this agency for many months without a lot of breaks and trying to give it my best every day.
We’ve got two long term clients, we’ve got good prospects, and we’ve strategized a way to sell design in what’s — to be honest — a tough year for design.
I feel like we’ve reached an equilibrium where we have a team, we have a strategy, and we have the long term projects to make sure that the company will last.
And now we just have to continue. If we have enough sales, we can start thinking about a third designer towards September.
I am proud of the work we’re doing, and of the team we’ve built. We’ve got some very nice projects to show soon in our portfolio.
I feel it’s only going to get better from here on now because the base is done, the website is there, the team is there, the base logic of what we sell and why it’s there. And now we go to the next phase. Vámonos!
Just want to give a bit of warning about Adobe’s shady plan practices.
I use Photoshop and occasionally Lightroom, and I pay €9.99/month for the photography plan.
On top of that, I sometimes need Illustrator, and then I’m paying about €35 per month for Illustrator.
Now I wanted to just get some stock photos for a client project, so I got into a €29.99 plan for Adobe Stock thinking I could cancel it when I didn’t need it.
Two months later I tried to cancel. Monthly means monthly, right?
Not in Adobe’s world. Unfortunately, Adobe’s shady practices secretly put me onto some kind of year plan, where if I cancelled when I didn’t need it, which is right now, I had to pay a fine of 134 euros.
With Figma releasing their draw features and me being so pissed off about this, I immediately also cancelled my Illustrator plan. For which I apparently also needed to pay a 55 euros “fine”.
I paid both fines and my long-term trust in Adobe has completely sinked.
I hope to run an Adobe free agency because this is really not cool.
This is a bit of a niche rant that will only interest a very specific audience, but I wrote it, so I might as well publish it. Lately I’ve been having too much blog posts sitting in draft.
First of all, kudos to Marc Thiele for organising Beyond Tellerand all these years and for putting all the talks online. Very nice.
Now, about Matthias’s talk. I feel this talk could have been given 5 years ago.
Yes, the browser is the true grain – if you only consider the browser as a deployment target.
But design tools these days like Figma and Framer are gravitating towards supporting a visual environment to work with that grain. This talk is more or less ignoring that.
While I don’t disagree with the message to design and explore in the browser, Matthias is kind of ignoring that design tools are constantly evolving towards how the web works.
The standard way these talks seem to go is saying “haha Figma” “why a static picture?” and then showing designing in the browser as the way of the light.
I think that’s a very narrow view on design and creation.
These talks tend to mix up design and implementation completely. These talks are not talking about design – i.e. solving a problem in a visual manner through exploration and iteration. They are talking about implementation.
Talks like this forget that the process of web development where you are writing code and refreshing a browser hundreds of times to see what you are doing is not creation. It’s implementation.
The manipulation is indirect, which leads to highly uncreative results. One of my favorite conference talks is Inventing on principle.
In a way it’s difficult to compare this talk to Matthias’s talk, but it also talks about creation, and one of the points is that you need to be able to directly manipulate what you are creating in order to make good decisions. In a way, a fluid typography example in the browser that works across breakpoints is exactly that.
I miss some of that when I am designing in Figma. But when I am designing a fluid type scale, I am designing a very narrow slice of the whole thing I am designing.
Most examples shown in these kinds of talks are just implementation things. I’ve seen a type fluid scale and a subgrid a 100 times before. I did some of this in 2010 with Sass. I mean, they are good examples for beginners. And it’s good that there are better ways to do the same in 2025. But don’t try to posit that the web is the design tool.
It’s a way to visualize certain things that are a bit ahead of what traditional design tools can do.
While this talk is well-intentioned, and for any beginner designer it would be good to watch what Matthias is talking about and learn all the front-end techniques mentioned, this type of talk in my opinion fundamentally misunderstands what design really is.
This type of talk tries to posit that you can design in a browser and does it by showing a bunch of tech demos.
The reality is that you can’t actually design in a browser.
You can put things together, you can make disparate experiments, but in my opinion you will always need a free canvas to explore and iterate in a meaningful way.
You will need go through the design process, which has lots of bits and pieces and possibilities, where likely at some point you want to bring things alive in various ways – going towards a prototype. And that can be at any time in the process.
One of the great ways to make things alive could be an HTML/CSS prototype – but usually this is at the point that you already know what you are making (or you are iterating with AI, but that’s a whole other blog post 🤓).
It’s rather rare to see the act of creation truly happening from scratch in the browser. Who can really do that – and what are they making that is not an implementation of an idea created elsewhere?
In what Matthias is showing — fluid type scales, color logic with okclh, subgrid demos — in my opinion you are past design at this point – you are in the implementation world. This is a different world.
Many of the talk givers have roots in either web standards or accessibility. They work for browser vendors or as consultants have a vested interest in continuing to do what they do the way they do it.
If Figma, Framer of whatever design tool upends their job, it’s painful for them. If Framer ships a carousel component that makes every carousel on every Framer website accessible, there’s nothing more to report in an accessibility report.
If Figma Sites can generate the code that they like to write by hand, there is no selling of front-end development anymore. The reality I foresee is that something like Figma Sites and Framer will be used for small marketing sites, and at some point a big company outgrows that — and of course there is a need for real front-end development then.
My theory is that tools upending someone’s jobs gives them an almost visceral reaction to complain against the tool, not because it’s necessarily bad, but because it threatens their livelihood. I’ve seen a similar reaction to Figma’s AI features last year from designers themselves and it’s a bit funny to see the same thing this year.
Now it’s the front-enders and accessibility people that have their pitchforks up. The reaction to Figma Sites last week was especially stupid.
65 000 people watched Kevin Powell’s video taken from a livestream where 500 people gave a thumbs up to Kevin where Kevin thinks he is fighting the good fight.
But his whole video misses the point that you can set a custom tag in Figma. He complains about non-semantic div soup but he just simply missed one of Figma’s features. I feel like he should issue a bit of a correction to his audience.
He also gives an explanation to his massive audience about aria-label that fundamentally misunderstands how aria-label works. It subsumes the content that’s inside, it doesn’t lead to duplicate reading of the content. I respect Kevin and his CSS teachings, but maybe he needs to read up on accessibility before making points like that?
People like Matthias Ott and his friend Matuzo then go on and applaud that kind of “haha” about the code that Figma sites generates. This part is in Mattias’s talk as well.
They go on and complain about the code structure that devs use today. Then they make a vague point about the cascade with references from when HTML and CSS was invented and then go on that the web was never meant this way. I’m sorry but that’s just repeating things that Jeremy Keith said 10 years ago without providing anything new.
You could clip in 10 minutes from an old Jeremy Keith talk into this talk and it would be exactly the same talk.
Maybe I am just getting old but I wanted to be presented with new information. Conferences are supposed to provide some new info, that take the current world into account, not regurgitate old stuff. Yeah, there is cascade in cascading style sheets.
And unfortunately the world has discovered that seemingly doesn’t seem to work for them and they gravitated towards Tailwind and component-scoped styles.
I also don’t like a gazillion Tailwind or typical CSS in JS output, and I’ve tried to fight the good fight against Tailwind (see this post and there’s many more if you search).
But on Tailwind, I’ve accepted it as something that people do. I can’t fight it anymore, because it’s become an accepted way of working.
These days I am more results-focussed: it it accessible? Is it performant? I won’t complain about the code structure, only about the result.
Look at X.com: if you look at the code if you open the browser dev tools you might have CSS in JS nightmares. But it’s one of the most performant and usable web apps out there for me. That’s what I am evaluating. (Now the Mastodon crowd will ready their pitchforks that I am still on X…)
Design tools are constantly evolving towards how the web works.
Check out how Framer is evolving for example. Framer has included rem font sizing since 2 weeks. Figma implemented aspect ratio for images since a few months. Figma just shipped grid at Config last week.
Through variables Figma can simulate dark/light mode in a visual environment. You can easily export those values to code for usage in the browser. If Figma ships okclh tomorrow, the argument of Matthias’s talk kind of disappears.
My point of view is that the shipping of features in design tools that correlate to browser features has been happening for years and is something that’s an absolute enabler for people to create.
Figma especially goes out of their way to make the primitive base of what they make transportable to the web. The engineers behind the new Figma draw went to great lengths to make sure the new dynamic stroke logic is exportable to SVG (see this tweet).
Then why bash them so much? They are doing engineering things that don’t even come close to the level of most consultant’s daily work.
Yet all they get is bashing from a specific community that doesn’t bother to fully evaluate the tool, then reacts to wrong information because it fits their world perspective. That’s confirmation bias in action.
The design tools are gravitating towards the CSS tech, and they do 90% of what you need in most projects anyway, so what’s the big point of taking a stance on designing in the browser?
Matthias says “CSS is the most powerful design tool for the web.” No, it’s the most powerful implementation tool.
The tech mentioned in the slides about CSS features is rather niche; most of what we needed was implemented between 2010 to 2020 in CSS.
Yet that slide is used as a main argument that designing in the browser is so much better of a design app.
What I mostly see are a bunch of technicalities. Yes, the browser has :where and :has but that’s just about selecting the right elements. That’s unrelated to design.
Sure, there’s a popover API now that half works: but I’ve implemented popovers since forever in my apps. And I could go on and give a similar example for everything on that slide (@supports etc.). As I said earlier in this post, this is implementation, not design.
The extras that we are getting now on the web are mostly just a bonus and not fundamental. I can do just fine with hex colours.
The problem in most of my projects is NOT the color scale. It’s apps that are broken for users on a UX level. If I would make a Maslow’s hierarchy of needs for the apps I design, implementing okclh sits at the very top of the triangle.
During a certain part of the talk Matthias is showing us a color palette implemented in okclh. He is saying that this stuff is only possible to explore in the browser, where you are “painting with the web”. That’s a very narrow view.
First of all in the color blog post he is admiring, the tools showing the visualization were most likely not even written with web tech. They were done with all kinds of low-level tools and then converted to web code to visualize on the web. Yet Matthias paints a picture that this is ideation on the web.
I did similar work using a combination of Figma and scripting to map lightness scales to a uniform color space. Using python and chatgpt to get to a color ramp that is uniform (with hex). It was a pain – and I do agree that it’s nice to set up a color scale in okclh() directly in the browser.
Let’s say you are in a design project and you have to work with those colours, then it’s a bit lame that when you go back to design work in Figma, where you then have to recreate an incomplete picture. I agree in that sense that designing with static pictures doesn’t work — a main point of the talk — when the actual implementation target has different capabilities.
But once again, first of all the things he is talking about are quite niche, and next thing we know, Figma implements okclh(), and the argument that the design is a static picture that doesn’t represent the dev reality disappears.
Right now, we are evolving towards a situation where you can create what you used to need code for in a visual tool in an easy manner. For a certain kind of project — a small marketing site — you can skip the front-end development phase and go directly to these tools. Figma Sites is in beta and will likely evolve fast over the coming year. Framer is already usable today for this use case.
You can now hit publish in Framer to get to a real, high-end, responsive website with great fluid typography. I know this because we made a marketing site for a client with Obra just a few weeks ago and it took us way less time than it used to. I tested it for accessibility with Voiceover on my phone and it works just fine.
There is no bothersome front-end repo to maintain; no difficult CMS implementations. Just a visual tool and a publish button. In my mind, this is the future, where you pay a vendor to handle the annoying, repeated implementation parts for you.
Some of the crowd I follow om Mastodon would rather live in a world where they hand-code every detail. I think that’s fine from a craft perspective, and excellent for teaching, but a bit naive in the real world.
Anyway, that’s my perspective. In no way do I want to attack Matthias, I think it’s an excellent talk. I just find that he doesn’t use the work design in the right way, he is talking about implementation experiments in the browser. He also ignores how the design tools are growing towards the grain of the web, dismissing them with a static picture argument that was true in 2012, but not in 2025.
Deze week ben ik nog eens in België. Ik reis een paar keer per jaar tussen België en Mexico, en mijn primair doel van de laatste twee trips was werkgerelateerd.
Ik ben bezig met de opbouw van Obra Studio en telkens ik in België ben is het goed om klanten in het echt te zien, om af te spreken met nieuwe collega’s en natuurlijk daarnaast toch nog even tijd nemen voor familie en vrienden.
Wij zijn ondertussen met een team van 4 aan de slag aan allerhande projecten. We bereiken bijna de €100 000 verkochte omzet, waar ik blij om ben.
Als eigenaar van een agency heb ik altijd een beetje schrik van “de zomer”. In juli ligt België nogal plat, en dan heb je maar beter je projecten verkocht. Ik ben blij dat dat grotendeels het geval is en we veilig en met voldoende werk de zomer doorkomen.
Vorige week maandag starte een nieuwe collega, en kwamen we samen in een co-working space om te praten over de eerste projecten.
Vandaag heb ik een Figma workshop, waar ik 2 designers les zal geven in Figma. Eén van de uitdagingen is controle nemen over een door een agency aangeleverd design systeem.
Tegelijk leveren wij als agency ook systemen op en is er intern het gesprek gestart wat de exacte kwaliteitsnorm is van zo’n oplevering.
Ik praate met een goeie vriend die als design manager werkt bij een scale-up, en ik deed hem uit de doeken waarom ik zo hou van een agency. Ik hou van de uitdagende opdrachten, van verplicht te worden creatief uit de hoek te komen (zeker als het werk niet automagisch binnenkomt zoals dit jaar!); ik hou van de duidelijkheid van, dat als er een project is, je een afspraak maakt over wat er moet gebeuren en dat uitvoert. Je zit niet te wachten op momentum in een design project, je hoeft het niet te forceren: de noodzaak is er al via het project.
Vanavond nog een verkoopsmeeting in Brussel, en een afspraak met een potentiële business partner.
Mischien is het omdat ik al lang beweeg in agencies, maar ik voel me als een vis in het water.
Ik heb gisteren na 4 maanden eindelijk nog eens de tijd gevonden om een ritje te maken met de fiets. Een vriend had een volgwagen geregeld. Met zijn drieën gingen we op weg naar Teotihuacan (ongeveer 60km van Mexico-Stad).
Het was een fantastische fietsrit en ik was blij om nog eens iets anders te doen dan werken, want het is nogal intens geweest de laatste maanden.
Het is een vreemd jaar voor design. Ik zie een paar zaken in de markt.
Eén feit is dat er op dit moment veel designers aan het werk zijn die eigenlijk maar half weten wat ze doen, wat na enkele maanden werk de facto een negatieve impact geeft op de perceptie van design binnen een bedrijf.
Een bedrijf dat met prutser(s) werkt beslist na een negatieve ervaring dan al eens snel om design door front-enders te laten doen, of niét te doen, met een niet-ontworpen product als gevolg. Zeker als er bespaard moet worden.
Een slechte ervaring met een UX-bedrijf is van alle tijden. We zagen dit patroon met Mono reeds in 2014; er waren meerdere bedrijven die terug overtuigd moesten worden van het nut van design.
Ik denk dat die “slechte ervaring” nu overgegaan is naar het interne. Designers werken in bedrijven maar kunnen niet eeuwig claims blijven maken over het “design systeem verbeteren” als job-bezigheid.
Op een bepaald moment moeten ze een sprong maken naar écht product design en de zaken fundamenteel bekijken (als dat werk al bestaat binnen het bedrijf in kwestie). Er zijn er die dat kunnen, en er zijn er die blijven hangen in hun enige vaardigheid om een scherm te kunnen produceren. Daar zien managers van in dat de meerwaarde beperkt is, zeker als ze het min of meer zelf kunnen.
Er kan momenteel veel met templates (steek er maar rap een shadcn template in!), er kan verder geprompt worden om interface design te laten doen door niet-designers.
Maar ik vraag me af: leidt dat nu echt tot goede resultaten? Als ik de meeste resultaten van vibe coding zie denk ik: dit is verschrikkelijk. Hier is nu eens echt over niks nagedacht. Volgorde van de menu items? Micro-interacties? User flow? Allemaal genegeerd, om een snel prototype online te zetten… sorry, maar dat is geen product design.
Ik ben zelf super geïnteresseerd om de laatste technieken zelf te gebruiken (zoals het een paar dagen geleden uitgekomen Firebase Studio: dit is de nieuwe default voor mij), maar als ik zelf begin te vibe coden ben ik snel 60 iteraties ver om tot iets te komen dat op iets lijkt.
Om daarna de code te nemen en verder te werken in een Cursor; of om het toch terug naar een design app te brengen om er over na te denken. Met andere woorden: het proces stopt niet bij de initiële prompt. Over dit proces schreven we met Obra een hele gids.
Mensen denken doordat ze iets visueels te zien krijgen de perceptie dat je 80% van je werk klaar hebt terwijl het eigenlijk 20 of 30% is. Het is niet omdat je snel een interface kan bijeen prompten, dat die interface ook echt goed en bruikbaar is.
Die interface is niet gevalideerd, het is in feite een eerste ideetje dat je op je scherm hebt gekregen. Het is het equivalent van de eerste 3-4u werk in een designprogramma. Ja, je hebt een visueel artefact: maar dat is nog maar het begin van het werk. Als CXO ben je nu amazed dat je dat gedaan hebt gekregen, omdat je die vaardigheid voorheen niet had. Maar als je wat je nu hebt naar productie moet brengen, is er nog een lange weg te gaan.
Een markt bestaat uit vraag en aanbod, en de vraag is momenteel beperkt.
Ik ben er zeker van dat er een betere periode aankomt na een tijd, maar gegeven enig macro-economisch wereldnieuws in combinatie met een nakende recessie, en de twee bovenstaande factoren (prutsers die de markt verpesten; dat product managers en CXOs zelf een interface in elkaar kunnen knutselen), is er minder werk voor product designers.
Eén van mijn theorieën is dat, als het over de designers met te weinig skills gaat, dat een deel van die mensen de jobmarkt zullen verlaten omdat ze gewoon niet aan de slag kunnen.
Een ander deel zal via mentoring en de juiste motivatie toch doorbreken tot een goed designer profiel. (Ik denk terug aan een apprenticeship – laat iets weten als je het juiste profiel bent!)
Wat betreft het vibe coden van producten en het “niet meer nodig hebben van een dedicated designer”. Voor kleine bedrijven zal er na een paar maanden zal er wel een besef zal groeien dat er misschien enkele fundamenten missen in het designwerk, en het misschien toch eens met enige coherentie aangepakt moet worden.
Als een softwarebedrijf groot genoeg is, hebben ze sowieso toch dedicated designers nodig. En er zal altijd een markt bestaan voor kwaliteit.
Wij hebben als nieuw bureau wel boeiende opdrachten voor startups en SaaS-bedrijven, maar het plan dat ik had van het echt zwaar opschalen naar 5 FTE in 1 jaar lijkt me op dit moment nog wel vrij ambitieus.
Wij werken nu met 4 freelancers aan verschillende opdrachten maar in # uren gaat dit over 2 FTE. Binnenkort gaan we naar een 3 FTE. We groeien traag, maar gestaag.
“An agency is people” en de juiste mensen tegenkomen om het juiste team te vormen blijft een permanente uitdaging. Wij hebben momenteel 1 job uitstaan, maar als mijn verhaal je aanspreekt, los van die specifieke vacature – neem zeker contact op.
Ik ga volgende week nog eens naar Belgie, om de eerste persoon die vast in het team komt werken verwelkomen.
Als ik België ga neem ik altijd de kans om vrienden en familie te zien. Daarnaast neem ik de tijd om koffietjes te drinken met de juiste mensen. Een babbel brengt altijd iets. Als deze post je op 1 of andere manier aanspreekt, laat zeker iets weten.
Ik ben nog altijd bezig met het bouwen van een groter bedrijf en de enige manier om dat te doen is via de juiste projecten, opportuniteiten en contacten. Neem contact op voor een koffie!
Currently, I am about four months in starting up my new agency. I wanted to document a bit of the journey as we move forward.
Starting a company has its ups and downs and is definitely not as stable a job as working for a product company, but most days I couldn’t be any happier with my decision to start an agency again.
Some days the doubts creep in. The most worrying part for me is that it’s particularly difficult this year to get the right clients, as some design processes have been turned on their head by the new AI design capabilities; the market is flooded with designers; and the impending recession isn’t particularly helping either.
I know what kind of projects we are good at: helping with the design role in a software team when a) a piece of software that is already successful is getting a redesign or b) in the phase of company growth where the company needs both the strategic vision of a senior designer, yet it’s not sensible to have a full-time hire. One task for me is to sell myself and my team to that specific kind of client.
When I was working in my previous agency, I literally had no idea how to do sales and business development. Most projects came via referral and overall things mostly flowed naturally. This is not the case this year and I have to do active outreach, keep a list of potential clients, and really get out there. I feel like I’ve picked up some skills in that area over the years. Part of it is a mindset to deliberately work on the company instead of in the company; another aspect is literally how you spend your time. If you are meant to work on business development, don’t be working on side projects or writing blog posts (guilty as charged…).
I also find it quite difficult to hire – what we do at Obra Studio is quite specialized. Even though there are many designers looking for roles, many don’t have the necessary skills to do the particular kind of work that we do. I’ve had a hard time defining what we want in designers. I am looking for sort of a mix between an agency and a product designer. Somebody T-shaped enough to switch roles within projects in the pursuit of shipping great software. Somebody who’s actually interested in user interfaces and didn’t just choose this field “to earn six figures”.
At this moment, we have two more open positions to fill. We are looking for a UI/UX designer with front-end skills. This is a contract role for one year in a part-time capacity. I am also still looking for a business partner to run operations in Belgium and take a joint risk in building the team. The main requirement is proven experience as an agency founder and to be driven to work on building out a boutique agency with a high quality standard.
The most difficult jump I foresee is the jump from 2FTE to 5FTE (full-time equivalent). While we currently work with 3 freelancers, we are only generating 2FTE of work. We need to move to generating work for 5 FTE. The business partner in Belgium is a crucial part in scaling up operations.
All in all, I can’t complain. The two things I was discussing are more or less evergreen problems for agencies: having enough clients, and hiring the right people. In general, things are going steady and we are approaching €75k revenue in a short period.
Currently, we have about 3 clients in what I’ve started to call “Obra Education” (Figma workshops, designing with AI workshops etc.) and another 3 in our main work, the design projects. Four clients are from Belgium, one from Luxembourg and one from the US.
I’ve steadily been working on our Craft CMS-based website with a trusty web developer freelancer. I’ve started to create landing pages for the different types of services we have on the Obra website. The latest one is about the UX rework of Bootstrap-based codebases. I was in a conversation where I was reminded that this was a specialty of my previous agency.
I notice more questions than I expected about Figma workshops; and about designing with AI. What I didn’t expect was no questions whatsoever about accessibility services, even though the European Accessibility Act is basically around the corner.
It’s tempting to sometimes focus on optimizing processes, but for now, given our tiny size (3 freelancers & me) it’s not necessary to optimize things too much. You can forever look at processes, templates and the perfect website. However, the focus should be on growth. I have to remind myself to keep my eyes on the ball.
It’s April 1st but I am already thinking a few months ahead. The summer months are typically low on work, as Belgium tends to fall asleep in July and you basically have out-of-offices talking to each other. I want to secure the right projects to work on to continue our growth trajectory. If you are in the market for an agency, check out our design services.
You can have these dreams about a cool design agency, but in the end, you have to treat it like a business. But if you treat it too much like a business, it becomes something else, something you might not agree with.
This blog post is about purpose, strategy and vision. Three highly conceptual topics. I believe this post might not be everyone’s cup of tea, but linking it to the right persons will help me on my journey.
Purpose
I was asked this question this week in a survey:
What is the purpose of your firm? Please rate with:
0 as a minimum: Maximising shareholder value is the main driving force when making business decisions.
Middle: When making business decisions we carefully balance financial, social and/or environmental objectives including the interests of our stakeholders.
7 as a maximum: Our company is deeply committed to both positive social and/or environmental outcomes. Purpose shapes our core value proposition and is a top priority of the company’s leadership.
When I answered, I put Obra squarely in the middle.
I had lots of thoughts lately about someone who made a statement that an agency is essentially a margin business; someone works for you, and then you take a margin on their wage/a cut on their freelance rate, and that’s it.
This comes with lots of philosophical questions; obviously my agency is providing employment for myself. It is providing employment for others (currently 3 freelancers & growing)
Obviously we have to make profit to exist.
But that’s not all there is to it.
You want to work on projects you ethically agree with.
You want to provide quality work that you are proud of. If my work was a dumpster fire but I got paid handsomely for it, I wouldn’t be happy.
You want to grow as a person & team
You want to build a team; there’s a social aspect to the job.
So within the range of “maximizing shareholder value” and “fully purpose-driven”?
Let’s find a good middle ground. Maybe shift it a bit more to purpose-driven if we have enough stability/money and thus the luxury to do so. Then another question that made me think:
Strategy
To what extent is your company planning the strategy? Please rate with:
0 as a minimum: We have some idea about the strategic direction, though there is no clear strategic plan.
Middle: We have a strategic plan, but we did not carefully generate alternative strategies to determine this plan.
7 as a maximum: We have clearly determined the firm’s long-term strategic plan and generated and evaluated alternative strategies before we determined this plan.
For this one, once again I put Obra straight in the middle.
But to be honest, it should probably have been 1 or 2: “We have some idea about the strategic direction, though there is no clear strategic plan.”
I determined strategy and planning are 2 entirely different activities (thanks to this helpful video); then put my own spin on it.
So these things are separated: a strategy comes from identifying a market opportunity, then checking if your company can do it better, faster or cheaper, by applying tactics. These tactics lead to activities.
Fig 1: Strategy: market opportunities lead to a strategy, lead to tactics, lead to activities
These activities can eventually be planned. So in a way, there is a thing as “strategic planning”, but how you get to it is not by starting with the planning.
So for example, a market opportunity I determined is doing something with the rise of LLMs that can basically generate entire front-ends now. Combining this with earlier vast experience in HTML prototyping and design skills as a team it leads to an opportunity to do something unique (see; slides on LinkedIn).
Such a market opportunity can be mapped on a strategy board. But then the actual activities to get there (make the slide deck, present the deck, determine the workflow, create project templates etc.) are a different process.
Like the referenced videoa above states, too often these things get conflated.
Fig 2: Activities: some you do, some you don’t. We all have limited time to execute on things. What is needed and what is a distraction?
Vision
Another thing I was triggered by this week is this checklist in the intro of the book Traction.
Specifically I was triggered by the first five points in the “Organizational checkup”:
We have a clear vision in writing that has been properly communicated and is shared by everyone in the company.
Our core values are clear, and we are hiring, reviewing, rewarding, and firing around them.
Our Core Focus™ (core business) is clear, and we keep our people, systems and processes aligned and focused on it.
Our 10-Year Target™ (big, long-range business goal) is clear, communicated regularly, and is shared by all.
Our target market (definition of our ideal customer) is clear, and all of our marketing and sales efforts are focused on it.
Figure 3: organizational checkup, from the book Traction (taken from the free Kindle sample)
Do we really have a clear vision, in writing? Currently, we work with 3 freelancers, so it’s not that important to go all vision on them. But as we will progress towards having more business partners, payroll employees, more collaborators etc. this will become increasingly important.
The book Traction was written specifically for a company that’s doing semi-well, 2M revenue with 10 people (in US market), but that’s kind of stuck where they are. The author argues that with their plan they have basically led these kinds of companies on a growth pad to unlock a better business.
I find most business books to be summarizable in a few key sentences. One book that helped me a few months ago was the eMyth – it’s also referenced in this book. Another one I need to look into is profit first.
When it comes to vision, with Mono our goal was to become a reference in UI design in Belgium, building high quality designs to serve our clients.
High quality is very specific; how do you even determine quality? (Dear reader, this question would lead us to far, but I certainly want to give this topic a go later ;))
A reference is in the eye of the beholder: who are you a reference to? Do you seek the respect of peers? What is “recognition” anyway?
Obra Studio is in many ways a continuation of what we did with Mono, but I feel like this time around, I need to work more onthe business instead of in the business.
The core logic of wanting to do quality work stays.
But there are so many new factors around this time, from AI to me living in Mexico to how the UX market is evolving (in weird ways). I guess the challenge is to keep chipping away at the problems, tackle them, and build the business.
If this blog post vibes with you in any way, feel free to e-mail me: johan@obra.studio . I removed the business partner listing from the website but I am still looking to collaborate with the right people to make this happen.
This week I got a chance to try out Subframe. It’s a new design tool that is slightly hard to position within the category of design tools.
Subframe follows the logic of Subform (RIP) where you are not working on a free canvas, but all your designs are “auto layout” by default.
A tool like Framer — that leans towards auto layout all the things — still allows you to draw something freely and then put it in a stack when you like; allowing for sort of a Figma-like freedom when exploring ideas (minus the proper vector tools).
In Subframe you don’t have that “creative freedom”, rather you are constrained to changing layouts by either editing them in a sort of “insert component in an already existing stack”-kind of way or by prompting them with AI.
The benefit of this style of working is that designs are essentially constrained to the “system”, which then allows for an immediate code export. In the spectrum of creativity vs system design, Subframe sits squarely in the system design logic.
In the current version, the base system itself does not seem that manipulatable (relying on a bunch of base ShadCN/Tailwind like components like many AI code generators).
What I would find interesting towards the future is to be able to manipulate the base system in a manner that’s more flexible. In my projects I have a lot of custom needs.
Another thought I have is that if code conversion is immediate, but you then change something in the code, like adding a new component, how do you ever backport it back to the design app?
Within design systems, for years, we’ve been looking for sources of truth.
There is the design tokens logic (often overcomplexified by consultants); there is the problem of syncing design to code; and there is the problem of working at scale. On the corporate level you usually end up with a tome of guidelines (think Shopify, IBM…) that is sometimes helpful and sometimes wildly inflexible.
Would Subframe help solve this problem by having an immediate bridge between design and coding work? The paradigms the founder are working on are at the verg least extremely interesting explorations into this problem statement, and I am looking forward to follow its further development.
