Filip Bolčić

“Do you have experience working with CSS-in-JSS libraries?”

 asked the interviewer, my soon-to-be team lead.

I was applying for a position at my current company, Ars Futura. They were looking for a developer to bolster the frontend team working on

The team operated within a strict design system and wanted someone who could be easily brought up to speed. Having little experience, I was lost for words. Luckily, the interviewers didn’t take it to heart and the meeting ended on a positive note - I got the job.

The reason behind the question becomes obvious once you accumulate some experience; how we handle styling on the frontend is important. Building a production-ready app requires an abundance of styling directives that, when declared with CSS files in a traditional fashion, become notoriously difficult to manage.

The community conceived many solutions to this problem, and one of the more popular ideas that took hold was CSS-in-JS. Take a look at 

which explains the key points succinctly.

We too have used CSS-in-JS successfully. In Ars Futura, the library most commonly employed on new projects is 

the weapon of choice I finally encountered when starting work on PontaHR.

For the first three years, we used Theme UI for each and every styling concern we had. We carved out our design system with a low-level component library, implemented color modes, and used it for all the other myriad concerns that a fashionable, production app has to handle daily. And for the most part, it worked beautifully.

But then, suddenly, three years into the project, we decided to replace it with another framework. Given our working implementation, and being a small team with a product that was yet to hit liftoff, this may seem unnecessary. So why did we do it?

This post will explain our journey of code refactoring a CSS framework in a production application. Committing to a refactoring decision at this scale is hard; there are always other priorities and it can be difficult to get the whole team on board. But, if the reasoning behind the decision is good, the application will profit in the long run. Our aim is to display our thought process in order to help other developers and decision-makers facing similar conundrums. 

But before we do, let’s talk a bit about the platform we were, and still are, building.

What is PontaHR and why are we building it?

n 2022, our company experienced a growth spurt, almost doubling its employee count within a year. We needed more governance, and even though content with our home-grown HR administration solution, we quickly outgrew it. 

Most of the software on the market had an overbearing amount of features,  better suited for an enterprise than an agile, fast-growing company. We wanted simplicity and a software that feels efficient, taking care of only the essentials - but taking care of them well.

In the end, we decided to build one ourselves – and PontaHR was born. It is a comprehensive human resource management solution geared towards small-to-medium companies. We aim to give fast-growing businesses a tool to manage their employees, enhance and grow their culture, and have fun while doing so. If you are interested,

When we started working on the application, we decided on Theme UI because the team was familiar with it. Unfortunately, CSS-in-JS libraries rely on a couple of tricks that come with inescapable performance overhead. This can be seen once we examine how these libraries work under the hood.

CSS-in-JS libraries enable us to write styling logic alongside our component logic. For example, this is how we can style a

When we run the application, the styling rules are generated in the document CSS source and applied to the proper elements. To someone encountering this for the first time, the results can feel like magic. How is the logic from our source code transformed to appropriate CSS? How does the application know where to apply them?

The reason is simple: CSS-in-JS libraries are heavily dependent on JavaScript.

