Transcript: Django for the Meat Industry - Bryton Wishart

I'm Will Vincent, joined by Carlton Gibson.

Hello, Carlton.

Hello, Will.

Welcome, Brighton.

But you live in Australia and you're building this real-world solution with Django.

So I'm excited to talk about what that is and how you've done it.

So maybe could you give the quick pitch on what is cured compliance?

So cured compliance was a bit of a brainchild between myself and my business partner who just happened to be a butcher.

But what we've looked to do, I guess, is digitize all the compliance and regulation that a retail butcher in Australia has to do.

So, you know, people don't realize the amount of, I guess, regulation that goes into making meat safe and, you know, ensuring the meat that a butcher is selling to us consumers is safe and you know uh fit for human consumers.

Um so it's yeah, we seem to move very we seem to like regulation in Australia.

Because like one of the supposed as a Brit, one of the supposed advantages of Brexit was that we'd be able to import US meat.

And then like, but hang on, US meat, the standards aren't quite what we were used to.

And so there was a bit of like, is that an advantage?

I don't know.

Anyway, carry on.

Yeah, anyways, we don't need to get into that.

But yes, it's it's good that especially food that we consume has regulation, and so there's quite a lot of it in Australia.

So it was kind of this opportunity to really innovate the industry, right?

Which was awesome.

Um, so we're still a fairly young startup, but I maybe started this six months before we incorporated.

Um so it's sort of been about a three-year, six-month journey, and that's realistically where I sort of found Django.

So that was kind of my first time I touched Django as a framework, um, was sort of that three years, six months ago, uh, just kind of when we had this idea.

You were assessing two or three options that are out there.

Well, what stuck out about Django?

How come you sort of, you know, because you've been taking a bit of a punt if you didn't know it previously?

I sort of had a fundamental knowledge of Python uh from the early days.

Um and this was back sort of when the machine learning kicked off with the the introduction of the cloud computing.

So I had I'd sort of done a bit of work with Python there and went, that's kind of the language I know and trust.

Um, and then just went hunting for frameworks.

And for me, it was all about I didn't want to do the difficult things like manage authentication, manage all of those sort of things, I guess that you know we say is batteries included, um, that some of the other frameworks just didn't have because yeah, you don't want to get authentication wrong.

So but so that that batteries included thing, that's a real big selling point, right?

What was the you know, start project and and then what?

And that's that was kind of the start.

Um, and and originally when this started, it wasn't so much we wanted to make a product to sell, this was how do I solve a problem for my mate's business, more or less, right?

How do we digitize this and make it simple?

Um, and so there was kind of no plan to productize this or commercialize it anyway, shape, or form.

It was purely let's build something.

Nothing, you know, we did the first bit of research was which was does something exist in the market that we could just buy and use and solve the problem?

Um, and there was kind of nothing designed for the meat industry.

Um, everything was very much a hey, you're a cafe, these are kind of your pre-start checklists, and that's that's kind of it, right?

So there's a bit more involved, especially when you're doing um like small goods production, that sort of stuff in the meat industry, you've got to have that traceability layer.

Um, and so there was sort of nothing out there, and we decided to do the uh idiotic thing and build it ourselves.

Um, so because often people start with the models and then they build a view and then the form comes last.

But you've because you're starting from these paper forms, is it almost the other way?

And you know, you back then you'd write your you'd write a sequel a SQL code to deploy to a database, and that was it.

So this whole model and RRM was a very foreign concept to me as a developer, like it wasn't something I'd touched before.

So um very quickly learned that the RRM and models were my best friend, and it meant I didn't have to write SQL, which was amazing.

Um, and then it was kind of this build the form, build the model, and start to really think about what what do models need to look like to digitize, because there was a bit of a learning curve going from here's a paper form that sort of has here's all the information they want to capture, but how should this best be designed into a model that's gonna allow that whole class-based driven, you know, automatic form and all that sort of stuff?

I um I got very, very comfortable with working with migrations and rolling migrations back and doing all that sort of stuff um really quickly because yeah, you do make mistakes in those models and you go, that's just not gonna work, especially if you start thinking about how does it scale, right?

