Colin: 0:00

The person giving your demo is also the person who initially called you or scheduled a meeting with you. So we're not we're not trying to replicate what you currently do or trying to make it better and replace it. We've done over 1500 hours of development in the Americas in 2023 alone. Almost 250 new subscriptions with 110 earlier multi-year descriptions. Our back end is actually a custom Python framework. And then our front end is actually a JavaScript framework called Owl.

Emilia: 0:30

Welcome back to Planet Odoo. Well, unless you're new here, then in that case, hello and thanks for joining today's conversation. Make sure to check out all of our episodes on all of your favorite listening platforms every Tuesday. On today's episode with me, Emelia, I am joined by Colin and John from the sales team and Developer Squad. They are two of Buffalo's longest standing employees and masters of their craft, which is assisting customers in finding the best solution for their business and then building it to meet their needs. I am not the most technical person, so I brought in two of the most technical people I know so they can explain to all of us what the heck is happening inside of Odoo and the processes that go into bringing you the perfect solution. Whether you're a business owner, entrepreneur, customer partner or someone interested in Odoo. This podcast is for you. Welcome, Colin and John. Thanks for joining us at Planet Odoo.

Colin: 1:22

Thanks for having us. Yeah, it's a pleasure to be here.

Emilia: 1:25

You guys having a busy day or is this the first thing of your day?

Colin: 1:28

Somewhat. You know, I always find things to do, even when I don't have anything specifically assigned to me.

Emilia: 1:33

So Colin, here is a team lead with our direct sales department in the Buffalo office and John, affectionately known as JOT if I reference him as that is part of the developer squad and he is the team lead for that department here at Odoo Buffalo. And so his job is to kind of develop the software for the customer, pass any customizations or anything out of the box that is specific. And we do all of that in-house at Odoo, which is really, really awesome. And Colin runs the team. That is the first kind of interaction that you have with the company. So when you're interested in looking at a new ERP software. And so I really kind of want to jump in immediately because you guys do similar things just at different ends of the customer experience. So what is the difference between development services and research and development, would you say?

Colin: 2:24

I think I can answer this one best, so let me start with research and development. Those guys are basically in charge of all the features that every single Odoo customer sees. So all of the core apps that we sell, that's what R&D kind of does development services. On the other, on the other hand, is custom tailored to specific clients. So when those features that R&D develop, the clients find that it's not sufficient for their use cases and they just need that very niche feature, we come in and we'll actually do those for that one particular client only.

Emilia: 2:59

Okay. And then Colin, when people kind of come to you and you're looking at the holistic picture of the software, at what point do you kind of realize that there might be developments that might be needed?

Colin: 3:10

Yeah, I mean, it all depends on what they're looking to do specifically. A lot of the times it can be handled out of the box, but there are use cases where an integration or a custom development might be necessary. A lot of it comes down to what they're looking to do with it and what industry they're in. But overall, that's kind of where the differentiation happens, is whether it's a hard requirement for either regulation or the specific industry they're in, or maybe it's something that they think they need versus actually being able to do out of the box. So there's always that differentiation as well.

Emilia: 3:48

Okay. And so when when looking at the software, we're talking out of the box customizations and developments as the three different ways that you can kind of use Odoo. So when customers come to you, what is kind of the process that you go through when looking at those three different areas?

Colin: 4:04

Definitely. Yeah. So I mean, I always like to start out with a list of requirements. That way I can know off the bat whether just by reading through the requirements list, whether there's going to be something that potentially needs to be customized. And then from there, if it's something that isn't able to be customized out of the box, meaning using our studio tool and dragging and dropping fields or making relationships between different models in the database, then that's where we'll create a presale ticket and actually have a developer spec out the estimation for the like the requirement. And then from there we can speak with the customer on what is involved in that feature they're looking for.

Emilia: 4:49

Okay. And then I guess this is kind of general, but how often is a customization needed for a client, would you say?

Colin: 4:56

