DEV Community: Yevhenii Kosmak

How to become a better Django Developer by doing a pet project?

Yevhenii Kosmak — Tue, 16 Aug 2022 16:23:44 +0000

My name is Zhenya Kosmak. Now I work as a product manager, but I have 3+ years of quite serious commercial experience using Django. And even now, I strive to code for at least 10 hours weekly. I deeply believe the best way to master any framework, Django as well, is to build a truly big pet project. So a few bits of my recent pet project experience.

The pet project's name is Palianytsia. It's a tool for enriching Ukrainian vocabulary and, generally, studying Ukrainian. Now, 2 months after project public launch, we have 200+ DAU (daily active users) across all clients (web app, iOS, and Android apps) and a sufficient audience (10K+ followers on Instagram). The back-end of this product is entirely on Django.

It must be noted that a great developer in the modern world couldn’t be imagined as a single player. Many tough challenges show up, particularly in teamwork. So it would be a rather more quality experience if you start your pet project with a team containing competent people for such roles as product owner, designer, and project manager.

Your pet project should solve a sufficient number of most standard back-end tasks. The tasks have to be real, not synthetical. Here are examples of how you can set them up.

Main feature

In our case, it was a search mechanism on top of ElasticSearch. We have a database of sentences from different sources, and the task of this API endpoint is to return the most relevant sentences for each query. We have additional aspects on this. The sentences must show different contexts in which the user's input was used. Also, the search results should come from various sources in order to include principally different ways to use the search phrase.

This task teaches you how to work with ElasticSearch, and customize its ordering. Also, you practice using DRF to build quality API endpoints here. If you want to obtain excellent documentation of such endpoints, you might use drf-spectacular or else as well.

Data collection

Django developer must be a Python professional as well. Not all the everyday tasks are covered with some Django libraries, but they still have to be solved. HTTP scraping is one of the most standard ones.

We needed to collect articles from 40+ websites to provide users with comprehensive examples of each word or phrase usage. So we've built some abstract parser classes for most routine needs:

BaseParser. We define general parsing logic here.
BaseFeedPaginationParser. We use it to collect article URLs when the website's feeds are paginated, i.e., the URLs of the feed look like https://example.com/feed/<page>.
BaseFeedCrawlerParser. On some sites, there were no paginated URLs; they had only infinite scroll or "Next page" URLs on each page. This parser works with such websites. Also, we use it for Wikipedia.
BaseArticleParser. This guy is used for collecting the content of each article.

Such class hierarchy was a definitely productive solution. After finishing work on these classes, developing a parser was mainly like writing a config file. For example:

class DetectorMediaBaseFeedParser(BaseFeedParser):
    start_date: datetime.date

    def feed_urls(self) -> List[str]:
        return [
            f"{self.base_url}archive/{d.strftime('%Y-%m-%d')}/"
            for d in date_range(self.start_date, today())
        ]

class DetectorMediaBaseArticleParser(BaseArticleParser):
    paragraphs_selector = "#artelem > p"

    def extract_paragraphs(self, dom: HtmlElement) -> List[str]:
        # Current markup
        paragraphs = super().extract_paragraphs(dom)
        if paragraphs:
            return paragraphs

        # Old br-only markup
        content = cssselect_one(dom, "#artelem")
        paragraphs = split_br_into_paragraphs_lxml(content) if content else []
        return paragraphs

You can only guess what a mess we could get if we developed each parser separately. It's also an excellent practice for requests, asyncio, or anything else you prefer to get the data from websites.

When you’ve made 40 similar scrapers from scratch…

This task also teaches you how to orchestrate those parsers. We had to gather millions of articles based on our estimates, and we wanted to be able to collect all data from all sites in 24 hours. So we have to use a tasks queue to ensure the solution is efficient and scalable. The most common approach on the Django stack is to use celery, but we prefer dramatiq as the most lightweight and still productive one. Bringing such a solution to a stable and scalable level is also a very effective way to improve your coding skills.

Last but not least, we need a state here. We have to save each gathered URL and article content after scraping, so we wouldn't lose the work results if our server crashes. And the content is stored in S3 Wasabi cloud storage. Here is your practice with PostgreSQL or any other RDBMS you'd like, and S3 as well.

Data processing

Okay, we have articles; what's next? We need a database of Ukrainian sentences split properly, with filtered artifacts (such as BB-code parts or broken HTML, which occurs on most websites), normalized (we don't need repeated spaces or else). As input, we have a PostgreSQL table with articles; each article is stored on S3 storage and split into paragraphs. So we've got such tasks:

Split a paragraph into a list of sentences. The job looks easier than it is. No way it's something like paragraph.split('.'), it's way harder. For some direction, you can look at this StackOverflow question.
Skip all paragraphs with mostly non-Ukrainian content.
Filter out trash content.

Let's add some 3rd-party tools