Um, so originally when it was just sort of this one thing for one person, it was like, yeah, whatever.

Um, but then kind of as another person went, hey, I'd like this too, we went, oh, okay, how do we how do we make this better, I guess, from a design point of view?

So, like, you know, because it's just for your mate, you don't need to restrict the query sets.

Um, and you know, I think originally I was using just a default um user profile, and then I hit that part where we're kind of up and running with our first first customer.

I went, oh, I'm really limited of what I have what I can do with this user profile from day dot.

Um, and so I had to go and do the extended um custom user model to add those additional attributes, right?

Um, which then meant restarting the entire project, restarting the migrations.

Um, and lucky enough at that point in time there wasn't really any data in the system, and the other customer hadn't been using it for that long that they were like, Yeah, that's fine, blow it away, start again.

Um so I sort of learned that the hard way, which was fun.

But it's a good thing to learn that lesson at that point rather than sort of much later on when Yep.

At what point so you have so the models alone is a huge thing.

At what point were you working on the interface that the you know n the butchers could use?

Like how long did that take?

Um, so I'm lucky enough that I know someone who's very, very good at that user experience um and is really good at CSS.

So I we ended up just contracting him in to do sort of one day of work a week on just helping making the user interface.

Um we chose Bootstrap as a simple framework to work with from that UI experience because people are very used to that look and feel.

Um, and then it was kind of how do we simulate the paper, like how do we make the form, the digital form, look like the paper form?

Because butchers are kind of in that digital divide where because of COVID, a lot of shop prices went up, but before COVID, big supermarkets have sort of driven down the prices.

So you sort of have this generational gap of butchers in Australia.

Um, and so it was kind of that how do we how do we make this digital experience as closest to the paper experience for them?

So they weren't sitting there going, what does this additional field mean?

How does it flow?

Um, and then it's kind of that, yeah, we just started there, and that was kind of the starting point.

And it's it's sort of evolved over time as we've optimized forms, I guess, where you're not double handling information or where passing data through between different forms, etc.

Okay.

Because I guess if you want to match a paper layout, did you use something like crispy forms?

Because again, I I don't want to blurt my HTML up HTML up where it's like let the framework do the heavy lifting to a degree, right?

Well, as much as you can, right?

Well, it sounds like the butchers really hated the paperwork because getting people to switch, even if they have some annoyance, is you know, famously hard, right?

It has to be really overbearing to to have someone, you know, take time out of being busy to learn a new system.

Um, but I guess that sort of proves the efficacy of what you're trying to do if uh at least one or two people were willing to go down that journey.

Because, you know, I guess as an application in a regulated industry, your app is only as is is only effective if the regulator actually supports it.

Um so if we we built something the regulator went, nah, that's not right, we'd be down the water.

If they're used to accepting forms, paper forms.

So an auditor will come out on site to the shop, and that's kind of where they would view all those forms and tick that off.

Um, so we've sort of done those training sessions with their auditors to go, hey, this is how you can see this type of information.

Um, and they've actually really adopted, I guess, really loved it because for them it's not looking through two or three binders of forms.

It's cool.

I just want to look at this information quick and easy.

Here's a filter, bang, done.

Um, so it's sort of streamlined some of their auditing processes, which has helped a lot as well.

They can do it in the office before they go to the shop, and then when they get to the shop, you know, they can spend more time actually inspecting rather than looking at the paperwork, which is a possibly a win.

And one of the things we're sort of looking to roll out with, I guess, regulators in the long term is that whole digital audit experience.

So it can be, hey, I'm just gonna rock up and walk through your shop now to make sure it's clean.

But everything else is done.

You have some internet of things, internet of things around temperature and like walk us through like what are all the things, and then how do you you know sync that up with with the dashboard?

Let me go and see if there's something we can buy off the off the shelf, right?

Um, which, you know, the great thing is there's a lot of sensors that do that job for us.

Um, but then I was kind of like, how do how do I actually plug this into the Django, right?

How do I get the data there?

How do I how do I store the data efficiently?

And how do I, you know, create the interfaces that you can view and see the data?

Um, because having the data is one thing, but if you can't view it, it's it's worthless, right?

Um and so we sort of started with this.

