Principles of the Software Company Focused on Product Leadership

Say No, Stay Small, and Aim High.

It’s pre-holiday time — a time to draw the bottom line for the current year and make plans for the upcoming one. The New Year is often chosen as a magical turning point to give up smoking, take on yoga classes, or follow a totally new approach to doing things. We are publishing this long read to share some of the principles we stick to in flespi and how we feel they help us do the “right” things.

Company bio

flespi is an innovative brand within the Gurtam company developing a cloud backend solution for telematics and IoT. The flespi platform accelerates the creation of own telematics applications, integration with third-party platforms, and development of custom location-based services.


Let us put our business strategy upfront. It may help you understand the reasoning behind the guiding principles explained below.

We define it as product leadership which for us constitutes the creation of pioneering technologies, continuous improvement, and educating businesses on the best practices of their use.

If your company pursues another strategy, some of the below-listed principles will not apply or may not fit to what’s considered right in your company.


Isn’t it all about people, huh? A perfect plan will not complete itself anyway. We start talking about the team first since the subsequent sections will perceive the concepts here as a prerequisite. So no BS, let’s go straight to business:

  • No more than 10 people. Firstly, this is considered by many as the golden middle for the manager’s span of control. Secondly, internal communication among the team members becomes more intimate — you have a chance to closely familiarize yourself with what everyone else does whether at a weekly meeting (see below) or in a pub without it taking too long and without splitting into subteams (or drinking at different tables).
    We are a team of nine, BTW.
  • Static. Our team has had no openings for over a year and is not going to have any for at least another year. This means that everyone on the team is here long enough to learn all the nitty-gritty about the project, become independent and “infected”. As a side-effect, it allows us to have less internal documentation as everyone is acquainted with most common processes and workflows. It’s not to say that the docs are not important, it’s to say that in an intensive “startup mode” that we work in being able to do less of something is a blessing.
  • Multifunctional. Doing the same staff for the project for more than two years makes you an expert in the field but may also dim the excitement in your eyes and leash the utilization of your potential. That’s why we embraced the concept of a SWAT squad — when you change roles, challenge yourself, make yourself uncomfortable, and do everything. For instance, Jan, our developer, presents at conferences, communicates at exhibitions, writes articles, and is involved in sales and support. Yet he is still primarily a developer. 
    Of course, the degree of multifunctionality differs across the team depending on the tasks, personality, and project demands. But all of us dip our toes into this deep pond to broaden the professional horizons and feel ourselves in the colleagues’ shoes.


Engineering constitutes the very essence of what we do, what we focus on, and what we pride at. So, being crystal clear about what we do, what we don’t do, and how we go about doing what we do is crucial.

  • Architecture moderation. In the blue waters that we are navigating it’s easy to lose course being lead astray by the seductive naiads (aka genius ideas). We have to be vigilant to keep our eyes on the ball. Luckily we have a dedicated watchman (platform architect, project manager, visionary, developer, you name it). As a person who invented the concept of the entire flespi platform and who sees the big picture in detail, he looks at each suggested idea, feature or concept through the architectural prism to see if it fits in. A great feature requested by a client or suggested by a team member, no matter how cool it is, will be rejected if implies putting band-aids on the current processes or undermining the existing backbone. However, it in no way means that we do not listen (see the next bullet).
  • Proactive feature invention. We do listen. But we carefully align every suggestion with our core architectural principles — something that our users cannot do. The user wants to achieve a particular goal; the way in which we help them achieve this goal is not important for them but is important for us. 
    A lot of times we deduce the customer want and needs from communication without them saying it directly. And if we see the value and potential in the feature, we’ll schedule it for implementation.
  • No fear of change. To err is human. And quoting Rag’n’bone Man “we are only humans after all”. Occasionally we realize that we were going the wrong way. We don’t put up with this or turn the blind eye — we fix it. Even if it leads to a domino effect across the project. We want to be frank with ourselves and our users by doing the best we can to deliver top performance. No compromise here.
  • Dynamic priorities. Like most software companies we develop the product in iterations and prioritize the tasks. However, we allow the priorities to be flexible. Bug fixes and other urgent critical changes will always get on top regardless of the plan. Depending on demand or related tickets some tasks may become more important which raises their priority. Others may be reconsidered and assigned a lower priority based on the current state of affairs.
  • Stale tickets disposal. Some tickets may transition from one iteration to the other. If they do so for a long while (6–12 months), we simply get rid of them as useless (and rarely, if ever, regret). This greatly helps our developers to see the scope of work — not 200 raw tickets but 20 specific and topical ones.
  • Friday dive-ins. On Friday afternoons we all take seats in our cozy meeting room and have a friendly talk for 2–3 hours. Each team member goes over all the noteworthy things he or she was busy doing on a given week, answers any arising questions, asks for colleagues’ opinion about the bothering issues, and outlines the major tasks for the upcoming week. This is a perfect ritual for bringing everyone in the team on the same page.