Definitely. I mean, in the world of ERP things. Seem to be getting more and more custom in the way that customers view the framework and view the platform in general. I think companies are going that direction as well. And with Odoo, there's a lot of ways you can customize the system at a low cost point using Studio. So I think customers who need a more customized solution or are looking for the more tailor made option gravitate towards Odoo anyway. You know, it's one of the biggest selling points that if you need to track a couple extra fields or you need a different model related in your database to provide more information from one area to the next, you know, you can do that relatively simply. And I think it's a value add to the customer.

Emilia: 5:47

And then when the sales team is looking at what kind of customizations might be necessary when creating that proof of concept demo, is that something that you guys do those customizations to show the customer?

Colin: 5:59

Yeah, I mean, sometimes it depends on how specific it needs to be. A lot of times you can get it to 80% of the way there where they can visualize and see what needs to be done. Obviously, you're not going to do every little customization that they need, but to at least demonstrate that the capability is available out of the box and being able to do that with studio, it's a relatively quick process and I think that allows the customer to know whether a customization will support whatever that that need is. Or maybe they want to explore a development route to have it even more customized.

Emilia: 6:37

And so then when the development reaches your stage, JOT is this something that you're seeing more specifically, how do I put this? Do certain companies of certain size more likely choose a development route or different industries, or is it a mixed bag?

John: 6:54

It is very mixed from what I'm seeing. You know, the really small businesses know those mom and pop shops tend to not want to do customizations in development, and I think that's more budget focused or as a reason and so much that they actually need these extra features. And so they're more willing to find workarounds or do things manually when we could automate it through a development.

Colin: 7:16

Yeah. I think in general, a lot of times most companies think, oh, like we need this super custom or super developed platform to run our business. But then at the end of the day, what it comes down to is, is there a return on that investment? And if you're building a feature that might not provide a return on an investment as of a five person company versus a 250 employee company, there's always that differentiation of whether it makes sense with your budget.

Emilia: 7:48

Gotcha. Yeah. So a lot of kind of what we've been talking about on the podcast is certain compliance things that we've been seeing kind of come up, whether it's within government or health care or and maybe even the cannabis industry, different compliance needs that customers might have for their databases. And I know what I've heard kind of odoo people say a lot is you can make those compliance requirements fit in odoo in a certain way. So are you seeing anything like that with these different industries that have certain compliance standards?

John: 8:21

Yeah. So things like it's mostly in reporting is usually when it comes to compliance, making sure all your reports are accurate and they have all the necessary information. So things like the cannabis industry has requirements on like THC levels and all of that which, you know, aren't standard features in Odoo, right? So those kind of require customizations because not every product is going to have THC levels, right? So we'll add those in and then we'll make sure they're in all the proper reports that they need to submit to the government. Other industries that maybe have to deal with, you know, government contracts might need additional requirements. You know, so a lot of government involvement is really where we get customizations to kind of fit each, you know, each area's requirements. Right, Right. Yeah. Localization is a big thing.

Emilia: 9:12

Oh, could you explain that more?

John: 9:14

Again, government requirements. But even then, like even even specific industries in areas have requirements on more reporting. I guess, you know, accounting is a big thing. Taxes, it's all about taxes.

Emilia: 9:31

Okay. So so when we're talking about determining whether Odoo is a good fit for somebody's company, obviously their first interaction is with the sales team. So when you get a company's requirements and they lay out all of their business processes for you, do you visualize the end goal or the setup? Do you kind of already see it working in your mind and then kind of have to just put it on paper, so to speak, or how does that kind of process go for the sales teams?

Colin: 9:58

Yeah, definitely. Would say the longer you're here and the more you play around in the software, the more you almost have a visual roadmap within your head of right. If feature or requirement x pairs with the solution in Odoo, you can start to visualize that in your head as you read through requirements list. The biggest thing with requirements list though, is you want to focus on the business outcome versus the specific process. Because what a lot of times companies will do is write out how they do things in their current platform. And that's not always helpful because we're not we're not trying to replicate what you currently do or trying to make it better and replace it. So I think that's really a big breakdown in terms of whether or not they're focusing on the business outcome or the actual process that they're doing in their current system. And then from there, right, it makes it easier to understand what they're trying to accomplish and it allows you to give them more options in Odoo versus having to go back to the drawing board and delve into the requirements deeper.

