The Python Podcast.__init__

Share on social media:

[00:00:13] Unknown:

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great. When you're ready to launch your next app or want to try a project you hear about on the show, you'll need somewhere to deploy it. So check out our friends over at Linode.   With their managed Kubernetes platform, it's easy to get started with the next generation of deployment and scaling powered by the battle tested Linode   including simple pricing, node balancers, 40 gigabit networking, and dedicated CPU and GPU instances.   And now you can launch a managed MySQL, Postgres, or Mongo database cluster in minutes to keep your critical data safe with automated backups and failover.  

Go to python podcast.com/linode   today to get a $100 credit to try out their new database service. And don't forget to thank them for their continued support of this show. Your host as usual is Tobias Massey. And today, I'm interviewing Tony Pavlovich about Python's strengths for startups and the steps to building an MVP. So, Tony, can you start by introducing yourself? For sure. That's a pleasure. Thanks for having me here. My name is Tony,  

[00:01:11] Unknown:

and I'm cofounder of Planix. Planix is a web development company specialized   in Python, and I'm the 1 who   originated it, 1 part of it. So cofounder at Planix. That's who I am. And do you remember how you first got introduced to Python?   Yes. That's, an interesting point. And I think it's all about evolution and developers' curiosity   because   I'm being, like, a business mind, like, businessman,   not a tech guy myself, but still highly involved into technical things in Python.   Like, this story started 10 years ago.   It started when I was a business developer at 1 Ukrainian company,   and it was company providing web development services.  

That time, it was really popular to deal with PHP, dot net, and all the things.   But, like, developer's curiosity, this is something that brought   the Python up, and it was actually the request of my colleagues and the place we worked with. And they asked, like, if there is a chance to deal with Python because at that time, they just played with it. They learned some basics of it, a couple of simple scripts, but there was some, you know, curiosity to to understand what the tool is, about how powerful it is, and etcetera. So,   like, 10 years ago, it was, like, my first touch with Python. And   after talking to the CTO of the company, we decided to   potentially look for potentially   interesting commercial projects with Python, and that's how we we actually found 1 of the Fintech startups.  

And this was our, like, first cool, really interesting, and challenging   commercial project. So it was our first touch with Python, like, 10 years ago.  

[00:02:53] Unknown:

You mentioned that despite not being   technical   by sort of training, you've ended up in that space and you helped to co found the PLANEX   agency. I'm wondering if you can describe a bit about what it is that   motivated you to start a business in this space and some of the story behind how you ended up building this company and some of the particular services that you're focused on offering?  

[00:03:15] Unknown:

Yeah. Okay. So to start with, like, the first sentence that describes us is Python Web Development Services.   That's what we are all about. But another thing about us is   about business.   Because I think that all of the technologies, they are made up   for solving problems, solving challenges,   and, like, solving actually potential need like, real needs of the customers, clients, and just it's it's your tool. It's something that you use to make good things.   And my idea, it's not only my, but it's idea of me and my cofounder, it came off of a good service. So, you know, everyone enjoys   getting like, receiving a great service. And the same thing about   web development and outsourcing, outstocking in general, this is our industry. So   I understand that there is a way to, you know, to build a bridge between technologies,   business   by providing, like, a great service. Because what we were doing in my, like, first company where I started,   we were helping people to build their products.  

And during that time, I've seen, I don't know, like, 200,   300 products that people try to build from scratch, from trying to rewrite them to   support their legacy products. So people from all over the world. And it was really challenging and interesting to   deal with the entire world and speak, like, 2 languages, 2 languages of, like, business and technology.   And after we discovered, like, Python, like, how powerful this tool is,   we decided to, you know, really   build something great where we could combine   all our patients, where we could provide, like, technological solution, like technology solution to   business challenges   where we could provide perfect business   solutions, where we   could help our clients to grow our business,   and   that's how we ended up creating Planix. So we started this place to make it a good place both for our employees and for our clients.  

