Where deep tech
meets business.

I spent an intensive week in Shanghai recently, supporting our local team and meeting current and future customers. I've been coming to China for more than ten years now and it still rearranges my assumptions every time — in some ways it feels like a trip into the future and the past simultaneously.

The thing that stuck with me this time wasn't in a customer meeting. It was in the back of a Didi.

Several of the taxis I rode in had a transparent chassis system — 透明底盘, the composited under-vehicle view that lets a driver effectively see through the floor when parking or navigating a tight space. In Europe I had filed that away as a premium feature, something you find near the top of an options list. In Shanghai it was in ordinary working taxis with serious mileage on them.

Feature parity arrived quietly

The numbers behind that are the part worth sitting with. More than 70% of new cars sold in China now ship with L2 or higher ADAS. Cars priced around ¥196,000 — roughly €25,000 — come with systems I would have called premium two years ago.

The easy read is that features got cheap. I think that misses it. What actually happened is that the car changed category.

The replacement cycle tells the real story

Chinese industry data puts the average age of a used new-energy vehicle at around 3.4 years, against roughly 8.6 years for a used petrol car. Somewhere near 90% of NEVs get replaced inside five years, while about 70% of petrol cars stay with their owner longer than that.

Those aren't the numbers of a durable asset. They're the numbers of a device. People are buying cars on something much closer to a phone cycle, and everything downstream of that assumption changes — how the thing is sold, how it's serviced, and above all what the software is expected to do after the sale.

The retail side made the same point visibly for a while. NIO opened its Shanghai flagship inside the HKRI Taikoo Hui mall in 2017, complete with a library and an art gallery, and for several years the mall showroom was the signature of the new Chinese brands. That particular experiment is now receding — EV brands have been pulling out of mall space, with robotics and sportswear brands moving into the units. The storefront was a phase. The buying behaviour it was designed around stayed.

What that does to software expectations

This is where it gets directly relevant to anything I work on. In the customer conversations, the expectation that came up repeatedly was constant updates. Not "does the software work" — that's assumed. The bar is whether the experience still feels new and relevant a year in. If the car is a device on a three-year cycle, the UX has to keep earning its place for those three years, and a release cadence measured in model years doesn't survive contact with that expectation.

The regulatory posture follows the same logic. Local OEMs have adopted the Western frameworks — ASPICE, AUTOSAR — selectively rather than wholesale, optimising for speed over ceremony. It's a genuine trade rather than an oversight, and it carries genuine risk; the interesting question is not whether it's correct but how long the gap between the two approaches stays survivable for the slower side.

The uncomfortable part

If your development assumptions are built around a fifteen-year vehicle life and a multi-year release cadence, you may be building very carefully for a product category your competitor has already left.

What I can't tell you is whether a three-year replacement cycle is a market that stays that way, or an artefact of how people treat any new technology before it settles down. Ask me again after the next trip.

Close ↑

Few months back i started my vibe coding career with my own website atrorantaaho.com and a web replica of my TI calclulator - now it was time to move on to the heavy lifting and see if I could become an Embedded SW developer overnight. I'm not leaving my day job yet but I can tell you the results are promising! 😉

I'm excited to introduce you to my latest vibe coding project Pörssisähkö (electricity spot price) Physical Ticker Device. Finland moved to 15-minute spot pricing recently, and I wanted something that just tells me the current price at a glance, no app required.

Current prototype:

⚡ Board: ESP32-4848S040C-I — an all-in-one module (Guition/Sunton), no breadboard wiring
🧠 MCU: ESP32-S3
🖥️ Display: 4.0" 480×480 IPS (ST7701S), 16-bit parallel RGB
👆 Touch: GT911 capacitive — swipe between Today / Tomorrow / Settings views
📡 Data: spot-hinta.fi's public API, 15-min resolution, fetched twice daily

Everything's rendered with direct drawing calls (Arduino_GFX) — no GUI framework, just immediate-mode graphics on an always-on RGB panel. It's USB-powered for now, which is the obvious next problem to solve. And yes, this HW is an overkill but the integrated ESP modules make it very easy to skip the assembly and focus on coding.

The bottom line: I coded this in an hour — or technically Claude did — with little to no understanding of what "I" wrote. If it isn't mission critical (consumer electronics, say), this approach may well suffice, and the software value-add layer is going to change very fast.

Close ↑

I spent a week at NVIDIA GTC 2026 in San Jose in March. Long trip from Finland — but I treat a week like that as an investment: pressure-testing assumptions, meeting the people building the future of autonomous systems, and bringing back insights that actually matter for customers and product decisions.

The headline from our week was Qt Group joining the NVIDIA HALOS AI Systems Inspection Lab. Months of work turned into something public and concrete. But the announcement itself is almost the least interesting part of the story. What's more interesting is what it signals for how the Physical AI market is actually going to develop — commercially.

HALOS is a consolidation play, not just a safety framework