We found a a a vendor that sold these really, really just basic Bluetooth gateways.

Um, and we went down the road of Bluetooth sensors using just uh Bluetooth low energy sensors.

The idea being they were cheap.

If a butcher broke them, it wasn't gonna break the bank to replace them.

Um, because butchers' apprentices are known to just wash everything with a hose and including electronics.

So having those sort of cheap replaceable sensors was kind of a yeah, the idea was, hey, if you break one, it's not gonna be the it's not the end of the world, you're not paying $500, it's a you know $30 sensor, just buy another one.

Um, and then we had these gateways, and originally these gateways were just doing post requests to to an endpoint that I wrote, um, which then sort of raced me as well, how do I secure this endpoint, right?

Um, because these gateways don't do authentication.

Um, so I actually had to then write some middle um middleware that worked more or less like a whitelist.

So it would look up the customer's environment, go, does his MAC address as a gateway be registered in their in their environment?

If so, that's an acceptable post request and accept it.

If not, just drop it pretty much at the at the server level.

So had you done like how did you know about this concept of middleware and to take that approach for this problem?

So I've I've got both of your books, Will, from memory.

And I'm one of those people, once I read a book.

Well, it's not in there.

It's not in there, right?

Um, and that's kind of where I just started digging deeper and reading the docs, to be honest, as like, hey, how does middleware work?

Um, and then you just start doing the old Google search for tutorials on middleware.

Um, and that's that's kind of

Yeah, quite soon off the bat, you're now storing um time series data from instruments, which like that just must stack up really, really, really quickly.

And lucky enough, I only take one measurement every five minutes.

Okay.

So it's not it's not every second.

Um, every second would be a different game.

Um, but you know, Postgres is very, very good at doing this type of stuff.

And it's kind of one of those things.

Do I do I op do you, you know, the old I guess developer problem is do you over-optimize and start thinking about that, or you go, do we wait until we have a problem and then go, cool.

Hopefully by then I've got a bit more money that I could throw at the problem and get it resolved that way.

Yeah.

Um, we are just slow and steady growing as a business, which is wonderful.

I'm sort of, you know, this is still myself and my business partner and our one contractor.

Um, so we are still a very small startup, and there is a physical limit of how many customers you can onboard because of that.

Um which is, you know, I think a blessing in disguise because it means I'm not dealing with hyperscale, and hyperscale is scary.

And it gives you time to grow into the bigger things, and oh no, we can do we can tweak the database, we okay, relax a bit, tweak, tweak the server, okay, relax a bit.

But someone who's newer in their career, like how exactly did you do that?

Did you use Django Rest framework?

Did you use Django Ninja?

Like what you know, yeah.

Since you said that the rest of the rest of the project is explicitly not really using APIs, you're using HTMX, so it's server rendered.

But I'm pretty sure

That means it's just working.

Um it then just either returns a HTTP response 200 and grabs the uh the JSON data and loads that through.

So it's yeah, not using REST, not using anything like that.

It's just a boring old function view.

I mean you're making me think that maybe that's an interesting angle to you know teach people about API stuff rather than just jumping right to rest framework or some of these things, be like, well, you we can do it a little more simply.

That's interesting.

Not to get off topic, but

Right.

How do we approach that?

And that sort of brought in, I guess, if you consider the sort of the lifespan of the app, we we started with a real basic web app that you know was designed for one person realistically, and then also another person went, I want that as well.

And went, oh, now we have multi-tenancy.

How do we approach that?

Um, and so you know, the great thing is we have a really good rich environment, I guess, in Django of all these third-party add-ons that it's very easy to get this sort of functionality without doing a lot of engineering.

Um, and then the alerting brought on that whole well, now I need some form of task processor.

Um, because you know, you can't just do that, I guess, off a.

I'm sure there's a way you could do it, but it's probably not the efficient way or the right way to do it right you probably need some sort of background processor running to to do this alerting or alarming or have the hardware do it for you and obviously the hardware could alert you but at that point we just didn't have the hardware that had that functionality.

So we ended up looking at Django Q and that was kind of the one that I went that's simple to deploy um it really just needed a Redis service uh server to to act as its queuing mechanism um and I spent a lot of time with salary but I just found its learning curve to be too great at that point in time right um Django queue sort of everything was built into Django admin so you could just log in and go let me