So both of parties involved   could really enjoy the process. So it's not just average work, but it's something great, something bigger, building your product, building your lifestyle for employees, and building the products for the client. So we call ourselves startup for startups   because we are, like, self funded business, and we know what it takes and what are the challenges of the companies who are trying to start their business from scratch. And that's what makes   great because we know the pitfalls. We know how to overcome difficulties.   So that's how we combine technology and business. And   after, like, seeing a lot of people trying to do that, we understood that, yeah, we   we saw enough to   be ready to share our experience   and to produce some great   effort, on the way to make the world, like, you know, a bit better place to live to share, like, our passion   to technologies and to business.  



[00:06:13] Unknown:

1 of the   core necessities for any business that's starting out is being able to prove out their ideas and determine whether or not their product direction is something that their customers are actually interested in, which is part of the motivation for building an MVP or minimum viable product for people who aren't familiar with that acronym.   I'm curious if you can talk to some of the goals and   outcomes that organizations are looking for when   they come to you looking to build an MVP or when they first start thinking about what are the initial   capabilities that they're targeting, what is the scope and the objective of the MVP that they're trying to build?  



[00:06:51] Unknown:

That's really good question   because   you really should find out what it is all about. So when it comes to MVP or minimum viable product,   I would compare it with a couple of things, like, to those who never encountered with such terms, who never deal with that. Let's think about, you know, sort of, for example, wine degustation or cheese degustation or, for example, test drive of the new car, or   I don't know if you have such things here. It's like temporary tattoo,   which, goes away, like, in a week or 2. And with p, it's quite similar to all of that   because from its name, it's about   something which is minimum version of the full real product.  

And   this was invented for businesses and not only for businesses. This idea is actually   applicable to,   like, real life, to anything you do in your real life. So it's when you don't know if the market   really needs your product. It's when you are not sure if your   idea is really great. It's when you doubt about,   you know, different   nuances of your product or if you have some hesitation about your product or you just need to find the right way to move on with your idea, that's where MVP   comes on the scene. So MVP   helps you to   spend not too much effort and not too much of your time, not so many time, not too many resources   on something,   but still get   the feedback and get information, get insights to build this product well   and to adjust it to your customer needs.  

So it will help you to collect maximum feedback from your potential customer. That's what it's made for. It helps you to analyze the market demand,   for example, to proof your idea.   That's the basics.   Additionally, MVP is great when you're not sure about your technical stack. So it helps you to test this technical stack as well. So without,   you know, investing heavily into that.   At the same time, when it comes to monetizing your product, MVP is another great thing to verify the strategies that you had in mind.   And   at the end of the day, it lowers your risks   and already lets you to engage with your potential clients.  

So that's the best thing about the MVP that describe it, like, in very detail. So  

[00:09:19] Unknown:

When I was preparing for this conversation,   I found a useful post on your site about the differentiation   between a minimum viable product, a proof of concept, and a prototype. And I'm wondering if you can talk to   what are the   distinguishing characteristics of each of those   approaches. And   when a company is better served just going with a proof of concept or a prototype and not going the full MVP route and some of the   types of information that they're able to gather by going through those different  

[00:09:51] Unknown:

stages? This is the mistake that clients often do. They mix up the terms between prototype,   proof of concept, MVP, and it's really important to not to know the difference between them. So, like, if we talk about the prototype, let's talk about it in the way, like, what is it, why you should use it with the audience, and when is the best time to use prototype, proof of concept, or MVP.   So if we talk about the first   stage among these   approaches and solution like prototype.   So in fact, what is prototype and why is it different from proof of concept? So prototype is something like clickable. It's like clickable piece of software   that doesn't require any coding   that you could already see, but you don't spend any time on writing the code. Because compared to proof of concept, which is, like, already some simple solution with minimum features but really no design.  

This is the difference.   While at the same time, MVP   is already   a product.   It's still   minimum viable, but still version of your product, which you could already use and test.   So   why do you actually need to create any of this?   If we talk about MVP, which is a topic today, this is, like, the most powerful thing because you could collect the feedback, engage your customers, and test the market. That's about MVP. At the same time, proof of concept is a bit different thing because it just proves the visibility of your concept. So feasibility, and that's it.   So compared to prototype, which just gives you the visual representation   of the flows and gives you understanding of basic   features. So it helps you to, you know, to calibrate your ideas a bit.  