NVIDIA built HALOS as a full-stack safety system: functional safety, cybersecurity, AI safety, and regulatory compliance, unified under one framework across three compute layers — DGX for training, Omniverse and Cosmos for simulation, DRIVE AGX for deployment. The first ANAB-accredited AI Systems Inspection Lab in the world. That's the technical story.

The commercial story is different. When NVIDIA builds a validated, accredited ecosystem and starts naming who belongs in it — automakers building on DRIVE Hyperion, tier-1 suppliers, safety tooling vendors — they're not just creating a technical framework. They're creating a procurement shortlist.

BYD, Geely, Isuzu, Nissan: all adopting NVIDIA DRIVE Hyperion for Level 4 vehicles. When your vehicle platform is NVIDIA, and NVIDIA tells you which safety tools are validated for that stack, the conversation changes. It's not "can you support CUDA?" — it's "are you in the HALOS ecosystem?"

The only player in a new niche

The specific angle for Qt and Axivion is narrow but powerful: NVIDIA published official CUDA C++ Safety Guidelines, and Axivion is the only static analysis tool that automates compliance checking against those guidelines. Not one of several — the only one.

In B2B sales, "the only" is a very different conversation than "one of the best." It removes evaluation. It removes comparison. It puts you in a category of one.

NVIDIA is now featuring Axivion directly in their developer newsletter and on the NVIDIA Trust Center as the go-to tool for CUDA safety guidelines. That's not marketing — that's a distribution channel.

What this means in practice

There are three real commercial effects here:

First, NVIDIA will start referring development teams that need FuSa support directly to Axivion. When a team building on DRIVE Hyperion asks NVIDIA "who helps with functional safety for CUDA?" — the answer is now a short list with one name on it.

Second, the credibility transfer is immediate. Being validated by NVIDIA carries more weight in a safety-critical automotive conversation than any amount of independent marketing. The question "is this tool used in the NVIDIA ecosystem?" now has a clear answer.

Third, the market is consolidating faster than most expect. Physical AI is not a future trend — it's happening now, with the world's largest automakers already on the NVIDIA stack. The window to be established as the safety tooling partner in that ecosystem is narrow.

The real work: delivering value to joint customers, one interaction at a time. Partnerships like this only matter if the follow-through is there. But the foundation is now solid.

Close ↑

I started my professional career in Supply Chain and Global Procurement and ended up spending 12 years in various sourcing roles and later advising procurement leaders on their choices of technology at Sievo. With the development of AI tools lately, I've been closely following the market and debating if the traditional SaaS tools will disappear with the push of Agents and self-built analytics.

After coming across Stan's post on Zinit and the super easy "throw these files to Claude and see it yourself" self-eval (or demo as Stan called it) of the platform I grew very curious. Finally had the time this Sunday to run the eval and see it myself.

Few reflections here.

The visualization and findings are solid, clear McKinsey quality — similar to what I've seen numerous times before and something I've come to expect from working with McKinsey over the years.

Furthermore, the summary is crisp, well structured and to the point. This definitely drives top-down action. Back to this later.

My biggest concern: the data reality gap isn't addressed much at all. Quite honestly, this is what I was expecting AI tools to handle in the future. Yes, this is a demo only — but the file is pretty much dream data for anyone wanting to run analytics: clean item descriptions, fairly consistent supplier names, one row per transaction, pre-categorized. Real ERP exports never look like this, and this is where the value of spend analytics tools (should) be, per my experience.

Data extraction. Rarely does the data you need live in one consolidated ERP. It's actually scattered around multiple — sometimes hundreds — of ERP systems (for larger enterprises), Expense Management Systems, MRO systems, or Supplier Systems. APIs are getting better and data moves fast these days, but knowing what to extract and how to combine and cross-check these data points is where the real value lives.

