__Once upon a time__, we had an idea to set up a company for like-minded people to work and collaborate together and pursue an agile way of life. The end result was Extreme Consulting a boutique consulting company helping clients meet their business goals and gain upper hand in a competition for survival. Little did we know that more people wanted to work in a similar, meaningful way.

Our people have multiple overlapping talents that are utilized in the projects. We are looking for designers, service designers, management consultants, developers (both front-end and back-end as well as unicorn full-stackers), data scientists and generally senior business people who can help our clients grow.

We are currently looking to quickly fullfil the following positions:

- [__Frontend Developer (React, Node)__](https://extremeconsulting.typeform.com/to/umLP4p)
- [__Full-Stack Developer (React, Node, AWS)__](https://extremeconsulting.typeform.com/to/umLP4p)
- [__Backend Developer (Node, Ruby OR Python)__](https://extremeconsulting.typeform.com/to/umLP4p)

[Send us a message and let's book a meeting!](/contact "Book us a meeting!")

We have offices in Helsinki, Finland and Sofia, Bulgaria. We believe in doing things the right way.

Careers at Extreme Consulting

Check Out Our New Career Opportunities

I'm a big sci-fi geek. Currently, I'm watching *Star Trek: Voyager* on Netflix. For the second time. The last episode, *Message in a Bottle*, got me thinking what I love about this series so much. Faster than light travel? Exotic, new cultures? Rayguns (or *phasers* as they call them)?

As science and tech fan, these are all cool — but it's not the reason why I watch it over and over again.

In the mentioned episode, The Doctor (who's a computer-generated hologram by the way), uses a *tricorder* to measure the environment. This multi-functional device can sensor scan the environment and materials. It can also perform calculations and data analysis and record its findings, including audio and video.

What gives me the goosebumps is that we have all this technology available to us today, albeit not built into a single device. A smartphone handles most of the stuff, and everyone has one. We also have affordable sensors for temperature, humidity and the like, and material scanners are in professional use already. Yet it was the coolest thing a science fiction writer could imagine in the late 60s.

Writers imagine things that improve the quality of life and bring humans to the next level, and scientists and engineers make them a reality. This is what gets my juices flowing. To see a Tesla driving by itself or my children asking Google Home a question and getting an immediate answer. Both of which were science fiction 20 years ago.

Constant change is deceiving. It happens in small increments, and we don't realise how fast technology gets better. Just ten years ago, we didn't have Apple Pay, Google Drive, Spotify, Uber, Airbnb or the iPad, to mention a few. Doesn't sound like fun, now does it?

This is why I get up in the morning. To make a small increment.

A Love Letter to Science Fiction

I've done a lot of global corporate .coms in my life. *A lot.* In fact so much that once I established Extreme Consulting a few years ago, I swore not to do it again. But as it often happens, that didn't last for long. Maybe it's because I'm pretty darn good at it. ;)

Large website projects almost always follow the same pattern. There are beautiful designs that are hard to implement because of the limitations of the platform. The content creation is behind schedule. Integrations take a lot of calendar time. A headless CMS can, at least partly, solve all of these problems.

A traditional CMS tries to solve two problems at the same time:

1. Content creation.
2. Presentation (web).

This means that storing and managing the content (pages, news, blogs, etc.) and displaying them on a webpage are handled by the same piece of software. This is problematic, because not all websites look and feel the same. The headless way is to separate the concerns. A headless CMS worries only about the content creation flow, and exposes an API for developers to use the content. The benefits include:

- The CMS doesn't set limitations on which frontend frameworks to use.
- Content creation can begin immediately, before a single line of code has been written for the website.
- The same content can be utilised in different channels, like web and apps, even print.
- Heavy duty CMS's often take a lot of processing power and thus have high running costs. A custom frontend is a light or heavy as needed.

There are number of headless content management systems available on the market today. Extreme Consulting website is NextJS-based with custom frontend. I'm using Contentful headless CMS to write this article. The website code was written in about a week.

Monoliths like WordPress, Episerver or Sitecore might not always be the best solution

Why Headless CMS?

Reasons to Choose a Headless Content Management System

# Core Technology Solutions

We are technology agnostic and not committed to any single programming language or platform. Today, the most wanted tools seem to be NodeJS, React, Vue, Python and .NET.

![Screen Shot 2019-03-21 at 14.35.31](//images.ctfassets.net/5wnw2cvk2nff/6YgjOP6fQxHCPWjG2c71sK/0be772c771891d343932be8f2acacfc6/Screen_Shot_2019-03-21_at_14.35.31.png)

# Content Management Systems

We have a history of creating content-driven websites, from marketing sites to global corporate dotcoms. We work with pretty much any CMS and know how to carry out a website project of any size. We often help our customers with design, information architecture and content production, too.

![Screen Shot 2019-03-21 at 14.39.27](//images.ctfassets.net/5wnw2cvk2nff/4LxgH5rwR5fGUQlmnUHNcP/3d0a1f28dac0350250d404ad3fe97e00/Screen_Shot_2019-03-21_at_14.39.27.png)

# Technology Partners

We have partnered up with all the major cloud providers.

![Screen Shot 2019-03-21 at 14.35.21](//images.ctfassets.net/5wnw2cvk2nff/2Oel5aygehbk857Elseef3/6a71fc0fa915fe20b2b79b25887b6adf/Screen_Shot_2019-03-21_at_14.35.21.png)

Programming languages, products, platforms and tools we have used over the years.

The Toolbox

__One fine Helsinki winter's afternoon__, while slugging away at a client project,  reminiscing melancholy about the good old times (Curiosity Mars rover landing was seven years ago!) and waiting for a build to complete, I came across a suspicious listing of a car for sale on one of Finland's most popular car-listing websites (who happen to be a client of ours!). 

It was a "Swedish tank" — a Saab 900 with barely just over 80K kilometers on it and not a speck of rust (which for that particular model is the biggest killer: the funky door design, with the bottom of it wrapping neatly under the body, giving an appearance of a perfectly flat inner door making it feel very thin and light is a perfect moisture trap). There was only one problem: the car was in Lapland, with me sitting comfortably at a sea-view window in our office 800 rural country kilometers away, I thought I saved my wallet a beating.

Alas, it was too late, the need, nay a craving to possess this fine example of automotive design and engineering has set hard and fast. It was time to go to Lapland! 

Armed with my laptop, an overnight sleeper train ticket and the knowledge of our philosophy of "getting stuff done" no matter when, how or where (it's the results that matter!), I've set off to Rovaniemi. 

Eleven hours later, I was greeted at the train station by the proud owners of the vehicle in question. What a beauty! All doubts dispelled and transaction completed, me and the now previous owners were enjoying a Finnish pastry with some terrible gas station coffee, discussing the ins, outs and various quirks of my new possession. For one it took longer than I'd like to admit to remember how a manual choke on a carbureted engine works and the optimal ways of using it.

Another eleven hours, a speeding ticket, an extremely dubious shortcut or two (thanks Google!) and countless more cups of terrible gas station coffee later, still feeling the ground vibrating beneath my feet and ears pounding, but safe and sound, I was home. Miraculously, unfathomably having burned just one full tank of gasoline, averaging a little over 6 liters per 100 kilometers for the trip, which is admirable even by today's standards. 

My wife thought I was mad, so did Tommi and Lasse, but it was Lasse, [a passionate electric car enthusiast](/article/our-technology-stack) and a proud owner of one (manufactured by a certain company named after a notorious scientist who advocated alternating current), who could not wipe the grin off his face while furiously working his way through Saab's five short gears, enjoying the leisurly climb from 0 to 100. It was [Tommi](/article/careers-at-extreme-consulting) who could not help but notice the sublime beauty of 50 year old tech parked next to the automotive bleeding edge. And it is my wife who, while still thinking I'm crazy, happily joins me in "the new car" for an occasional spin down to some place time forgot.

Now where was I going with this... 
Tech stacks! Of course. 
Here's the thing: when evaluating the needs of a project try not to be seduced by the latest and greatest "it thing". There is no chasing tomorrow. Today's bleeding edge is tomorrow's dusty textbooks. Progress marches on with ruthless indifference and often little logic. 

Floor the pedal on that Model-S! Give that latest JS library a shot. Experiment with a brand new language that promises to be the last one you'll ever learn. We wouldn't be in this field if not for the love of technology. It's just that sometimes, an old Saab 900 is just what the doctor ordered.

As I was crossing the arctic circle enjoying the winter sunrise, the thermometer outside read 5°C, above zero. Maybe that alternating current guy was onto something...



What to consider when evaluating technology

To Lapland and Back in 24 Hours

Tech Stacks and the Art of Classic Car Maintenance

In August 1628, Swedish warship Vasa set sails and left Stockholm for its maiden voyage only to founder after sailing one kilometre, killing 30 souls. It had taken two years to build and was heeled over by a light breeze, being too top-heavy. The project was ambitious, to begin with, and there has been speculation about whether the initial plans were modified to add more features on the fly.

I have a track record of pissing off salesmen in the company I work in. I've done this by telling a potential customer that they should actually scope down their idea and release an MVP (Minimum Viable Product) first. I get it — to a sales-person, this might sound like throwing money away.

Obviously, I disagree. Small iterations just make so much more sense business-wise, and they are also easier to implement. This means reaching deadlines, manageable expectations and faster go-live and user feedback. In other words, higher customer satisfaction. Which leads to better and longer lasting customer relationships.

Below is a brilliant image of the MVP approach by [Henrik Kniberg](http://blog.crisp.se/author/henrikkniberg).

![mvp-vehicle](//images.ctfassets.net/5wnw2cvk2nff/5434z0dkhXpPsaFGkynJbH/4c029c657c15d91602cd96308cc75e3b/mvp-vehicle.png)

This image has received a lot of criticism too. I've heard comments like “sometimes a skateboard just won't do, you need a car.” They are right, sort of — the example only works if the business problem is about moving people from one location to another. But if it is, it really captures the essence of MVP thinking.

Let's say each iteration takes one month to build. This means that in the *not like this* example the person is still in the original location and the *like this* guy is far, far ahead after 1 month of skateboarding, 1 month of scootering, 1 month of cycling and 1 month of motorbiking. I think you want to be that guy, way ahead of your competitors.

Another detail that is often missed from the picture is that the two cars on the last stage look different: The other one is a 4-seat family car and the other one a 2-seat convertible sports car. This is because at stage 0 when they planned the whole thing, they didn't know how many people they need to transport. So to be on the safe side, they decided to have seats for four people, even though they knew that in the first phase they only needed to transport one person.

In the second example, they acted based on the data at hand: Build a minimum viable means of transportation for one person. At some point, they needed a seat for the second person, which was possible in stage 4 or 5. So not only the like this people are far ahead, they also have a better car for their needs.

Other people don't like the MVP approach, because they, in their words, don't want to release crappy products. This is a common misinterpretation, which I think is brilliantly corrected by the image below (compliments to Aarron Walter).

![mvp-pyramid](//images.ctfassets.net/5wnw2cvk2nff/2TW9JSfly9VYC3CI9dKkZz/414c7f068d67a4d5a551e4bfc26679c1/mvp-pyramid.png)

The idea is not to implement features half-assed — the idea is to release fewer features and more often. While you should always aim for success, if you fail, this way you'll fail fast and can correct your mistake in the next iteration. Warship Vasa would have, mildly put, benefited about this approach. Starting with fewer cannons and other top-heavy features would've most likely revealed the ship's lack of initial stability without a total disaster.

While you might be nodding in agreement right now, this is very hard to do in practice, especially in large organizations that are used to the waterfall model. It's also hard if the product has several stakeholders, each thinking their business need is more important than the others. It requires some hard decisions on prioritization and in some cases splitting one product into two.

There's an old saying about customers knowing what they want but not what they need. Same applies to stakeholders. The hard part is to steer the focus away from the how (buttons and features) to the what (business needs). Once those are clear, the implementation should be relatively easy for a digital product studio.

Don't go waterfall.

If you aren't even a little bit embarrassed, you are releasing too late.

Laurila on Scoping

What are the latest and greatest tools for frontend web development? When mostly focusing on bigger and longer projects it’s not too often you get to revaluate the essential tools for your frontend stack. About being the latest and greatest, I have no idea, but here are some pretty interesting stuff to consider when starting fresh. 

### Styled System

[Styled System](https://github.com/styled-system/styled-system) is a tool for passing style props to components. Very cool approach for creating a component library with theme-based styling. Check this nice [overview](https://medium.com/styled-components/build-better-component-libraries-with-styled-system-4951653d54ee) by Alan B Smith, or dive deeper into technical details by reading [this great article](https://varun.ca/styled-system/) by Varun Vachhar.

### Rebass

Wait… it looks like a UI framework? But I hate UI frameworks. Well, it isn’t really one. It’s just a super lightweight UI component library based on [Styled System](https://github.com/styled-system/styled-system). It provides just the foundational components for you to build on, and a grid! You can also just use the [grid](https://github.com/rebassjs/grid) if you like!

### Parcel

[Parcel](https://parceljs.org/) claims to be a “blazing fast, zero configuration web application bundler”. I must say it feels very promising.

Interesting stuff to consider when starting fresh. Vol 1.

Tools of the Season

__Recently, the Finnish press called me a “raging electric motorist”__ ([YLE](https://yle.fi/uutiset/3-10601404)). While I'd like to think I normally keep my cool, I quite like this title. It has character. Previously I titled myself as "Full-Stack Software Craftsman With a Business Twist" on LinkedIn, earning the record of longest title in my workplace at the time.

The truth is, I'm not really into titles, at least not in a serious way. Also, I have never applied to a position like a developer, architect, team lead or such. I have just applied to a number of companies and found the right position after being recruited. This would be my ideal candidate, too — if you are passionate about business and software, we are interested.

However, I have learned that most programmers don't like this approach. I guess it's too vague. So here goes:

- We like small teams.
- [We don't do waterfall.](/article/laurila-on-contract-models)
- Most of our staff are senior in their field.
- Node, React(Native), Python, .NET, PHP (but not limited to these)
- Only public cloud (AWS, Azure)

Questions? Please don't hesitate to [call](tel:+358407707107) or [message](mailto:lasse.laurila@extreme.consulting) me.

Our Technology Stack

What Title Would You Prefer?

I have a fireplace at home. I love it, but like any piece of technology, it requires maintenance. A couple of years back I had my chimney swept. After the job was done the sweeper came to me with an expression on his face that looked like bad (expensive) news. I was right — the coating on the inside of the chimney had been fractured or damaged in some way and needed to be redone.

So I asked around a bit and got recommended a guy to do the job. He came over, had a quick look at the chimney and came to me with a number. “We have this thing called *fixed price*”, he explained, as I was cocking my developer's ears. He told me that it means that they carry the risk if something unexpected would happen.

I refused. I asked him what their hourly quote was and if they could just give an estimate and charge me time and material based. While puzzled, he agreed. Once the job was done I ended up paying a bit less than the original fixed price. It only makes sense — as I was now carrying the risk, I should be able to make a profit too. But this is not why I wanted this contract model.

So, what if something unexpected would've happened? Maybe the contractor found out that the chimney was in way worse condition than they originally thought and needed some additional repair work, not just the coating. In a time-and-material-based model they had come back to me and told about the situation so I could decide on how to proceed: Was the old chimney worth the extra cost? Do I want to repair it now or maybe later when I have saved more money? For the contractor it's all the same, they will get paid in any case.

With a fixed price, the situation would be totally different. No matter how much extra effort they put in, they will never get paid more. So basically, they have no incentive to repair the chimney properly, quick and dirty would do. Sounds like a bad idea to me.

Now, you might say that this wouldn't work in software development because no one has an unlimited budget. Luckily, software development is very different to chimney repair work. It's very dynamic, which allows us to decide on a budget, schedule and high-level plan and then execute it implementing the most valuable features first. With this approach we don't know the exact features we'll get, but we do know that we'll get the best possible product within the given budget.

Another problem with fixed scope project is that you have to put a lot of effort into planning and estimations, the latter being 100% waste in a sense that it doesn't add any value to the final product — it only serves the project. Planning is obviously not all waste, but given the fact that in real life implementation details often slightly change when writing code, there is a lot of waste in detailed planning, too.

This all might seem a bit puzzling to someone used to the waterfall project model. Instead of gathering the functional and non-functional requirements¹ to a huge document followed by an RFP process, how should it be done? Here's my suggestion:

1. Gather your *business* requirements. What is the business goal you want to achieve? What is the problem you are trying to solve?
2. Innovate and find the core solution and the basic approach. Don't focus on details. This can be done in-house or with a partner.
3. Looking at the potential business benefit and the rough size of the solution, agree on a budget. It makes sense to do this together with the contractor(s).
4. Choose a contractor. You already know the price, so pay attention to their competence, references and try to evaluate if they have truly understood your business needs.
5. Implement in an agile² way. Be involved in the process! It's your baby, not theirs. First, implement the core features so that they work; don't dive into the details in the first phase! Just make it work. Fine-tuning comes after that.
6. Release as early as possible. No internal testing or user study can replace feedback from real-world users.

Don't go waterfall.

¹ I've always found the concept of *non-functional requirements* a bit silly. Why would you want something in your product that doesn't do anything?

² There are many agile frameworks and there are books written about their differences. I recommend choosing one and committing to it, maybe the one your contractor prefers or suggests for the job.

Laurila on Contract Models

Our story begins with a simple idea of doing things the right way i.e. creating services and features that the client actually needs. In our world it means real live __user testing__ of a products that has been built for the end customer in mind. Our __Service Design__ process is heavily data driven to really answer the customers needs. 

One part of our daily struggle is to make sure our co-workers are happy since it directly translates to our customers happiness... go figure.

We simply refuse to believe that development can be separated from design so we always include a mix team of talented professionals with the client´s project. This could manifest as added __architectual__ knowledge, if it´s a development project, and business understanding like __Business Management__ or some specific industry insight like __fintech__ to the team.

It´s hard to pinpoint our core industries since I think we have done it all from healthcare to logistics, from finance to pets, from maritime to real estate and from eLearning to eCommerce.

If you would like to know more about choosing the right technology for you then read what Greg wrote about tech stacks and [buying a car from the Arctic Circle](/article/technology "What to consider when evaluating technology"). We would also recommend you to read about [Game Theory and Business](/article/what-has-game-theory-to-do-with-digital-business "Learn about Game Theory and how it affects business") by Aleksanteri.

We design and we build. We teach and we measure. We dream the big and we always deliver. Until we loose our passion we´re here to help you to make your dreams come true.



Contact

Careers

More

The Toolbox

Programming languages, products, platforms and tools we have used over the years.

Core Technology Solutions

Content Management Systems

Technology Partners

Lasse Laurila

Co-Founder, CTO

Raging electric vehicle enthusiast

Related Articles

Careers at Extreme Consulting

We have offices in Helsinki, Finland and Sofia, Bulgaria. We believe in doing things the right way.

A Love Letter to Science Fiction

What gives our CTO the goosebumps

Why Headless CMS?

Monoliths like WordPress, Episerver or Sitecore might not always be the best solution

To Lapland and Back in 24 Hours

What to consider when evaluating technology

Let’s Work Together to Take Your Business Forward

Helsinki, Finland

Maneesikatu 1-3, 00170 Helsinki

Lasse Laurila, CTO
+358 40 770 7107
lasse.laurila@extreme.consulting

Sofia, Bulgaria

20 April 13 Street, 1st floor, Sofia

Strahil Strahilov, GM
strahil.strahilov@extreme.consulting
+359 88 795 3307

Contact

Careers

More

The Toolbox

Programming languages, products, platforms and tools we have used over the years.

Core Technology Solutions

Content Management Systems

Technology Partners

Lasse Laurila

Co-Founder, CTO

Raging electric vehicle enthusiast

Related Articles

Careers at Extreme Consulting

We have offices in Helsinki, Finland and Sofia, Bulgaria. We believe in doing things the right way.

A Love Letter to Science Fiction

What gives our CTO the goosebumps

Why Headless CMS?

Monoliths like WordPress, Episerver or Sitecore might not always be the best solution

To Lapland and Back in 24 Hours

What to consider when evaluating technology

Let’s Work Together to Take Your Business Forward

Helsinki, Finland

Maneesikatu 1-3, 00170 HelsinkiLasse Laurila, CTO+358 40 770 7107lasse.laurila@extreme.consulting

Sofia, Bulgaria

20 April 13 Street, 1st floor, SofiaStrahil Strahilov, GMstrahil.strahilov@extreme.consulting+359 88 795 3307

Maneesikatu 1-3, 00170 Helsinki

Lasse Laurila, CTO
+358 40 770 7107
lasse.laurila@extreme.consulting

20 April 13 Street, 1st floor, Sofia

Strahil Strahilov, GM
strahil.strahilov@extreme.consulting
+359 88 795 3307