create a schedule task and off it went.

just in time for I think Stan to release Django Q2 because Django Q as itself was also I guess a stale package and wasn't getting any sort of lover updates.

So I then had to rewrite this I guess uh package to then support Django Q as well and sort of go through those changes that Stan made as well.

You could go down the road of having a database for every single customer which you know is probably the most secure and secure way but probably the least cost effective way.

And ultimately it was the schema separation and just that inbuilt in the Django tenants that kind of went this is probably the easiest way for me to do it without having to rebuild every single model with a with a tenant field more or less.

And so trying to wrap my head around what what are they what exactly are they asking there?

Are they they just read about it or do they you know I thought you give a nice summation there of it.

So every customer has their own you know business name at q compliant dot qitcompliance.com so they it creates a bit of ownership opposed to maybe using something like a header approach where they just log into a single website and it's um you know the header handles sort of the tenancy aspect on the back end.

So I think that creates a bit of a customer ownership piece um but it also opens up the ability in the future to do their own sort of CNAME branding as well right so if they have their own domain they could create their own cured dot their domain dot com type approach as well and we could support that from a DNS point of view.

Just while we're on this last bit so are you now um helping to maintain Django Q2 or are you in that sort of around the ecosystem there just keeping your eye on it?

I haven't packaged it up but there is I think a link on Stan's GitHub to it for anyone who does want to use it.

So you can just fork my my version and be up and running more or less.

So yeah I am a little bit involved there.

One day I hope to be involved a lot more but I'm still still a learner in that sense.

You know I can I I had done sort of previous work where I'd help customers deploy you know Azure web apps with databases in that sort of pass environment world.

So for me it was kind of you know that dev ops piece was actually the easiest part of the whole the whole process um it was the the learning to be a developer was the hard part.

I think my hosting's been covered for about four years or three years so far.

Okay.

So we sort of we've transitioned away from that that post that post request type uh process I've still got a few customers on that older hardware um but we transitioned to I guess to a more robust um messaging protocol and that was really around we found some hardware that we could build up functionality and capability in the portal to actually program the hardware so it allows a customer to go into the portal go hey I want to you know change something on this sensor and that's going to push down through the M

QTT gateway and program that sensor to that point.

Now we've still kept that sort of Bluetooth approach in terms of sensor tech, but that MQTT sort of approach has just opened up a whole lot of functionality.

And that's then started to get me thinking about well, we have we've been trying to solve this one problem, and that is when a butcher does a cooking, so let's say they're cooking ham or bacon, um, at the moment they use a data logger.

That data logger goes in the meat, measures that that.

That's normally a USB type device.

They then have to plug that into a computer, download the Excel spreadsheet.

And we wanted to create, I guess, an experience where Butcher could just put in our hardware, go into the go into the cooking log and just hit the start recording button.

And straight away you have that that cooking log being put straight against the actual log with you know pretty graphs showing cooking temperatures, all that sort of stuff as you know as it flows.

Um, and so that's sort of we tried to find, I guess, hardware that suited that requirement, and we couldn't find anything.

So I again did the old Google around, hey, what could I use, you know, what what could I use in Python to help me build sort of, I guess, that next layer down of hardware.

And um MicroPython was kind of this great package, I guess, framework again that has quite a lot of functionality that I could actually start working with.

And I think I ordered in a couple of ESP32s and plugged them in and just started plugging away to sort of build build this stuff.

Um, and you know, I ordered in some decent thermometers that, you know, I RTD units um that sort of had the requirements.

And, you know, again, pulled out my old physics textbook on electrical engineering and started going rereading, you know, things like Own's Law and Growing.

That's right, you know, all this sort of stuff.

Um, and you know, just started sort of working on some circuitry stuff and you know, reading different parts.

And so we ended up to the point where we've got a prototype um unit that works there, but just the capital expense right now to take it to the next level is sort of you know 15, 20k.

Yeah.

Which you know, as a again, you know, a small startup, it's you've got to look and go, do I spend that sort of investment on such a single piece of hardware, or is there money better spent on other aspects right now to you know help growth and whatnot?