This is a rough sketch of the steps the libraries have to take to generate the CSS (thorough explanation can be found on

The problem is that CSS-in-JS libraries like Theme UI do the work during 

This invariably hurts the performance of our application: it chucks extra work at the browser when there are thousands of other things happening. This is a widely recognized downside; there is

a great investigation of CSS-in-JS pros and cons by one of Emotion’s most active maintainers

As we rolled out features and our vision shaped, this situation kept nagging us. What will happen when PontaHR grows and there are additional UI components, each coming with its own heap of styling logic? Are we leaving a performance margin wide enough for lower-end devices? Finally, are we sacrificing the user for the developer experience?

Fortunately, there are other solutions that combat the same CSS issues while doing the compilation work outside of the runtime.

The trick is to move the processing work to 

This is a rough sketch of how buildtime libraries work:

The important thing is that none of the work is done during application runtime. We get the same benefits of CSS-in-JS but with no runtime overhead. DX checked 

Switching our styling framework from runtime to buildtime meant we could have the best of both worlds. With the appropriate library, we could keep our design system and development flow while ensuring a better experience for our users.

But, to do so, we would have to reconstruct the very foundations of our app. It would probably involve touching each and every file in our source code. 

Such an application-wide refactor is no small matter. Development teams are prone to shirking from them since they involve a cumbersome grind which takes time that could have otherwise been spent doing something more interesting.

Product owners and managers often cringe at the mention of refactors - especially if they don’t come from a technical background, and even more so if the issue is not immediately obvious and measurable. Their mindset is always geared towards providing immediate value to users.

In other words, the relevance of such a refactor should be evaluated carefully and honestly. But if it’s right, it's right, and the whole team should stand behind it.

It’s common to procrastinate on refactor decisions, especially if they’re not mission-critical. There is also the refactor impact; small ones should be encouraged and done often, like dusting, to keep surfaces shiny. Big ones are scary and laborious - there should be a good reason to venture into them and it would require a coordinated team effort.

But, we should always keep aligning ourselves with the product’s mission and vision, which for us means delivering the best user experience. We realized there was room for improvement, and it became clear – we should do better.

There was another favorable circumstance that helped move the needle on this issue: the application was still in its relative infancy.

For an application-wide refactor such as this one, time is of the essence – every additional page, feature, or component will incur technical debt. If we know such a refactor is waiting for us around the corner, now is the best time to do it.

These insights, scope, relevancy, and time, are great compass points when evaluating refactor decisions. For us, even though we were vary of its scope, the importance and immediacy of this project convinced us that we should go for it. It just felt right.

We wanted to switch to a buildtime CSS framework. But which library to choose?

There are multiple approaches available, each with its merits and weaknesses. With so many options to choose from, it can be hard to decide, especially since it is related to such a fundamental application concern. Welcome choice overload 

Our approach was to focus on the big stuff and let the small issues slide. A different styling framework will invariably work differently, forcing the development team to adjust its routines. The key point to consider is whether the tradeoffs are good for the app. 

These were the main concerns we wanted to solve:

In the world of software development, the technological landscape shifts rapidly. But, even though what is hottest changes often, fundamental tech, like HTML and CSS, doesn’t. So, betting on something closely related to these principals can add sturdiness to your stack.

Style co-location but used like regular CSS. A buildtime library with no overhead, and great maintenance. From these puzzle pieces an image emerged - we wanted to work with 

Tailwind is a utility-first CSS library, which means it is based on small, laser-focused classes that handle very specific styling concerns. A preprocessor analyses the source code and produces a static CSS file with only those rules used in the project.

Even though Tailwind is one of the most widely used CSS frameworks today, it is not without its opponents. Its biggest asset is also its key issue – utility classes are laborious to write and can turn your code into an ineligible string soup.

Will using this technology require different ways of writing code? Sure. Is it uglier than our previous solution? Maybe.

The most important question is how big of a concern is liking this way of writing for the architecture of our application.

The big things - maintainability, features, performance - will keep the application running smoothly and should be key points of concern when evaluating a tech decision. Small things shouldn’t discourage it.

This doesn’t mean that the developer's voice is unimportant - these types of refactors require a coordinated effort and everyone should be on the same team. The approval required to drive such a change should not be strong-armed but earned by providing relevant information and discussing it as a team.

Up to this point, the research was done mostly by one person. The development team knew a refactor could be in the works but the details were not yet shared. We assembled a meeting where we discussed a potential refactor from Theme UI to Tailwind. We analysed its pros and cons and evaluated the differences opposed to our current solution. Once the necessary data was laid out, it was easy to get everyone on board. The team was ready to hit the ground running.

Getting stakeholder approval is another enchilada. Product owners are not interested in technical details; value and time are their main currency. And when a refactor that would upend the whole app is proposed, your arguments better be good.

More concretely, these are the questions you need good answers to: what value to our users is provided with this change? And how much time would it take?

Our research showed better app performance but it was purely theoretical. It was time to transform this knowledge into something more tangible. We decided to construct a proof of concept by overhauling one of our simpler features - the login page.

This page looks deceptively simple. The truth is, in modern UIs, you’ll find a boatload of styles lurking underneath every component: hover and other states, responsiveness, and animations are some of the concerns that need to be handled in addition to base layout and styling.

Using one of the simplest pages made it possible to have a concept quickly, allowing us to examine both the development effort required to refactor at scale and the theoretical performance benefits.

I will not go into specifics here – suffice to say that our measurements showed performance improvements across the board.

We discussed the refactor again, this time presenting data to the whole project team: product owners, designers, marketing, sales, and development. The response was great and we got the green light.

An application’s styling framework is the architectural bedrock on which every component, page, and feature is constructed. Changing it means pulling the bones out of your codebase and regrowing them as fast as you can as if using 

. Unfortunately, we couldn’t invest in a pure refactor sprint.

As I’ve stated before, the application was relatively young (it still is), and a lot of our energy was spent attracting clients and figuring out all the future directions in which PontaHR could evolve.

Providing maximum value to users is always a principal concern, but in this atmosphere, it's even more so. Being a small frontend team of three, we didn’t have the resources to lunge for it. This meant that the development had to occupy little pockets of spare time that were left after the main work was done.

We were in it for the long haul, and this knowledge shaped our refactor strategy.

Our application is built on a robust design system that includes primitives (such as colour, spacing, breakpoints) and atomic components (boxes, buttons, text) that combine to build complex UIs. Everything else is constructed on this foundation - every page is a collection of components and primitives arranged in layouts.

Our plan was to focus on the design system first. Since the existing code had a high level of reuse, refactoring it meant we would simultaneously strike at the concrete pages and features.

Working on such core features also meant we needed to be extra careful. Messing up a keystone component, like a simple button, would produce bugs throughout the app. So, our first few weeks were spent refactoring our design system and testing the changes meticulously.

Then we moved to concrete pages. Our plan was to start from simpler cases (like the login page) and move successively towards more complex ones (like the careers page, where users can collaborate and manage their listings).

The consequence of this strategy, where we updated piece by piece in spare hours, meant that our application supported two libraries and twin design system implementations. This bloat in our codebase didn’t worry us - it was a temporary, but necessary, tradeoff.

The real issue were the features that required the design system couple to live together peacefully, for example, dark mode. Since any page could consist of library A and library B components, both of them had to react accordingly to theme changes. But, because each library’s approach differed, we had to marry their implementations so the users would not experience any discrepancy.

We could go further into the specifics of how, but it is not really important. Every application, its implementation, and its use case is unique. When faced with the same problems, the steps your team will have to take will undoubtedly differ from the ones we had to.

The thing of note is to devise a plan early and stick to it. Huddle your team together and brainstorm the best approach. Assign roles, figure out priorities, and tackle this thing head-on.

A good strategy takes a refactor of this scale from scary and undetermined to something manageable.

And so, little by little, we managed to jettison the redundant library from our codebase. At our pace, it took approximately half a year (

That's a lot of time but it was well spent. A palpable feeling of satisfaction lingered when we watched the final bits of the existing code dissolve after the cleanup; akin to overhauling an aged motor on a cherished car with our own two hands.

We knew the driver was now in for a smooth ride.

How to organize and get approval for production-scale code refactoring.

A Smooth Ride: Replacing PontaHR’s Styling Framework

Ars Futura logo

Ars Futura

Creating Custom Map Markers for Android Development

Many Android mobile apps leverage the Google Maps API, which offers plenty of features that can be customized to meet specific needs. From adjusting map styles and colors to tailoring roads and labels, developers have extensive control over the visual elements. While these default customization options are often sufficient, there are scenarios where the out-of-the-box features fall short.

So, when dealing with mobile app map markers, we can use the default location markers provided by Google and tailor their attributes, such as color, opacity, and associated data. Alternatively, we can substitute the default marker image with a personalized one using the BitmapDescriptorFactory class. In this blog, we’ll explore how that could be achieved, and if you’d like to know how to do it yourself, keep on reading!

Let's begin by presenting a scenario where you’d need such customization.

Imagine we're developing a delivery app that involves various markers based on specific data for each location. 

The four distinct markers we'll need are:

 Marks the depot, serving as both the initial and final stop.

 Indicates a location the driver must visit, featuring a sequence number in the center to denote the delivery order. Its color varies based on the delivery status: green for on-time, yellow for potential delay, and red if the delivery is at risk of being late.

 Similar to the unfinished task, but with a checkmark replacing the sequence number.

 Marks a location where the driver can restock its inventory.

In this post, we'll explore how to implement such a customization to enhance the functionality of our delivery app.

We'll start by implementing Google Maps into our project. To achieve this we'll need to log in to Google Developer Console, create a new project, and generate an API key.

We'll add the Google Maps dependency into our module (app-level) 

 file along with Kotlin extensions for the Google Maps SDK.

implementation("com.google.maps.android:maps-ktx:5.0.0")

implementation("com.google.android.gms:play-services-maps:18.2.0") 

 layout will have a Google Maps fragment. Since data binding will be used throughout this project, everything will be wrapped up inside the 

<?xml version="1.0" encoding="utf-8"?>


<layout xmlns:android="http://schemas.android.com/apk/res/android"

   xmlns:tools="http://schemas.android.com/tools">



   <androidx.fragment.app.FragmentContainerView

       android:id="@+id/mapFragment"

       android:name="com.google.android.gms.maps.SupportMapFragment"

       android:layout_width="match_parent"

       android:layout_height="match_parent"

       tools:context=".MapsActivity" />


</layout>

Assuming all the configurations are accurate, launching the app at this point will display the map.

The next step is to create a map marker object. This will contain all the information we need to create our map markers.

data class MapMarkerObject(
	val sequenceId: Int,
	val completed: Boolean = false,
	val depot: Boolean = false,
	private val delay: Delay = Delay.ON_TIME,
	val category: Category = Category.MAP_MARKER,
	val locationName: String = "",
	val coordinates: LatLng
) {

	val outerRing: Int
    	get() = if (shouldShowIcon()) color else R.color.white

	val innerRing: Int
    	get() = if (shouldShowIcon()) R.color.white else color

	val drawable: Int
    	get() = if (depot) R.drawable.ic_depot else when (category) {
        	Category.RESTOCK -> R.drawable.ic_refresh
        	else -> R.drawable.ic_check
    	}

	fun shouldShowIcon() = completed || depot || category == Category.RESTOCK

	val color: Int
    	get() = if (depot) R.color.depot else when (delay) {
        	Delay.DELAY_AT_RISK -> R.color.at_risk
        	Delay.DELAY_LATE -> R.color.delayed
        	else -> R.color.on_time
    	}
}

enum class Category {
	MAP_MARKER, PARKING, RESTOCK
}

enum class Delay {
	ON_TIME, DELAY_AT_RISK, DELAY_LATE

The project will include the following color palette:

<color name="black">#FF000000</color>

<color name="white">#FFFFFFFF</color>



<color name="on_time">#52BFAB</color>

<color name="at_risk">#FFC775</color>

<color name="delayed">#F35627</color>


<color name="depot">#83A3A3A3</color> 

We're almost ready to start adding our map markers! But before that, we'll need to create an XML layout for these markers.

Now that we're all set up, we can start adding our markers.

Since we have added the KTX library to our project, we're gonna take advantage of several Kotlin features.

, we can simply copy and paste the code snippet provided in the 

lifecycleScope.launch {

   lifecycle.repeatOnLifecycle(Lifecycle.State.CREATED) {

       val mapFragment: SupportMapFragment? =

           supportFragmentManager.findFragmentById(R.id.map) as? SupportMapFragment

       val googleMap: GoogleMap? = mapFragment?.awaitMap()

   }

}

Next, we're gonna create some dummy data for our markers:

private fun getMapMarkers(): List<MapMarkerObject> {

   val marker1 = MapMarkerObject(

       1,

       locationName = "Arena Centar", coordinates = LatLng(45.77, 15.93)

   )

   val marker2 = MapMarkerObject(

       2, completed = true,

       category = Category.RESTOCK,

       locationName = "Avenue Mall", coordinates = LatLng(45.77, 15.97)

   )

   val marker3 = MapMarkerObject(

       0, depot = true,

       locationName = "Ars Futura", coordinates = LatLng(45.79, 15.95)

   )

   val marker4 = MapMarkerObject(

       3,

       delay = Delay.DELAY_AT_RISK,

       locationName = "Supernova Garden Mall", coordinates = LatLng(45.83, 16.04)

   )

   val marker5 = MapMarkerObject(

       4,

       delay = Delay.DELAY_LATE,

       locationName = "City Center one West", coordinates = LatLng(45.79, 15.88)

   )

   val marker6 = MapMarkerObject(

       5, completed = true,

       locationName = "City Center one East", coordinates = LatLng(45.80, 16.05)

   )

   val marker7 = MapMarkerObject(

       6, completed = true,

       delay = Delay.DELAY_LATE,

       locationName = "Westgate Shopping City", coordinates = LatLng(45.87, 15.82)

   )

   return listOf(marker1, marker2, marker3, marker4, marker5, marker6, marker7)

}

Adding a custom map marker can be done using the 

lifecycleScope.launch {

   lifecycle.repeatOnLifecycle(Lifecycle.State.CREATED) {

       val mapFragment: SupportMapFragment? =

       supportFragmentManager.findFragmentById(R.id.mapFragment) as? SupportMapFragment

       googleMap = mapFragment?.awaitMap()



       for (mapMarker in getMapMarkers()) {

           googleMap?.addMarker {

               position(mapMarker.coordinates)

               title(mapMarker.locationName)

           }

       }

   }

}

By launching the app now, we can see markers on our map. There are two problems we need to fix next - we're using the default marker icon and those markers are not centered.

Let's start by adding two new methods. The first one will convert the device-independent pixels to pixels, and the second one will be used to convert our XML layout into a bitmap image.

fun dpToPx(dp: Int): Int {

   return (dp * Resources.getSystem().displayMetrics.density).toInt()

}




private fun getMarkerBitmapFromView(marker: MapMarkerObject): Bitmap {

   val markerBinding: MapMarkerBinding = DataBindingUtil.inflate(

       layoutInflater

       R.layout.map_marker,

       binding.mapFragment,

       false

   )

   markerBinding.mapMarker = marker

   markerBinding.lifecycleOwner = this

 markerBinding.customMarkerView.measure(View.MeasureSpec.UNSPECIFIED, View.MeasureSpec.UNSPECIFIED)

   markerBinding.customMarkerView.layout(0, 0, dpToPx(MAP_MARKER_SIZE), dpToPx(MAP_MARKER_SIZE))

   markerBinding.linearLayout.layout(

       dpToPx(MAP_MARKER_STROKE), dpToPx(MAP_MARKER_STROKE),

       dpToPx(MAP_MARKER_SIZE - MAP_MARKER_STROKE),

       dpToPx(MAP_MARKER_SIZE - MAP_MARKER_STROKE)

   )



   val returnedBitmap = Bitmap.createBitmap(

       dpToPx(MAP_MARKER_SIZE), dpToPx(MAP_MARKER_SIZE),

       Bitmap.Config.ARGB_8888

   )

   val canvas = Canvas(returnedBitmap)

   canvas.drawColor(Color.WHITE, PorterDuff.Mode.SRC_IN)


   val drawable: Drawable = markerBinding.customMarkerView.background

   drawable.draw(canvas)

   markerBinding.customMarkerView.draw(canvas)

   returnedBitmap.compress(Bitmap.CompressFormat.PNG, 100, ByteArrayOutputStream())

   return returnedBitmap

}

The parameters to the layout are relative to the parent view’s upper left corner. X increases as we move to the right and Y increases as we move down. After we set up our layouts, we need to create a bitmap using the desired height/width. Next, we create a canvas that provides the means to draw on a bitmap, we draw on that canvas, and compress the bitmap into PNG to reduce its size.

We’re all set! Now we can start creating our custom markers. We’ll extract the addMarker method and add an icon using our 

private fun addAssignmentMarker(mapMarkerObject: MapMarkerObject) {
	googleMap?.addMarker {
    	position(mapMarkerObject.coordinates)
        	icon(BitmapDescriptorFactory.fromBitmap(getMarkerBitmapFromView(mapMarkerObject)))
    	title(mapMarkerObject.locationName)
	}
}


The only problem we have right now is that our marker icons are not centered and we’re zoomed out way too far. We’ll fix that by adding bounds and re-centering the camera.

lifecycleScope.launch {
	lifecycle.repeatOnLifecycle(Lifecycle.State.CREATED) {
    	val mapFragment: SupportMapFragment? =
        supportFragmentManager.findFragmentById(R.id.mapFragment) as? SupportMapFragment
    	googleMap = mapFragment?.awaitMap()

    	val builder = LatLngBounds.Builder()

    	for (mapMarker in getMapMarkers()) {
        	builder.include(mapMarker.coordinates)
        	addAssignmentMarker(mapMarker)
    	}
    	val bounds = builder.build()
    	val cameraUpdate = CameraUpdateFactory.newLatLngBounds(bounds, 80)

    	googleMap?.moveCamera(cameraUpdate)
	}
}


Centering the camera is done in three steps. First, we need to create a 

 builder and add all of the marker coordinates into it. Then, we create a 

object containing those bounds and some padding. Lastly, move the camera using the moveCamera method and the 

If all of the steps are completed, your map should have seven custom map markers. Clicking on a custom marker will recenter the map to that marker and display a default info window containing the location name.

Google Maps offers a versatile toolkit for users to enhance their navigation, exploration, and communication. Throughout this blog, we’ve covered information on how to set up Google Maps and add default and custom Google Maps markers. Whether it’s for business, events, or personal use, understanding how to customize map markers enables us to create more intuitive and efficient mapping experiences.

A simple guide to creating custom markers for the Google Maps API

Creating Custom Markers for Google Maps – for Android Development

Roza Zanini Mozara

Financial Times 10000 Ars Futura 2024

 has listed Ars Futura as one of the fastest-growing companies in Europe, earning us the spot on the 

The FT1000 list is an annual ranking of the fastest-growing European companies, organized and compiled by the Financial Times and Statista. The selected organizations are based on their revenue growth rate over a three-year period, so in this case, from the beginning of 2019 to the end of 2021. The growth must be primarily organic, meaning it’s acquired internally, not achieved through acquisitions or outside investment. 

(revenue2022/revenue2019) - 1 = Growth rate.

In this, 8th, annual ranking of Europe’s fastest-growing businesses, we’ve ranked as 

 in the overall ranking (placing us 49 spots higher than in 2022), an awesome place among some really amazing fast-growth companies! Our absolute growth rate from the beginning of 2019 to the end of 2021 was 

, more than doubling in size. A nice and steady growth rate! 

“It's great to be recognized by the Financial Times, especially for the second time. It's a testament not just to our growth in numbers and revenue, but also to the quality of the work we put out there and the partnerships we build. This award belongs to all of us at Ars Futura. Here's to pushing boundaries, together.” 

We’ve come a long way in these 11 years, but none of it would have happened without our amazing team. Without their talent, ambition, hard work, and dedication, we wouldn’t be where we are today. 

Pop the confetti! 🎊

Ars Futura Listed in Financial Times Among Europe’s 1000 Fastest-Growing Companies

Sanja Karan

Mental Health and Employee Wellbeing at Ars Futura

A little over a year ago, we introduced free and unlimited psychotherapy as one of the benefits for all Ars Futura employees. Being a part of Ars Futura’s HR team, I must admit, it's been one of my favorite initiatives in the last three years since I joined the company. To mark the anniversary, I've decided to put pen to paper and detail the journey – from idea to implementation, as well as the benefit reception among our team.

Let's begin with the starter kit, the prerequisites when introducing psychotherapy as a benefit in any company:

There isn’t an HR person out there who hasn't had a conversation with a colleague where private information or problems were shared. And as an HR person, you can only really listen. There's always a lingering sense of bitterness after such conversations and a desire to help your colleague in some other way, aside from just listening. That feeling is essential for a 'people first' mindset, as I mentioned. Introducing psychotherapy as a benefit requires, above all, genuine care for the well-being of employees in your company.

That's kind of where it all started for us. With discussions about wanting to support our colleagues who are struggling or going through tough times and wanting to talk to someone about it. 

This brings us to another point in the starter kit – "Management that gives a damn".

No benefit that the HR department in any company comes up with and wants to push forward will succeed if we're not on the same page with the management about the kind of environment we want to build for our employees. 

Once we got the green light from our management, we started researching therapists and meeting with them for a vibe check. Ultimately, we selected three who met our criteria. 

We assembled the list of psychotherapists we spoke with based on recommendations. Every member of our Human Resources team knows someone who has been trained in practicing a particular psychotherapeutic approach, so we had sources we trusted.

A mix of objective and subjective criteria guided our final selection. 

 included the desire to have therapists practicing different therapeutic approaches (cognitive behavioral therapy (CBT) and gestalt) and a combination of female and male therapists available. 

 relate to how well we know the people at Ars Futura (and since we're still a pretty small company, we know them quite well), and based on that, we assessed which of the psychotherapists we talked with would be most liked and trusted by them. 

Honestly, we were a little worried about the number of people that would 

 use this benefit. The contract between Ars Futura and the therapists is regulated so that the therapists send an invoice with the number of clients they've seen and sessions they've conducted at the end of the month. Without specifying gender or names, of course. For us, anonymity needed to be guaranteed. Despite this, there was a fear that the benefit might be underused due to the lingering stigma surrounding therapy. Especially as some individuals may worry about the disclosure of their use of therapy services.

Fortunately, those fears didn't come true, and this is where the third point in the starter kit, "Established psychological safety," came to our rescue. 

To deepen our employees' understanding of psychotherapy and motivate those who were still hesitant about therapy, we took a few additional steps. 

We organized a meeting for the entire company, during which each of our three selected therapists introduced themselves and talked a bit more about the psychotherapeutic approach they practice. The aim was to make our team associate names with faces, making it easier for them to reach out and schedule therapy sessions. Additionally, we added a document to our internal handbook where we elaborately explained Cognitive Behavioral Therapy and Gestalt therapy, highlighting how they approach a problem in different ways. Through all these steps, we emphasized the anonymity of therapy and how individual therapy would be a safe space for anyone who chooses it.

When we introduced the psychotherapy benefit a year ago, we had 56 employees (now we're at an even 60). The total number of attendees who went to at least one therapy session with a therapist (although most have attended multiple sessions) is 20. 

About 30% of the company has tried psychotherapy, and we think that's a really good indicator of the benefit's success.

 It’s the first (and probably only) time we can say people are just numbers, as all the personal information is 100% anonymous.

Another thing to note when it comes to numbers is that we’ve implemented this benefit with an 

unlimited number of therapy sessions – Ars Futura covers all expenses

We generally pay attention to how many surveys we send and how often we send them to Ars Futura employees, to inquire about different matters. We don’t want to be overly repetitive, although we genuinely want to know what people have to say about various topics. Because of that, we conducted satisfaction surveys on the psychotherapy benefit only at two points since its introduction (every six months).

The average satisfaction rating with the therapists and the effectiveness of the therapy is 4.42 (out of five), and the comments are really positive.

All in all, we’re really happy with how this whole process turned out. It’s a win-win situation – some of our colleagues have a higher quality of life because of this benefit and we have happier employees. We hope it will also come in handy for some who haven't tried it yet if they ever need it. And finally, I'm glad we checked all the boxes from the starter kit so that free psychotherapy and its application truly came to life at Ars Futura.

Let's talk mental health and employee wellbeing

Employee Wellbeing in Focus: Free Psychotherapy as a Workplace Benefit

Lea Metličić

If you’ve ever managed a website that requires manual content updates, you know the struggle of acquiring developer hours so they can help you add or fix a chuck of text or a block on that same website.

Although this song and dance might seem like an integral part of every web development project, it doesn’t have to be! There is a better and easier way and it usually begins with the implementation of a content management system or CMS. A CMS is software that can help you add, manage, change, fix, or update any piece of content on your website, without code or technical knowledge.

a CMS enables you to create content without necessarily creating any code

All this to say that choosing a good CMS can significantly impact the performance and flexibility of your website.

A quick and easy way to ensure that you can enrich your website with content is to implement a headless content management system.

Unlike traditional CMS solutions, a headless CMS separates the Front-End presentation layer from the Back-End content management, making it easy to add, change, and update any block or text you might need. At its core, a headless CMS separates the content creation and storage process from the way content is presented to users.

This separation of Front-End and Back-End enables a more efficient development process in many ways.

Firstly, because of a headless CMS, developers can work separately on Front-End and Back-End, allowing for parallel work processes to happen at the same time and making your deployment cycles much speedier.

Secondly, it promotes a more agile and iterative approach to web development, enabling teams to respond quickly to feedback or changing business requirements.

Lastly, a headless CMS facilitates a more diverse ecosystem of tools and services. Developers can choose the best-in-class tools for their specific needs, integrating them into the content management workflow. 

A headless CMS is really great at scaling content across different channels and devices, ensuring a consistent user experience. This makes it possible for users to interact with your content on their preferred device while you maintain a strong online presence and engage with them wherever they are.

Content reuse is another bonus of a headless CMS solutions. With content stored as structured data, it becomes easier to repurpose it across different channels. Whether you're posting on a website, mobile app, social media, or any other platform, the same underlying data can be used, ensuring consistency and saving time in content creation and management.

To wrap it all up, the benefits of using a headless content management system on your web page are multifaceted and very much worth it. This is especially true if you struggle with a lack of developer hours, use different design systems on your platforms, and have a need for a high content churn. 

The flexibility, scalability, and security offered by a headless CMS make it a great choice for organizations aiming to stay ahead in the digital landscape.

By decoupling the content management process from the presentation layer, businesses can achieve a more agile development process, deliver content across diverse channels, and future-proof their web presence. 

As the digital landscape continues to evolve, embracing a headless CMS represents a strategic investment in building a robust and adaptable web presence.

Some of the main benefits of implementing a Headless CMS for your website or product.

Is a Headless Content Management System Right For You? t

Is a Headless Content Management System Right For You?

Ars Futura Best Employer 2023

All the best things come in fours – the leaves on a lucky clover, the Beatles members, and now our Best Employer awards. And just like the clover, they really are lucky! 

For the fourth year in a row, we are one of the best employers in Croatia,

 thanks to the answers from our team in the MojPosao questionnaire.

Out of our team of 60, the majority would recommend Ars Futura to their friends. Also, most of them find fulfillment and happiness in their day-to-day jobs. Specifically, 90% of our employees feel this way!

Here are a few more highlights we’d love to point out in this year’s stats.

Our connections and interpersonal relationships are shining through! 

The highest-scored questions are related to teamwork and friendships among coworkers, the support our team gets from their managers, and overall great working conditions.

Our team respects and trusts the people they’re surrounded by, cherishes collegiality, and thinks their teammates are ready to help. Clearly, the 

 are great and the office atmosphere is thriving. They also love teamwork! In Ars Futura, it really does make the dream work.

The second highlight are the relationships between team members and their managers who they perceive as caring, ready to help, supportive, and willing to grow from feedback.

We say a
lot about...
everything

Popular Articles

We say alot about...everything

Popular Articles

We say a
lot about...
everything