The Future of Flutter

Flutter is storming its way to the hearts of mobile developers. Only until now, one of the biggest companies, like Alibaba or Tencent has chosen the new Google’s framework upon native solution and React Native ones. Flutter is fast, easy to learn, flexible and prepared to make beautiful apps using the same code base. So is this all a fad or maybe the new framework is here to stay?  

In our previous articles, we have introduced the Flutter framework and Dart language and compared it to the most serious opponent – React Native. But there is still one concern left – will the framework be popular enough to secure the future of existing projects? What if Flutter community and support will not develop fast enough? There are at least a few reasons why we strongly believe the future is Flutter.

1. The structure and learning curve of the Dart language seems promising

Although Dart is still a niche, it is quite an easy language to learn and can be picked up by Kotlin or Java Developers. In fact, almost everyone with basic programming skills can try it. There are numerous pieces of evidence on the web (on the development forums or reddits) that people with no previous experience with Dart are now creating mobile apps using Flutter framework with ease.

Dart has also insanely good documentation. It is crucial when learning a new language, especially the open source one. Apart from that, the vast majority of framework components is handled by internal Google’s core development team which ensures consistency. That is why even if the Flutter community is still small, there is quite a big chance that it will grow fast.

2. Flutter heavily focuses on fully custom UI

One thing great in Flutter is its flexibility in creating own components. The framework has almost every widget the developer might need for a native application, no matter if it is based on Android or iOS UI. But even if something is missing, there are still a lot of possibilities of creating custom widgets. This is extremely helpful when developing custom apps or “branded-apps” for bigger tech companies. That being said, Flutter should become one of the most common tools for mobile startups in the near future.

3. Flutter may pave the way for Fuchsia OS

Fuchsia OS is the capability-based operating system developed by Google that might replace Android. Although Flutter is not directly connected to Fuchsia, some features are inspired by it – like the custom widget creation used in Fuchsia’s Now Feed for example. In fact, making apps with Flutter is kind of one step forward ahead of the market. Why? Because iOS and Android apps made with Google’s framework are already Fuchsia-ready! So before the system is even released there will be lots of apps compatible with it – you may prepare for the future by choosing the right framework now.

4. Flutter makes programming faster and more efficient

As we have mentioned in the article about the pros and cons of choosing Flutter, the framework is currently one of the most efficient ways of developing cross-platform mobile apps. First and foremost, it introduces a stateful hot-reload, a feature that helps to test changes in the project almost in real-time, without recompiling or losing the state of the app. Lack of OEM widgets and no JavaScript bridge for reactive views ensures great app performance. And widget-based design, where all widgets are part of the project, not the platform, is a guarantee that apps made with Flutter will always be compatible with iOS and Android devices. It all sums up to faster time-to-market, which is an essential factor for young, hungry startups.

5. Flutter has a big, determined corporation behind it

Google is determined to establish Flutter as one of the best frameworks for mobile apps. That surely means a lot of support and development throughout the years to come. Google is doing everything to convince developers to use their framework, providing a unique experience, performance, the fastest time-to-market there is, and incredible documentation support. The best evidence of how meaningful the Flutter is for Google is that the company already uses it in some of the most important apps (business-wise) like Google Ads for example. There is no better way to demonstrate how much faith they put in their framework.

Summing up

To sum up, there is no doubt the future of Flutter is bright. More and more developers learn Dart; big e-commerce companies are not afraid of using it for their most important projects and Google is determined to develop the best framework there is.

The future is even more interesting when we consider the next mobile operating system, Fuchsia OS, that is slowly being cooked in Google’s labs. The state of the market might rapidly change when Google releases the new system, forcing all Android developers to become Flutter developers. That is where Flutter will shine the most.

There will be an interesting battle between two of the biggest tech enterprises in the world – assuming that Facebook will pick up the glove and make the effort of reconstructing React Native. But no matter what the result will be, the ones who benefit from it is us – developers and users of the mobile apps.

Flutter vs. React Native: A Comparison

Cross-platform app development is on the rise. Start-ups, e-commerce, and other tech companies struggle with developing interactive apps fast, efficiently and with ease. Facebook’s React Native has been recognized as a reliable tool for mobile development. However, Google’s Flutter, a tool that came out of beta only a few weeks ago, has been gaining much interest lately.

Let’s take a look at those two competitors in this detailed overview to decide which one is a potentially better tool to develop a cross-platform application.

Flutter and React Native – quick overview

In our previous blog post, we have shown the pros and cons of the latest Google tool, Flutter. So just to remind you: It is a framework introduced by Google round 2017 (the company released first, stable version December 2018). Flutter utilizes Dart language to create beautiful apps for both iOS and Android using the same code base.

React Native is Facebook’s tool developed since 2015. It uses JavaScript built upon the React library, which is also Facebook’s invention. Apps made with React Native are also cross-platform. Most prominent startups in the world (Facebook, Instagram, to name a few) have developed their mobile apps with this framework.

Flutter and React Native – similarities

Undoubtedly, Flutter and React Native are somewhat similar frameworks (at least at first sight). Both help developing apps using the same code base; both are supported by giant tech companies; they are open source and free. They also share the hot reload feature and excellent UI solutions for a remarkable native experience.

A close and detailed comparison of both platforms reveals numerous differences between them though. From a programming language, through performance, up to the state of community – React Native and Flutter are two different ways of creating mobile apps. Let’s dive right in!

Programming language

React Native works on JavaScript. It is a widely adopted language, with a lot of support from the online community and a track record of many successful mobile and web applications.

Flutter uses Dart, which we have explained in details in the first post of the series. Dart is fairly new, although the learning curve for this language is not steep, especially for experienced developers familiar with C# and Java.

User interface

Both frameworks differ when it comes to designing the user interface.

Creating UI with React Native means using the components native to the system. Apps created that way are almost indistinguishable from native ones. The vast number of React Native UI components promises a great user experience, even better than its younger opponent. However, native components are also a significant burden for React Native because of performance issues and limited portability.

Flutter uses widgets for UI creation. They are not part of the platform which gives Google’s framework an advantage in terms of portability, performance, and compatibility. User Interface made with Flutter feels really native and looks great thanks to its proprietary widgets.


In React Native, when an app requires native elements of the platform (e.g., camera usage), there must be a JavaScript bridge to convert JavaScript variables into native ones. This may cause performance issues when building a hybrid application, especially with the animation speed.

Dart, on the other hand, was built to be the JavaScript successor. It is one step closer into native applications and backed by C++ engine. Flutter not only does not use the bridge to interact with OS elements but even further reduces the interaction with them thanks to Skia (the graphic engine). That means apps developed with this framework achieve significantly better fps than React Native ones.

Development time

Delivering projects on time has become one of the most critical elements in commercial app development. Both Flutter and React Native support cross-platform and reduce time-to-market for mobile apps. In both cases, third-party libraries and ready-to-use components make coding more efficient.

React Native has been on the market since 2015. Many developers recognize Facebook’s framework as one of the most convenient and swift ways to develop an app. Comparing to native development over 90% of the code can be reusable, and over 70% – shared between the platforms. Also, JavaScript is such a popular tool, that finding a React Native developer is easy. On the other hand, since React Native uses the bridge and native elements, it often requires separate optimization for every platform – the problem that widget-based Flutter does not have. That may cause more prolonged and wearisome development process.