But I can imagine it's also a bit of a rabbit hole that you can be like, oh I could be fixing this UI bug that I don't really, or I could be playing with my microcontrollers.

That's a bit of a risk, huh?

And it's that whole, you know, how how thin do you spread yourself across something, right?

Um, and yeah, that's that's there's a reason it kind of got to a point and it's like, yep, there's a prototype, I could give that to somebody else to manufacture, and they could, you know, improve it.

I mean, I guess you contract that out once you get to a certain point, you can contract that out to companies in China, right?

Who will put it together and all the rest.

Um, you know, once you've done all that, then you go, you know, go to a manufacturer in China and go, I want a thousand units of these and you know, give me your best price pretty much.

But it's kind of that you've got to do that certification step first.

So it's could you

I don't think it's patentable to a degree because it is just a thermometer, and the purely the reason we're rebuilding it is we just weren't happy with the accuracy from a compliance point of view.

Um, and that's because there's kind of a range we've got to work which is negative 30 to about 120 degrees, and we need to be within 0.5 degree accuracy in that range.

Um, most otherwise won't be accepted by the regulator.

Most thermometers that they're that they're using at the moment actually don't meet those standards.

But we don't want to be that that company building something that doesn't meet that standard, especially when you know the strong point of our company is we are backed by the regulators to a degree where they've gone, yep, we're happy for this to be used and we trust them to deliver XYZ for us.

You have paying customers now, right?

It's it's moved beyond your just your your business partner.

We've I think my last count was about 50 butchers across Australia, um, paying a monthly subscription.

So yeah, this is we sort of pick up two or three, uh yeah, about two or three every fortnight.

So one a week on a growth, and it's just that's a nice nice, slow, and consistent, which is what I like.

The first is so what are you using to for subscriptions?

How are you managing that?

Stripe is really, really good at that stuff.

Um, and again, you know, there's a wonderful package for Stripe that makes it very, very easy to pro you know, manage.

Yeah.

Um and the one challenge we actually had there was the way the webhook works from Stripe.

Um, and the way I guess because every request we have comes from a customer's tenant that comes from its own C named URL, um, the Stripe, the Stripe endpoint, you know, I'd have to have a webhook for every single endpoint.

So I actually wrote a very tiny Azure function app um in Python that just sits there as a middleware more or less and collects their web endpoints and then based upon the metadata in the endpoint, then redirects it to the correct um tenant for ingestion to update the subscription.

I'm I'm working on a sort of e-commerce course, and subscriptions is a big thing that sort of can be simple to simple to do in prototype, but then often has a little bit more complexity than people think.

And also then you have to dive into user accounts and how do you you know manage it?

Do you have a flag?

Do you how much are you tracking?

Churn so it can quickly become a rabbit hole in practice.

I am uh discovering.

But sounds like it wasn't much of an issue for you.

You just Python package from Stripe and yeah, write a couple of middleware and you're good.

And again, it's I could definitely improve it, but if it's working right now and it's not a security risk, I'm kind of looking at the technical debt going, do I need to pay it right now?

Right.

You've got a business, you're up and running, you're three years in.

Okay, so this is a good place to be because now you but now you've got this sort of okay, how do I spend my time?

Am I building new features?

Am I paying down some of that technical debt, cleaning up some of those gnarly bits that have been there since week two?

And yeah, how do you how do you balance that that kind of consideration, Need?

Not much, but if you pay back a little bit every single week, you never get into that really, really bad situation where it's like, oh, I can't upgrade because of something.

Um and I I guess I've been in I've been in a couple of companies where they never paid technical debt, and I've kind of seen that hell, and it's like, okay, you know, it's only going to be a couple hours every week, but that's enough to sort of keep you there so you you know you can do those really simple upgrades between the different versions of Django, package updates, and not have everything fall over.

I would try and put aside a Friday morning, it's like, okay, a couple of hours on a Friday morning to just you know clean the floor.

Like from my experience, one of the problems with technical debt is the people deciding on what to do next are a layer up or up, and so they're not feeling that pain.