And if we talk about audience   of this, like, approaches   and stages, the audience is also different. For MVP, it's already your early adopters and your potential clients. So it's like real guys.   Well, proof of concept is more about some internal things. It's about your stakeholders   who participate in this process. It's about some internal experts   and maybe some of your future investors. So it's not a real world thing yet, but it's already about important people.   And prototype is just the very, like, low level. It's for investors,   stakeholders, and some early focus groups. That's it.  

And if we talk about the time when each of the things   should be done and presented, then MVP is   already a development phase.   So it's the phase that's before the launch of the real full product.   As for proof of concept,   you should go with it after you are done with the discovery stage and you have already done some planning. You could, of course, require it.   And again, back to prototype,   it's   during the discovery stage or maybe a bit after. So it's a bit similar to proof of concept at this stage. So a big difference is the audience   and a bit time of the implementation   of these stages. And at the same time, you should remember that MVP is already   the first version of your product because prototype and proof of concept, these are preparational stuff. This is something for mostly internal use.  



[00:13:17] Unknown:

As far as   the scoping of the MVP, what are some of the pieces of information   that companies and teams are able to gather from that   prototype and proof of concept phase that can feed into the MVP to help them understand   these are the ideas that are not worth pursuing. These are the things that we want to do, but not right now, and figuring out each of the key   semantics of maintaining the minimum amount of scope viable to make sure that it's actually something that's useful and functional and a product in terms of something that's actually   ready for end users to interact with even if it is still a little rough around the edges.  



[00:13:53] Unknown:

We should understand that MVP comes from some point. It either comes from marketing team or it comes from   your idea. So it has some source. It has the beginning.   And depending on this beginning, you could come up with   a different set of, you know, assets that you have at this time. For example, what do you mean? If it comes from marketing, you already have probably a long list of requirements or you maybe   have a lot of ideas that you have to test and just to make sure that they are right for your product. When it comes just from your own idea to build, you know,   a a new Facebook or a new, I don't know, Instagram,   some new big product, revolutionary product,   then it's probably your personal thoughts, your personal experience.  

And it leads us to the different   set of, like,   things we have before we begin. So probably it's a list list of ideas or list of requirements. And   when it comes to, you know, to scoping, what's gonna be actually the part of the MVP?   It may sound complex, but in fact, it's pretty simple.   Because you may have this long list, but when we come and start discussing what's gonna be part of the MVP, we just propose you and offer you to rule out   until you have the list of 10. Until you have the list of 10 features.   Then we revise this list again. So   when you start ruling out the features, you understand. So, for example, without this feature, the product could leave, and   your clients won't lose the value because   MVP   is all about the value. You should bring your value to customers with your minimum   effort because you need to really make sure that this is of real value.  

And   once we start ruling out all of these requirements and when we start to shorten our list, we   think about, like, what we really need and what could bring this value to our customers. So at the stage when we have 10 bullets with   the potential features,   we ask our clients to cut the list to 5 bullets.   And then   when we have, like, really 5   of the things,   we could really begin approximate estimation.   And when we see that it fits our timeline, it fits our budget, then we could come to an agreement. So all of this scoping, it's all about the dialogue with stakeholders   and with the developers.  

Because   while cutting out this unnecessary   for the MVP features,   we rethink all of that. So that's the process. We should understand that nothing is different, and even there were cases when we we got all of the features to just 1 feature. And even then, we modified this feature because it took us a while to go through this process until we really understood what we should start with. So this is all about the dialogue   and dialogue that leads to the final value that you could bring to your clients.   And,   additionally, you should take into account that sometimes these requirements are already defined by the industry. For example, if we take into account health care industry, it has its internal policies and compliances that you have to follow. It already defines your scope. So   to make a long story short, when you have a long list, you just begin to rule out things that you believe your customers could live without until, like, later stages.  

And when you go to the heart of your product, that's your, like, killer feature, the main thing, something that will move your business further.  

[00:17:30] Unknown:

