we are mantro digital
and we deliver technological impact

arrow icon

[ about ]

we are the engine room of the mantro ecosystem.

we are home to hardware tinkerers, software technicians and design afficionados.

Benjamin mantro digital

Ben
CTO

ivan mantro digital

Ivan P.
CTO Zagreb

Robert mantro digital

Robert
CTO Trnava

Sebastian mantro digital

Sebastian
Technician

filip mantro digital

Filip S.
Technician

Jens mantro digital

Jens
Afficionado

davor mantro digital

Dex
Technician

filip mantro digital

Filip M.
Technician

Alex mantro digital

Alexander
Technician

Corinna mantro digital

Corinna
Afficionado

Fabian mantro digital

Fabian
Technician

Sefan mantro digital

Stefan
Technician

pascal mantro digital

Pascal
Technician

ivan mantro digital

Ivan V.
Technician

roberto mantro digital

Roberto
Technician

Bogdan mantro digital

Bobby
Afficionado

Armin mantro digital

Armin
Technician

Mihai mantro digital

Mihai
Technician

Ivan B.

Ivan B.
Technician

Peter

Peter
Technician

Peter

Jakub
Technician

Peter

Bozo
Technician

[ fundamentals ]

we are wired for high-standard yet pragmatic work results. we craft tailored solutions for the individual situation. we aim to enable progress without establishing codependence.

we are not cutting edge scientists nor do we aspire to be. we work on the future by building technological solutions that solve tangible problems. nothing more, nothing less.

[some of our guiding thoughts]

This. Is. Us
:
{
No reason to get bold here. We are special, as everybody is special. Whether you are specialized on ecommerce applications or on serially building early stage b2b/tech products.
Our way does not have to align with ”what everybody says”. Also there is no need to feel better than anybody else. Our objective has side-goals that need to be accomplished that might not exist in other settings.
}
Productive Amnesia
:
{
Never be too proud to admit a change in your opinion. The world changes, constantly, and sometimes faster than we want. Things once established fade away and new paradigm shifts linger around the corner. Don't fall for analysis paralysis, but also question your beloved tools and practices from time to time. Discuss them, question them, reestablish them, or throw them away. The important part is to make it a reflected endeavour.
}
Core Product Problem
:
{
Every product brings different challenges to solve. In the most cases a brilliant login dialog does not solve anything. But if you try to establish a new open id service, it might very well be. Think about the 1-5 core problems you will be facing (in terms of complexity and effort). These are the parts which demand good architecture and solutions. Again, a login dialog might be refurbished quite quickly. A tax logic probably not.
}
Thought Model
:
{
Every team member should have roughly the same thought model about how things work in the product. Using the same (high level) words helps a lot. Identifying the CPPs helps a lot. Ultimately you should be able to pitch the inner workings of the product clearly while drinking coffee. Even though eventually your product might go "rocket science", the thought model should still be easy to understand.
}
Domain Context
:
{
Your product is living in a domain. Which might have restrictions, culture, trained behaviours and certain expectations. It is a huge difference if you want to introduce an internal QA tool in a steel-mill or if you are developing a hardcore MMORPG Asia grinder. Understand your context and understand that some of your assumptions might be horribly wrong. Embrace the differences and learn their effects.
}
Maturity Context
:
{
"WTF? You don’t have 98% coverage?“. Yep, I actually have 0%. Main reason for that is that I don’t have tests.

Sounds familiar? Well, sorry to break the news. Both are wrong, and right. Actually it depends on the maturity of the product. Early stage? Maybe don't focus on tests, iterate instead. Late Stage? Well, you better have good tests. Always understand that something might not be important right now… but maybe in the not-to-distant future?
}
Black vs. White
:
{
Yes vs. no, right vs. wrong, absolute vs. relative. More often than not things are not digital. Although sometimes you have to make extreme calls between technologies (frameworks, methods, etc.), it is more of a judgement call. Get rid of simple dimensions, the reality is very colo(u)rful. A tool might be perfect in one occasion, but horribly wrong in another.
}
Fail fast (and defend!)
:
{
Darn, an exception. Why did this happen? This is not good. It should not fail. Let’s catch it. Maybe log it. Well, probably not a problem, let’s move on.

A perfect solution for your local one-man-show tool. A disaster for your backup cronjob. If you can handle only state 1-3, throw an exception with a meaningful message on all other states. Throw in your name, the class, the method and why you cannot proceed anymore.
}
Comment
:
{
This for loop iterates through all "keys" of "array". Great job. You wrote a comment. Clap clap, Captain Obvious. If you write good code, you don't have to comment what it does line-by-line. Focus on the exceptions to the rule, the extraordinary, the hack you had to introduce because of a weird DOM behavior in FF < 39. Explain yourself. Write your name. Add StackOverflow links. Don't hide, you probably had your reasons. Give others the possibility to understand, even if future readers might have a better solution for it.
}
Valley Bias
:
{
But the folks at FAANG always use Uranium powered docker containers from outer space?

Well, great. Thing is, I'm out of Uranium and I've never been to outer space. Some companies in the valley (and elsewhere) are operating outside of the normal scale. It's ok to read carefully about their operations and learn, it's ok to think about aspects you can extract form these learnings and put to good use in your own product. But don't cargo cult blindly, especially if you don't have Uranium at your disposal.
}
Power to the people
:
{
Erm, our deployment dudette is on 4 weeks vacation. No releases in that time.

That sounds bad. Very bad. We should design systems in a way that we can rely on safeguards. That the process is understandable. That the necessary things are documented. And everybody needs to be able to execute crucial steps. Be it deployment, or bugfixing. Deploy often. Get rid of the fear. Get used to it. Mistakes will be made, shit will hit the fan, yadda yadda. Step up and do it yourself. With the help of others. With supervision. And then, without safety net. Yourself.
}
Take Ownership
:
{
I don’t know who wrote that code, I have nothing to do with it. The guy left a month ago.

This is a very common sentence... in a corporate. You should never find yourself in that situation. Take ownership of what you do. Somebody is leaving? Ask them for a handover, check out the code, read into it. You think somebody is about to do a bad decision? Speak your mind, explain why you see negative implications. You see parts of the code breaking? Come up with a plan on how to tackle it.
}
arrow icon
arrow icon
laptop full of stickers
react logo as a stickertypescript logo as a sticker

[ contact ]

work with us

Exterior view of the mantro zagreb office

zagreb

zagreb@mantro.digital
+385 99 461 4343

Zaharova ul. 5
10000 Zagreb
Croatia

Get Directions

exterior view of the mantro digital office in munich

munich (HQ)

munich@mantro.digital
+49 89 41617700

Zielstattstr. 19
81379 München
Germany

Get Directions

mantro trnava

trnava

trnava@mantro.digital
‭+421 917 538 446‬

Bernolákova 49
91701 Trnava
Slovakia

Get Directions