So to them it's an abstract thing, but when you're on the ground floor fighting with it, uh uh it builds it builds up and takes an emotional and time toll on you.

And it's like, but hang on, you realize you're you're killing us slowly here, right?

With this constant grind.

Death by death by a thousand cuts.

Like it doesn't it doesn't seem like you've hit major stumbling blocks with Django specifically.

Um, is that fair to say so far?

Um, you know, compared to some of the other people I've spoken to who I guess are using more of those Java or no type type frameworks.

Um, yeah, it's nice that it works.

That's that's a really nice benefit, right?

We should get some t-shirts for that.

Yeah.

So Magic Wand, what you know, what would you like Django to add, right?

Because this is obviously Carlton and I came from DjangoCon a couple of weeks ago, and this is always the discussion internally.

Like, are there some things that are top of mind?

You know, if if Django only had it would make things easier for you.

Like, I can't if you look at all the security frameworks, you know, that the default requirement now is that any web internet-facing application you're using has or supports multi-factor.

Um, and I think that's something that probably needs to just be an inbuilt battery now, opposed to potentially a package.

And if yes, what are you using?

Yeah.

Yeah, okay.

That's the one.

So maybe not as big as this, like right now, but um I think most people would agree, like, yeah, we should we should have this or something like this in core.

So it doesn't have to be you know every possible option, but you know, an out-of-the-box look to FA.

That would be lovely.

I guess with butchers, you don't have people saying they want single sign on to their, you know, to their global provider or anything, but they yeah.

How do you guide can I ask butchers that like traditionally not thought of as like the most technically sort of connected people?

So how do you um educate them about using two-factor auth and things like that?

Do you guide point them towards a password manager or

If you consider every bank this day forces two-factor on pretty much all their consumers, um most people get get two-factor these days.

Um, you know, if you went back before COVID and maybe a few more years then, I definitely know my RT Pro days, there was always a massive change project to get multi-factor or something rolled out.

Um, but I think banks have done an amazing job of just forcing it on everybody and everybody's kind of accepted it as a security improvement.

So the discussion doesn't get too hard to have about about two-factor football, just because they're kind of used to that already from their banks.

Okay, okay.

I think that might Australia may be a little bit ahead of other places in in that.

What's on your road then, Brighton?

What's what's what you know, the next 12 months, 18 months, if you could knock off a few, you know, headline features, what would you what are you excited to build?

Um, and this is not so much because of the AI boom, but more around there's just a really no novel problem I want to solve, and that is at a regulation level, a butcher is meant to be monitoring the meat temperature.

Um, so that actually means the actual temperature of the meat, not just the refrigeration ambient temperature.

And so what I want to work on is can we have a probe unit sit in the meat for a day, have the ambient temperature and the probe temperature running side by side, and then based upon that develop an algorithm that's unique for that fridge going, cool, if your fridge is saying this degrees, then your meat temperature is going to be this degree, and depending on how long the meat sits in that fridge for or display cabinet, um, it will slowly warm up over a period of time.

So being able to then predict this is what the meat temperature should be to provide that, I guess, that next level of assurance.

Yeah, okay.

And you know, you look from a pipeline, as soon as you have that fridge go outside of its ambient temperature parameters, you could then invalidate that machine learning model and go, because the fridge has changed this, this is no longer a valid thing, so you need to re-measure.

And you and you or you've got to measure more frequently, or you've got, you know, because yeah, and all of that can be ticked off by the regulator again.

And yeah, okay, that sounds really interesting.

It's not building some crypto or something, it's like, here's a practical use of machine learning.

You're gonna fit to a cup of yeah, good.

But people would go into the freezer and in the freezer they would lose cell phone or they'd lose reception and they come back.

So they had to do all these technical things around offline versus online.

It sounds like that's not an issue for you at all.

Like people are just entering it in on a computer, so you don't have to deal with that situation.

Um, but we are, I guess, a reactive web app.

So we do build down whether you're on a mobile phone, a tablet form factor, or a PC.

Um, so for us, a lot of these butchers, it's more just getting Wi-Fi signal in the shop.

Um, you know, they might have their their little consumer router sitting in the office that's in a different location, but then all the work is happening quite a you know quite a way around away through multiple brick walls.