Flutter, as a relatively new framework, has a noticeably smaller community. Dart is still a fresh language, in oppose to popular JavaScript. But since Flutter outgrows React Native in terms of usability and simplicity, the development time shortens significantly, especially for those developers, who get to know Dart beforehand. It is super easy to start developing in Flutter – it is all about downloading and unzipping Flutter package and creating an environment variable inside of the framework’s folder.


Documentation and IDE support is one of the essential elements for fast and efficient coding. Again, React Native and Flutter differ in this field, mostly because of uneven time on the market.

React Native has bigger and more complex documentation. The official documents are full of guides and answers for frequently asked questions about various elements of building cross-platform apps, which is a good thing. However, some developers may find React Native’s documentation clumsy and chaotic, mostly because of its open source nature.

Flutter’s documentation is considered to be organized and very thorough. The framework even has a document written especially for React Native developers, helping them to move from old to new tool. The framework is compatible with lower amount of  IDEs (VS Code, Android Studio, IntelliJ IDEA). But then, the best React Native’s alternative (Webstorm) is a paid version, so it puts it a little behind Google’s tool.


With over 3 years on the market and JavaScript being a widely recognized programming language, React Native is a winner in this competition. Most prominent companies and an extensive amount of developers use it to create cross-platform apps. However, React Native may still feel the breath of younger competition on its neck.

All because Flutter growth is impressively fast. Although it may not have as much Github stars as React Native, it gains momentum and attracts new, dynamic companies, like Alibaba or Tencent – to name the few. Flutter community is really dedicated to develop the framework as fast as possible. Up until now, there are nearly 1500 Flutter packages available on official Dart page – and counting.

Summing up

The battle between React Native and Flutter is mostly a battle between stable, recognized framework versus an opponent that is new, dynamic and hungry for success.

React Native is an established and reliable tool with a stronger and more mature community. It leverages one of the most popular programming languages and offers great native app performance, especially for iOS apps. On the other hand, developers may find it harder to learn and use because of problems with components and documentation. Not to mention the development time and optimization issues.

Flutter shines when it comes to great UI and quick time-to-market. Although it requires some effort learning the new language and lacks firm support from the community, these are not the groundbreaking cons. Especially when comparing the performance, development time and possibilities of both platforms – Flutter greatly overperforms its older competitor.

Flutter vs React Native – brief technical summary


First Release: 2017
Created by: Google
Technology: Dart
Time-to-market: Fast
Documentation: Smaller, but clear and precise
Hot Reload: Supporting
IDEs supported: VS Code, Android Studio, IntelliJ IDEA
Native performance: Great
Used by: Google, Google Ads, Alibaba, Tencent, Hamilton Musical, JD Finance

React Native

First Release: 2015
Created by: Facebook
Technology: JavaScript
Time-to-market: Slower than Flutter
Documentation: Extensive, actual, but a bit clumsy
Hot Reload: Supporting
IDEs supported: Almost every IDE possible
Native performance: Great
Used by: Facebook, Instagram, Uber, Tesla etc.

Why Choose Flutter? Pros & Cons

Flutter helps develop cross-platform mobile applications that are fast, well designed and compatible. Let’s dive into the newest UI framework from Google and learn about its wide and promising possibilities.

What is Flutter?

Flutter is a free and open-source framework for building native-looking apps on iOS and Android from the same code base. It has been on the market since 2017, and as a full product (not beta) since first Flutter Live Conference, December 2018.

Although it is a relatively new tool, companies like Alibaba (one of the biggest B2B online markets) and Tencent (the leading Chinese internet-based group) have adopted the technology in their most significant products already. Google uses Flutter in Google Ads app as well. Also, the framework is the development platform for their upcoming operating system, Fuchsia.

We at iteo are part of this revolution, too.

How Does Flutter Work?

Why is this a revolution? Because of its nature and capabilities, Flutter is not a framework but rather an SDK for applications designed for a touch screen. Its primary purpose is to work with iOS and Android devices but can run on other platforms as well.

One has to learn Dart if he or she wants to develop apps in Flutter. This is relatively easy object-oriented programming language with many features useful when building a native application.

As for the interface site, Google’s framework uses Skia, an open source 2D rendering engine. This set of components allows creating UI in a way – for those of you familiar with game development – engines like Unity allow creating games.

It is because widgets are the core of this framework. Everything in Flutter is a custom widget created to look natively both for iOS (Cupertino) and Android (Material Design) devices. The whole UI design is all about combining those widgets, including text, shapes, animation. They determine even aspects of the layout like padding. You can even build your own complex widgets from simpler ones.

Pros and cons of Flutter

Although Facebook’s React Native is a top-of-mind competitor for the pros and cons paragraph, this time we concentrate only on Flutter’s benefits and disadvantages that one might consider when determining a technology for the next mobile app.

Benefits of Flutter

1. Allows to build iOS and Android apps at the same time

Because iOS and Android apps build with Flutter use the same code base, there is no need to develop for one system and then repeat the process for another. Apps made in Flutter work on both Apple and Google platform seamlessly. That means less coding for your development team and more business opportunities with a simultaneous launch on both platforms.

2. Speeds up coding and prototyping

If there is one aspect that should convince anybody to use Flutter is its hot reload. This feature allows seeing any changes made in the code almost in real-time, with no need for app restarting. The updated source code is injected into the running app and Flutter automatically rebuilds the widget tree so that changes are seen in real time. Hot reload speeds up the process dramatically and also improves the whole process helping the devs to identify bugs as soon as they appear and test new UI or features without tie-ups.

3. Great performance

Since Flutter is not using any OEM widgets and there is no JavaScript bridge for reactive views, the app performance (especially startup times) is noticeably faster than in non-Flutter apps.

4. No compatibility issues

All widgets and their renderers are part of the app, not the platform. There is no need for any additional libraries to ensure compatibility with iOS and Android devices. There are some restrictions, though. Running Flutter is possible on iOS 64-bit devices and all Android devices above 4.4 or 4.1. with software rendering.

5. Open-source

Flutter is an open-source tool which means it has countless possibilities of customizing almost everything in the framework – from Material and Cupertino widgets to animation and gestures.

Disadvantages of Flutter

The risk and limitation of Flutter are the effects of its young age.

1. New language

Although Dart is an easy language to learn, it’s still a language to learn. That is why, since Flutter is only several months on the market, the first steps could be tricky for those who look some online help and support from the community.

2. Suited for universal apps

Flutter’s biggest advantage – building native-looking iOS and Android app using the same code base can be its biggest disadvantage for some. It is a framework designed for universal, cross-platform apps. Using Flutter for platform-specific projects that use platform provided view or are in any way tied more to one platform than another is not the best choice.

3. Apps cannot be smaller than 4MB

Because Flutter-made apps are using built-in widgets not platform widgets, their size is usually bigger. Right now the smallest possible app made with Flutter can weight no less than 4MB, but the Google team ensures that they are working on optimizing it even more.

4. A new, unstable tool

Like all new tools, Flutter can experience problems of relatively fresh technology. Typical concerns include not coping with changes in the UI of iOS and Android for example. Some developers also claim Flutter is still not mature enough to handle big, e-commerce applications – but Tencent and Alibaba’s examples seem to prove otherwise.

