Prospect Call Transcript
Meeting Date: January 15th, 2026 - 4:36 PM
Craig Rhodes [00:00]: Like culturally and stuff. So if we have a few minutes for that and of course we can schedule any follow ups too. So. But yeah, Robert and Laura, if you could with your stories maybe.
Robert Rosales [00:11]: Yeah. So let me start by. Yeah, you mentioned about the website and the phone app, which are, you know, just different devices, different experience for the customers, but same functionality pretty much. And it's not uncommon to have more functionality on the website than on the phone app first. So the phone app would be, you know, there might be some things that are not necessarily don't need to be on the phone app, but the idea with the phone app and by the way we do have internal developers that's doing the website. It's just that their skill is they don't do app all the time, which is different. So that's where I'd like your feedback. So we're a trucking company, we pick up and deliver and this phone app is to support the function of a pickup and delivery and information in between.
Robert Rosales [01:16]: Obviously there are items on the phone app that would be more informational, like you know, company information, the officers of the company, the locations of our terminals. These are information available on the website right now. So more like, you know, a lot of maybe static pages, the ability to display our history, 110 years of history. Right. So if you think about it, there are those static information and then there is those dynamic interaction. For instance, in order to create a pickup, we need more authentication, user authentication on that just to make sure that it's a legitimate pickup before we send our trucks to go pick up a package or a freight. Creating a bill of lading, which is very intense, a lot more intensive.
Robert Rosales [02:10]: If you think of, if you were to call us and say I need you to come and pick up a freight that is thousand pounds, we would need to know how many pallet is there a hazardous material, is it paint, is it where it's going to, where it's coming from, who's paying the bill, that kind of stuff. So there's more information that needs to be entered by the user and that's more dynamic. Those types of dynamic interactions have an API back to our backend system just like we do now with our website through API. Those are readily available for you to use when developing the application.
Robert Rosales [02:53]: But one thing that is new or maybe specific to the phone app is think of Uber and the ability to display, for instance that if I'm delivering to your house, Craig, that you might pull up this app and say the delivery is coming in five minutes. You would have a tracking number and you would be able to track our eta. Now, for a residential, that might be as like, okay, if you're here in five minutes or 10 minutes, that might beneficial to you. But more so beneficial to think of distribution centers, right? Think of, you know, we're delivering.
Derek Gibbs [03:37]: Three.
Robert Rosales [03:37]: Pallets, £5,000 to a distribution center. And the idea with that is if we are letting you know that there's a delivery coming, what we want the distribution centers to do is to start preparing their dock to receive our delivery. Right. And so that is beneficial to the customers, beneficial for our drivers. Right. Just so our drivers don't have to be waiting, Customers don't need to be waiting. So I think that is more specific to the phone app that we want to add. The website may not necessarily do that. It could, but the website is not necessarily used by receiving team at a distribution center. It's more like the phone, like your experience with the Uber or Lyft. So that's the idea there, that's a little bit more complex. There are also conveniences that we could extend to the user using a phone app.
Robert Rosales [04:46]: For instance, if you made a shipping, if you frequently do, you just imagine you're a distribution center and you sell widgets and there's a customer that you always send these widgets to that could be made more efficient because you do it all the time. You know what I mean? It's just maybe different items, different number of items. This time instead of 2, you're shipping 5 or 100, but it's going to the same place. So there might be those types of conveniences that we can extend to the phone app so that they can do it. There are also again, dynamic.
Robert Rosales [05:31]: If you call us and say, how long does it take to shift from our Seattle, from Seattle to Los Angeles right now you go to our website and you do the same inquiry goes to our backend, calculates the number of days to deliver that should be available on the phone as well. And that's more dynamic because it goes to our backend and our backend calculates that service time and then sends it back on the API. So there's the static, there's more dynamic, there's convenience. Right. Those are the general functionality. I'll stop there. If there's anything that I said that's like, that's easy peasy, that's kind of more complex or, you know, so I'll let you comment on what I've said so far.
Jay Singh [06:20]: Super helpful, Derek. I see you Excited to jump in. Go for it.
Robert Rosales [06:24]: Yeah.
Derek Gibbs [06:25]: I mean, these are like always really cool projects to do. We can speak, you know, I have some questions I can ask and I can speak a little bit about kind of some of our own experience building some of this, these types of things. Had kind of a big project when I was at PPC and strategy and doing something similar for PepsiCo, kind of managing kind of like delivery, orchestration, assignment of people, kind of DC assignments. So can hit on that. I think there's a lot of similarities.
Derek Gibbs [06:56]: The biggest thing that I think would drive some of the effort on this is how much of these, the services that you need are already available in your systems and have already been externalized as services that we can just call and there's not that much changing and sorry, the mobile app and the web application just become more of a portal for accessing those services and making sure that these things are connected versus needing to actually design those services in order to do this. Estimate time, delivery time, DC assignment, all of that stuff. If that doesn't exist, as you can imagine, that'll drive a lot of the build complexity.
Robert Rosales [07:36]: Yeah, yeah. The API. Most of the API that we need is already built. The one that's not built, I mean, we have an eta. We always have a prom and a two. Right. So you can map that out on a map. We have an ETA because that comes from our trucks. The only thing that may not be available is the current GPS location of the truck that's delivering. Like, think about Uber. You need that, right? You need, you know your endpoint, but you don't. You, you're going to need a GPS location of that truck as it moves through traffic. Right. And that might. That, that's the one that we don't have. That's the one that we don't have. That, that needs to be.
Derek Gibbs [08:15]: And you want to get it off of the device, presumably. Right. Like a driver is going to have the device that should have GPS kind of going.
Robert Rosales [08:23]: Right, Right. So our drivers, they have a device, it has a gps, it has an app. We're using the application right now that is capturing the GPS location. It just needs to be exposed out to the phone app so that you can use it. Yeah.
Craig Rhodes [08:45]: We had a conversation about this one this morning, actually, because weren't sure if it was maybe a thought around like, you know, privacy of like where they were and making stops and stuff. But would an idea be like, would you know that they have 10 stops and so at least we might know that they've made the seventh stop and they're on the way to the eighth stop. So if I'm the 10th stop, I guess I would know that they have two more stops to make. Like, do you know what I mean? As opposed to like a real time, you know, latitude, longitude, location. I'm not sure if that's like, you know what I'm saying?
Craig Rhodes [09:20]: I'm just trying to like, understand how much, you know, people need to know or if giving them certain information is, is better, like on the way to like the exact location.
Robert Rosales [09:31]: Right, so we have the eta. Yeah, we have the eta and we have the sequence of stops. Right? The sequence of stops is, is a good information, but not really accurate, even if it's your third stop away. Well, it doesn't mean that you'll be there in 10 minutes or 15 minutes, because each stop may take about 10 minutes, may take half an hour. You don't know. But we do have an eta. So the ability to get the sequencing, it's there. It's available through an API right now. And the ETA is also available as a data point, if that can be used. I mean, certainly it can be used by the. Even if we say, look, the ability to map out and tell the customer that it'll be there in five minutes or 10 minutes is not quite baked. And that could take longer.
Robert Rosales [10:27]: But at a minimum, we should be able to say, here's the eta, because that's the information that we have right now with an API. Here's the ETA, right? And it'll be there in about 1pm or 2pm or whatever it may be. Right? That's available right now.
Derek Gibbs [10:42]: I mean, it could be, it could.
Jay Singh [10:43]: Be interesting as we're going through like some level of discovery here is like, you know, do, like, do drivers. Are drivers okay with like kind of sharing their current location? So then we can work back from literally like getting an Uber and doordash. I think it's on the driver's. It has to be on the driver's device where the kind of, the current location is relative to the eta.
Robert Rosales [11:06]: Right?
Jay Singh [11:07]: And so maybe like that's okay, right? If they're, if they're already working with you guys, and they're probably subcontractors and stuff too. Like, you know, you have to maybe get something there. But we can talk through that because that'd be a really cool experience just to work.
Robert Rosales [11:20]: I mean, the ability to expose. That's a business decision, it's not a technical one. Right. I mean, the technical process design on how to get that data so that you can use it is one thing. The other part, where is that secure? Is that. Is that okay with us? We, our drivers, we employ our drivers. So we have the ability to say, look, you know, they don't really have. We're concerned about security, of course, so we'll have to talk to our legal and all of that. But that's just conversation and policy in the back end. Nothing technical. Right. So, yeah.
Derek Gibbs [12:01]: Who are the main. Or who are all the different user groups that might need to kind of access this? And I'm guessing, you know, maybe the drivers would need to. But is there a kind of a managerial counterpart to it where you'd want to see some other things or administrative or dispatcher kind of use? Like who are. What are kind of the different groups of folks that will need to serve through this?
Robert Rosales [12:21]: So it's. It's going to be all. All our customers, shippers and receivers. Right. Probably. Probably more of the recipients of the shipment is more interested in when. When do I get the orders that I put in place? Right. But the shipper might be also interested. But, you know, if you look at big shippers that are shipping, you know, thousands of shipments a day, they probably won't use those shippers won't use this app, but the people that they're shipping to will be interested and when they're going to receive the freight. Yeah, yeah.
Derek Gibbs [13:09]: So a lot of. I see I'm getting a better understanding. So it's more intended for kind of like either end of your chain here. So it's not primarily like an internal kind of application to sort of manage, but it's more to provide visibility to sort of folks that may be shipping or receiving stuff on the other side, and then you're getting this data from your internal systems and surfacing it the right way. Is that right?
Robert Rosales [13:35]: You're absolutely right. But as you know, you build an app and it will be used in a manner that you didn't intend it to be, right? Yeah, yeah. Primarily for the people receiving the app. But I guarantee you, because we've had an app before, over 10 years ago, it just not. It didn't get updated and the security got just fallout of alignment with Play Store and itunes. But when we had this app, very basic app, and it was intended exactly what you said, Derek. But what we found is that our internal people on the dock was actually. They were actually using this app because if they're walking the dock and there's A freight that in the middle of the dock and they don't know what it is for, they go ahead and scan it and say, what is this all about?
Robert Rosales [14:21]: They don't have to go back to the office and, you know, and find out what that freight is that's sitting in the middle of the dock, that nobody knows what it is. Right. So there's always going to be that unintended use, which is okay. But yes, primarily think of it as a tool for the person receiving the freight. Now, having said that, obviously it's intended for potential customers. Yeah, right. It's intended for the shippers. Different percentages of usage, maybe, but the functionality is there to serve as different stakeholders. Yep.
Derek Gibbs [15:06]: Makes. Makes total sense.
Robert Rosales [15:08]: Yeah, yeah. And maybe.
Derek Gibbs [15:11]: Or go ahead.
Robert Rosales [15:13]: No, if you want to get a good idea of what those functionalities are, go to our website and pretty much what you can say is anything that's available there, that's an asterisk, should be available on the phone Contact us page. How do you get ahold of us? Right. Company history, locations, holiday schedule, you know, how to file a claim, information about API and edi, which is Laura's team is very good at. Right. Those types of things. Now, there may be things on there that, like I said, we may not. We may decide not to push it out to the phone just because it's complex. Yeah, yeah, right, yeah.
Derek Gibbs [16:10]: Mobile always has a kind of an additional layer. And this is. Do you know what operating system already you need to be for iPhones android? And are you envisioning like a local app or you think just surfacing in one of the browsers, but kind of like mobile friendly?
Robert Rosales [16:30]: You know, the experience with an app is obviously more richer than a website that looks like an app. Right. And so we do want to have an app in a way that would play nice with itunes and iPhone android predominantly. Right. And back in the day, this app was written in Cordova, which, you know, kind of. And then I don't know what the language being used right now for React or whatever, the language that can do this, that would be something that I wouldn't want to maintain. Two code sets specifically for iPhone, specifically for Android. I want a more universal language that could play, that could run on an iPhone. And that's helpful.
Derek Gibbs [17:30]: That's an important kind of requirement that we can think through. And I think what I might want to do is share a little bit of our process. And typically, I mean, this has been super informative, super helpful, but basically for all of the Projects that we do, whether it's mobile app development or internal automations that are covering a bunch of things, we start every project with some type of discovery phase. Sometimes it's quick, maybe it's like a week or two weeks. Sometimes if it's bigger and we really want to get our hands around defining the scope for this, it could be longer. It obviously goes much faster. If you guys have already put a lot of thought into how you want this to look, or we're pulling directly from something that we're wanting to replicate functionality and do things incrementally.
Derek Gibbs [18:19]: But that would probably be the first step if we, you know, how we would approach it is doing this kind of discovery phase that's probably tracked across, you know, kind of the technical architecture side and then also like functional requirements.
Robert Rosales [18:30]: Right.
Derek Gibbs [18:31]: Who are the user groups that we're expecting it to serve, what should it be able to do at least in its kind of initial release? And then we can identify, you know, nice to haves or things that happen afterwards. But we could kind of scope around what we think will be kind of the essential to launch with. And oftentimes what we'll do is we'll have. We typically like the idea that we can really launch something earlier that you can start getting people using and getting feedback on and you might still have a little stretch of kind of development that's still planned so you can respond to that.
Derek Gibbs [19:05]: So rather than try and get everything specified up front and then we build it and launch it, that's a little bit of like MDPs, maybe halfway or three quarters of the way through and then you still have kind of planned build cycles that you're using to maybe add some of the nice to haves once you're getting user real feedback. The time frame on a build like this is hard to say up front without going through the discovery. We've launched mobile apps in as little as two to three months, but it's pretty scoped down and restricted for something that is definitely going to be customer facing and end user facing and that you're going to want to be pretty feature complete at the time you launch can take longer, it could be four to six months.
Derek Gibbs [19:56]: But typically what we'll do is we'll have that discovery session first and then have these decision points and options depending on what you're comfortable releasing as the initial version to folks, maybe there's like a four month version, maybe a six month version and if you want to have the whole thing fully built out before you do, kind of like a Wide release, it could be longer. But that would probably be the first step that we would take is scope out what we think that kind of initial discovery would look like. And then anything you guys can share about stuff that you've already defined requirements on the site, I think there's stuff there, but then even maybe a login to the portal of like what people would otherwise look at would also be helpful. And then.
Derek Gibbs [20:41]: Yeah, and then that would be kind of, you know, starting point. And then typically what we do is we have kind of pods of folks. And so all of this would kind of sit inside of a pod that's paired between, you know, a product manager that's going to be owning it, like a kind of senior tech lead, like Max. And then depending on how quickly we want to move, we might have supplemental engineers, you know, maybe one or three that can kind of give that team some leverage to sort of build all this stuff out. And we also bring in design is a big portion of how we think we add value to this process.
Derek Gibbs [21:11]: And we have a team of very talented designers that will deploy more heavily up front, especially kind of like this discovery and initial design, kind of UX definition and UI design. And then they'll be kind of involved, ongoing as they're doing like refinements to the screens, tweaking, kind of the branding, colors, all that sort of stuff. So that's generally our process and I'm happy to answer any questions you might have about that.
Robert Rosales [21:37]: Yeah, no, that makes sense. There's definitely going to be a 3 month version, 6 month version and a 12 month version as we add more functionality. There are the ones that we think are three month version are the ones that we already have an API, we already know how it works. And then the six month version, maybe the ones that are, like I said, the Uber type of experience. The notification, I know when my Alaska Airlines is late, they give me this notification. Right. This would be great. Security obviously needs to be baked in. Right. So you mentioned about login, so there's that. So the discovery part, the good thing about it is that we know, I think we're ahead in knowing what, exactly what we want instead of, you know, the full blown business requirements. I think we're ahead of that.
Robert Rosales [22:38]: So this is the, you know, this is a project that is now in flight. When I, when I mean in flight doesn't mean we're in the middle. We're at the very beginning, but we are now talking about it internally. So I do want to move quick on this one, I want to be able to launch the first version in June. I know we're in January. Sounds far away, but it's going to go quick. So June is the timeline when we also have the same version on our website. We're going through a facelift kind of thing. Some of them are just cosmetic stuff. So we want to coincide the new facelift for the website and also a launch of version one of the phone app. And so with this, in order to move forward, I do need some budgetary numbers from you, maybe from Craig.
Robert Rosales [23:39]: And I think your capabilities are there because you've done this before. So I'm glad to hear that. There's nothing here that alarms us, like, oh, my God, we can't do Uber, you know, So I was waiting to see if you would say you can't do that, but I'm glad to hear that, like, oh, yeah, we've done many of these before. Good stuff. Go ahead, Jay.
Jay Singh [24:05]: I know we're out of time, too. So, Craig, we can work with him in terms of, like, and pricing and everything and get you back, like, a more formal proposal, I think. Robert, how would you think about the connecting point with the website design and this? I think one thing that we talked about with Craig earlier is like, usually we would actually kind of help manage the original discovery and design and then the right branding, and then that will kind of dovetail into two different work streams, like the website refresh and the mobile app design and build, especially as you want to kind of see continuity between both of them. And so even if it's not us owning that, I think we need to have some visibility in terms of what's going on with the. With the work stream, with the website.
Jay Singh [24:47]: Just so, just so, you know, customers want to see the website, it's aligned with how they're also interacting with the mobile app. Unless you're saying, you know what, don't worry about it, like, the mobile app's gonna. It's okay if it's kind of its own thing. Laura might think so.
Robert Rosales [25:02]: She's laughing because she agrees with. With you. Okay.
Jay Singh [25:05]: I mean, that.
Craig Rhodes [25:06]: That's where. That's where Laura comes in.
Robert Rosales [25:08]: Right.
Craig Rhodes [25:08]: To, like, bridge that. That gap between both worlds, I suppose.
Derek Gibbs [25:12]: Right.
Craig Rhodes [25:12]: So you have, like, it's. It's not that the website is owned by marketing. Right. Like, that falls under your application space, Laura, then.
Robert Rosales [25:23]: Correct? Yes, absolutely.
Craig Rhodes [25:24]: Okay, so you're in. You're in all. All the things, so. Oh, all the things.
Derek Gibbs [25:29]: Yeah, yeah, that's cool.
Robert Rosales [25:32]: Yeah, we do need that continuity and you would need to be aware or you can. We'd be able to make sure that we're aligned with the website and the phone from a visual look and feel to it.
Jay Singh [25:50]: Okay, great.
Robert Rosales [25:52]: Yeah, that makes sense.
Craig Rhodes [25:54]: Hey, I know we're at time and you guys have other stops to make and stuff as well, but see, I'm all these freight puns that I was doing also in our earlier, earlier meeting.
Derek Gibbs [26:04]: Right?
Craig Rhodes [26:04]: Like accident crushing.
Derek Gibbs [26:06]: Well, a couple things.
Craig Rhodes [26:07]: One is like we. We do have like the About Casper overview piece and I feel like maybe that's something that Jay, you could grab a few slides from that and send it out as a. As a follow up. Just because I want Robert to be aware of. You know, there's great case studies and references in there that you guys may want to see. And then also, you know, as we go or maybe work on the proposal and then have a chance to. To feed that back to you all. So maybe I could work with Beth and figure like, you know, next week or however many days we might need to accomplish the, you know, proposal draft or if there happens to be another meeting.
Craig Rhodes [26:44]: I know I had some questions about some of the things that the app is doing and if those systems, you know, do or don't exist or what extent. But anyway, yeah, we can flush all that out. I don't want to make you guys late, but I really appreciate the time, you guys. And then like I said, I'll work with everyone with Beth to get follow up things. And obviously June is a. Is a achievable but yet soon arriving goal. And so we don't.
Jay Singh [27:11]: We'll.
Craig Rhodes [27:12]: We'll try to speed up this part of the process as much as we can so that we could get going. I think so.
Robert Rosales [27:17]: Yeah. Okay.
Derek Gibbs [27:18]: Yep.
Jay Singh [27:19]: Yeah, let's. Let's think of on Monday or Tuesday. Yeah, let's. Let's keep the ball rolling. I'm excited.
Derek Gibbs [27:24]: It's a great.
Robert Rosales [27:25]: Awesome.
Derek Gibbs [27:25]: Thanks so much, everyone.
Robert Rosales [27:27]: Thank you.
Jay Singh [27:31]: Cool. Nice. That's a good call for you because like that is. That is. That is. That is what happens, right? That's the whole. Dude. Awesome. Yeah. Robert was stoked, man. He was impressed. Derek was like, Pepsi, go. I've done this like talk to lingo. That helps. That helps. Dude, Derek is.
Derek Gibbs [27:52]: Insane. All right, my brother.
Jay Singh [27:57]: I. I'd love for you to check the landless campaign.
Robert Rosales [28:04]: Cool. Cool. Okay, sweet. It's real.
Jay Singh [28:42]: Starting to run by that creek. Starting on the road. Valley free it. Nice and hilarious.