Um, and cold room, cold rooms are very, very good at blocking signals.

Um and so we've sort of had to help, and that's kind of one of the things that our gateways also do is they act as an access point as well.

So our new gateways not only do they do the MQTT, but they're also an access point that can then relay internet's connections via either an Ethernet or via Wi-Fi.

Yeah, running Ethernet in and you plug into the gateway and off it goes.

Um, if not, you put the gateways next to each other close enough through the walls that they can talk wirelessly and they just act as a wireless bridge and off they go.

Oh, I'm really excited.

Your business sounds brilliant.

I guess I can't help but think of the business case.

Like how many, like how big could this get, right?

Like how many local butchers are there?

You know, at what it so that's the first part.

And the second part is at what point do you say, I need help, and what does that help look like?

Is it purely technical?

Is it other areas, right?

Um, then there's a whole lot of processes and about 500 abattoirs as well, uh, from a small abattoir point of view.

So we've sort of looked at going, if we can own the butcher market, um, it it provides us a really nice stepping stone to start talking to processors, and then you step again into that small abattoir space.

And we've sort of got a lot of support from the industry to to do that from a traction point of view, which has been wonderful.

Um, you know, I guess for us at some point we are looking, we are working with the industry body to actually see if they want to fund from a fund this sort of development work.

Um, at which point, you know, it'll be nice to have more technical people helping build this, be able to move a little bit faster.

Um, but it is, you know, as a bootstrapped business, you can only move, I guess, as fast as your your cash in the bank, right?

The capital.

Um, and most of the time that is how do we how do we count the cents and not spend money where we don't need to spend it?

Yeah.

And then if the growth comes later, you're all the more set up for it, anyways.

Yeah, definitely.

And it's we've really wanted to avoid that because as a business, um, we're more we really focus on we want to be a purposeful business that actually helps the industry.

Um, and we think taking that investment money um just wouldn't allow us to be that to be that mission-based business because ultimately we're about how do we create safer food, um, you know, fundamentally, and you know, how do we help the industry?

And that's only gonna work if we've got a business that is there to actually help the industry and not not about how do we pay back shareholders as quick as possible.

Yeah, no, it's been it's been great just chatting about it.

And I think it was a a a really fun exercise to actually sit there and start to dot out all the all the things I've actually done because I think sometimes when you're in the business, you don't get time to reflect and go, wow, what have we we've actually done quite a lot of stuff.

Well, and you when you um emailed us, you know, you shared you have this demo app, which is a great way to to actually play around with it and see it.

And I imagine you can share a version of that with prospective customers too, where they can see, oh, this is really what it might look like.

Like that's a very powerful uh demo to have like a a you know, real life demo version.

So that demo just lets them actually see, oh, it's not scary, it is actually easy, it's you know, the user interface isn't overwhelming me from a user point of view.

It is I I think I can make this change, and then it's kind of that support piece to get them there.

Keeping it

So I really trust him to look at you know what I build and go, can we simplify this?

Can we make it a more cleaner experience?

Um, you know, is a button three pixels too far to the left or something ridiculous like that?

And he'll spot those type of things and be like, yep, let's adjust it, let's do all that.

Um, you know, even down to like icon icons, consistency of icons and all that sort of stuff throughout the app.

So, you know, when somebody looks at a button, they go, Oh, that icon means this.

Um, like I don't think about that, but that's kind of what he does.

And um, yeah, you sometimes you just need that person who's got a different view on stuff to go, hey, I can build a lot of stuff, but you know, it's not gonna be pretty.

I need you to take it to that next level.

It's good to know what you're good at and what you're not.

I mean, I really appreciate you reaching out.

We don't, to be honest, we don't usually say yes when people call to email us, but we we love when people do, and we can have these discussions about, again, real-world projects being used with Django.

And I think it definitely in informs my perspective and you know, listeners who are involved with Django development to try to be aware of this and you know, listen to what you're saying, especially around two-factor auth, you know, these these things that we can do to be a little less insular.

So I really appreciate you taking the time to come on and share the story.

Yeah.

It's been wonderful.

It's been really interesting to talk to you, bro.

Bye bye.

Bye bye.