The other side of the MVP conversation   is once you've built it and launched it, there's the question of determining   whether it is successful and what features you need to add in   in the subsequent set of priorities and just the overall process of understanding   what is the actual outcome of building and releasing this MVP. Because once it's   running and people are using it, you need to have some set of measurements or some set of objectives that you're able to determine whether or not this was successful or whether you need to, you know, just kill it and, you know, accept the loss and move on with some other ideas and just figuring out what are some of the potential issues that organizations run into with the lost cost or or with the, sunk cost fallacy where they say, well, we've already built it. We need to just keep pushing on this   and, you know, understanding when it's worth investing in it further and when you need to actually say, okay. This was a useful lesson, but we're not going to keep going with this idea. We're going to pivot and go with something else.  



[00:18:25] Unknown:

Right. Right.   Now it's a marketing turn. Once you have the product up and running,   you already have your early adopters.   That's the time when you   get your first feedback,   And you can get it, like, in very different ways. You can get it by different analytics tools. You could handle different survey campaigns,   Whatever your marketing department or your marketing capabilities are, whatever your budget allows,   it's now about communicating with your clients and getting their feedback.   Depending on the source, if it's analytics, you just see, like, what's the most usable feature, if your clients   actually understand   your product, if it's easy to follow the design that you have came up with, or   if it take them time to sort out different functionalities   that are in place.  

So you now start analyzing   what you have on your plate after your customers really start playing with your product.   And   there are a lot of cases when   people, like, understand that what they consider   it important, in fact, is not important.   And   it's now about your   expectation,   it's about your timeline and about your budget   because   it all depends. Like, the more money you have, the easier MVP and analytics will will go, like, obviously. Of course, you should have expert, but it's a bit easier when you have limited resources.   So once you are done with MVP,   you now need to be   very careful with the feedback and analytics that you gather. And   after you have this analysis, you already could decide, like, if it meets your expectation or not. And   depending on the resources you have, you may decide, like, if it's worth rebuilding certain parts of it, if it was completely changing the strategy,   or if it was   just, you know, close the project and to just forget about it. There is, like, a good, like, inspirational story from 1 of our clients who's like, has a startup from the New York.  

It was like self funded startup as it usually happens, but finally they came to good investors.   And I've been checking with the CEO of the company, and she told me, like, we didn't really know what the value of our product was until 6 months later.   Even though she was deeply into the industry for, like, 5 years,   she has, like, perfect education. She knows what to expect.   But after the real analysis of real people playing with the product, they understood that   people are more interested in something that we didn't consider so import important as the other, like, killer feature we saw. So we changed our direction   and successfully moved further. So this is the real case and this is something you as like as an entrepreneur, like as a young businessman should be ready for. So be ready that MVP will bring you something unexpected.  

Hopefully, it will bring you what you really wanted, what you really was ready for, but sometimes it gives you some unexpected outcomes and you just should be ready for that and   decide accordingly depending of, like, your opportunities   and the assets and resources you have at that time.  

[00:21:41] Unknown:

Digging now into the actual work that you're doing to build these MVPs,   can you describe the set of tools and frameworks and development practices that you have invested in to be able   to reduce the overhead involved in getting started and building velocity in a project and the ways that you approach the overall structure and development of the code to be able to iterate quickly and be flexible   and allow for evolution in the design and implementation of the project?  

[00:22:11] Unknown:

MVP is something, like, really tricky because you should balance between   speed and quality.   Of course, everybody just wants the project to be done, like, fast and at a high level of quality. That's easy to understand. We all want that when it comes to something. But it's important to understand that it's really balanced. And   with the MVP,   the speed is   sometimes   and I would say often, that speed is often more important than quality   because   the outcome of the MVP, like, the conclusion that you could make when the MVP is ready, you may come to the decision that you need to change something significantly   and changing something that you've spent a lot of time on building this will take you, like, again, a lot of time. So when you build empathy,   it's about this balance. So in order to be fast   and in order to be able to provide quality at the same time,   we have actually used the tool that everyone probably is familiar with. It's Python framework, which is called Django.  

Incredible tool. Like, super powerful.   And it's like, I would say, like, a perfect solution to   95%   of the   requests in web development world in, like, startup world when you build something digital.   So we actually use Django, and it helps us to speed up the development because we have some boilerplates.   Some of them are inspired by cookie cutter, but we have adjusted them to   the reality that we meet with our clients.   And it already includes,   like, modules and solution, the most popular in our clients' requests.   So most of those cases like login functionality that, like, in 90% of the project, you will need it. And   it's just 1 of the examples.  

