I started in 2001, we're in 2025, I'll let you do the math. Or not, it's not necessary...

Anyway, I've been working and building applications for a while now.

I've worked with a multitude of technologies

C, C++, Visual Basic, Php, TclTk, Java, Kotlin, Angular, Backbone, Knockout, Jquery of course, Oracle, Mysql, PGsql, Sybase, SQL server

It gives me a headache just thinking about it all.

Among the applications I've created, I could mention Malt, even if the stack I used in 2012 is a far cry from my favorite stacks today.

More recently I could tell you about rssfeedpulse, a SAAS I built last year, Bloggrify, a static blog generator in the Nuxt ecosystem, or Blogtally, the latest application I released early this year.

And inevitably, I ended up creating my tier list of the most solid technologies for building applications.

The one I now systematically reuse when I create new products.

If this list could ever save you time, I'd be delighted. And that's what I'd like to talk about today.

The RADAR tech

I'm not going to use a tier list, but a Tech radar.

This tech radar is already available on my blog and will be updated regularly.

On this tech radar, we're going to talk about technologies, sorting them into 4 main sections:

• backend
• frontend
• infrastructure, i.e. databases, cloud, etc.
• and a catch-all section, tools

You'll notice 3 circles on this radar. Because even in the technologies I use, I don't put them all on the same level:

• LOVE: the technologies I couldn't live without.
• OKish: the technologies I use are good, but they're missing a little something. Or sometimes, I just don't use them enough to be in the LOVE category.
• Meh: that's the category where, frankly, if I could find a replacement, I'd try it out without too much remorse.

Obviously, a few clarifications: this tech radar is not intended to list and classify all the technologies in the world.

If it's not here, it's because I don't use it. That doesn't mean it's useless.
If it's there, it doesn't mean it's the best technology in the world, just that it satisfies me in MY context.

My context is that of a web developer, now on his own to build products with budget constraints.

Frontend

On the frontend, I've been in love with Vue and NuxtJs for several years now.

I've seen many frameworks come and go over the years, but today it's clearly Vue.js that I'm most productive with. For me, it's the most accessible framework for backend devs. Its ecosystem is quite solid, and in this ecosystem, I have to mention Nuxt.

Nuxt is for SSR, server side rendering.

And if ever this acronym sounds barbaric, remember that the big problem with applications built in Javascript for years was that they produced sites that were absolutely not optimized for SEO because everything was done on the client side, which is a disaster for the bots of the main search engines, Google, bing etc..

With SSR, all content is generated on the server side, sent to the client, and then navigated in the browser, as with a classic front-end application.

Nuxt is THE de facto solution with Vue.js, the equivalent of Next.js in the React ecosystem.

But Nuxt isn't just a bit of tooling around Vuejs for SSR, it's much more than that: state management, transition management, intelligent routing, simplified SEO management, prefetch, systems for optimizing data retrieval and tons of very practical modules for optimizing image loading, creating sitemaps, robots.txt and so on, the list goes on.

For all these reasons, it's definitely in LOVE.

Still in LOVE, I'd definitely put Tailwind, an excellent framework for simplifying CSS writing in applications.

But tailwind is not a component library. It's just another, simplified way of writing CSS. But its greatest strength is its adoption by many component libraries.

Because, if we're talking about design, I'm far from being an excellent interface developer.

If you let me do the UI, it'll be... functional. Which is a polite way of saying that it's ugly.

So, I need ready-made component libraries that look professional.

And before, I had to install big, fat libraries like Bootstrap to use only 5% of them, now I can pick just the markup I'm interested in from a component library, without taking everything else.

The libraries I use the most are preline, flowbite and pagedone, and it's thanks to them that I can manage to make interfaces that aren't as awful as what I've been able to do in the past.

Unfortunately, the secret of a good UI isn't just the assembly of components. There are notions of color, spacing and, of course, usability. And to acquire some of the right reflexes, you need to constantly seek inspiration and look at how other sites are built.

And there's a site that does just that: it's Dribble.

But I'm not going to dwell on the subject too much, it's not impossible that I'll talk about all this again in a dedicated article.

In Okissh, on the other hand, I use almost no component frameworks, like boostraph and the like, but for certain cases, I've added Daisy UI so as not to recode all the modal logic or dropdowns.

It's not bad, but I don't think I'm used to the framework enough to put it in the LOVE category, and it doesn't deserve to be there for two components.

Finally, the last brick in this front-end category, I add echarts.

I've tested tons of libs for creating graphics in applications. There's always something missing, there are always limitations.

But with echarts, I've found a pretty cool lib, very complete, very customizable.

On the other hand, it comes with a certain complexity and it's a real pain to know how to use it properly.

So, it's not in LOVE, because it's complex and that sometimes makes it frustrating.

Very...

Backend

Moving on to the backend, I'm going to take a quick look at my main technology, Spring boot, used with the Kotlin language.

I'm not going to spend too much time on these two technologies, as they're fairly obvious in the Java world. Spring boot for web frameworks is the benchmark.

Kotlin is a little more debatable. It's a slightly more modern version of Java, slightly less verbose, even if Java is gradually catching up.

Then, the first techno I love is Sentry. I only use the free version and it's already very good.

To put it simply, when you use Sentry, you install a small library in your backend and then every error reported in production creates a Sentry "task".

I don't know if I've sold the potential correctly, but I think it's essential. On the one hand, it forces us to correctly report the right errors, with the right level of information, otherwise Sentry won't be usable.