Emilia: 11:08

Okay. And then another kind of we just talked about customizations, developments and out of the box, but we also have different versions. We have our SaaS, we have on premise and we have ACH. So at what point do you kind of have the conversation with the customer about what they will, which version they will need? And, you know, generally speaking, how do you make that distinction?

Colin: 11:32

Definitely. I would say smaller, more standard project is it'll be fine on just odoo online. There's there's no issue with just hosting your your database on our online platform. You can still use studio. So you still have the ability to to customize out of the box. The differentiation with ACH comes in when there might be a development or maybe you have your own internal IT team and I think that's generally where I would recommend to a customer because there's just more administration level access to your database. And then if there was ever a time where an internal IT team wanted to make a development or just have more control over the the hosting option as well as like the database itself, it just gives them that that flexibility. And then on premise is usually, you know, there's there's some companies I would say out of fear want to host their database internally on their own server or, you know, on an AWS or something along those lines. But then there's the other half where maybe due to a government requirement for contracting things like that, they might want to host their own database to, to meet compliance needs. But generally that's where the distinction lies. Yeah.

Emilia: 12:54

And then when somebody chooses a version, I think for the most part you see kind of ACH And then on premise, do you come into play when databases are on premise?

John: 13:07

Personally, I never have, but I do know that there are the very rare occasions where other members of my team have done developments for customers who are on premise.

Emilia: 13:17

And what does that look like?

John: 13:18

Generally, we write the code and then we send it to them and we let.

Emilia: 13:21

And then they have to kind of implement it themselves.

John: 13:23

Have to implement it themselves because we have no access because. Exactly. So generally, if a customer does want to go on premise, eventually we still recommend they start off on for any developments just for ease of development and deployment and all of that. And then once they're ready to go live, then they can take everything back to their own on premise server.

Emilia: 13:41

Gotcha. And then do you ever go on site to help a customer who is on premise?

John: 13:46

I never have. I don't know of any of our team members have either. But, you know, it's something that I would be willing to entertain if it ever came to that.

Emilia: 13:56

If someone wants to send me.

John: 13:57

Yeah, absolutely. You know.

Emilia: 14:00

Okay. So I kind of want to talk about cost now with these developments and with the services that Collins team provides, what is kind of the the cost breakdown and how does that what are the components of the cost breakdown? So when someone's coming to speak with you and they're looking to introduce their project, how do you do a kind of a cost breakdown for them?

Colin: 14:21

Definitely, yeah. So presale, if we know of a development that's required for the customer, we'll submit a presale estimate. And so what happens is the presale team that handles developments will spec out the development and then estimate how many lines of code it's going to be, as well as the number of hours it will take. And what that really means is the lines of code are what odoo charges to maintain that code. So you're going to have technical support with that. Going to have bug fix with that as well as upgrade support with that, which is a big piece of it. Additionally, there's the lions or excuse me, there's the hours it takes to actually write the code. And that's also estimated during that process. And a lot of times customers will come back to us and say, well, why do we have to pay maintenance on the code? Well, the maintenance, if you think about it from the perspective of having an employee, if you're going to pay a developer internally, you know, $80,000 to do developments and things like that, the cost of maintenance is much lower than having an internal someone on staff.

Emilia: 15:38

Possibly and paying.

Colin: 15:39

Yeah, I mean, if you're if you're talking $18 per 100 lines of code, you know, you can do the math and understand that the the trade off between hiring a developer and outsourcing us outsourcing it to odoo is going to be much more cost effective. And the reason we started offering it is because prior to maintenance, there would be a gap, there would be a customer needing development, we would do the development and then we wouldn't support it. So then they would have to come to us for upgrades and it could be out of budget for a customer. So by having a specific amount that they pay every month or pay based on what contract they're on, it just makes it much more palatable for the customer and also closes the gap between standard upgrade versus anything that's customized or developed that needs to be upgraded, upgraded.

