Technology Is Not an Afterthought

Technology will always shape the entire lifecycle of a product. I hear a lot of people who are strong on theory say it doesn't matter. To me, maybe that's because their problem isn't hard enough, or they don't have the planning and vision to map out the overall technology for a project.

I'll borrow one of my recent products to talk about this: Look. Repo

A Clear Plan

My product is an app launcher, and I'm someone who loves optimization and speed, so my app truly needs to be:

• Fast
• Lightweight
• Consumes little resource on the host machine.

With requirements like these, reaching for a cross-platform technology like Flutter or Electron is a blasphemy; it runs against the original goal. So I chose a systems programming language to handle the layer underneath, and native on top: Swift for macOS. To make the app run faster, down in the core we also use quite a lot of algorithms for search and ranking, greedy and dynamic programming being the prime examples.

Change Early. It Hurts, but It's Worth It

When it came time to port the app to Windows, I chose C# and WinUI3, because I figured native would be the better bet. But the truth was fairly brutal: Microsoft's stacks tend to be underbaked, buggy, and not great on performance. My app has a lot of hard effects like rounded corners, transparency, blur, and so on, and UI3 handles this kind of difficult work quite poorly. One more thing: when I built the app, the bundle ballooned to 60MB. Plenty of people would think that's small. For me, absolutely not.

For the reasons above, even though porting the app from macOS to Windows had been a lot of work, I still decided to throw away what I'd built on Windows. In its place, a new calculation: Tauri. A cross-platform technology with a Rust core and a frontend that's almost limitless. Tauri's core being Rust is a plus, since Look's core is also Rust. After porting Look to Windows and Linux with Tauri, the app bundle dropped from WinUI3's 60MB down to 4MB, and all the hard effects I wanted to apply could be done quite cleanly, because I chose Vanilla JS for the frontend.

If I hadn't changed course early, sure, I could still have made it work, but my app would have had a lower standard. C# .NET performance can't compare with Rust, the app would be heavier, and over the long run, as more features pile on, changing it would have become exponentially harder.

Leverage AI

Inside my Look there's a feature I quite like and think will only grow more useful over time: on-device AI. Apple has shipped Apple Intelligence since macOS 26, and I've always seen this as an opportunity for everyone, so I integrated this on-device model into Look. The model's performance is low for now, but with a company like Apple it's bound to improve. This is a one-time investment that keeps paying interest over time.

Of course, the model isn't strong yet, so I tuned it carefully so it wouldn't hurt the user experience at all, and I also prepared interfaces so I can plug in other AI models down the line.

A lot of people don't like AI, are afraid of it. But to me, AI is nothing special. If it serves a purpose and brings some benefit, I'll use it, no question.

Everything Connects

For the products we've built, on the documentation pages or the website I always integrate a demo section, so users can interact on the web without downloading my app. It isn't the full 100%, but it's around 80% of the real experience. This matters a lot: it keeps the description from being boring, and your demo carries more credibility because it re-enacts the real app rather than meaningless lines of text or a PowerPoint file. Why can they connect like this? As I said above, I use Vanilla JS (plain HTML, CSS, JS), so I can reuse quite a lot of it to build the web demo. Live demo here I just copy it over, tell the AI what needs to change so my demo stays simple and hits its purpose, then confirm and fine-tune if needed, and it's done.

On that note, I also wouldn't advise anyone doing technical work to build apps with drag-and-drop low/no-code tools. I know they look convenient, but don't count on it: your product ends up full of generated garbage, sluggish performance, and reusability, extensibility, and folding AI into your development and testing become far more complicated while delivering worse results. Not to mention that no/low-code technologies have a higher chance of being abandoned or left unmaintained in the future compared to a reputable programming language. Relying on something good is fine; relying on something bad is, to me, a stupid decision.

End

These are just some notes I wanted to share, off the cuff. Once more: as a technologist, I care about business, but I never want to disregard the technology either. If someone tells me technology doesn't matter and anything goes, I'll probably struggle to work with them. If someone tells me to build software with drag-and-drop tools, I'll feel a little sad. I care about everything that produces productivity and quality, right down to the PC, the operating system, and every single tool a project uses.