Sometimes when you want to say something in one language, you can only recall the word or phrase in another. So let's add Google Translate so that our users would be able to enter queries using any language, and we will search for translation in our database.

It's a nice opportunity to practice using dependencies (google-cloud-translate), storing credentials, and even developing a cache mechanic. The last one would be helpful to decrease the number of requests sent to the API so that we will spend less. By the way, if you send less than 500K characters monthly, you wouldn't even be charged with Google Cloud cause it's free under that limit.

And one more tricky task. The user searches a query. Should you or shouldn't you translate it? There are several ways to solve this issue. We decided to go this way: we stem and normalize all the words from the query, then we find all of them in our dictionary of Ukrainian words. We definitely shouldn't go for a translation if we found all of them. Else way, we better get it.

User-related mechanics

We need authentication, authorization, registration, password recovery — all that boring stuff.

It's a good chance to practice django-allauth, dj-rest-auth, djangorestframework-simplejwt. Remember such things:

Users shouldn't be logged out for no reason, so cookies shouldn't expire in one hour,
Their credentials must be safe, so that should be HTTP-only cookies and data kept secure on the server side,
All errors must be processed intuitively and logically, so the front-end part will be easy to develop.

Developing 3rd-party authentications is also a good idea for new technical experience. Adding Google or Facebook as sign-up methods might be a more intriguing task than you'd imagine.

Should we do some automated tests?

This many tests we’ve made!

Of course, we should! But please don't do it like your home assignment at university. Choose the most vulnerable parts of projects for future developer mistakes and cover them up. In our case, we made such:

ElasticSearch test for disk usage, RAM, and response speed. Actually, we did this before all else in this project as a part of the proof-of-concept stage. We filled the ElasticSearch DB with dummy data and used ApacheBench, and some write-only Python scripts to test the performance on the production-level server.
Performance tests on the primary endpoint to ensure we'll endure the load. These tests were added to the stable code base so that we could rerun the test when needed.
Unit tests for parsers, text processing mechanics, and string utilities. So that we can be sure that our technical solutions would be changed only in a conscious way.

Bottom line

Let's summarize. On such a pet project, you can effectively learn:

General business logic development. When you have a real-world task, the coding experience becomes more fluent.
Work with mainly used databases. Any project relies on them, so if your task is challenging enough, you may learn those well.
Task queues. They become vital just as you encounter any IO-bound, CPU-bound or high-loaded objective. Choose high restrictions, and you learn it well for sure.
3rd-parties. They are an integral part of any product. The more you learn, the better you're ready for the next ones.
Network libraries. Not to say vital, but an omnipresent piece of knowledge you'd definitely need. Any pet project will acquire your attention on this point.
Tests. Not homework, but real salvation of doing error twice.

It's almost the same as spending a year on a commercial project. But you can do it yourself, and if you are patient and stubborn enough, you can master it. So think about it :)

And the last thing. If you are thinking about something bigger than a pet project, you can talk with me directly or check out our cases on Daiquiri Team.

Alerting system and forgetfulness: benefits for the product owner

Yevhenii Kosmak — Tue, 26 Jul 2022 14:46:00 +0000

My name is Zhenya Kosmak, a product manager, and I wrote this article describing my experience as a Technical Product Manager. You can connect with me on LinkedIn if you want to discuss your project or anything related to this article. And I will be glad to share with you some pieces of advice 🙃

If your development team spent several thousand hours on your product and it's already in production, the issue of its stability is already quite significant. All services on the servers should work stable, and if there is a critical problem somewhere — the development team should figure it out and start fixing it. In this article, we'll talk about our experience setting up a Calibra alerting system. In this case, we have managed not only to ensure the technical stability of the product but also to optimize costs and improve our client's processes.

This article is a part of the cycle "Alerting system: why it's necessary both for developers and product owners." This article describes how the alerting system might come in handy when it's hard to keep everything close at hand.

To make understanding the problems we solved easier, we need to tell the essentials around the product. Calibra is a BPMS, i.e., a system that covers most of our client's workflows. The client's company managed numerous advertising campaigns for their clients in their interests. The client's company earned from each lead they brought. Calibra managed the accounts from which the ad was launched; all advertising settings; automatically changed the ads; collected statistics on the effectiveness of advertising, and much more.

How it worked all in all

TLDR:

We collected metrics on each server of the system using versatile tools. Each metric was sent to the centralized storage.
We called any unexpected situation "event-to-alert." It has the date and time of beginning (when the issue happened) and its end (when the issue was resolved).
We used centralized settings for sending notifications for such events. When something wrong happened, we sent a message to the channel on Slack. Same thing when the situation is resolved.

As a result, the client stayed informed about the product's problems. And by this, we mean not just technical issues but also the problems of the client's business as such.

"Reminders" to pay for 3rd-party tools