So it's actually full of such solutions   that sometimes necessary, sometimes not. But at the end of the day, they will save you a lot of time during the development. So you   with the MVP, you have to provide the first version as soon as possible. So your client will be the first 1 to play with it.   So, additionally, like, while working on different projects,   we really enjoy working with Docker. Like, these 2 really helps us to isolate, like, our working environments   and really helps us to   simplify,   like, server configuration. It's like the part that you cannot exclude from any web development project,   and it's, like, a cool solution. So Django   Django is a boilerplate, which is based on the cookie cutter and with the help of a Docker, that's what we use. If you talk about front end, MVP is   something that gives you flexibility at the same time. Because when you build, like, a new product, you   you could spend, like, a fortune and, like, lots of your time on building the UI and the UX. What helps you to build MVP is some prebuilt theme. So bootstrap theme or some front end framework theme. It helps you to save a lot of time because you already   have something ready to use. You just customize it according to your needs. And, you know, you won't regret if you need to   just forget about this project because you didn't spend a lot of time or money on this design version. But once you get this feedback, you already have opportunity to come up with the perfect design with a custom made solution specifically for you. So these are the tools that we use to speed up the development at the very early stages at the very early stages of the development.  



[00:25:41] Unknown:

As far as   the developer experience and the environment setup, that can also be a critical piece to helping developers move quickly while maintaining quality in terms   of linting rules, making sure the tests are run on a consistent basis,   you know, making sure that there are consistent style guides being applied, so things like black. And I'm wondering, what are some of the configurations   and developer environment setup that you found to be most critical to keep constant and consistent across projects to allow your developers to be able to jump in quickly and be working in a familiar environment and not have to try to adapt themselves   to bespoke environments and bespoke project structures because that can, you know, slow down the overall ability for them to be able to get comfortable and be productive.  



[00:26:29] Unknown:

At some point, we decided to come up with some storage of our knowledge   because every project is unique, but at the same time, you, like, face   the same difficulties and you face the same challenges. So,   like, a while ago, we started to   fill in our knowledge base, which contains answers and,   you know, practical solutions to the most frequently asked questions of our developers, and it keeps the records of the development,   you know, tricks, hints, and something helpful that could save you, again, could save you time at the very beginning. To give you an idea, we even have a section in our knowledge base, which is related to naming policy in MVP projects, you know, for startups   because   it's quite frequent case when   you don't know, like, what will be the name of your project, but you already have to come up with some naming conventions   in your code, and you need to give names to a variable. And so   we have a strategy about that, and we have recommendation how to deal with the project when it's not ready for, you know, some final decisions when you should be ready to change something in the future. So the knowledge base is our   first thing here is, like, the storage of all our experience with recommendation   that all our developers and also nontechnical   guys in the company could use just to know the reality.  

Because   often, I would say that much more than half of our projects of the MVP are successful.   And   a successful project means that if you started developing it, then you'll probably continue this development. So it's not reasonable to replace the developer who started the project with someone else in the middle of this project. That's why if you begin this project and it's successful,   you'll probably stay on it, and you won't know something that happens on the other project. That's why this knowledge base is unbelievably important because it shares the knowledge, you know, from the entire company. So from different projects, from different experiences, from different developers.   And I would say we are really proud of it. We also try to schedule, like, internal workshops   to share this knowledge in my company. So it's our internal community   that we try to develop small Python community.  

And, of course, we try to follow, like,   8 recommendation. We use Pylint and the black that you mentioned. That's also our choice depending   on the project. Like for most of the projects, we use it for making up our code. So In terms of the  

[00:29:04] Unknown:

architectural   styles and some of the useful patterns that you found for being able to   build quickly but   maintain   extensibility and allow for future evolution   of the project, what are some of the   approaches that you found to be most helpful for being able to maintain that velocity and flexibility?  

[00:29:26] Unknown:

