- Posted in agency-life
De laatste dagen heb ik zitten werken aan het herinterpreteren van een vibe-coded prototype naar een wireframe. Een beetje omgekeerd werken dan anders dus.
Maar het is leuk en spannend: het project team zit goed met slimme mensen, ik leer veel bij over het onderwerp van de app – sales – en het project heeft een stevig tempo.
Ik ben ook blij dat we in de zomermaanden een stevig project hebben kunnen scoren. Altijd goed voor de omzet en de werkzekerheid.
- Posted in agency-life build-in-public hiring industry jobs
I started hiring again at Obra Studio. Find our jobs at our website:
We’ve grown a lot since we started the agency in the beginning of 2025. We’re a solid team now looking to grow to the next level.
A few things keep coming back in calls so I thought I’d write about them to avoid giving the same explanation to everyone.
Requiring Dutch as a language has given me a lot of pause over the years. Why is Dutch a hard language requirement when more than 80% of our internal communication is in English, and clients in general don’t mind working in English…?
This requirement is about the Belgian market. Currently we have 6 Belgian clients and 2 clients in the US.
Team members are encouraged to use public channels on Slack, avoid too many DMs (especially when they contain project info or discussions) and speak English in general.
So why still this language requirement for Dutch? The reality of the Belgian IT market is that a significant part the taxes we pay flow into government and government-subsidized projects (18.15 billion EUR in 2024).
The environments you end up working in for some projects (universities, government departments, subsidized orgs like VDAB, VRT etc.) are typically 100% Dutch and projects require you to speak Dutch. As such to be hirable for these types of contracts, you need to speak Dutch as well. We haven’t had this type of project yet, but with Mono in the last two years, a rather significant part of our income came via these types of projects.
These projects have been a reality to keep an interface design agency afloat in Belgium. For all the buzz around Belgian startups, the scene in general is relatively immature with most funding floating to the same types of parties; funding in general being severely compared to a few golden years ago if you exclude the outliers (e.g. Lighthouse) or companies that don’t hire for project work anyway (Odoo).
A secondary reason is that some of our work is in an industry context where the users of our work (e.g. factory workers) do not speak English. The usability test has to be conducted in Dutch.
It is our intention to create two company hubs: one in Belgium and in Mexico City.
Belgium is pretty small and we focus on the triangle Antwerp – Brussels – Ghent. Currently most of the team is based around Ghent, but we have people from Brussels and Limburg as well.
Mexico City is a huge city and travelling within the city can take as much time as switching cities in Belgium by train. We are generally centered around the neighborhood of Condesa.
Generally work is 100% remote with exceptions for meeting the other team members for design workshops or limited social activities. Independence to go towards our clients and conduct workshops with the client, do usability tests and field research on location (in hospitals, factories, schools…) is a requirement for designers.
I don’t want to be the company that sends their employees on an Ardennes weekend twice a year, taking away their free time. However, I am planning to do a Christmas dinner in Belgium, and eventually want to make enough money to have the team gather in a place with a latin vibe, realistically a good place in Spain would be the stand-in for the ultimate dream, sending Belgian to visit Mexico or the other way around; sending the Mexican team to visit Europe.
For Mexico City, the idea is to get an office in a co-working space and work together 1-2 days a week. Ideally the person we find is a real chilango, and communication is in both English and Spanish. We have been doing designer, developer & PM meetup events in the city to grow our network.
Some freelancers have already decided to travel on their own to Mexico and say hi. I myself travel 2-3 times per year to Belgium and then spend time with the team and clients.
We are not ready to hire payroll.
I wrote on this blog earlier that I made the decision to go for freelancers only. We split our job in 2 roles: hiring in Belgium for a freelancer that works part-time and hiring in Mexico for either part-time or full-time.
I feel like eventually we will want to work with mostly people on payroll when we reach a stable point when it comes to how the business works. But right now, the talent we need is usually with freelancers; and I believe a payroll job is a (very) long-term promise for a stable job, which we can’t provide yet.
The risk I can realistically assume is to give a freelancer a 3/5 contract for 1 year (132 days); this ties the freelancer to the company but also allows them to do other projects. When there’s a lot of incoming work we can give more work to the freelancer; but if not, in general they have much more certainty having an agency contract than being a freelancer having to sell all of their own projects.
When a freelancer joins with a year contract, they don’t have to worry about sales or marketing themselves. Projects get sold for them. You have stability for 1 year and possibly much more if the agency grows.
This stability comes at a certain price where the agency obviously takes a margin on the work to grow itself and to pay the roles not directly generating revenue (business development, sales, marketing)
In many applications, designers mention that they are not learning; either they are in an environment where they are the only designer, or the environment they are working in does not value design.
Obra is 100% the polar opposite of that, where if you’re looking to expand your skills and to grow as a designer, you are in the right place.
That doesn’t mean we don’t have a baseline expectation in place for the level of design you already have. We want you to grow from a good designer to an excellent designer.
At Obra, we have an education pillar where we focus on Figma workshops, we’ve been actively exploring how to design with AI (in a good way) for almost a year now; and in general, we are focused on reaching a very high level of design.
If a high enough level cannot be attained, the designer is mentored to get there (and the more senior designers compensate to deliver a great project). There’s my profile as an agency owner, but next to this we currently have 2 senior design mentors to help grow medior designers to a senior level.
Are you interested? Know someone that is perfect to join for an important role to grow a new boutique design studio, that helps software companies to the next level? Find our jobs at our website:
- Posted in pre-accounting workflow
This is another pre-accounting post. Last time I talked about dealing with international invoices in Google Sheets.
This post is about processing credit card statements efficiently.
The task at hand here is to compare the expenses you have in 1 table in a sheet, with the statements from the credit card expenses statement.
If you are doing pre-accounting tasks i.e. gathering all docs for your bookkeeper, this helps you to gather your documents.
I will look at every line item and then either validate that I already have the invoice, or be reminded to find the invoice.
Your credit card has a final value that gets removed from your business account when it’s time to settle the bill. Every time you make a purchase with a business credit card, a line item gets added to the statement.
Your accountant will have to match the line items against the corresponding documents to have supporting documentation when doing the quarterly VAT return.
If you accidentally make a private purchase, this will have to be marked so a private purchase doesn’t end up in your business expenses.
My accountant has complained in the past that I didn’t find every document, and then I was presented with the dreaded “wachtrekening”, a document that lists all the missing documents.
This list always contained 10-15 documents… after a while, I got complaints from my bookkeeper about my accuracy when doing the pre-accounting, so I decided to be more diligent about it.
Every month, I get my business credit card statements from KBC via Doccle. There is a feature within Doccle where you can add an accountant to a connection. Within that feature, you can add an e-mail address. I added my own e-mail address, so this way, I get the statements via e-mail and do not have to enter Doccle. This is what they look like:
This old document contains only 3 transactions, but at this point in time for Obra Studio, I have to process 30-40 transactions per month.
To make sure that I have an invoice for every line item on the statement, I started adding the line items from the credit card statement to what I call my “shadow bookkeeping” sheet.
This is a Google Sheet that contains income and expenses.
As a first step, I need the data. I’ve saved this prompt, which I put in ChatGPT along with the document:
Please give me a CSV of this PDF with the following columns.
date of transaction
date of settlement
description
amount in EURChatGPT then generates a CSV:
After downloading this CSV, what you’ll want to do is append the current sheet to your Google doc, via the “Import file” dialog.
This leads to having the entries in your Google doc:
The next step is unfortunately a manual step for me: look up the different documents and compare them against the statements.
There’s more things to be automated here: finding the documents in my mailbox, and match them automatically.
A task for an AI agent, maybe?
If you have any workflow tips, feel free to share them in the comments.
- Posted in film
Ik wist niet dat er een nieuwe Jurassic Park uitging komen, tot ik hier in de buurt een gigantische advertentie zag.
Ik zag uit dat er een nieuwe versie van Jurassic World Evolution uitkomt tegen eind dit jaar.
Het is misschien niet zo hoogstaand, maar: sign me up!
- Posted in development react-native
Yesterday afternoon, I sat down with a friend and asked him for some advice on React Native.
He recommended that since everything is moving towards Expo to use Expo Router, to use React Native Reusables (which is akin to a shadcn/ui for React Native) and also to use NativeWind.
I got inspired and decided to just make an app. I started at 6pm and I finished at 9pm.
Making something is the best way to get experience. First, I created new React Native reusables project.
I removed some of the initial complexity of the setup. It ships with six or seven components, but I actually only wanted two. Components work shadcn-style so you can easily remove the code and add new components. It also ships with dark mode, and I didn’t want to get lost in the details, so I removed the dark mode code.
The easy thing about the Multi-Currency Converter is that I’ve built it two times before. I built an iOS version that I never shipped (see this blog post), and a web version (which you can find here). Because I know exactly what I want, I can look at the previous app and instruct an LLM to “vibe code” it for me.
Here’s a demo of my result:
After doing some initial setup and understanding the codebase manually, I got started.
I set up the UI for the main view containing a list of your currencies and a virtual keyboard, the edit language settings view and the edit currency settings view, I started making improvements.
I used a combination of Cursor, IntelliJ Idea Ultimate, the mac OS terminal and Wispr flow
After having a working UI with mock data, I got to implementing the actual functionality. I already had the code for this from previous projects. This was an easy conversion from the web version since the code is pretty much the same: a request to an API storing the user settings in local storage and… done.
I decided not to focus on i8n, dark mode or offline support for now. These features can always be added later.
Overall, the experience was quite good. Changing the Tailwind styles via NativeWind felt more closer to web development than anything else
The last time I tried to make something with React Native was 6 or 7 years ago. Yesterday I made an entire app in a couple of hours, that works both on my Android phones and my iPhones.
Next up is checking out more of the evolved ecosystem: I hear good things about EAS – Expo Application Services. Maybe I can get a build into the hands of people.
I also have a 6-month old marketing design that I need to get out. Maybe this could be a new Framer project? Framer has been evolving like crazy.
If you’re looking to help ship any of this, let me know: johan@obra.studio .
- Posted in pre-accounting workflow
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):
=INDEX(GOOGLEFINANCE("CURRENCY:"&G171&"EUR"; "price"; B171); 2;2)*F171This 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).
=IFERROR(INDEX(GOOGLEFINANCE("CURRENCY:" & G163 & "EUR"; "price"; B163); 2; 2); INDEX(GOOGLEFINANCE("CURRENCY:" & G163 & "EUR"; "price"; B163 - 3); 2; 2)) * F163This 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:
- Posted in agency-life obra-studio
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!
- Posted in workflow
How to kill processes that are running on a certain port? For example, I am running shadcn but I get an error that the port is in use (“EADDRINUSE”).
How can you fix that? For example for port 4000 – list the processes (PIDs in macOS):
lsof -ti:4000 Then kill those processes:
kill -9 $(lsof -ti:4000)That should do the trick!
- Posted in rant - 1 comment
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.
- Posted in conference process rant
I watched this Beyond tellerand talk by Matthias Ott and it really made me think. So much that I wrote this long blog post.
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.