Who benefits from Flutter?

To sum up, there is no doubt that Flutter is currently one of the most exciting tools in the market to develop mobile applications.

It can be especially interesting for:

  • Startups, e-commerce and all tech-related companies that want to build 2D app faster, more efficient and release it on all available platforms at the same time
  • Programmers themselves – because it makes coding faster, more efficient and compatible
  • Designers – that want to build great-looking, modern applications that meet the standards of both mobile platforms

The Story Of Our New Identity

Creating new branding is a very big deal, especially when you really want your brand to properly reflect who you are and what are your core values. Anyway, we decided that the beginning of 2019 is a perfect time for a change.

Since the very get-go in 2011, iteo has been successively changing, but our visual identity remained the same. It has been serving us well for a chunk of time, but at some point, it just stopped feeling right. It was good but didn’t tell the story nor express our vision. We knew it was a bit outdated and difficult to scale up in the IT industry that needs to be following the latest trends at all times, this kind of feeling was unacceptable. Change is something you can’t avoid, especially if creating new ID allowed us to express the journey we’ve been through and what we’ve accomplished.

Following those trends and, most importantly our inner guts, we decided to take a bold step forward and redesign ourselves.

Keeping it short and sweet

There are three key adjectives that define us as a team: CREATIVE, PROFESSIONAL and FRESH (big word, huh?). We combined them using three main elements in our new branding:

Onelines – creative

Shapes – professional

Colors – fresh

While working on the concept of our new ID, we wanted to create uncompromising and awesome stuff, but at the same time needed to keep professional. It is extremely important for us to create a brand that our team wants to identify with, that is recognizable and respected on the market.  

New Logo

Why did we decide to change our logo? Because it visually didn’t represent any specified concept. That idea was inside us but was not reflected by the logo.

This is exactly why we created the new iteo sign. One that we, as a team, can use in a conscious and deliberate way. One that will also look pretty damn hot as an office neon.

The current logo is a oneline shape based on a steady circle with a rebellious spin thanks to the letter “i” that whooshes right through it. On the one hand, it’s just a simple and literal sign, but on the other, it represents many objects and visions. Just take a look:

Visual Identity Components

It was extremely important for us to create something unique. This is why we combined geometric shapes – they are stable, predictable and genuine with oneline illustrations that are fresh and mischievous.

Why geometric shapes? Cause, they are symmetric. Just like with people’s faces, we all subconsciously look for symmetry, as it’s a norm for aesthetics. People feel good and safe with it – which is exactly what we need in those crazy times.

To make it even more rebellious, we added a twist onto the figures themselves, by covering them only partially in orange colour which makes them a bit rebellious yet even more symmetric.

Oneline Illustrations

Onelines are not just random illustrations.

The concept was based on the assumption that designing and developing software for a customer is a process that is most easily visualized by a line having its beginning and end;  just like in the case when our company conducts the client through the process of creating software from the beginning to the end. The line can have different shapes and noodles; it can also represent different problems that we encounter as a team. But in the end, we always get rid of them, making the line straight again and ending up with a desirable solution.

With only one line, the three-dimensional illustrations outline our ideas. Not to blow our own trumpet but we are the first who use this kind of illustrations and create them with great precision on such a scale. It’s something fresh and unique in our branch, don’t you think?

Website Design

All those elements are visible on our website. It’s clear and simple, but simultaneously has shapes and lines that make it unique. Combining linear illustrations with geometric shapes aims at joining the professionalism and modern style of the company.

We made it intuitive and suitable for every device, which may sound obvious but is still very much relevant. The biggest challenge for corporate websites is the amount of content. We overcame this problem by creating sections based on pictures and texts with a horizontal scroll.

The Reason for a Change

Change is a must in the IT industry. It is also said, that if you don’t change, you don’t grow.

After 8 years, we got mature enough to make such a bold decision and take up the challenge of rebranding. It’s another step towards our growth and a better future. The experience that we already gained and an exceptional team that we have, help us create products that make a difference and brought us to the point where we are in right now.

Inside,  iteo team still remains the same. And trust us: we feel that our current visual identity reflects who we are way better.

Welcome to the world, new website and new ID! Holla! 🎉

* Kudos to our awesome design and development team that made all of this happen!

7 Reasons Why Agile Sucks

Let’s be honest: at this point everybody and their dogs seem to be Agile. Almost every single software house and digital agency work accordingly to Agile methodology.  There are tons of conferences about Agile, workshops about implementing Agile into your working routine, there are Agile Coaches, Agile Masters and Agile Gurus – so it’s obvious that you want to be Agile, as well (although last yoga classes gave you some doubts).

With great popularity comes great critique. A lot of people wonder: is Agile as effective and useful as everyone seems to think? As we have a lot of experience working in this methodology (more about Agile as our development and design approach here), we can tell you for certain: it’s horrible. Here are the reasons, why:

1. You can’t swim in the ocean of paperwork anymore

Agile manifesto tells it upfront – it favors working software over comprehensive documentation. Working accordingly, you have to deliver only value-driven, business-beneficial documentation, focused on what’s really important for the project.

There is no place for the wonderful, time-consuming and work-blocking paperwork, no time being wasted on ineffective communication blocked by unnecessary documents. It’s horrifying. Because of that, we have more time for the development itself. Who wants that? Not to even mention the fact that our office shredder starves to death.

2. You can’t be unpleasantly surprised with final product anymore

Because of the meetings, sprint plannings and stand-ups, you know about everything that happens in the project. What’s worse – you can even intervene! Your feedback can be incorporated into future iterations. Misunderstandings and misconceptions can be recognised very early. You have the power to make revisions. Your requirements can emerge as your project grows.

Agile deprives you of the enjoyment of being disappointed with the final product – with properly executed Agile process, you end up having exactly what you wanted. It’s such a turnoff.

3. You have to be engaged and up to date

Working in Agile, you are not an employer that commissions work to be done. You are a part of the team. You see the work progress in full transparency and are able to check whether everything goes as planned.

That shouldn’t be the case. You should be able to experience the anxiety of uncertainty what is happening and whether the end result will be exactly as you expect. The sense of the ownership and control is definitely not something you want, right?

4. Each Sprint will bring you another mockup or Beta-version to review

Agile processes are based on an idea of working in recurrenting circles rather than in subsequent phases. Every Sprint is an integrated work of each team involved (Development, Design, etc), output of which is a part of product, prepared to be potentially delivered. This doesn’t mean that the product has enough value or marketability to be released, but that all the work that needed to be done for the currently implemented features has been done.

No one wants this kind of flexibility. Any releases should occur exactly on the date planned at the very beginning, no matter the state of work, how polished the product is and how many changes you would wish to make. Who wants to focus on sufficient functionality when you can focus on rigidly set time frames?

5. You are forced to do faster review cycles

Agile encourages you to contact your business partners regularly. As the whole process depends on cooperation and commitment from both sides, the more responsive you are, the faster the project occurs. Agile values comprehensive reviews and addressing issues as soon as possible.

Results? No one wastes time waiting for the response, everything is done on time. Once again: in a sneaky way you are being deprived of endless email exchanges, not to even mention that rush of adrenaline when you wonder whether you will get the response today or not. Those damn daily builds and constant checkups ruin everything. It used to be so much more fascinating with that constant uncertainty!