So here, I would go with monolith architecture,   and 99,   almost 100 percent of our projects are based on this architecture.   It's reasonable choice, which fits   most of the projects,   especially when it comes to the beginning of the life cycle of this project.   And that's why we like preferred Django. It really helps with speed of this development   just because it has really   well developed ecosystem   and it has really rich functionality.   Then after that, we could change our strategy and we could think about   different   solution and,   like, replace our initial plans   or just extend them. But initially, it's all about monoliths.  



[00:30:11] Unknown:

Going back to your point about   Python being a good choice for being able to build these products and iterate and Django being a useful framework,   What are some of the   surrounding benefits that you've seen from choosing Python as the target language and ecosystem to invest in for being able to build these MVPs   and for getting startups off the ground and some of the potential challenges or risks that you have seen as an outcome of choosing Python?  

[00:30:39] Unknown:

The first 1 is definitely the development speed. It gives you that that's what you need with the MVP.   Another advantage here is that   you could clearly understand   and you could predict, not just predict, you just know when   the tools that you use will get a new release. So it's   when you know when   the next release of the tools that you are using. So you don't have surprises with the toolset that you use. So it's the development speed, and it's about the predictability. Right? That's predictability of the release cycle of the toolset that you use. That's about it because   you clearly know when they're gonna be a new version and you won't get any surprises   with your toolset. So that's the main thing. Because modern project,   they require   implementation   of, like, huge amount of functionality.  

And it's really important to take into account   a lot of questions related to the security   synchronization of different components in the project.   For example, like changing the DB structure   that will require changes in the form, in the admin panel, and the API requests, and etcetera.   And Python, as well as Django allow you to develop functionality   fast   and to still get the high quality,   which is unbelievably relevant for startups. Because   most of the requests I get from clients is like, how fast could you build that?   Could you cut the development type and still keep the expected quality? So it's really relevant for startups.  

And   at the same time, Python and Django allow you to develop fast and do not regret about the quality. So   another point here is that   the tool that we use, they have,   like, a big community,   which means that it's popular and your toolset is really popular   so you have access   to helpful information.   And if you start with something, if you have problems   or challenges, I don't know, with certain feature, you don't know how to implement it, or you're just stuck with a certain library,   I think that in most of the cases, you could easily find answer online.   And   this, again, about the predictability,   about   forecasting the thing   that that helps you to stay stable and provide,   like the expected result.  



[00:33:04] Unknown:

For   companies or teams that are looking to use Python to get started, what are some of the cases where you might steer them away from it and into a different language or maybe if they are within Python, maybe choosing a different framework than Django?  

[00:33:18] Unknown:

That really depends on the requirements of the project   that you have. So there are obviously some drawbacks that these tools have because these are just, like, default tools for, like, fast development.   That's why there are some potential drawbacks.   And, for example, like, when it comes to   functionality,   if you take a look at Django, which gives you, like, a built in functionality, and if you understand that this project just simply doesn't require all of that, that your clients   and customers   just won't use it. So it will be just an extra   problem for you if you better go away without and go, like in a simpler way. Just for example, if we say we're using Python, you could go with microframeworks   and you could go with fast API,   which is another perfect project. You just aimed for a bit different things. So when you see that there will be a lot of unused functionality within, like, built in functionality of your framework,   then just look into another tool. That's   1 of the solution.  

You could also think about drawbacks of John Bosac's   it being demanding   to to the resources.   But I couldn't say it's really a big problem and that it's too demanding, but you should still take it into the account.   At the same time, 1 of the drawbacks of that   genuine Python is not the fastest framework. So   if the performance,   the, like, speed of the operation is important for you, you should consider some alternatives.   But in   like, the most popular request that we have from our clients   is still a very good solution.   There are rare   cases when Python and Django is not good, and   I would   say that very often clients already know about that. So if they know about these specific requirements and details,   then probably they're already aware of the tech side of things. So to sum up, I would take into alternatives if you need something like performance and speed depending,   or if you just don't need to use all of this prebuilt functionality that comes under the bonnet of the Django.  



[00:35:31] Unknown:

And in your experience   of working with teams and organizations   to build MVPs   and get started with learning about their customers and what projects and products are worthwhile? What are some of the most interesting or unexpected or challenging lessons that you've learned?  

[00:35:47] Unknown:

I'll be pragmatic here because there is no fancy or fancy answer about that. Unfortunately, it's very pragmatic. And the answer is just that victory loves preparation.   I would also add flexibility   here.   There's no big surprises. So if you work hard, if you plan hard, then   there won't be anything unexpected to you or challenging. It's all about really preparation.   Another important thing during the development of MVP   is communication between all of the stakeholders.   And once it's done about communication,   communication with   your early adopters and your future users.  

So just stay well prepared and you will be successful and be ready that something may go wrong. That's all about entrepreneurship.   And what else you should take into account is before you start developing MVP,   just make sure that   you decided to go with the right vendor, with the right provider of these services. Just make sure that these guys are reliable, that you speak the same language. Of course, it's perfect when you are the developer yourself and you just begin to create like a new revolutionary product. But if you are not a tech savvy, just try to be the right company, the right tech partner.   And once you   select the right partner,   make sure that the technologies you select for your MVP is correct. Of course, there are a lot of projects where Django, Python won't work. So you need to be   ready to interview, to be ready to analyze   all of these details before you begin the development   because it will cost you a lot if you realize it in the middle of something. That's why you have prototyping and proof of concept that we previously mentioned that will   prevent you from something unexpected.  

And just don't forget about the purpose of MVP.   So MVP is still the first minimum version of your product. It's minimum but viable.   Don't go,   really further with that. Don't try   to build the entire product with the MVP approach because building products   will require even more   dedication from you. Nevertheless, MVP will still be complicated and challenging. Building the product will be even more   involving and demanding to you. Just remember the purpose   and make sure that you go with the right partners and with the right technologies for that, and, like, be well prepared. That's my advice.  

[00:38:15] Unknown:

And so for teams who are thinking about going down the path of building an MVP to prove out their ideas, what are the cases where that's actually the wrong choice and they might be able to   get those same lessons and same information some other path?  

[00:38:29] Unknown:

Definitely, MVP is a wrong choice when it's too early or it's too late. And when I mean to wait, I mean that when you're already sure of the solution that you have. So when you don't need to test your ideas, when you don't need to test your series, and you already know your customer, so that's where you can safely   skip the stage of MVP. Just go and build your product and just conquer.   The same about when it's too early to build the MVP.   When you just got an idea   and you didn't think well, you didn't come up with a proof of concept or with a prototype.   You didn't discuss it. You didn't   plan it well. You didn't go through discovery stage. Discovery stage is incredibly important   at the very beginning of your product.  

So that's why you've been asked a lot of questions that you didn't think at once. It's again about choosing a good technical partner who would ask you this question. Because in your head, you probably already have a solution that's   that's worth with love. So when everybody will enjoy, but you need also to hear some criticism from the other parts and to hear the question that you didn't think about.   So MVP is not the best solution when it's too early or when you have already full information about the product you're going to build.  

[00:39:44] Unknown:

As you continue to work with clients and invest in your team and your development practices, what are some of the   trends or developments in the Python language community and the Django framework community and some of the broader software ecosystem that you're paying closest attention to and considering for some of the future work that you're doing for your team and your clients.  

[00:40:05] Unknown:

That's nice   Because development   is all about learning something new, and   we learn something, like, really daily. We don't have something on our horizon that we're closely watching and we keep an eye on the releases   or something like that   because every day brings us the challenges that we didn't hit yesterday, and we have to find the solution for them. And the more we learn, the less we know,   surprisingly. But there are so many tools that we didn't try yet, and they already exist.   And   once we get this new challenge, it's perfect just because we're gonna look for the solution that we don't have in our old knowledge base yet. That's why it's opportunity to learn something new. So   my recommendation   is just not to stick to   the toolset that you have,   but it's about exploring everything.  

Okay. Not daily, but still, it's about exploring something new. Just to give, like, a real life example,   1 of our tasks that we had was   about OCR, optical characters recognition,   and we're trying to go with some, like, default Python stack with some Tesseract libraries,   things like that.   But, like, after doing some research on the topic that we are still very familiar with,   we discovered Adobe API solution, which solved our task in, like, in no time. We got solution, like,   with without spending   a lot of money on that, but it was, like, implemented, I don't know, 10, 20 times faster   than if we go with the custom made solution. So just keep exploring,   keep doing your paid projects,   Try to learn something new and try to teach somebody if you have the knowledge. It will help you to discover what you have within your stack and will bring you something new that you you never met. So   to to answer to finally answer your question, we just keep exploring what we have around us without   sticking to something specific except for Django. Yeah. But we have, of course, like, as every community, we have channels in our Slack team where we share what we   learned today, what were the challenges, what were the tools, and the solution. So that's how we learn command our team, and   that's what keeps us up to date in our industry.  