Almost all products now use 3rd-party tools — this is advantageous given the savings in development costs. Calibra has had a dozen such integrations. Some could be paid annually; some are billed on an unpredictable schedule. Our client had to use several credit cards because not all 3rd-parties could bill each card.

So our client inevitably forgets to top up some of the credit cards or is mistaken with payment amount sometimes. As a result, the 3rd-party tool stops working until you make a payment. Forasmuch as it was not rare for us to change 3rd-parties, we decided this risk should be covered with an automated solution.

Since such a situation shouldn't be considered a real long-term threat, we agreed this would be managed post factum. When a payment error happens — we inform the client. So we developed such a simple process:

Bill failed, after which the 3rd-party stopped working.
The 3rd-party API stops working; alerting system determines that it is non-payment according to the error code.
The client and we find it out with a Slack notification. The client can solve this problem immediately.
As a result, the integration resumes working in the shortest time.

With this type of alert, you require a minimum amount of false alerts. When your employee has to check the issue instantly after notification, it shouldn't become a routine. If such alerts fire frequently, the problem should be solved in another way. For example, a client may hire a separate clerk who will take care of this. But when you have 1–3 notifications monthly, as it should be on a growing product, this solution is just what you need.

In our case, such situations occurred constantly, but they didn't harm the stability significantly. Therefore, thanks to the monitoring system, we secure the product's stability from the human factor in this matter.

There were several remarkable technical aspects behind this solution. One of the 3rd-party tools we used occurred to reply with 401 (Unauthorized) HTTP code. Usually, it means that you had provided incorrect credentials, e.g., the wrong password in your request. We rechecked our credentials, and they were fine. When we contacted support, we found out that this response meant an expired subscription. According to their logic, if a user fails to pay for a subscription, this user no longer exists, so the response with the 401 code is valid. Huh, it happens. So we added this case to the alerting system. Also, we documented why this solution was built in such a bizarre way.

Another case. One of the 3rd-parties began showing frequent alert noises. As we figured out, the 3rd-party team struggled with the growing load and repeatedly responded with a "Gateway timeout" error. We've just changed that we consider responses as event-to-alert only if we've got no 200 responses during one hour.

Thus to build a trustworthy alerting system, you have to know your 3rd-parties pretty well.

Bottom line

It might look like something unimportant. But when on Monday you discover that during all week-ends some of the landings were down since Cloudflare payment failed, and marketing budgets for two days are wasted… You change your opinion.

The same solution could be achieved in other ways. But it's much more convenient when you have a generalized solution that could be customized anytime.

If you need something similar on your product, we will discuss it with pleasure.

Alerting system and product metrics tracking: benefits for the product owner

Yevhenii Kosmak — Fri, 15 Jul 2022 12:24:06 +0000

My name is Zhenya Kosmak, and I wrote this article describing my experience as a Technical Product Manager. You can connect with me on LinkedIn if you want to discuss your project or anything related to this article. And I will be glad to share with you some pieces of advice 🙃

This article is a part of the cycle "Alerting system: why it's necessary both for developers and product owners." This article confers our arguments on why you should track vital metrics with alerting tools and how this aids a product owner.

To make understanding the problems we solved easier, we need to tell the essentials around the product. Calibra is a BPMS, i.e., a system that covers most of our client's workflows. The client's company managed numerous advertising campaigns for their clients in their interests. The client's company earned from each lead they brought. Calibra managed the accounts from which the ad was launched; contained all advertising settings; automatically changed the ads; collected statistics on the effectiveness of advertising, and much more.

Let's start with an example how client company may lose money without monitoring:

How our alerting system worked all in all

We collected metrics on each server of the system using versatile tools. Each metric was sent to the centralized storage.
We called any unexpected situation "event-to-alert." It has the date and time of beginning (when the issue happened) and its end (when the issue was resolved).
We used centralized settings for sending notifications for such events. When something wrong happened, we sent a message to the channel on Slack. Same thing when the situation is resolved.

As a result, the client stayed informed about the product's problems. And by this, we mean not just technical issues but also the problems of the client's business as such.

Tracking critical product metrics

One of the product's subsystems was especially financially important for our client. This subsystem provided the sending of lead data to the advertising platforms. With this data, advertising platforms have optimized the audience targeting so that the effectiveness of advertising increased significantly.

The integration between marketing platforms and our product was a complex one for a bunch of reasons:

Google Ads and Meta Ads are different in the sense of gathering information and have various bugs on their side. We spent dozens of hours talking with them, figuring out those issues.
Each lead event must be saved on our side for sure before being sent to the platform side. If we break any subsystem, any server crashes, anything else — we shouldn't lose any lead. So we developed a separate microservice that received all the lead events.
Every lead event was sent to the main DB to be shown on the statistic pages of our product. Marketing managers used this metric on each ad to track its efficiency. If any part of lead event information was corrupt (for example, the type of event was malformed), we didn't send it to the platform and logged it for further investigation.