6. The risk of earning money rapidly increases

In Agile, you, as a client, are able to choose the features we should focus on. Basically, you determine what’s most important for your business.

Talking on our behalf, we are always doing deep market research, serving as advisors and validating our clients’ business ideas. It essentially means that we not only take care of raw code, but also make sure that all the functionalities suit your project’s idea, are economically viable and will make your product truly attractive. That’s a very Agile characteristic, as Agile always prioritizes real value.

It’s really limitating. Working this way, you deliver only things that have a chance to succeed on the market. That shouldn’t be the case – money are bad and you shouldn’t earn them thanks to your hard work on an innovative project. Period.

7. Your product may succeed, which means more work for you

Remember, when we talked about testing your idea by developing an MVP? The general conclusion was that no matter how great the idea is, users can love it or not – even the most experienced inventors cannot fully predict their target’s reaction. Maybe you are trying to solve a problem that doesn’t even exist? There is a difference between being confident about your concept and blindly believing that it has no flaws and people will love it instantly.

Agile is keen on the needs of real users. As it is so flexible and gives so much space for making changes and incrementing a feedback, it provides an opportunity to do a lot of testing and reviews. Agile encourages you to be focused on what your target group really wants, so, once again, you deliver real value, not just a software.

As a result, you get a product your users can really benefit from. Why would you want it, though? It rapidly increases your chances to succeed on the market, so may bring your project much more popularity, wider audience and bigger income and, eventually, more work for you. Disadvantage after disadvantage. Think twice if you can handle it.

Praise of agility

As you have probably already noticed, this article may contain trace amounts of irony. We’ve been working in accordance to Agile methodology for quite some time now, and we truly know its pros and cons very well.

It’s not a faultless way of delivering a project, everything depends on how well you adapt it. You have to really understand the fundamental concept and take time to implement it, which most definitely isn’t easy. Not every work culture is ready for it. It may be challenging (especially with bigger projects), it may seem like it lacks predictability, it requires a lot of commitment and honesty. However, in our humble opinion – it’s totally worth it.

It’s not about emotional attachment to the famous buzzword. It’s not about following a given guidance religiously. It’s about incrementing good, logical practices that basically should be common sense based. Staying in touch, accepting the need for changes, reviewing what was done, focusing on real market need – if we take away fancy names and big words, we’ll see a reasonable way to deliver a successful product. That’s why all those companies are so onboard with it, not because it looks good on their website under the tab “Approach”. It’s a powerful tool for software development that helps to deal with many common obstacles, following understandable values – as little, and as much as that.

Submitting an App in App Store

After creating your mobile product in cooperation with your digital partner, you probably wait impatiently for it to be available in App Store. However, Apple’s ecosystem is very peculiar and knowing certain mechanisms and methods may save you lot of time and nerves.

As we have assisted many proud clients in that process, we wanted to  share our experience with you and give you some tips and tricks for going through app review and making sure your product will get well-deserved exposure, so that users will find it easily.

1. User roles

Let’s begin with the user roles that determine which tasks you can perform in App Store Connect, platform that allows to upload, submit, and manage applications.

Basically, every person involved into submitting an app into the App Store has a function that is associated with specific tasks and constraints.
We have Admin, Legal (Team Agent), Finance, App Manager, Developer, Marketer, Sales, Customer Support and Reports. The last one isn’t assigned, but belongs to Admin and Legal by default.

Talking on our behalf, it’s always the client who holds an Admin role. He is also the one managing role distribution between project members, which usually depends on company’s policy. The most important thing to remember here is that you have to be at least an App Manager to submit an app and its new versions.

2. Adding new app in App Store Connect

Actually, adding your product to the App Store can be quite exciting. If you spent months carefully establishing your idea, and then watch it become a clickable solution, you most probably enjoy talking about it. Well, App Store is there to listen.

You begin with:

Platforms: In most cases it will be iOS – unless your product was created for Apple TV, then you choose the tvOS platform.

Name: The official name of your app as it will appear in the App Store.

Primary Language: This should be set to the language used in your app – if your project is in your native language, it should be selected here.

SKU Number: A unique identifier for your app that is only used in reports.

Bundle ID: Here you should select the ID that uniquely identifies your application. Usually you use reverse domain name notation for choosing an application’s bundle identifier. Once it has been selected, you will be unable to change it for this app.

After approving entered data, you will be able to add more information about your product. However, you want to submit a whole application, not just an empty shell with a fancy description – that’s why now the chosen member of your development team will submit a build.

3. Submitting a build

First of all: what even is a build? It’s a pre-release version and as such is identified by a build number, rather than by a release number. Before official version release, developers may work on multiple builds.

You don’t have to worry about submitting a build – your developers will do it for you – but important thing to remember here is that the processing will take a while. A singular build issued for iTunes Connect testing needs a dozen minutes to half an hour to be accepted.

Your developers will submit the build using XCode or Application Loader, but your field of interests narrows down to iTunes Connect.

Obviously, the build has to be fully processed to be submitted. However, in the meantime, you can safely enter the rest of information needed. Let’s talk about the views first.

4. Screenshots

Picture is worth a thousand words. No description will catch your user’s attention better than alluring screenshots of your product. They allow users to get familiar with your product and decide whether they are interested in it or not. Their attractiveness often determines the answer. You can read more about great screenshots for App Store here.

Talking on our behalf, we always make sure that screenshots we provide for our projects are suited for success – we make sure they not only show app’s core functionalities, but also highlight product’s best sides.

You can add five screenshots in total and in most cases its best to add as many as the App Store allows. You submit them for a 5.5 inch display by default, so the screenshot size equals 1242px × 2208px. Required pixel density equals 72 dpi and the file format should be PNG or high quality JPEG.

You can also add screenshots dedicated for iPhone X display (5.8 inches, so 2436px × 1125px, doesn’t have a frame around a screen), but it is not necessary. The only mandatory size is 5.5 inches and App Store will calibrate the views for every other screen size. Depending on user’s device screen size, he or she will see screenshots calibrated for his smartphone.

5. App description & other information

Now you can add all the additional data that will allow your users to get to know the product better.

It it supposed to be engaging, yet short and informative. The best practice is to begin with highlight of application’s main function, followed by short list of its features.

Remember to use a tone of writing tailored to the overall image of your company and use terminology your potential users are familiar with. Take a moment to think-through to whom you target your product to and match your style of writing to the way your recipients communicate.

Once you submit a new version of your application, you will be allowed to update your description.

Things to leave behind while writing a description? Definitely unnecessarily added keywords – they won’t improve search results, the place for keywords is somewhere else. Also, don’t talk about pricing here, there is also a whole separate section just for that.

Those are the words that help to find your app in the store. They are limited to 100 characters in total.

Important thing to remember: improper use of keywords is a common reason why app can not make it through a review. Avoid using unauthorized use of trademarked terms and other protected words and phrases, terms that are not relevant to the app, competing app names, as well as any offensive or vulgar words.

To maximize the use of keywords, avoid plural forms of words you have already used and duplicating words in general. Also – you are in App Store, the word “app” won’t be necessary.

Support URL
It’s a link to a page that belongs to the developer. It allows users to get in touch with the app creator if they experience problems or have any questions about the application.

Marketing URL
It’s a link to a page dedicated to marketing activities of the app – speaking shortly, your product’s web page.