Emilia: 16:38

And I'm sure those those who are listening, who are developers themselves are going to find this next question kind of silly. But for myself, Jyoti, how do you come up with how many hours it's going to take and what it's going to cost, and what does that process look like for you and Odoo?

John: 16:57

Yeah, that's always an interesting question because I'm never sure if the numbers I provide are ever right.

Emilia: 17:02

So and it's an estimation, right? So it can.

John: 17:05

Change. It is an estimation and we make it very clear that these are not exact numbers. So generally, at least during the pre-sales, what we'll do is we'll just provide what we call a dirty estimate where it's more of a this is a very ballpark number based on experience. And, you know, just like surface level investigation.

Emilia: 17:23

If you.

John: 17:23

Know these. Yeah. So we'll provide, you know, a number based on, you know, maybe other customers have done similar things. So we'll give them a number. We'll usually give them an error to, you know, 50% error or 30% error. So it gives them more of a range. And even then, you know, still never sure if I fall within that range. I've certainly missed the mark before, but usually once the you know, they agree to that and it gets over to actual implementation, we will provide a much more accurate estimate and that will actually come with technical specifications. You know exactly what fields we need, exactly what views need to be modified, what code needs to be written and where. And that's all deliverable. So we'll send that right to the customer, go, This is exactly what we're going to do. This is about how long it's going to take. You know, that error number goes down. So, you know, if I was 50% before, maybe it'll go down to 30% and then we hope the customer approves it and then we can do that work and then we hope we fall within that range. Yeah. And, um, and then, you know, sometimes, you know, we get lucky and we discover something that was missed during this analysis and the actual development takes, you know, 40 hours less on a, you know, a 60 hour development. And we're like, yeah, actually we finished it in a third of the time.

Emilia: 18:40

That's awesome. And again, probably a silly question for for most for you guys at least. But what is running on the back end of Odoo that you're doing this work in? And what about the front end frameworks?

John: 18:50

Yeah, so our back end is actually a custom Python framework or you know, built out by PHP himself way back in the day and it's been kind of growing ever since, has lots of features. It's designed to be very modular, which makes it very nice for creating customizations for our clients, right? We can still keep most of the source code and then we only have to maintain the parts we write versus, you know, changing the existing source code and creating an entire copy of all of odoo. And it's millions and millions of lines of code, right? Can you imagine paying $18 a month for 100 lines of code for a million lines? It'd be crazy. So that's our back end. We run on Postgres for our database, which is a SQL database. It itself is actually open source and open source software likes using other ones. And then our front end is actually a relatively new JavaScript framework called Owl, short for Odoo web library and the declarative framework that kind of draws from other frameworks like React, which was built by. Facebook and view, which I actually don't know who made that those that one but developers who have played with React before, if they try to use Owl, they'll see a lot of similarities there. Okay. We just decided to do our own thing.

Emilia: 20:15

So then I guess the question becomes, do you ever say no to a development? All the time.

John: 20:21

All the time.

Emilia: 20:22

And then what happens in sales when the development gets rejected?

Colin: 20:28

Yeah. I mean, a lot of times we try to push away from developments even before they get to the developer team. Um, but sometimes, you know, you have to, you have to do it just so you can show the customer that, No, they said it wasn't going to happen. Right, Right.

Emilia: 20:44

You don't believe me? Believe this guy? Yeah.

Colin: 20:46

Usually when when it does come back as a no, there's usually a very good reason for it. You know, there's different technical limitations. There's also just other like, for example, if you were going to want to integrate to another POS system, well, ODOO has a POS system. So unless there's a I mean, a very, very, very good reason for it, the response is going to be, well, we have a POS system. So it's it's not something that we would we would do.

Emilia: 21:15

Yeah. Our connections to other softwares or applications, something you guys see a lot that's.

John: 21:23