As follows, we had multiple points at which our system might break. On the other hand, we have already had several precedents for the failure of this process, and in most cases, not for reasons within our product Calibra. Our client used a few third-party products to filter the bot's traffic; settings for gathering lead information might be set incorrectly on the ad's settings; etc. Each part of this system might cause lower performance of advertising. This little simplified illustration shows the scale:

So, having the whole set of correctly sent lead events, we decided to alert when we haven't as many lead events as we expected. Thus, if too few leads were received, we could alert this to fix it as quickly as possible, optimizing the client's advertising costs as much as possible.

As a result, it looked like this:

If in 1 hour there are no leads for a group of advertising campaigns, this is a problem, in which case the alert arrives.
We created a checklist of typical problems on our side, covering 95%+ cases. If this is not our problem, the client has to solve it. We have checked all these situations using a checklist after a Slack notification.
After checking, we called the client's team members in the Slack thread, informing them of the problem on their side.

As a result, we solve some of the client's problems by informing them timely and when they must act. At the same time, we are more likely to notice product problems that we can solve on our own.

Bottom line

We developed a relatively mature monitoring system for the early-stage product. It might look like an over-kill, but stories like this confirm the opposite. Problems like you've read above are waiting for you all the time. And you need a customizable solution to be ready. In this case, only you will be sure that CEO-level product metrics are on track.

So yeah, this is the only and the definite reason why product owner needs an alerting system. Some metrics matter a lot. You need to maintain the product in a way to fit their expected values. Just because it saves money.

If you need something similar on your product, we will discuss it with pleasure (link to our website).

Stay tuned for the new articles!

Do I need to develop software at all?

Yevhenii Kosmak — Mon, 11 Jul 2022 15:45:38 +0000

During my professional life, I spent a lot of time with clients who simply didn’t need my services. So I wrote this article. Here I have tried to reveal the most common cases when the cooperation between the development team and the entrepreneur fails for objective reasons.

At times it’s just our issue — we don’t have specific experience or something like that. But more often, it’s a client who is not ready for development. Either a client doesn’t yet have a good enough vision to develop a product, or they don’t need a product to be developed at all.

When it’s early to develop, I prefer to postpone the start of work, quite an understandable attitude. But why do I refuse to start when, objectively speaking, the product can be developed? There are two options that I face particularly often:

There are no similar products, and no one knows how to develop one well. Here at Daiquiri, we think that we can create things that no one did before. The main thing for us here is that the entrepreneur has a reasonable belief in the feasibility of the desired. But till the client can't prove to yourself that the realization of their ideas has good chances for life, we will recommend not to rush. We prefer not to become people who just waste clients' money with the words "well, that was just an experiment."
Such products are already on the market, and they're made well. At the same time, the count of such products is small. Thus you are unlikely to be able to hire a developer who already has experience developing such a product. There are two opposite risks here. On the one hand, this can be a highly complicated niche, and many threats are difficult to predict at the start. On the other hand, the purchasing power of consumers in the niche is, in reality, much less than you expect, and making the product commercially successful will be very difficult.

When the developers are most likely not needed (yet)
1. I have no budget guidelines at all
2. I understand badly how the product has to work
3. There is almost the same product, and it works, but I need a slightly different one
4. I need a full copy of the already existing product, I want to earn
How do you make sure that the development is needed?
How to formulate tasks and find a developer
Good luck

When the developers are most likely not needed (yet)

I have no budget guidelines at all

There are many cases where you want to know if it is expensive to develop "something like this." It's a valid question for a manager or entrepreneur. And if you don't have competent people for an answer in your network, it costs money. But this is not a development but consulting.

Often, if you don't understand (at least approximately) how much you are ready to pay for development — you don't need it. Of course, we do not talk about a product that a trainee can make in a month. If the problem is not solved effortlessly, and you are not ready to spend energy learning the importance for you, you are unlikely to be able to delegate the problem's solution as well.

Any product manager foremost has to understand the business idea completely. After this, it's possible to give some estimates. Not understanding the product's priorities, its most significant threats, and the research it needs — is the right way just to spend money pretending you're developing a product.

There's a popular and fair thought that a designer without task constraints can spend on art on any budget — the same in the development. Understand how necessary each block of tasks is for the product. Then finding adequate solutions will be entirely possible.

I understand badly how the product has to work

It's okay if an entrepreneur just doesn't have a technical view that will be enough to understand how the future product has to work. It's a typical situation where the product team's task is to find and develop this vision based on understanding the problem and the consumer.

And this is an entirely different situation when, in fact, the entrepreneur lacks experience in the market. It is almost impossible to build a successful product on a fragmented market understanding. If the product hypotheses are constantly too far from the truth, unfortunately, this is the case. And here, it is better to suspend work on the product until the time when its vision becomes more precise. And if there are doubts about the quality of the product vision initially, it is a good idea to think about whether it is time to start development.