It’s an information about who holds the legal rights to the app. You should also include contact details, in case someone needs to contact you about legal issues.

App Icon:
It has to make a strong first impression. It’s the first thing your potential users will see, so it has to visually represent your product.

Designers from your team will do their best to create a perfect icon for you – and as for its technical side, it has to have sizing of 1024px × 1024px, RGB color space and can’t contain the alpha channel (which allows pictures to have transparency property)

The number of app’s official releases. If you submit the first version of your product, it will be 1.0 for now.

Age restrictions for your app’s usage. You have to answer a few questions regarding application’s content (violence, nudity, gambling, etc) in order to define whether your product is allowed for young and sensitive audience or not.

Be sure to select a primary category that best describes the main function of your app. Remember – primary category determines your product’s visibility.

6. Going through the app review

Every single app submitted to App Store is being manually checked and reviewed by a dedicated person. Yes, you have read it correctly – every single app out of around 2 millions that are currently available in the App Store. That’s impressive, you have to confess.

Why am I telling you this? Well, information you will add now will be addressed directly to your reviewer. So it’s very important to treat that section seriously, as it is in your best interest to go through a review as quickly and easily as possible.

Contact information
It’s there for the reviewer to be able to contact the person responsible for app development in case of any troubles or misunderstandings. Typically, it is the person that has been given the Team Agent role in your organization. All fields are required to be filled.

Very important and often underestimated! You can add here any notes for the reviewer, for example explain or draw attention to some elements of the app. It builds trust and decreases the chance of rejection.

Demo account
If your app requires creating an account and logging in, here you should include login data. This is the user account that reviewer will use to log into the app and check its functionality and viability for the App Store.

Version release
Here you determine whether you want your app to be released right after being accepted by a reviewer, or if you would prefer to do it manually. By default it’s being released as soon as possible (“Automatically release this version”), but you can make it available from a certain date, or choose to do it entirely by yourself.

Version information
If this is the first version of your application, you leave it blank – however, when you update your product, it’s best to inform your users what was updated and why.

What else you should know about the review process?

Once again: every single app is reviewed by a dedicated person, so it can take a few days. Here you can find a website that will show you current estimated time, based on recent reviews.

Review time depend on how complicated your product is, how many functionalities it has and how many things reviewer has to check. Keep that in mind.

Reviewer’s opinion isn’t final and irrevocable. You can always appeal against his or her decision and even arrange a phone call to discuss it.

Notes for reviewer can be a make-or-brake! Sometimes the problem app reviewer encounter can be trivial and can be easily explained. Here is an example from our experience: one of our projects included recording a video, but it was supposed to work in landscape view, so when reviewer tried to test that functionality with phone laying on the desk, gyroscope didn’t react and video couldn’t be recorded. Reviewer thought the app was damaged, while it wasn’t and the situation could be easily prevented by adding the explanation in the Notes field.

Reviewer does not only check the smoothness of operation of your product, but also if it contains any inadequate or offensive content. So it’s important to be honest when choosing the app’s rating.

7. Pricing and availability

Lastly, you have to choose whether you want your app to be available for free, or to charge money. In order to do that, you choose the pricing tier (you can read more about pricing tiers here) and it will be automatically converted into your currency.

Then you have to choose the availability option – you can give a discount for educational institutions or choose app to be available only privately – and finally, you are all set and done.

Now you only have to click “Save” and then “Submit for review” – and wait for your beloved product to hit the shelves of the App Store.

Good luck!

Starting a Digital Project

Last time we answered some questions we frequently get prior to starting a project (you can read it here). This time we will talk about the issues that bother you when the project actually starts.

We talked with one of our Project Managers, and thanks to her experience, we gathered the list of five things clients often want to know, are unsure of or get mistaken.

Without any further ado, let’s begin!

1. Can we combine the work of two teams?

There are situations when clients have, for example, their own backend team, but need an agency to develop the frontend part of the project. Quite often they wonder if it is even possible to combine their work – and whether it will be an effective cooperation.

We are here to explain: of course we can – whether there will be two separate teams or more, everything boils down to clear agreements at the beginning and willingness on both sides to cooperate with each other. Of course, it’s much easier when both teams work in the same methodology – and that leads us to another issue…

2. Can we combine the work of two teams with different methodologies (Agile and Waterfall)

Sometimes our clients work in different methodology than we do. We work in Agile, and to be more specific – Scrum. It happens that the other team we work with on a particular project work accordingly to Waterfall methodology. We talked about both methodologies in the previous part of the article, but basically Waterfall means working in a  chronological order: first the concept, then design, development and testing, while Agile follows an incremental approach.

What happens then? Well, we have to make an effort to create a hybrid of both. It’s relatively easy when it’s only a communication hybrid, like leading the project in Scrum but creating the project plan in Waterfall. A more difficult situation occurs when we have to combine two separate tech teams, one accustomed to typically corporate processes at client’s, and Scrum-befriended developers in our office. Nevertheless, once again – clear agreements and willingness to cooperate always save the day. We are able to make things work as long as both sides are compatible and affirmative.

3. Is Time & Material a way to go?

Lots of our clients have this misconception in mind that Time & Material is an unpredictable monster that will suddenly swallow all their budget. It’s most definitely not.

T&M is a financial summary method where customers are charged for the exact amount of hours spent on a specific project and the costs of used materials. It has a lot of advantages, most significant of them being its flexibility, so important in Agile methodology. It is really great for long-term projects with dynamic requirements and when the scope of the project is not fully known from the very beginning.

Having a fixed price model is actually quite risky, especially when the scope of the project occurs to be not specified enough. Why change requests happen? Because very often in the process of estimating, the scope is not detailed enough or client is unsure about many issues. In the process, it happens quite often that either something turns out to be impossible to be done, or client changes his mind or would like to add  a new functionality. Such changes are treated as a change requests (CR), and it means expanding the scope of work, which results in costs increasing. In pretty much every fixed price project, change requests happen on a daily basis and in the end it becomes clear, that the scope and budget have changed significantly. Nevertheless, clients still prefer to have their budget rigidly specified from the start.

Is there an actual reason to be afraid of T&M? First of all, it isn’t true that in T&M you have no estimation. There is one, but it is much rougher. You can, for example, determine your maximum budget.

Secondly, you agree on the hourly rate before the project even begins. When you work in Agile, you are a  part of the team and therefore you are present at every sprint planning (every week, every month, as you will). Every task is estimated separately, which means that you can clearly see the price of every sprint – and even invoice every one of them.

In practice, you have a lot of control over financial issues in T&M. We give our clients access to JIRA, a tool we use to manage projects and track errors, in order to be fully transparent. Thanks to that, you can clearly see, in every single moment, how many hours every person involved has already worked, and how many hours you have “left to spend”. That gives you a great sense of control over the money flow. If you see that your budget is about to end, you can decide whether you stop the project, make it simpler or maybe look for funding.

The more unconventional, personalized things you are doing, the more use you find in T&M. Once again, you are the part of the team now – we have a common goal.

4. Why do we suggest another technology?

Sometimes things change. The project that was meant to be simple succeeded so rapidly that now you want to expand it and create something bigger out of it. You want some new features and functionalities – but the technology in which the app was created is simply not enough. It can not support your needs anymore and that is the harsh truth.