Since we are creating novel technologies and concepts, we need to think about how our users will get their heads about them.

  • No reference manual. Probably not what you expected to see, but we are realistic about our resources and clearly understand that maintaining an up-to-date reference for such a dynamic project will be a nightmare. So, we went another way↓.
  • Lively blog. We write one or two blog posts every week. Set in stone. We are versatile — from deep tech and architectural long reads to more applicable connectivity and integration how-tos to birds-eye-view marketing and business reviews.
  • Knowledge base. This is a comprehensive guide for our users where they can get acquainted with the basic theoretical concepts, find step-by-step instructions for specific tasks, and learn about the most effective troubleshooting techniques. Knowledge base entries are inspired by questions from our users which make us type the same answers time and time again.
  • Tight intertwining. The pages of our commercial website, the knowledge base articles, and the blog posts are densely interlinked for seamless user navigation to the subject of interest.
  • Open-source projects. We are a for-profit business but we love giving to the community and sharing our technologies, ideas, and developments. We make some of the libraries we develop and use in our solutions as well as some auxiliary tools open-source and put them on GitHub. This way we want to build trust with developers considering to use the flespi platform by showing them some of its internals.


No product can stay competitive without proper testing. Flespi is no exception. This is a social responsibility to our users and a key component in fostering credibility and brand loyalty.

  • Part of the development process. We do not have dedicated QAs on the team. Developers are responsible for properly testing the features they work on.
  • Feature-by-feature coverage. Once a feature is developed, it should be fully covered with automatic tests. This is taken care of by the developer of the given feature as this person knows best the peculiarities and the possible variations in use.
  • Platform health check. This is a comprehensive test of the platform as a whole running every minute. This way we make sure all services are available and all functions are operable. If something goes wrong, the test will post a “downtime started” message into our SRE Telegram group (which any of our users can subscribe to); then the test will retry every ten seconds and will post the “downtime ended” message when successful. After careful investigation of each incident, we post its extended explanation to inform our users of the reasons and the steps we’ve taken to fix or prevent it from reoccurring. Openness is our approach to building trust.


Creation of innovative products goes hand in hand with the need to consult the early adopters on its most efficient use. We are regularly preparing new resources and introducing new ways of supporting users in their efforts.

  • Online chat. We developed it in-house and added only the features we need (e.g. quick access to the user account and logs). Clients can access it directly from their flespi admin panel. The time of the first response during our working hours is less than a minute. This tool is so much handier than the conventional email correspondence primarily because it’s integrated into the actual product and clients don’t have to switch tabs to initiate the conversation.
  • More attention to advanced questions. This may sound somewhat discriminating or unfair but we develop an advanced product, not a one-button app. Flespi is a toolkit for developers, so we cannot teach the basics. First, we don’t have the human resources to devote and second, our experience shows that such users rarely stay for long, so the efforts don’t pay off.
  • Saying No. This point is piggybacking on the previous one — we do not do anything for the users, instead, we teach them how to do in themselves. This is one of the cornerstone principles for us. We are positive that when the person follows the provided guidelines, s/he will internalize the information better and will learn the concepts deeper than if getting the ready-made solution from us. Yes, they may struggle, but this will make them better users next time.
    We are working hard to make the self-help process more flexible and intuitive by adding hints, expanding the knowledge base, shooting how-to videos, and putting together guides and checklists.

BDSM (Business Development, Service, Marketing)

Flespi is a Platform-as-a-Service solution and we are offering it as a monthly subscription. Below are some of the guidelines we stick to.

  • Online presence. Our target audience is mostly technically-savvy guys, so we are primarily relying on online marketing to build a brand recognized as an expert by the telematics community. We also show up on major industry events like GITEX, MWCA, CEBIT, etc. to spread the word, talk to the leads and existing clients in person, and show we are a reliable and “tangible” business partner.
  • Client filter. You can say we are picky. Yes, when it’s a pain for a client and a pain for us, that’s not leading us anywhere. The first filter is language — being an experienced developer in the world where all manuals and references are in English is nearly impossible without a decent command of English. We have all the websites and materials in English and expect our user to be comfortable using it.
    The second filter is expertise (see More attention to advanced questions above) — we are sure we can give more to clients experienced in the field. We are happy to guide novices but mostly with links to our articles and external resources.
  • No pushing. We do not use any of the “sales”-methods to market our product. On the contrary, we are double-checking the needs of our prospects to be a hundred percent sure flespi is the solution they need. Because if it’s not, they will be disappointed one day, will complain or demand something since the complexity of switching to another platform will range from hard to impossible. We will do our best to avoid such situations at all costs. Our goal as industry experts is to help the client find the best solution, even if it means advising a competitor’s product.
  • Price non-negotiable. Terms of use are explicitly outlined on our commercial website and are equal for everyone. This way we free ourselves from tiresome bargaining. If the user doesn’t realize how flespi can save them thousands, they might not need flespi at all.
  • Automation. We are trying to automate all recurring processes in the company — blocking, downgrading, and upgrading user accounts, invoicing, payment reminders, etc. — to minimize the human factor and to save time.
  • Fees on us. Currently, we accept only PayPal payments and pay all the service fees for our clients because we know how annoying it is when the service costs $100 but the amount due is $110. We respect our clients and want them to pay exactly what our pricing page says.


If you’ve read until this point, you might find some items to contemplate. We do not claim to have found a magic bullet nor are we going to submit our conclusions to the business textbooks. We just know it works for us and we believe it may work for others.

We are well aware of the ramifications of our guiding principles, so we’d be happy to hear your thoughts in the comments on which ones resonated with you, which made you shrug in doubt, and which made you frown in disagreement.