There is almost the same product, and it works, but I need a slightly different one

For example, you want to develop Uber Eats to deliver cocktails. There are already several competitors in the market who have shared the food delivery market. You already have domain expertise and potential customers, or maybe you want to use such a product by yourself. Besides you believe that especially this business model could fundamentally better solve the problem of cocktail fans.

The difference between your desired product and actual Uber Eats seems pretty tiny — you need a slightly different menu and a different structure of filters in the application. Maybe the process of adding ingredients to the cocktails could vary from "I want a Big N' Tasty with double cheese." Let's assume you're already sure that cocktails will stay in good condition during the delivery. Also, you had already solved the packing problem and knew how to make this solution wider. Okay, brand-new Uber Eats now looks like a great idea.

Let's think about why you still shouldn't develop such a product:

Competitors are not yet aware of the existence of this niche. You should not develop a product in the following variants:
- It's a really cool niche, and you should develop the product for it particularly, but you need to build up almost the same thing that competitors already have. Okay, but your team would have less time and experience to create the central part of the product. The competitors already have more experience, better vision and opportunities to enhance their own products. Your decision should rely on competitors' costs and this basis you should decide whether it is worth it. Until you do an exhaustive analysis on this topic, your risks are too high to begin development.
- This is a good enough niche for the product, but the main one — simply food, is fundamentally bigger and more important than it. Also, you know how to reduce the complexity of development compared to what Uber has done. Most often, unfortunately, the development budget wouldn't significantly decrease if you remove a couple of features. Successful cases of such products exist; however, they are very few.
Consider another situation; a competitor is already planning to develop a product for the delivery of cocktails.
- Let's say you believe that you will do better. Statistically, most likely, you better not go into this competition; all the advantages are already on the competitor's side. It won't be easy to plan the product adequately if you do not have a clear competitive advantage that other competitors do not have.
- If you just need such a product, there is nothing easier — just wait. If you can't wait, help develop it by proposing all of the resources you are ready to spend on this solution to the owner of the existing product. With reasonable compensation to you. As a rule, it will be cheaper than to develop it by yourself. Is there any reason to think that wouldn't happen this way? Well, then it’s a reason to consider development on your side.

I need a full copy of the already existing product, I want to earn

You probably have a unique competitive advantage, which your competitor wouldn’t get. And you want to use it.

Unfortunately, we have to figure out your advantage, because without this we can't make such a product as you'd need. The problem statement in the way of "I need a complete copy of the product" means you don't want to understand the future product. That's why it needs to be made by the developers' team. And they are the ones who will make decisions about development priorities, due to which the goal can be reached, spending the budget optimally.

You have to tell everything about your competitive advantage to the development team, using the appropriate legal security guarantees for you. If you are ready for such risks — it may be worth it.

How do you make sure that the development is needed?

There is a definitive list of the questions that the team leader has to ask before starting. If you sincerely like your answers, the development team will most likely have the same feeling. And it will be an excellent ground for the beginning of the work.

Product description.

The task of the product owner here is to share with developers the maximum of their own experience and market vision in specific product requirements. Details are important — the more clearly you envision the product, the less time we will spend on secondary aspects of the solution. Reasons for each requirement are significant; the development team will carefully analyze each functionality and its purpose to spend the optimal effort on it. The product's essential characteristics should be outlined very clearly, so as not to lose the crux of the future product during development.
Vision.

For quality development, it is necessary not only to understand the reasons for specific decisions but also the approach to building the product as a whole. The reasons are often more important than the proposed solutions. An experienced team will be utmostly focused on this point. You have a prime vision, and the team has an objective to implement it. Explain why you propose to go in specific directions and vice versa. By the way, it was vital in our case Cognitive World Atlas; you can check out a whole story.
Product metrics

This is how you will give the product the maximum opportunity to be predictable for you. The goal described by the metric values becomes more practical, and the development team can approach the achievement of such objectives. Of course, metrics and the way they are calculated can change. Maintaining metric values valid throughout the product lifecycle is the development team's task.
Value proposition

When it comes to fundamental decisions or an affair that affects the entire product, the development team must assess the global implications. Therefore, we must fully understand what is most important for the product's end-user.
Competitive advantage

It will motivate everyone who works on the project. Even if it's not about development, then the presence of such a story motivates the development team; it is the flag of the product. We will all hope that we will be the first to bring such a product to market.
The distribution channels

Maybe the developer is far from the end customer, and the view can be built by other people, but only an inexperienced manager will miss building a detailed idea of product personas. And channels and processes of involvement describe what they will be. If you are lucky enough to work with worthy developers, you will be amazed at how much valuable advice you will receive from them on who and how to attract. Or what to consider when developing a product to make the channels work well enough. Cause a developer knows best of all what experience of interaction with a product the user will get from each situation.
Structure of cost and income streams