In this case, we may suggest you to rewrite the whole application in another technology. It is not an easy decision, so we will consider it carefully. We will talk about advantages and disadvantages of such decision, about features we can move to the new version of the app, define what will change, what we will be able to add, how it will convert into money, and so on. If we are developing a project from scratch, we always advise you to settle on a technology that will assure you with great scalability, instead of a temporary solution that only  ends up being a fancy facade. Unless you want something very cheap very fast – but then we make sure you are aware of the consequences.

Another case is when customers want to expand and build the same app in another technology – they have Android and want iOS as well, or the other way around. It’s not just an “update” or “additional feature” then, but a whole new project, developed in another technology, by another team, and with corresponding costs involved. It’s important to keep that in mind.

5. Why do applications need to be maintained?

We talked about it in one of our previous articles – maintaining is caring. It’s important to understand that the process of maintenance isn’t about sitting and watching the grass grow. It is the continuous control, checking, trying, changing, receiving feedback and reacting to it.

One of the aspects which cannot be stressed enough is the initial testing. Clients do not always realise how essential is their feedback in the first weeks. Before the product is officially launched, the client is obliged to test it, report every encountered problem and inform about any observation or opinion he/she has.

Of course, the agency has a whole team responsible for QA and testing – an extremely important but time-consuming and sometimes really frustrating process of finding any errors in the product. Later on, the client also tests the app on testing servers in order to see if everything meets the expectations. Our process of QA is inscribed into the standard of our services. That’s just the way we create software – solid QA is  an obligatory part of it.

However, there is a difference between testing environment and real world. You can’t predict everything, especially when it comes to Android – there are simply too many devices with it and too many versions of its operating system. That’s why initial testing, that comes right after, is so crucial. Nothing will go to the final production and distribution without the client’s official approval. Of course, the agency is responsible for fixing any bugs that are found during the established maintenance phase, but many of them can simply be avoided thanks to aforementioned solid initial manual testing.

#Iteoviduals #9: Wojciech Warwas

1. What made you join Iteo? Tell us your story!

Before I joined Iteo, I worked for another company for a year. My job was to develop and maintain their product, which was really fine, but after some time I found my work to be very repetitive and rather monotonous. Moreover, I worked with only one more developer (who also came to Iteo later on – Andrzej Nowak, Android Developer) and I wanted to be a part of a bigger team. I needed more challenges and wanted to work for a software house, where you have a chance to work on multiple projects, and therefore, a wide range of functionalities.

What’s funny – I really didn’t want to end up sitting in front of a computer! I studied medical enginery, so I was taking care of computer tomography, magnetic rezonanses and ultrasound examinations, but as the days passed, I found myself more and more interested in programming. During second, maybe third year of college I started working as Android developer (to be honest, I was more of a full-stack, as I was taking care of the backend as well). Then I decided to study Informatics at The University of Bielsko-Biala.

I have chosen Android development because I find it to be very challenging – you have to remember about smartphones’ limitations, such as capacity of RAM and processor, or battery durability. I like my job to force me to think.

2. Do you remember your first day or first few days at Iteo? What was it like?

I remember that everyone was very absorbed and busy, because there was a lot of work to do. I was supposed to take part in a new project so I sat down with my new teammates to ask them how they code, what are the standards here and how I should start.

I can also recall that I got a very peculiar task to write a representative piece of code for our potential client from America. They wanted to start cooperation with us depending on whether our code would impress them or not. Not going into the issue of the project itself, they liked the piece of code – and I was beyond happy, and to be honest, relieved. It was quite a challenge for a first day at new job!

3. What is your biggest professional goal you would wish to achieve?

I would like to be a part of a widely-known development team. The team that not only works their best to achieve a certain goal, but is also appreciated and recognizable. I want our team to reach that level, so the name “Iteo’s Android Team” will be a synonym of highest quality and the most innovative solutions. And I’m not talking about certain members, but about a whole crew. Teams like that have strong culture, their opinion is respected in the industry and their solutions are being adapted by others as well.

I think it’s a goal that can be achieved. Our Android Team is full of great developers and we are constantly working on things such as internal communication and organization. We organize our own meetups and are planning to do much more, though I will keep it as a secret for now (laugh).

4. Say the first thing that will come to your mind: Who is your biggest inspiration?

I always felt a lot of respect towards Brian May. He is best known for being the lead guitarist of Queen – but he is also a doctor of astrophysics. A highly educated man of science who is also one of the best guitarists in the world – now that’s something extremely impressive and truly inspiring. You don’t have to dedicate your whole life to one thing – you can develop in many directions and take advantage of many opportunities. Of course, you can’t exaggerate, because if you are good at everything, you are good at nothing, but being open-minded and having versatile interests is always an advantage.

I’m very fond of Android development, but I’m also a lighting technician and in my spare time I play the guitar and sing in a rock band. I don’t want to put myself into one box!

5. Who did you want to be in the future when you were a kid?

An Astronaut! Space was always something amazing to me. Not only the flights, but also the fact that those people carry out researches that allow our science to develop. It’s incredible that a few people can do so much for the entire mankind. And to be somewhere no man have ever been before – and where no man can stay permanently – is really fascinating.

6. If you were a fictional character (from a cartoon, movie or game) who would you be and why?

I would like to be a Superman, because he can fly into space! Generally, flying and shooting a laser with your eyes would be dope (laugh). Or I could be a rockstar. A superman who plays rock-and-roll, yeah, that sounds good.

7. Imagine you are on a desert island. You can choose one person from the entire team to keep you company. Who would it be and why?

It’s really hard to choose one person, for I would prefer to take whole Android team, or better – the whole Iteo team. Things that look impossible when you are alone may be easy to conquer when you have a good team behind you.

We have specialists in so many areas – Andrzej (Andrzej Nowak, Android Developer) for example is that type of an engineer that can do anything, from disassembling a tractor to programming in many languages. Marcin (Marcin Jasiński, XYZ Developer) plays the trombone (and other brass instruments in the Orchestra)  and Piotrek (Piotr Guzia, iOS Developer) plays the clarinet. Jakub (Jakub Stolarczyk, Android Developer) records and edit movies. We wouldn’t be bored at all. In the worst case scenario we would just organise day of programming on the beach, powered by solar batteries – imagine what a great advertisement that would be!

8. The most important question: iOS or Android?!

Personally, I prefer Android. But I think that if I wouldn’t be a developer, I wouldn’t limit myself to one operating system. In my opinion, everyone should at least try both of them, get to know their pros and cons and choose the more suitable option. I think that both iOS and Android aren’t perfect – and once again, I don’t want to limit myself and I simply use what is more useful to me at the moment.

7 Questions On App Development

Our Sales Team gets tons of messages every day. Before any project begins, our potential clients ask a lot of questions that we are always happy to answer. We gathered the most frequently asked ones and decided to answer them in order to help you get the idea of what  the collaboration looks like before we start our cooperation.

Of course, the answers are very general – we get into details during personal talks, depending on your needs and expectations, but we hope that those below will clear up a few things, explain some most common misconceptions and help you make up your mind.

1. Why does it cost so much?

Let’s put it straight: mobile and web solutions development seems quite pricey on the first glance. I mean, downloading an app from the store will costs you 88 cents on average. Yeah, not even a dollar. So why is its development so expensive?