[00:42:25] Unknown:

Are there any other aspects of the work that you're doing at PlanX or the overall process   of building an MVP and validating it or some of the benefits of the Python ecosystem   for startups that we didn't discuss yet that you'd like to cover before we close out the show?  

[00:42:41] Unknown:

I would recommend to you to be focused not only on the technical side of things because MVP is about understanding   the business.   This is why I love what I'm doing is because this is the mix of the business   and the technology.   So when it comes to developing an MVP,   it's crucial to   clearly understand what are the goals of this project, what we are trying to achieve. Like, what is the problem that we are trying to solve for our future customers, for our clients?   So once you are on the same track with all of the stakeholders,   with the participants,   that means you're ready. Because often development is, like, a thing that keeps you involved, that you are deep in the tool that where you write code into the IDE.  

You're often deep into your IDE. You just write your code. You enjoy the solution you prepare. But sometimes you could forget about the problem that you are solving. So   try to balance try to balance between technology and the solution you are doing, and that's another key to success. And, of course, communication.  

[00:43:46] Unknown:

Well, for anybody who wants to get in touch with you and follow along with the work that you're doing, I'll have you add your preferred contact information to the show notes. And so with that, I'll move us into the picks. And this week, I'm going to choose a utility that I've found to be quite useful a few times called data model code generator.   It's just a little command line utility   that you can feed a YAML file or a JSON schema, and it will spit out a bunch of Pydantic models for you that maps to the structure that you're trying to replicate. So you can very quickly go from an API spec or a specific data structure and turn that into some reusable Python models in PyDantic so that you can get up and running. And I just recently used that to build a wrapper library for concourse pipelines. So definitely   checking about utility if you're looking for being able to quickly spin up some data models for being able to manage typed data structures in Python. And so with that, I'll pass it to you, Tony. Do you have any picks this week? Again, I would go not to the technical side of things, but about recommendation and  

[00:44:48] Unknown:

about enjoying your life while doing the thing that you love. I think you're all aware about Richard Branson, the millionaire, the the owner of Virgin Brands.   And   the thing that I noticed   about all of the start up, all of the, like, young businessmen, all of those who try to build their products,   it's about   desire. It's about their curiosity.   And there's, like, a great book which will help   technical,   like, guys, nerds, geeks,   those who just prefer to stay in the code. There is a book that will help you to understand your clients   to be on the same track with them. The book is called Screw It. Let's Do It. It's about all of the opportunities that Richard Branson   had during his life about the solution   that pitfalls about, like, his failures,   about the problems he had, and how did he overcome it. And it's about the way to enjoy life while doing what you really like. It's about   you're ready to risk. It's about really, like, live life up to the full.  



[00:45:50] Unknown:

Alright. Definitely have to take a look at that. Well, thank you very much for taking the time today to join me and share the work that you're doing at PlanX and your experiences   of helping teams and organizations   build and validate MVPs. It's definitely a very useful exercise and useful set of lessons for anybody who's interested in trying to   prove out their ideas and figure out whether it's something that is going to be valuable to their clients and customers. So I appreciate all the time and energy that you and your team are putting into that, and I hope you enjoy the rest of your day. Thanks for having me here, and good luck.   Thank you for listening. Don't forget to check out our other shows, the Data Engineering Podcast, which covers the latest on modern data management, and the Machine Learning Podcast, which helps you go from idea to production with machine learning. Visit the site at pythonpodcast.com   to subscribe to the show, sign up for the mailing list, and read the show notes. And if you learned something or tried out a project from the show, then tell us about it. Email hostspythonpodcast.com   with your story.  

And to help other people find the show, please leave a review on Apple Podcasts and tell your friends and coworkers.