The first point is simply — anyone works better if knows conditions when the money runs out. If we talk about the best ones, they will know when money needs to be spent on other processes. That's why don't be shy in detailing your vision of costs. And the second point stems from the first - this is a potential button that you need to press, so that work on the product does not end. In my experience, I have repeatedly made decisions that allowed my client's product to live longer. And, of course, they gave me the opportunity to earn more. But this is a consequence, not a cause.

How to formulate tasks and find a developer

This is not a matter of principle if you work with professionals. Of course, well-prepared inputs simplify life in the early stages. However, in long-term cooperation, the primary vision of the product is not critical. The main thing is the proper foundation of the product, the right team, and the honest relationship between the owner of the product and the development team.

If you feel that the product manager didn’t clarify something important — sorry, probably, it’s not a suitable company, you have to find another one. If you can’t figure out why the question wasn’t learned by the developer well, or they formulate the reason badly — yes, it is better to go further. Do they build the product far from your vision, and can you show this specifically? You need one more search iteration. You need a result based on your justified expectations, but not that drivel. Go ahead and don’t stop.

Good luck

A cool task and its quality elaboration is all the development team needs to deliver exactly what you expect. If you have it, sooner or later you will succeed.

You will find that you need. Or you will realize that you are solving a very challenging task. But it’s pretty unlikely, you will probably get what you want.

And, if you want to save some time, you may be interested in our “Startup Consulting” service.

Presale in IT outsourcing: how to end the first meeting with a sincere smile

Yevhenii Kosmak — Thu, 07 Jul 2022 14:39:47 +0000

What should I do to ensure the client gets what they exactly want? And how to ensure that a development team would obtain proper working conditions? This is one of the main issues that arise before the start of any cooperation. The second question — how should I do it? We will present some ideas about the presale process for resolving these issues.

A short list of details that you need to have done before the first meeting with them:

The client is interested in your services and is really engaged in continuing the dialogue with you.
You have identified the client's basic needs and have roughly imagined their vision of the solution to these problems.
You know the approximate limitations of your proposal: budget, deadlines, and peculiarities of the future solution.

What should be figured out?

The following are questions, as well as contexts, angles, and meanings. Without considering them, the conversation will not be so fruitful. The exact wording of these questions depends on the situation and the client's individualities. But still, you have to know the answers to those questions after the meeting.

What do you expect as a successful project's outcome?
- [If it is a new product] By what criteria will you evaluate the success of the future product? Who is responsible for this product on your side? What are the key competencies of this person? Maybe you have some metrics that will need to be achieved? How can we increase our chances of success?
- [If you need to develop a product not from scratch] What exactly is ready? Maybe you have a description of the problem, a draft solution vision, product characteristics, and market analysis? Who is responsible for the vision, and what is your approach to its construction? What artifacts of works do you have at the moment? Could we get them, and how?
- [If the old product needs to be improved or replaced] Why is the old product no longer performing its task effectively? If there were errors, have you worked on them, and what are your results? In what form do you have requirements for the old product, and to what extent can they be used now?
- [If you need to prove or disprove the hypothesis] Why do you think involving another company in the research is effective? If so, how clear are the evaluation criteria? What threats do you see in conducting research on your own?
How will the product affect your company's business model? Should it increase profits, reduce costs, or balance the risks?
- Is it possible for us to learn about the general business model of your company? What market or niche do you consider your own?
- What is the target audience? Maybe you have developed proto-personas? What problems does your company solve in general?
- How will the product change the processes inside your company? Or will it create new ones, automate them, or make them unnecessary at all?
In what form do you currently have input for the future product?
- [If there is no input in text form] What do you see as necessary about formulating product constraints? What will be enough for you to be able to control the product's compliance with the requirements? What level of our involvement do you want in the choice of priority functionalities? Do you want me to describe our approach to this issue?
- [If there is some input but the customer has doubts about its quality] To what extent do you think you have exposed the main parts of the product? Do you already have some priorities? How precisely do you envision the first month of cooperation?
- [If the customer thinks the input is close to ideal] How much could this input change in the process? Which parts of the product are the least predictable in this sense?
How do you expect the tactical decision-making process in the workflow?
- Who is responsible for the quality of the outcomes in the project we discuss? Who will act as product owner on your side?
- How fast do you think the tasks on the project will change? What is the standard planning horizon? Do you have any thoughts on this?
- Do you want to control some technical decisions on the project? If so, how and for what purpose?
- What time zone are you and your employees in? What are your typical working hours?
What boundaries do you have in this cooperation?
- Do you have a deadline for the whole project or some milestones? Why do you decide them so? If there is no deadline, what expectations do you have about the development pace?
- Who pays for the project: your company, the customer, the client, the partner, the investors of your company? In which cases can the project funding be stopped before it is completed?
- What are the budget expectations, and how were they formed? Are you planning a budget for the entire product, or is it better for you to plan it monthly?
- Are there any special conditions for cooperation? Maybe security, technology, or do you need any particular competencies?