Probably the majority of the big, big development requests we get. I think part of it is customers are ingrained in their existing software and they don't want to switch to odoo or adapt their workflows. And sometimes there is just things that Odoo doesn't support. You know, big ones are usually, you know, tax computations are a big one just because of, again, regional laws and stuff. It's just not something that's easily maintainable by any ERP software. So, you know, those are, you know, deferred subcontracted out, if you will, to other softwares.

Emilia: 21:57

So this could be like a company choosing to use maybe our CRM and our sales and our invoicing, but then wanting to stick with their inventory system that they already have. Yeah. And like wanting to connect that. Yeah. Instead of switching.

John: 22:08

That happens quite often for larger companies where, you know, it's usually only like one small department in the company that wants to switch to Odoo. And then often I also see companies that don't actually do their own logistics. So they actually, you know, offload their logistics to, you know, other warehouses and stuff. So those guys don't use Odoo yet. So we'll need to integrate and send data over between, you know, the company's products versus the actual inventory and warehouse team.

Emilia: 22:37

And then do you ever see any app integrations with some of the more? I don't know, WhatsApp, for example, something, something like that where it's third party applications like that.

John: 22:50

I think I've been asked about integrating with WhatsApp before, right?

Emilia: 22:53

Super random pulled that out of nowhere. But in general, like applications like that.

John: 22:58

I don't remember what happened to that one. It's been a while. But yeah, integration with other third party apps.

Emilia: 23:04

And then what about integrating with like hardware? So for example, lab equipments, is that something you guys see?

John: 23:14

Once I've seen somebody, it was actually a CNC. Somebody once asked if we can integrate e-commerce with their CNC. So just imagine, you know, customer goes on to their website, hits "Buy now" and then the machine and their, you know, factory starts making it. Obviously we couldn't do that one. That's one of the few we had to say no to, mainly because none of us here have experience with CNC. And there's no way they're going to ship $100,000 machine, you know, the size of a room into our office. So that would have been an on premise development and it would have been too costly. And I don't think it was worth it on our end to do that. So that's something we would say, you know, maybe a partner can help you.

Emilia: 23:57

So obviously when you're working with a customer, there's that point of contact that you're directly working with. How do you communicate with this person to get the best out of the relationship?

Colin: 24:08

Definitely. Oftentimes you're focusing on that person's environment and also the context that they have to work within in their own company. A lot of times there's different internal politics going on where they have to do certain things in order to secure buy in from people on their team. You know, the thing I always say is it's best to get whoever is involved in the buying decision, involved in the evaluation as early as possible. That way, one, everyone on their team is on the same page from the beginning. A lot of times if you bring in someone else who has to evaluate and and also provide buy in to to sign off on the ERP, it's going to offset and push out your timeline because then this person is going to want to know. You know, from a high level overview what the system does and then from there, retrospective or their perspective department, they're going to want to know how you would relate to them. And so it's all about relaying the information in a way that makes sense for that point of contact. You know, if they're an accountant, obviously they're going to be afraid to move systems because right when you're an accountant, you have a large responsibility. So if it's if it's that party, you're going to communicate differently than if it's a person who is a sales manager. Right.

Emilia: 25:38

Right. And making sure that everybody in the company is on the same page about that ERP.

Colin: 25:41

Definitely. That's the I would say that's the number one most important thing, where if a company is evaluating a new system that can offset things, waste Time is having a buying team that's not all on the same page. And at least right, you're going to want a single person leading that team as well, whether it's the owner or whether it's a COO, somebody in charge of actually compiling all of the information from, you know, the accountant, from the inventory guy, maybe a production manager and and consolidating that into one thought of whether we move forward with this or not.

Emilia: 26:20

And then when it gets kind of over to you, John, what is the communication that you have with the customer, if any, and the point of contact?

John: 26:29