On the other hand, it gives me a super power: I know immediately when I have errors, I can correct them immediately and I can proactively contact users to tell them that "yes, I know, you had this problem, and I've corrected the cause*".
The wow effect is guaranteed.

Note that it also works to a certain extent for detecting performance problems, by analyzing differences in response times from one period to the next.

So Sentry is in the LOVE category, no worries.

Another tool in the LOVE category is openapi.

Openapi is a specification for describing APIs.

The big advantage of Openapi is that there are a whole host of utilities for generating clients for the APIs in question.

This is a huge time-saver, especially for my backend APIs that I expose for my Nuxt frontend.
Unfortunately, however, the Nuxt APIs don't yet expose Openapi contracts. It's a pity, but I hope it will come.

A nod to the Nuxt team if you're reading this :)

To continue on the backend side, I'm going to talk about Stripe.

Stripe, I don't think it's necessary to introduce it, it's the reference today in terms of payment applications.

It's what handles the whole subscription side of Blogtally.

The developer experience is pretty good, even if it's sometimes a bit tricky to figure out how to do this or that.

The customization possibilities are really quite extensive. You can set up one-off payments, subscriptions and trial periods. The whole payment and upgrade funnel can be delegated to Stripe, so you don't have to code anything yourself. There are workflow automation possibilities, for example to send discount coupons to a user who interrupts their subscription to try and catch them up.

It's really good.

So why do I only put it in Okish?

Because I'm missing two things:

• native integration with an affiliate solution (referral)
• being a Merchant of Record

The second point in particular makes me sweat, since Stripe's international invoices don't take VAT rules into account, which will inevitably cause problems.

The alternative solution for this is LemonSqueezy or Paddle, both of which are Merchant of Record.
However, I haven't made the transition yet. LS has been bought out by Stripe and I must admit I'd like to see it end up in Stripe eventually.

I don't really believe in it, because it's a big change, but I'm tired of making the transition before I've even started...

Now if you're just starting out, it's worth giving it a bit of thought anyway.

Infrastructure

For infrastructure, we're going to talk about three technologies.

Postgresql first.

This isn't really a surprise; I don't think any sane solo dev starts with Oracle, Sybase or SQL Server, but well, you never know.

Eventually, you might wonder why not mongo, since it's a database that continues to enjoy success in the SAAS world.

I was really into Nosql databases in 2012 and mongo has been Malt's main database for years.

But, today, there's no question of me going back to that.

Mongo remains a poorly finished product, which sells its flaws as features.

In short, I now systematically use Posgresql. Over and above the classic database functionalities, its native support for geometric types, JSON, good Window function support, and so on, all make this database a must-have in my context.

The second fundamental building block in my stack is Coolify.

Coolify is a PAAS, i.e. an open source development platform that you can host yourself.

Rationally speaking, you could say that if I use Coolify a lot, it's for budget reasons. Coolify allows me to be financially competitive with all the PAAS on the market.

That's not entirely untrue, but in reality, even in terms of functionality, Coolify is way ahead of many PAASs.

For example, Coolify offers the notion of a private network, meaning that only what is public is exposed on the Internet. And that's something that many well-known PAASs still don't understand.

In short, its place in LOVE is not "just" linked to a budgetary reason. The product is good, better than many older commercial PAASs.

Finally, I'd like to mention Metabase, my product dataviz solution for understanding my product data. But I confess that I don't use it very much yet, which explains its place in Okish. The product is good, it's just that I don't use it enough to consider it indispensable.

Tools

Tools is a bit of a catch-all category, but I could easily divide it into two sub-categories:

• the AI stack
• the marketing and content stack

Concerning the AI stack, I use Github Copilot in my IDE.

However, I use it mainly for its auto-complete, and I'm still a little frustrated by the quality of the refactoring offered, which has earned it a place in Meh.

I need it, but I won't worry about changing.

Outside the IDE, I use Claude daily, which is much better than chatGPT for code. Unfortunately, Claude doesn't have the context of my code base so I constantly have to copy-paste to Claude and then to my IDE, which is very inconvenient.

I'm looking forward to testing solutions in the IDE, such as Cursor or Windsurf.

I'm not going to go into too much detail here, I'll probably do an episode dedicated to the AI stack.

But I'd also like to mention perplexity AI, which for me represents the future of search engines. Quite simply, it's an AI whose role is to search for me and consolidate the results. This eliminates many of the risks associated with hallucinations.

Finally, I use Notebook LM from time to time, to collect and consolidate notes. I use it mainly to make videos, especially when I'm dealing with a historical figure, as I did with Licklider.

Finally, I'll conclude with the marketing stack.

I do SAAS, and it's crucial to have documentation that holds up and a blog that's particularly useful for SEO and content strategy.

For this, I have several tools that I use systematically.

Docus for docs, which allows me to write everything in Markdown. The tool isn't necessarily very customizable, but it gets the job done.

I use Bloggrify for the blog, not surprisingly since I'm the one who developed it. I spent a lot of time optimizing it for SEO and once again, the fact that I can easily write in Markdown makes it very easy to use.

Finally, I use Blogtally, my own SAAS, for web analytics and blog newsletters.

There's nothing like being your own customer to constantly improve your product.

In this stack, I'm still missing a marketing automation tool. It may become Mautic. Mautic installs easily on Coolify and offers, a priori, what I need. However, it's still a bit early to say which category I'll put it in.

And that's all.

For my part, it's the stack that's making me productive today. I'll keep this tech radar updated on my blog if it helps.

It was obviously complicated to go so quickly on each technology, so of course don't hesitate to ask questions in comments. It'll be a good place to dig into particular points.

And now, you can get back to business as usual.

Bye