Knowing the answers to the above questions, you can offer conditions of cooperation quite accurately. By the way, you can check out how we do it at Daiquiri Team.

How to figure this out?

Our approach here is simple and constructive — we need to be sincere and specific. When asking a question, you have to evaluate how it will be perceived. If the questions' reasons are unclear, they should be explained. It would be best if you spoke as simply as possible to make your thoughts easier to understand. And you also need to constantly keep an eye on the interlocutor's attention, being on the same wavelength. Let's look at a few examples of how you can do this.

Some topics and questions are delicate, such as about the money. The straightforward approach may not work here because the client may not be ready to respond. It may also take time for them to understand the importance of the question and come up with a quality answer. Therefore, the question should also be delicate and reasonable.

Look, there is a delicate question, but without an answer, it will be difficult for us to work. Tell us, how do you agree inside your company to make important product decisions? We need to understand this to give you the most relevant data on which to base such decisions.

The probability of encountering negativity and aggression is many times lower than in the case of a straightforward question. You may not get a complete answer right away, but this is already a significant advancement on the problem and valuable information to lead the product.

Sometimes a client may worry about such questions and think, "Why do they need to know this? It doesn't concern them at all." Seeing such a reaction, you should immediately explain to the client the reasons for this question. For example, you want to get a description of target audience or proto-personas. And the client does not understand why it is because you develop only the back-end. In this case, you can answer as follows:

I understand that our product does not apply directly to TA, but without understanding the product's end-user, we may rely on false assumptions. For example, we will spend too much time on less important API methods or work on minor entities in too much detail. So we should see the picture as a whole, then the probability of such mistakes is less.

At any convenient opportunity, refer to the previous words of the interlocutor. People like to pay attention to themselves, and often they can even say something new that they would keep quiet about in another situation. But it's important for your work, so record the answers and reactions to it.

By the way, you mentioned that the idea of the product belongs to you. Do you think you could take part in our team's brainstorming for the UX product? To what extent did you plan to engage your employees to improve the product's user experience?

And a few more small techniques:

Support communication on common topics, even look for them. This improves personal connections and reduces stress.
Make appropriate compliments. It is better to start with compliments on professional topics - so it will be easier to build an idea of each other in a working sense. When you already know the interlocutor better, you can be just a person for a while, not just a pro. Praising a colleague for something not about work is an entirely conscious story.
Keep track of time. If more than two-thirds of the time scheduled for the meeting has passed, and you have not learned the answers to even half of the questions - speed up and pay less attention to details. The overall picture is more important for the result than empathy here and now.
Always sum up. You met on the case, so it is worth summarizing what work questions were resolved during the meeting and how productive it was. In this way, you give feedback on communication to the interlocutor: what was helpful, what was not, and what will happen next.

Also, you can check how we hold kick-off meetings on our website.

How to achieve better results?

However, this is not all a good sales manager can do during a single presale communication. The little things are important, and the results often depend on them.

Supermarkets often make special offers — buy a toothbrush and toothpaste, and you get a discount. This technique is called cross-sale, and the same can be done when selling IT services. Knowing the current problem makes it easy to notice the client's other challenges. As in supermarket sales, the main thing is not to impose anything but only to solve a real problem. No pressure and "good prices" — just looking for good points to expand cooperation.
Don't be afraid to break the context. For example, you feel that the interlocutor is not interested, and you are sure you are not mistaken. Ask if everything is okay? Because if the client, for example, is worried about the health of a loved one and they can no longer think about anything, what kind of business can we talk about? Offer to postpone the meeting to another convenient time, and your client will remember that. And this will help you in the next meeting to be in a better position in the negotiations.
Don't be afraid to ask questions, even if the answer may be obvious. Technologies are multifaceted, and terms can mean different things in different cultures. Some may call the word "site" a landing page and the word "landing" a home page. There is nothing wrong with taking some time to clarify. And if you lose the essence, and on this basis, your company will make an inaccurate offer of cooperation, then all your work will be in vain.
Don't try to be who you are not. If you are asked questions you cannot answer, it will be your integrity if you immediately admit it and say that you have to convince that your answer is correct. It is a sign of a professional.

Why so?

Understanding the client's business is vital for a quality solution to their problems. So you need to know as much as possible.
Understanding how the customer sees the future product is vital for building effective communication with them. When you make an offer or make any decisions, you must consider all the client's opinions on this topic.
Personal relationships are no less meaningful than a professional approach. It is always important to remember that collaborations live less than people. You definitely want to be treated well, despite all the work moments.

Bottom line

For many professionals, presale causes the most difficulties, which is quite understandable. Here you meet new people for the first time, informal relations rules have not been built yet, and both sides do not know what to expect from each other.