Yeah. One of the nice things about my job or bad things, depending on the day, is that I don't often have to talk to the customer directly. We have our vsas kind of act as a filter to clean up my language. When the customer gives, you know, a request that seems unreasonable or kind of silly and vice versa, you know, sometimes they'll throw suggestions back and the customer will think that's dumb. But the BSA is kind of there in between, you know, kind of filter all that out and just give me the relevant information for my job and what I need to communicate back to them. And then occasionally I do get to talk to the customers and that's always fun. Yeah, I guess I shouldn't say always. It's usually fun seeing.

Emilia: 27:14

Do you find that you talk to a lot of other technical people when you're pulled into those calls or people like me where you have to kind of draw it out?

John: 27:23

I think kind of in between there there are times where customers have given me requests where I tell them outright like it's feasible, but it doesn't make sense. And sometimes they'll push back and they'll go, No, I can't. You do this and do that. And I was like, Well, number one, here's some documentation on why it doesn't make sense from a usability standpoint and also why it's hard from a technical standpoint, right?

Emilia: 27:54

And then sometimes they're able to understand at that level.

John: 27:57

One customer once asked if we could just copy paste the code from their existing software over to odoo to speed up the process. And so the whole range, the whole gamut in terms of technical ability and what they how they understand how software works.

Emilia: 28:13

Oh, that's funny. Um, Colin, please.

Colin: 28:16

Yeah,I was just going to add and also a lot of times Josh and his colleagues will get requests. Oh, hey, can you join this call? My customer has really technical questions that they need answered. And then. It'll be a question like, Well, do you have an API? Or like what is your API written in or what is written in its, you know, stuff that they could literally Google so.

Emilia: 28:39

Or ask a sales person.

Colin: 28:40

Right. Yeah. So a lot of times that's why when we do get that request for oh, can a technical team member join the call, we always ask them to send a list of the questions that they they need to ask them so we can evaluate whether or not it even makes sense to have a technical person on the call. Obviously, sometimes there's a little bit of that relationship building where you're trying to to meet them, where they're at, where, you know, just to to show face and make them confident in the solution. You might want a technical person on the call, but overall, most of the actual technical questions or most of the questions they ask are not actual technical questions. It's a lot of specifications and just system, you know, system information.

Emilia: 29:26

That they're requesting. Yeah.

John: 29:28

Quite often. I've sat in on some of these calls. I've been invited, you know, to talk to the customer, and then I'll just let Colin answer all the questions because I actually didn't need to be there. I was like, You're paying for this. Okay.

Emilia: 29:43

So speaking of customer questions, I have pulled some customer questions for this episode so we can get technical. These run, you know, all over the place with these questions I got. But I think they're great and we might as well kind of jump in with you guys answering them to the best of your abilities. So the first question that I received for our Ask an Expert segment is very sales focused, but maybe both of you can answer it is what is the catch? Odoo is so cheap but seems to be able to do everything we need. What is the catch?

Colin: 30:15

Yeah, I mean, there's a few considerations. I would say the the main one is that Odoo never had to buy another company to build out our platform or our product. There's a lot of legacy platforms that in order to stay relevant within the market, they've had to acquire other companies and that obviously increases the cost of the platform itself. Oftentimes there's also right with our sales process, we try to keep things very streamlined. Right. The the person giving your demo is also the person who initially called you or scheduled a meeting with you. So it's by keeping the cost of sale low and making sure that we're focusing on R&D and focusing on the things that matter, we can keep odoo at a price that's competitive and also allows companies from different markets to benefit from it, right?

Emilia: 31:07

So and as Nick Kazinski said on our previous episode, it just is a reflection of the value that it adds. And so for a smaller company, it will be representative of the value it adds. And for a larger company, the same. Exactly. Great. So next question is, is Odoo Enterprise open source and what is open source mean? So this came up earlier and I wanted to wait for this question for those of us who don't understand that.

John: 31:33

Okay, so Odoo is open source. Our enterprise features are not okay, but Odoo community has actually most of the features we see in enterprise already. There's actually a nice link on our website that actually shows you the difference. The big one is I think the more mobile friendly UI and accounting are big enterprise features which are not open source.

Colin: 31:58