Firstly – it’s not just about the code. Your application needs design, and if you want something more complex than a plain calculator, then also a backend part with a server, database and API. It’s not one person that does that, but a few experienced teams. That complex process typically takes up about three months up to half a year and requires stages of architecture, schematics, design, building launching and maintenance.

Secondly – the species of applications are very diverse. Some functionalities are easier to do, and some require more time, energy and resources. You have to trust your team when they estimate the time of a certain sprint in a project because if they say that a particular thing will take three weeks to develop, they do it based on their past experience. That’s where it is important, once again, to choose an agency you trust – it will definitely save you a lot of unnecessary frustration. Trustworthy agencies are transparent and will do their best to explain the time estimation.

Lastly, to put it simple – it’s truly the talent that costs the most. There is a high demand for mobile developers and designers on the market, and though you can find many of them, it’s much harder to find someone both experienced with developing solutions on a enterprise level and up-to-date with a particular technology.

Both design and development are rather easy to learn, but very hard to master, so it’s obvious that experienced team will cost you more.

There was an article lately that went viral, with the intriguing title of  “Why Outsourcing your IT to Poland Will Ruin Your Life”. We recommend you to read the whole piece, but the main point is that most people that decide to outsource to Poland are amazed with the outrageously high quality of our IT services, especially in combination with its relatively low prices, high reliability and communication ease. Thus it’s possible to find an inexpensive agency with both quality and quantity, and for that case, look no further than polish outsource.

2. How much time does the development take?

If you want the short answer – developing a medium size mobile application for one platform usually takes about three months. That’s the average timing, but of course, everything depends on various factors, such as number and complexity of functionalities, flow of the cooperation, chosen technology, and so on.

In app development, time equals money. Quite literally, if you pay for the project in Time & Material model, where you pay for the exact number of hours your contractor spends on your project. You get your first estimation before the project even begins, you specify the price per hour, and you are present on every sprint planning, agreeing on the number of hours needed to fulfil every particular task (of course, as long as your agency works in Agile methodology).

Nevertheless, things happen. Major changes commissioned for the last moment lead to delays, especially if the development team is big and consists of  few different technologies.

There is also a misconception that increasing the number of resources – meaning: asking for more developers added to the team – will solve the problem.

It may work for projects with fixed price contract, but in Time & Material adding new team members is far more difficult and affects the final estimation.

Have you ever heard about Brooke’s law? Fred Brooks, famous software engineer and computer scientist, published a book in 1975 called “Mythical Man-Month: Essays on Software Engineering”. It’s central theme is that “adding manpower to a late software project makes it later”. In his honesty, Brooke points out that “nine women can’t make a baby in one month”, which is now widely known as a humoristic but very real summary of this management misconception.

It takes some time for people added to a project to become productive. Each new worker has to become familiar with the project, its process and already used solutions. Moreover, the more people there are, the harder it is to keep them in sync, so the communication is getting more and more difficult. When you work in Agile, the more people in the project, the more hours you have to spend on daily (or weekly, or monthly) meetings, demos, retros, and so on. Besides, some tasks aren’t divisible – or it is simply unprofitable to divide them.

3. And what about technologies?

Every agency has specified technologies they use and are most familiar with. You can find out what they are on the agency’s website if you are looking for a particular one. Some of our clients have technical background as well, so they come to us with a prepared plan.
However, most clients know on which platform they want their app to be, but don’t really care about language or framework, as long as it doesn’t affect their vision of the product – There are also clients that don’t have any technical background at all. It’s also perfectly fine, you don’t have to be technologically-oriented, it’s our job to analyze your idea and serve as tech advisors.

Things look different if you are looking into developing an existing project – then the technology depends on what was already used in it. A similar case being when you have your own team to support the app after the agency develops it – then you obviously have to make sure the technology matches.

Will the agency interfere with your technological choice? Well, talking on our behalf, depending on your needs and project’s idea, we may suggest you to re-think your decision.

There are many factors that influence that – it may be because we know something will suit your project better, that the particular technology may be hard to maintain or that another type of application (native, hybrid, or web) may serve you more effectively. For example, you may want to have your app done in React Native (which is a hybrid), but at the same time, want it to have many native functionalities. In that case, we can prepare a rough estimation for you, and it may turn out that the price of such a complicated hybrid will be relatively similar to the price of two native apps. That will give you some perspective and food for thoughts, and together we will be able to choose a better option (by the way, you can read more about the pros and cons of native, hybrid and web apps in one of our previous articles).

Moreover, there is a tendency in app development for trends to come and go. How many articles beginning with “(Insert technology name here) is the new best thing and will change development world for good!” have you read in your life? We’ve heard that Phonegap will be revolutionary, we’ve heard that Xamarin will reach the entire mobile market, we’ve heard that React Native will dethrone native apps. Arguments are usually very similar – that given framework or technology will be cheaper and easier in development, it will replace the need to develop separate native applications and generally end world hunger. They are new, flashy and impressive but in most cases – only on paper. They are usually good solutions, but not really that revolutionary, and most certainly don’t live up to the expectations. They won’t necessarily solve your problems and meet your needs, so it’s better to trust your agency’s advice rather than chase the newest flashy thing everybody seems to praise.

4. What’s your design and development approach?

We work in Agile methodology, as most of development agencies these days. Agile is a famous buzzword, but what does it mean exactly?

Well, before Agile became such a standard in software development, most of us worked in Waterfall system. Waterfall means working in a chronological order, just as you may imagine the creation process – first the concept, then design, then development and then testing. Sounds perfectly fine, but as this process is sequential, you can’t really provide any changes after one step was completed. You have to be very careful in planning the whole process because one little misconception or misunderstanding may lead to a complete disaster.

On the other hand, Agile is a methodology that follows an incremental approach. It prioritizes the unceasing contact between client and agency, to the point where the client (product owner) becomes the part of the team.

In Agile you work in sprints. At the end of every sprint, project priorities are evaluated and tests are run. That allows any troubles to be discovered quickly and customer feedback can be incorporated into the design and flow before the next sprint is run.

Scrum is an iterative and incremental agile software development method for managing software projects and product or application development. So Scrum is in fact a type of Agile approach which is used widely in software development. Scrum gives you a very clear demonstration of the effectiveness of your software development practices.

If you want to know more about what Agile truly is and how to implement it successfully, we recommend you to take a look at John Cutler’s take on it.

5. Doesn’t outsource equal communication problems?

That’s a big question many ask loudly – and the rest asks in their mind: can we trust a team that is a whole continent away?
Truth being said, with all the technologies that allow us to communicate with anybody, anywhere and anytime, you would think that there shouldn’t be a trust issue anymore. Unfortunately, some clients had some really unpleasant experiences getting their products done at the cheapest abroad agencies. That created a lot of unnecessary distrust and evokes stereotypes about outsources till this day.

How do we deal with such a situation? First of all, in the Internet age, we have so many tools we can use to communicate, like Skype, Google Hangouts, Slack or Basecamp, not to even mention, a simple phone call. Agile methodology we use requires staying in touch all the time – weekly and monthly sprint planning are only a part of it. Before the project even begins you can get all necessary information and insights – on the calls, both technical ones as well as business oriented, even take the effort to meet you in person if you are sure you want to cooperate with us.