To overcome such difficulties easier, remember that you are communicating with the same person as you. They have their goals, expectations, powers, and desires. Be honest, empathetic, and professional. And everything will be fine.

We gladly assist you if such an approach fits you and you need something to be developed.

7 Reasons Why Django Framework is a Perfect Framework for Startups

Yevhenii Kosmak — Wed, 06 Jul 2022 13:26:59 +0000

The programming language and the main framework are often crucial for startups. The speed and quality of resolving tasks depend on them. At the same time, tools have to be modern to save time and be flexible for the quick rebuilding of the solution.

Python with Django is a perfect example of a typical solution to such a problem. They provide an ideal opportunity for the development team to create a product with any level of stability. From quick-and-dirty prototypes to stable, scalable applications. The wide range of benefits makes Django a powerful solution as the main technology for startups. And we at Daiquiri Team are versed in this.

Popularity

According to the TIOBE index, Python is the most popular language in April 2022. At the same time, Django has the largest number of stars on Github of all Python frameworks — 63.6K. The closest competitors are Flask with 58.7K and the rising star FastAPI with 44.3K.

Why is this important? The more popular the technology is, the more developers have created their projects using it. The more such projects were created, the more problems the developers faced and successfully solved. Developers' loyalty to the technology shows they are confident that there are no significant problems in solving business problems using this technology.

Recruiting the developer

It is vital for startups to be capable of hiring developers quickly. Django's popularity plays into the hands of product owners. The developer on Django is really relatively easy to find. Most Python developers with commercial experience have at least encountered Django.

Okay, among experienced developers Django is popular, what about newbies? The situation is definitely not worse. Django has a lot of educational materials (for example, here courses on Udemy), which reduces the entry threshold.

Django is also a cost-effective framework to work with. According to StackOverflow, Django developer's annual salary is $45.3K, while FastAPI developer's salary is $54K, for Flask — $54.8K.

What makes Django so appealing to developers? The answer lies in the following reason.

Simplicity and speed of development

Django positions itself as a Battery-included framework. So, it’s a framework where the biggest part of technical problems has ready-to-go and customizable solutions. It’s especially important for startups to have the ability to spend the developer’s time just on considerable things.

The developers can focus on resolving business tasks, not on developing things that were already built. In distinction to the above-mentioned Flask and FastAPI web frameworks, Django has built-in:

A critical indicator for early-stage startups is time-to-market. That’s why the speed of hypothesis testing has to be high. Django has a ready-made project structure that fits well for a quick start.

Also, Django has a lot of integration with 3rd-party, many of which are official ones. That's why Django developers spend less time working on solutions due to ready-made ones. These solutions are tested well, and their readiness to use in commercial projects is proven in practice.

You can also check out our case of developing an IoT system using Django. In that story, we had built a prototype in 3 weeks from scratch.

Quality of documentation

Django’s documentation is cool; everyone knows this. You can check it on Reddit, Quora, YCombinator.

Moreover, Django is open-source. The source code of Django has a large number of comments, which are elaborated extensively and in detail. That’s why every Django developer knows that if there are any doubts about the implementation of some functionality, you can just read the source code.

If it’s not enough for you, here’s one more argument — the size of the community knowledge base. There are 288.7K questions on StackOverflow tagged django. In comparison: Flask has 49K, and FastAPI — 2.8K issues. The vast knowledge base from the community simplifies the resolving of almost every development task. You can hardly worry that you will encounter a unique problem that the developers will have to resolve for a very long time.

Performance

For startups, the speed of hypothesis testing and time-to-market is more important than readiness for high load. Nevertheless, the ability to scale in the sense of performance is quite important for startups; otherwise, moving to a qualitatively different level can be very expensive.

Django authors didn't have a particular idea to make it very fast, but its performance is enough for most startups' products. According to one of the most trustworthy benchmark, Django is even quicker than Flask.

With the proper setup, Django can withstand enormous loads; this has been repeatedly proven by the experience of both startups and industry leaders.

Deployment

Due to the maturity of Django, there are a large number of ready-made solutions for PaaS services for Django hosting. For example, heroku, GCP, Bitnami, Clever Cloud.

Also, Django can be easily set up for work on any VPS, for example, on Digital Ocean.

Convenient and easy-to-set-up deployment is the key to a productive workflow for developers and solid security at the production stage. With Django, you will have a minimum of problems on this matter.

Positive experience of big companies

As we already said, Django is used by big companies, such as Instagram, Dropbox, YouTube, Spotify, The Washington Post, etc. Also, it is used by many middle and small startups to build their products. That’s why around Django, there are many solutions that especially startups need.

Django is a powerful framework both for the early and mature. It is perfect for experiments and for a stable product. Django has a huge number of ready-made solutions that are easy to customize for most real-life tasks.

We at Daiquiri Team have developed many products on Django. If you are interested in assessing whether this is a good choice for your product technologically — write to us, and we will be glad to discuss it.