But it's not only the features, it's actually the support in the upgrade support you get with Odoo. A lot of times when talking with customers that are on Community Edition currently, they're either hiring people to maintain their Odoo instance or they're having to spend a lot of time upgrading their community editions. Whereas if you're you're simply just paying for the enterprise license, all of that is included with your subscription. And so that just makes it much more streamlined and simple because you have people within our company that handle upgrades on a daily basis. So they're going to be much better at handling an upgrade than a person from your team who does it once a year.

John: 32:40

Yeah. So back to what your second question. What is open source? It really means the code is public. So it is out there. Anybody can kind of, you know, download it and use it and that's our community version again, and anybody can contribute to it as well. So any developer of any level of experience, they can look at the code and they say, you know, there's a bug in here, let me fix it, or I want to add this feature. They can actually contribute to the open source project, create what we call pull requests, and it will actually get reviewed by, you know, other contributors. And then if everybody approves of it, it'll get pushed into, you know, the the source code and it gets sent out to every one of our customers. Wow. So open source literally means that it's open source code. Wow.

Emilia: 33:29

So another question that I received, which is is kind of similar to the you know, what is the catch? Why is it so cheap? And just the background of odoo is we have only ever heard of NetSuite, SAP, Acumatica. Why have we never heard of you?

Colin: 33:47

Yeah, that's something you get once in a while. When I first started Odoo, that was something I would get a lot more. But now I think in terms of our our market presence, we're a much more mature product. And so there's obviously the different avenues that we we actually spend our money on. And one of those not as heavily as other companies is marketing, where, you know, a lot of the legacy ERPs really focus on spending their their dollars on advertising. And so you know that's a big piece of it. Additionally, it's just one of those things. As we grow, we are more heard of and it's one of those things. I argue now that when you compare us to a legacy ERP, you know we are a big dog now. We are like a market leader. We we have everything that customers need and it's in a way that's easy to use. It's scalable for an organization and it's also much more easy to customize than most legacy systems. So when customers ask that, I mean, it's one of those things I honestly I rarely hear it now.

Emilia: 35:02

All right. So my my last big question here, because I think some of the other questions I got, we've kind of already explained, but if someone wanted to implement the software by themself, what would they need to know or expect? So obviously we sell the subscription without implementation, though we recommend implementation because it's done in house as you can see. But if they don't decide to go that route, what would they need to know or expect?

Colin: 35:28

Yeah, I mean in terms of implementing ERP software, if you've never implemented an ERP software, you shouldn't implement it yourself. That's never going to be a fun time. So you should always have an implementation party assisting you with the implementation. Odu's Quickstart methodology really focuses on on training the trainer. You know, our goal isn't to have you come back for every little feature that needs to be configured. Once you're live, it's to have you operate as an expert in the software so that if you do need to implement another module, someone internally can. And there's also, you know, expert resources within your company. Now, you know, if you if you've implemented an ERP before and you want to try your hand at it, you can always do that. But with the support of an implementation expert, either internally at ODU or through an external party. Great.

Emilia: 36:22

And then what about over to you? I'm sure you're going to have a tidbit about why people should or should not implement themselves and or what to expect.

John: 36:31

I can only speak to the development side of things and I have seen code written by self implementers that are absolutely atrocious. Unmaintainable they'll, they'll write, you know, 10,000 lines of code for something I can do in ten. Right. So if you're going to do any custom developments, I would have an experienced developer or somebody you trust.

Emilia: 36:53

Someone who's an expert.

John: 36:54

And somebody who is an odoo expert to create these developments for you.

Emilia: 36:59

Great. Well, thank you guys so much for answering all of my silly technical questions. And thank you for joining us on Planet ODU.

John: 37:08

Thank you for having me. Thanks, guys.

Emilia: 37:10

Well, that's my cue. Thank you for joining us today. And if you liked it, take a look at some of the other episodes above. We have tons of other stuff. Talk to any expert from the Belgian team or join me and talk to more people from Northam. Go check out all of our episodes on your favorite streaming platform and come back. Bye, guys.