Honestly, everything depends on the commitment of both sides and their willingness to cooperate. We’ve had a lot of clients from completely different time zones – some of them were twelve, thirteen hours apart of our time.

The trick is to agree on the contact conditions at the very beginning of the cooperation and stick to them throughout the duration of the project.

Another crucial point is to choose and clearly determine the decision-makers on both sides. From our side it’s Project Manager, from the client’s side its Product Owner (sometimes the CTO)  – determined to be a spokesperson for any significant decision. Overall, you can truly do everything with your outsourcing agency, as long as both keep a professional approach and willingness to cooperate.

6. Are there any limitations when it comes to the things we can develop together?

Technology is amazing, but not limitless. There are things you simply cannot do – and even more things that are not worth the effort needed to get them done.

As we already stated, you have to think about applications as about answers – if users don’t ask the question, there is simply no need for it – and it won’t succeed, even if done perfectly.

Some clients have really uncanny ideas for their apps – and right away, some of the agencies do not want to get involved in them, which is really uncool. We prefer to invite our potential clients for workshops and then talk about their idea deeply, analyze it, work it through and come to the conclusions together (you can read more about workshops in one of our previous articles). We treat every client and every idea very seriously, so even if we are not sure if the idea will work in practice, we suggest creating an MVP (you can also read more about this in one of our previous articles) in order to see if that is the case. We want to be your business advisors, as we already have a severe experience. However, the last word is on you.

Why would we choose you?

That last question we get pretty often and it is the most personal of them all. Let’s be honest, there are many fishes in the sea. Every agency can say that they provide the best services, but words are only words. You need more proves and ways of measurement.

It’s where all the plebiscites and lists of the best come in handy. Unfortunately, they are not always completely honest and in some cases, simply consist of only those companies that pay to get there. Most reliable are portals like, dedicated to collect companies and confirmed opinions from their clients. Portals like that verify every rate, so you can be sure that if someone gives a good opinion, he really means it (and is an actually existing person, to begin with). It’s the customers’ opinions that matter the most, after all.

Therefore we find pride and satisfaction in our high rate on Clutch, but it’s not the only thing that may persuade you to start cooperating with a particular agency. Every single one of them is different – and some have exceptional features. There are as many value systems as clients, so a feature one will find useless, someone else may praise and be looking for. Therefore, a wide range of approaches is a really great thing.

As for us, we are often appreciated for our very human-centered approach, which basically means involving the user perspective in all steps of the process.

We want to deliver a solution that truly corresponds with user’s needs and requirements. We repeat it to boredom, but it’s true – applications are like answers, if users don’t ask the question, there is simply no need for it. We rely on years of experience, solid research, testing, observing and constant analysis of the outcome.

We also have something our clients like to describe as “project owner mindset” – basically we take care of every project we develop as if it was our own. We get fully onboard and start from checking out the industry we create the product for. We do our research, ask about many things, do the analysis. We get to know the culture, people, market and its whole environment and have dedicated people that take care of market entry strategies for markets such as the USA, Nordics, Germany and the UK. There is also our whole jazz about workshops, constant contact and serving as your business advisor instead of just being a conductor of service. That’s just the way we do it, and it can be clearly seen that our clients find it very helpful.

#Iteoviduals #8: Damian Krysta

1. What made you join Iteo? Tell us your story!

After I graduated, I was looking for my first job in the industry. It turned out to be a little challenging since even after a few job interviews, none of the offers looked really appealing to me. You know, when you begin your career, it’s hard to find conditions that satisfy both you and your employer. Fortunately, I found what I was looking for here at Iteo. It has opened the doors to IT industry for me.

2. Do you remember your first day or first few days at Iteo? What was it like?

It was simply terrifying (laugh). I have been thrown into deep water, working on a project since day one, and initially, I felt really overwhelmed. Fortunately, on the second day the rest of the team came over and while working together, it didn’t seem so hard anymore.
Looking from perspective, I know it was a simple project and that I was involved in order to show off my skills and to challenge myself. As soon as I stopped worrying so much, it turned out to be a great opportunity. I felt extremely motivated and treated seriously. Also, I really appreciated my teammates’ support – especially because half of them I knew from my college days! The atmosphere was phenomenal, I felt like going back to my studies (laugh).

Moreover, even before I officially came to the office on my first day, I was invited for the office bicycle trip. I had an occasion to get to know my teammates better. It also gave me an idea about how the after-work time at Iteo looks like.

3. What is your biggest professional goal you would wish to achieve?

Continuous self-development. I think there is no such a thing as “the pinnacle of one’s possibilities”. You can never rest on your laurels and say that everything has already been achieved. You can do anything really, as long as you are hardworking, up to date with everything that happens in your field, always curious and motivated.
I don’t really have any particular professional goal – I just want to do the best I can in the field I have chosen. I never stop searching and learning. I also invest my free time to improve, every day. I like what I do so I definitely won’t let it go to waste.

4. Say the first thing that will come to your mind: Who is your biggest inspiration?

I don’t have one person that inspires me – I get inspiration from listening to achievements of other people around me. For example, this weekend Mr Robert Karaś became world champion in Triple Ultra Triathlon. I’m also into running and I take part in events such as Runmageddon, so I think it’s amazing that a guy like me – even exactly from my country – achieved such a spectacular success.
I look up to people who have accomplished something and I try to observe what made them successful. I don’t tend to focus on a single person and rather learn from many people that follow their aims. That keeps me challenged and motivated. Maybe one day I will be the source of inspiration for someone? I would absolutely love that to happen!

5. Who did you want to be in the future when you were a kid?

I wanted to be Songo (the main character from Dragonball cartoon)! (laugh). And besides that, a firefighter. So you can say that I had pretty typical plans for a boy my age.
Later on, I became fascinated with programming. I got my first PC pretty late, but only after one year of using it, I went to IT school and started catching up. I found coding really fascinating, I was able to engage into a discussion about every single line of code! I consider myself a very lucky guy to be able to work in an industry I have so much fondness for.

6. If you were a fictional character (from a cartoon, movie or game) who would you be and why?

As I already mentioned, Goku from Dragonball. That cartoon marked me for my entire life (laugh). Even now I can be spotted in Dragonball t-shirt from time to time. When I was a kid I simply enjoyed the captivating action and flashy goings-on, appreciation for plot and characters came later. For now, I can’t say I’m a perfect Goku – first of all, he didn’t have such a round belly (laugh) – but I think I might get that idea of continuous self-development partially from him.

7. Imagine you are on a desert island. You can choose one person from the entire team to keep you company. Who would it be and why?

Will you allow me to give two answers if I explain them well? Yes? Okay, so it would be Michał Konieczny (Full-stack Developer) and Benjamin Rast (Frontend Developer). They are both such mood lifters! Even if something unexpected happens in the project, they always keep a calm and optimistic attitude. We would not only survive but also have a lot of fun. Moreover, they are my good friends and amazing developers who taught me a lot… So I would like to force them to survive the tortures of a desert island!

8. The most important question: iOS or Android?!

Weird question for someone who talks to you via Samsung! (laugh) Of course Android. Who would want to use a mobile phone that has a nibbled apple on it and, hence, is famous? It’s time to say “enough” to all those iOS-worshipping answers. We’ve all used Android at some point  – I don’t feel any need to change that state.