Categorization. Validation of the classification is easily 50% of the work. I've done this hands-on for different industries, regions, SMBs and enterprises — and it always gets messy. The demo has a clean "Category" column. For indirect data in practice, you'd first rely on GL codes, then cross-check with invoice descriptions, enrich with supplier data (DHL won't provide catering services regardless of what the GL code says), and then make an educated guess on where this invoice should go. Apply once, let AI learn from here.

The "same item" problem (direct procurement). The demo has matching item descriptions and harmonized item numbers across sites, which is what makes price harmonization possible. In reality, Plant A calls it "Hydraulic Filter 10-Micron" and Plant B calls it "HF-10M Filter Hydr." — same part, different free-text description, so the algorithm sees two different items and misses the savings entirely. It's not unusual to find the same bolts and nuts re-created 100 times with a new item number for each product variant.

Unit of measure chaos. The demo uses consistent units — EA, PK, and so on. Real data has the same item bought as EA in one plant and BX in another, making price comparison meaningless without normalization. A 10-pack of O-rings and a single O-ring both showing "Unit Price: $0.42" is a common silent killer of harmonization analysis.

These are just a few highlights and examples. To come to a conclusion:

1. A crisp summary is just the top layer of the cake. How spend analytics systems handle the data classification problem is where the real value lies.
2. From high level to the details with a few clicks — in an ideal UI you can quickly validate your findings at the raw data level, confirm the findings, and then deploy actions.
3. Action is what makes the changes, and this is where most organizations still fail to execute. You analyze and summarize, and in the end procurement operations continue as before. I see big potential here with Agentic AI — and this is where Zinit also seems to have an offering, with compelling real-world use cases.

The Zinit demo files are available here for anyone interested: zinit.com/en/spend-analysis

Close ↑

Inspired by Steffan Schumacher's Vibe Calculator — and the very same TI-86 I used back in high school (still have it, still works). Built with Claude in one session: a fully functional graphing calculator styled to look exactly like the real thing. Type any function into Y1–Y3, scroll to zoom, drag to pan.

Open the calculator →

Close ↑

I lead the Software Quality Solutions (SQS) business unit's commercial functions at Qt Group. Our tools portfolio is wide — covering everything from frontend UI testing to backend headless embedded development tools. These tools didn't grow organically within Qt; they came through a series of acquisitions, each bringing its own documentation, its own positioning, its own buyer personas.

What that means for our sales organization is a lot of enablement. A lot.

The typical path to product training looks like this: take a highly knowledgeable person, have them do a brain dump into a document — usually a PowerPoint, usually around 100 pages — then schedule an hour, maybe half a day if you're lucky. The outcome? Reps already stretched thin by their day-to-day work capture maybe 10% of the content. So, you re-train. You record sessions. You build shared material libraries that very few open.

One Saturday, I had a different thought: what if we flip the script?

Give Claude access to everything and make it an interactive Q&A tool. A 24/7 product manager. A sales enablement rep that never gets tired of answering the same question for the fifteenth time.

In practice, here's what I built

1. Connected Claude to our company SharePoint, Confluence, and product websites
2. Pointed it at the relevant materials and had it work through hundreds of pages of documentation and presentations
3. Asked it to build a simple web frontend with product categories and a Q&A bot

One day of work. The result isn't perfect — it's a prototype, not a product. But it changes something fundamental: a new rep can now ask "what's the difference between Squish and Coco?" or "how do we position against competitor X?" and get a sourced, accurate answer immediately. At 11pm. Without bothering anyone. Your product manager and sales enablement rep, available 24/7.

More updates to come as we roll this out.

Close ↑

Gong costs somewhere between $100–200 per user per month. It's a great product: conversation intelligence, deal risk alerts, pipeline analytics, coaching workflows built on billions of recorded sales interactions. If you're running a serious outbound motion and can afford it, you probably should. Most teams can't, or won't — Qt Group falls into the latter.

Qt runs on Microsoft Teams. Last year, like many companies, we got access to Copilot features including AI meeting transcripts and summaries. With our QA GTM teams we decided to run a small pilot, which then became a standard practice.

The workflow is three simple steps:

1. All first meetings and discovery calls with new prospects are recorded — always with the customer's explicit consent. (Surprisingly many don't object — except in Germany.)
2. Teams generates an automatic transcript and AI summary.
3. The summary gets logged into Salesforce, and posted into a dedicated Teams channel built specifically for this purpose.

That's it. Nothing custom-built, no new tools. And the best part: even without automation it takes 2 minutes of the rep's time.

What this actually buys you

For management it's pipeline visibility at the top of the funnel — the part that's usually invisible. Are we meeting ICP accounts? Are meetings generating next steps, or just good conversations? You no longer have to take a rep's word for it.

For product management it's a free feedback loop. What questions come up repeatedly? What objections keep surfacing? What features are prospects asking for that don't exist yet? That signal used to live only in the heads of individual reps. Now it's searchable.

For sales reps it's a shared learning library. You can see what your global colleagues are doing in their calls — what's working, what's landing, what's not. When a tough technical question comes up, you can search the channel for similar situations and find real examples with recordings attached. No more "let me get back to you" when the answer already exists in your team.

For the prospect, when you share it: a clean summary of what was said, promises in black and white, and clear next steps.

The honest part

Simple to implement. Harder to maintain. Recording consistently, posting the summary, actually reading your colleagues' summaries — it needs to become habit. That means manager modeling, consistent expectations, and a few reminders before it sticks. The tool does the easy part. The cultural change is yours to lead.

Close ↑

First test of the automation. This website was vibe coded in one evening to help build my personal brand, but also to share with the world my AI projects in sales.

Three hours from idea to live website with Claude and Vibe Coding. A few things I'm particularly happy with:

• Claude, GitHub, and Vercel fully wired together — shipping an update to the site with a single command in Claude
• Automated QA runs before every commit: Playwright running 20 different UI tests within Claude, fully automatic
• WAF, Bot Protection, Rate Limiting, and DDoS mitigation enabled — not that it needs any of it, but because security
• Basic marketing analytics in place — I need to work on this part

And of course, a little bit of content on how AI is changing tech sales. I'll be posting more about that.

Close ↑