English versions of selected startit.rs articles. Each section below is one article; the yellow box at the top of every section links to the Serbian original, and the Serbian original links back here.
In a classic digital product, the data team sees the user from the moment they open the app. Everything before that, where they were, what they used and why they came at all, is as a rule an assumption or a survey.
The gap is not small: some of the most expensive questions in a product, why someone comes and why they leave for a competitor, fall precisely into that invisible part, so companies cover them with estimates and market research.
For most products that is the only possible way, because other people's data is not theirs.
Solflare, the Serbian-Croatian fintech company behind the Solflare Wallet, used by more than four million monthly active users, works in a system where transparency is built into the infrastructure itself. Every transaction on the Solana blockchain is public, so the activity history of any wallet can be traced.
That history exists before the user installs their app, and it continues afterwards.
We asked Mihael Alapić, Data Lead at Solflare, how that changes the job of a data team. A year ago the team was just him; today there are six of them, and they are looking for two more.
All transactions that happen are visible on the blockchain.
That means that for a given user's wallet we can see the entire transaction history, regardless of whether it was made in Solflare or outside it.
If some user account moves to our competition and starts using their wallet, we can use that information too.
For users who install our app we can see whether they have had contact with crypto before, and use that for segmentation.
Combining product analytics sources with blockchain data really opens the door to a large number of different analyses.
— Mihael Alapić, Data Lead at Solflare
Segmentation here means dividing users into groups by behaviour, and product analytics is what the app itself records: screens, taps, steps. What is new is that those two things are being joined with a public ledger of transactions that belongs to no one.
This is also where one of the biggest engineering problems sits, one the data engineer job ad names itself: the pubkey from the blockchain, the device identifier from the app and the internal user ID need to be reliably linked so the team can understand the user journey across on-chain and product data.
The second change is the one every other data team sees as well: AI. Mihael describes it like this:
AI has changed the data team's job a lot.
Getting to reports and insights has become many times faster, mainly because far less time is spent on technical things that can be learned through practice, like writing code and SQL or learning a particular syntax.
What has stayed manual, and what now gets even more emphasis, is QA of the results, but also questioning the solutions that AI offers.
It is important to know how to communicate with AI, what can be trusted and what needs additional checking, but in general people's productivity has grown a lot.
What has not gone away is the most important part of the job: understanding what actually needs to be measured, whether the data is good and what to conclude from it.
The data engineer job ad says it directly: working with Claude Code is everyday practice there. The tools are otherwise standard for a modern data team, BigQuery, dbt, Python, PostHog, Dune, Metabase, Tableau; what is not standard is the amount and the kind of data that flows through them.
Raw transactions and app events become information through dbt: that is where they are cleaned, joined and modelled before they reach a report.
For an example of data overruling a decision the team would otherwise have made on instinct, Mihael reaches into Solflare itself.
One of the more significant examples was when data analysis showed us that a relatively small percentage of users, the so-called whales, meaning users with exceptionally high spending, generate a large share of our revenue.
That prompted us to give them much more attention, including setting up a team focused on their retention and satisfaction.
We launched VIP programmes, exclusive events and perks, and we actively involve them in product development through feedback on new features.
Insights like this sound fairly simple when retold this way, but they are actually the result of a combination of several different analyses and good knowledge of the product, so they are not exactly an everyday thing.
The data team has grown to six in a year. Asked what separates a good candidate from an excellent one in an interview today, Mihael says:
A good candidate stands out through knowledge, an excellent one through the speed with which they understand the problem, adapt and arrive at a quality solution.
With AI constantly raising the productivity baseline, the biggest difference today comes from curiosity, ownership, critical thinking and the ability to use new tools smartly rather than blindly.
Many of our readers who work with data do so in banks, insurance or e-commerce, not in crypto. For them Mihael has a direct answer:
Of course they are relevant for people outside the web3 world too. I hadn't had much contact with web3 before either.
What matters is that the person is generally good with data and interested in the industry they are entering.
What you additionally get here, working with large event datasets, complex distributed systems and a sense of ownership over the work from raw data to business decision, is very transferable outside web3 as well.
The job ads list both as desirable: experience from fintech, banking or insurance, and work with blockchain data.
Two positions are open, both for work from Belgrade, Novi Sad, Zagreb or remotely. Applications go through the ads: Senior Data Engineer and Senior Data Analyst.
When Marija Mladenović of Solflare walked us through the way her team designs with AI at one of our AI Hub meetups at the end of April, she closed with a caveat: what was giving her good results right then might not work at all a month later.
Four months on, we invited her back to measure together how much her practice had actually changed.
Asked to sum up the difference in a single sentence, she offered a scale: at one end, a process where everything is done by hand; at the other, one that AI drives. "If we were at 50-60%, we're at 80% now."
And when we asked how much faster the whole cycle is than in April, which was already dramatically faster thanks to AI, her estimate is at least 50%.
We started with the obvious topic: Figma, the main tool for most designers over the past decade or so.
Solflare's design team still keeps its design system, tokens and components in Figma, and that is where both designers and developers review everything before implementation. Marija is still in it every day, but for a different reason.
Not to design, but to keep an overview: to change a piece of copy, to look at a screen when we're checking something.
More to answer questions than to design.
Personally, I don't think Figma should be the source of truth for design.
The source of truth should be what's in the code, and that should then be visualized.
— Marija Mladenović, product designer at Solflare
Figma as a source of truth, she says, is a double-edged sword; her position is that the overview of what actually exists in the code should be generated, not drawn.
The decisive change is that Figma's MCP got a new version. In April, reading a file through MCP was so slow and burned so many tokens that for heuristic evaluation she preferred to send screenshots.
Today the same job, reading screens and pulling images out of the file, takes a few minutes instead of twenty to thirty. So what she used to do through a workaround in April she now does directly in the file.
Figma itself improved in another place too: there is finally a plugin that pushes a prototype from code straight into Figma, a tool she says she had been waiting a year for.
In April, Claude Design had existed for 12 days and came with a tight weekly limit; today it is a fully fledged product, and in her team, she says, it has become a habit. She uses it every day herself and has never once hit the limit.
Claude Design delivers a prototype in a couple of minutes. The time now goes into what surrounds it: writing the brief, laying out the key screens on the canvas the way you would in Figma, iterating through them, and only then developing the chosen part into a prototype.
For a whole feature that is a few hours of work. With an up-to-date design system, the output is "very similar" to their product, "almost identical in some situations".
For a competition inside the product she wanted a level-up animation, a job she would not even have attempted in Figma:
In a couple of iterations it packaged it perfectly, and I passed the file on to the developers.
That's something I wouldn't do in Figma, because I can't achieve it there.
I could, if I spent five days on it, which is exactly why that kind of work simply used to get skipped.
The furthest reach of automation is around the design system itself. All of it is packaged into a skill: a colleague of hers built it, and the whole team uses it.
You run it once: Claude reads the Figma file, recognizes what has changed in it and opens tasks in ClickUp, with the component version, a list of changes and the people who implement it tagged. That whole step is over in a minute.
And the biggest brake on skipping Figma completely?
Even now I can build everything through AI. It's just that what I get simply isn't consistent enough. That's what stops me from just handing it over to the developers.
She also adds a caveat of her own: she has not yet tested a full process without Figma on real features, so she cannot claim how it would hold up in a team with a complex design system.
She expects, though perhaps not quite by the end of the year, that they will build most things through AI, with the designer defining the product and setting the direction. She sees the process evolving toward a repository (say, GitHub) where design is on an equal footing with code.
Piece by piece, it already exists: a repository can already be imported into Figma and connected to Claude Code, and Storybook through MCP makes components readable for AI.
What is missing is for all of it to work as a single whole: to see visually what has been implemented and, from that, prompt a new page into existence.
At the end of June, Meta open-sourced Astryx, a design system that grew internally for eight years and powers more than 13,000 of Meta's apps, released explicitly as a system that both people and agents can work in. It is no coincidence that it came out in exactly this window.
Figma's plugin that connects Claude Code directly to Figma points the same way.
Her experience, moreover, is not an outlier. According to the State of Prototyping survey that UX Tools ran in spring 2026 on a sample of 1,478 designers, Figma still leads at 82.6%, with Claude right behind at 50.8%.
Of the ten tools designers use most each week, five are AI: Claude, ChatGPT, Claude Code, Figma Make and Gemini.
The AI in Design Report 2026, published in March, so still before our April event, pointed the same way: 91% of designers use AI in design at least weekly, and 75% daily.
AI Hub is supported by
