Articles
From React to Svelte - A Devshop's Journey
[00:00:00] Josh: Welcome to another episode of Devshop Stories. My name is Josh and I have McKay here with me. Today we're going to share a story about time and materials and fixed bidding. So the story essentially begins with Red Sky Engineering. Back in its infancy was always a time and materials shop. And with that came a lot of issues that we had.
For example, we would obviously have to do work for a set amount of time, so normally 30 days, and then we'd had like a 30 day. Kind of net terms on their payments. And so what would happen is we'd actually go 60 days before actually being able to be paid. And then you'd get into arguments about what was supposed to be there and not there.
And it just became a big hassle. And we just, McKay and I just kind of started asking ourselves like, there's gotta be a better way and we actually had a friend of ours who ran an industrial engineerings company and they had been doing basically dev shop for the last 20 years successfully and we're still running.
And we were probably three years, two, probably two years into our dev shop before this, and we just called him up. And McKay, do you kind of remember what we said? You know what he said to us?
[00:01:06] McKay: Yeah. After we were just like, Clawing our eyes out. Like, what in the heck are we doing? we're two years in. I don't think we can do another year.
you know, at the time we, I don't even remember how many, hundreds of thousands of dollars we had in receivables, but it was a huge number, untenable, you know, and he had just said, yeah, we had the same problem and we switched everyone over to pay first, and we lost virtually no one. You know, and it just comes back to this idea that, people behave. How you kind of place them in a position to behave. You know, we saw that happen with all the, all the contracts we had. We, we quickly switched over to doing the same thing because again, we had so much effective receivables, you know, it was causing a lot of debt and other challenges for our business and.
and, and there are enough challenges with the business already to not have to fight the battle of collecting the payment. You know, I look at the challenges being like, first you gotta find the business and you have to execute it successfully and then, and keep the client happy, and then you have to go collect the money now.
And so by removing one of those, it's like two, only two major items we have to solve instead of all three. And so we, we made that switch and that was a huge deal for us. And interestingly, it, it's been a similar experience.
[00:02:11] Josh: Right? And I remember him specifically saying, You know, some of these big companies, they're like, they, they say, Nope, we only do net 45.
Like, that's the only way we do it. And his response was like, great, you know, we'll, we'll uh, send you the invoice and in 45 days when we get that check, we'll start working on it. Right, ? Yeah. We'll get going. And, and what's crazy is that same company that said, We only do net 45. They got 'em a check that evening to get started.
So you, you basically lay down and say like, basically put your foot down. This is what we do. This is the only way we operate it. And they find a way to do it if they really want it, you know?
[00:02:42] McKay: And I think, and one of the keys he had there too is obviously you have to be willing to actually execute that.
The thing he had said that that he was surprised by was how many people went along with it. obviously on the more of the sales front, I was nervous about that. And we, we really didn't have a choice. It was kind of rock and a hard place for us. So it's like, well, we have to do this. So we went ahead and pushed forward with it.
And amazingly, like I say, they, they, you know, we have seen pretty much the same effect as him. In fact, it's interesting. in a lot of these conversations, you know, we kind of just switched our messaging. We said, instead of going in and saying, yeah, and then you'll invoice us and, and then we'll give you so many days to pay.
And we, you know, that's usually the conversation of how the structure goes. And so instead we said, instead we just flipped it and said, You know, Hey, yeah, we're gonna be doing the work and in order for us to get started on your project, we've gotta slate so many people to work on it. And so for that, we just, you just put money down and we'll kind of predict what we expect to have for that month, and we'll go forward with that as a retainer.
And if we're a plus or minus, we'll count that either into the next month or, you know, if we all, as the project ends, we can give it back to you, whatever, right? So we're not left holding the bag. and obviously that's all time and material based, but even on time and material based, you know, it's, it's worked exceptionally well.
And in the rare cases where we've had issues where people are like, well, I don't really have quite enough money to put down, which I think is funny. Right. So yeah. What happens on the alternative of that is they don't put any money down. They spend all their money and then they get to end of the month and they say, well, I can't pay you.
Yeah. And then we're like, well, okay. And, and now you're in the hot, you're in this rough spot where it's like, well, We haven't brought new projects on because we are doing your project. Suddenly you can't pay us. So do we kind of move along? And of course they're telling you they're gonna pay you. Yeah. You know, and we had the, the whole, all of this arrived from the fact that we had multiple clients that strung us out, you know, where we would bill 30 days.
So we had 30 days already baked in a payroll, and then they had a 30 day term, and then half the time they'd stretch that to 60 days. So we were getting a 60 to 90 day window of payroll that we, so we covered an entire quarter of payroll for this project. And then, oh, we want you to throw four or five more guys on there.
And it's like, well that. You know, it might be another quarter million dollars or more that we're gonna have to, we're gonna have to foot the bill for before we ever see the money. Right. And then on the backside of that is always the negotiation. Mm-hmm. . Right. Which is when, when people pay you upfront, if, even if you hand them a product at the backside of that, which you're happily willing to hand them, it's already paid for.
Right, right. When you, uh, when what we found is, you know, it's like all of a sudden we get to the end of this project. And they owe us, you know, hundreds of thousands of dollars. We have some form of deliverable already handed to them. And it's like, now what do we gotta, we have no leverage for negotiations.
So it gets to be really hard. And I, I mean, obviously I had to go negotiate all those things. And you take concessions, right? And we talk to the lawyers and like, well, , if you sue them, it's gonna be a hundred thousand dollars to really go about a lawsuit, even to get started. And it's like, holy smokes. You know?
Yeah. So, so let's take concessions. You know, the lawyer was like, go and make and be a really, really good negotiator. That'll be far better than taking legal action. And so, so you really just, you cut your feet off by doing it. And, you know, we had found ourselves in such a terrible situation and now months and months later, you know, pressing a year on some of it.
But, we've switched the script on that and the difference is we have clients that pay, they pay almost all on time. Even when they're late, it's like, oh, they're a week late paying, well, they're still prepaying. So now, right. You know, they're now really, we gotta, we got a prepayment that's a week late rather than a week late after we already paid everyone for a month.
So now we're a month and a week, or a month and two weeks, or a month and a month, you know. So even when it's late, it's still early. So we're still covering usually before we even incur payroll costs.
[00:06:14] Josh: And so there's kind of two paradigms. I just wanna take a step back. There's the time and materials, which means they're gonna pay us for the developer for every hour they work.
And then based on kind of their categories. So like a junior, mid, or senior. And then we, you know, we charge for PM and, and qa, so that's time and materials. They're gonna pay us exactly hours we have a, we use a software to track the hours called Harvest, and we essentially send 'em that invoice and then any materials they might need us to buy.
In the past we've had to buy cell phones. If we're kind of trying to integrate on certain types of cell phones and that kind of stuff. That's time of materials on the. Flip side of that is firm fixed price. And so fixed bidding. And essentially what that will take is it's gonna take you to understand the entire project, exactly what they want, what they're gonna deliver, at least in this phase of this M V P project.
And that takes a lot of time to actually bid that out and actually do that. I mean, it's gonna take multiple weeks of having. Senior developer sit down, break apart the problem, and give estimates, time estimates on each one of these little chunks. Uh, you'll have to have a designer that's gonna actually go through and design exactly what it is.
You have to have a project manager that's gonna go and break down all the, the scope requirements into documents. And so what we found to be actually best is to actually split, even if it's a firm fixed project. To do that initial phase, which we call the design and discovery phase, we'll do that as a time and materials, and we actually feel comfortable doing it that way because one, you might have some clients that come back a thousand times on that design and say, no, no.
Tweak that color, or tweak that button, or move that over here. Or they might just be, you know, oh, yep, that looks good to me. And so we can actually charge them exactly what that is and at the end, even if they decide they don't like our firm fixed quote, or they want to go somewhere else, we can still deliver them something.
[00:07:59] McKay: or go raise money.
[00:08:01] Josh: Yeah, or raise money.
[00:08:01] McKay: A lot of times our, they're early stage and it's like, They're, they're like, oh, can you help do a bunch? I mean, we've got a project right now that's asking us the same thing. It's like, Hey, would you guys be willing to do a bunch of work for us? And, and I think the developer world, this is like the constant ask is, would you work for me for free, for equity?
Yeah. and my take is that should almost never exist solely cuz I've never seen it work well. And we've tried it on many occasions, right? So I think we've given it the good old college try and it doesn't work good. You know, I don't, I just don't advise that. Uh, I think they've gotta have some skin in the game.
but really what comes down to it and the approach we take with groups like this and, and certainly with these guys as well, is gonna be, you know what, if you can cough up some cash, we can help you actually design discovery. If you are going to go raise money. You need to show that investor that you actually have not just an idea, but a real plan.
And most of these people come and, and they actually have great ideas. and they even have plans on how they might wanna put it in the market, which is great, but they have no idea how to execute the tech. They have no idea how to scope it. They can't design it. And so instead, we can actually help them put together something that they can go, put in a deck, go raise money on.
And then as you mentioned, like sometimes, you know, we've had a few groups that have done that, they've worked through capital constraints and they didn't end up building the project. right. And it's like, but it's the end of the, at the end of the day, they walked away with something that was of value to them and their business and the pursuit of their business.
No matter. So it's, so it's, they get a deliverable. So it's not just this ethereal thing. so it wasn't just pure consulting, it's like consulting to an actual end. And then from there, like you said, then we, we can fix bids. So, and we really are talking about two different things, right? The, the first part of this was Ben from business side.
Should we do net terms? Yeah. And, and I think my take and, across all our businesses, we've seen this. No, like that. Net terms just are so hard. It amazes me how many people just don't pay their bills. Mm-hmm. like, it's, it's crazy. I, I mean, we've run into multiple com, multiple people and companies who know that if it's like under 10 grand, you're not gonna sue them for it.
Right. And so they just don't pay anybody and you just walk away and eat that cash, you know? And so it's like if you're new to the business world, Be aware. Yeah. These people hit live. They're, they're here. They will, they're the vampires and they will happily suck your blood and move on. And if you're a sucker to let them do it, then uh, it's gonna happen to you.
So, so yeah, that's the net terms discussion, right. And so on the flip side of that is now, okay, now we, we, we've solved the net terms and we're no longer just a bank anymore, and we're actually a company. And we're getting paid for our work, but now how do we execute on that work? my background even before Red Sky was I did a lot of consulting projects and I try to do fixed bid cuz you make money, you make more money, right?
You have way more value. You take more risk, you take more risk. But, but you know, no one's gonna pay me 500 bucks an hour, but I think my time's worth it kind of a deal. but they're gonna say, well, well I can get this guy over. Here's time for a hundred dollars an hour. You think you're five times faster than him?
Yeah. I actually think I'm 10 times probably faster than him. But I, they won't believe me, right? No one's gonna believe that story so and so, and you are taking some of the risk on off of their plate for that reward by saying, well, I'll execute within this time window. But the challenge that you run into, I think with fixed bid and why we were so slow to really implement it and a lot of that was just cuz my exposure to it early on was such a mess is project start fantastic.
And then you get to the end and if you're a creative and a fast coder or something like that, you're probably a good, you know, Creative engineer, but you're not good at detail, right? And so come to the end of the project, I want change X, Y, Z, and five or 10 times that happen and you don't document that because you're not good at documentation.
You're just building, building. At some point you say, Hey look, we've. We've well exceeded what we intended to build. You know, like, like, and, and, but you don't have any documentation, so you go back to the client. It's just a giant disaster. So, so we had said, you know, even though I had made good money in the past doing it, it was like, we don't wanna do this because we don't wanna any disaster every time.
And so we took the approach of like, let's do this as a. You know, time materials. Right? And that worked well once we actually flipped it to not being, yes. Getting net terms, right. Um, that worked well, but there's no upside for the business. So we wanna hire really good people and we wanna pay them well and be competitive in the market, but we can't because we can't get clients to pay us enough money for their time to do it, you know?
And so, so you've cut up, you're fighting those two battles and I think the magical thing that happened for us, As we were just talking about a minute ago, it's really the, the powerful thing that changed was we put the right people in the right places in the business. and so we got PM people involved that were really detailed and articulate and numerical.
So we were actually able to track all our details. And I, I, I remember one of the parts that was really funny. To me to see. and I just had to laugh because I, I know how my internal tendencies are in terms of when I bid a project. You know, if someone says, oh, I want these things, how much is that gonna cost?
Right, right. Which is always a giant joke. Anyway, and then I'll pull some number just outta thin air. And it's usually somewhat approximately close, but it's only close to development costs. And, and so we always surpass that number and I always look at it and think, why we, why is it costing so much? So we looked at the numbers that we had put together, and only about 50%.
Of all of the time actually into coding,
[00:13:07] Josh: right? Where the other time is meetings and code reviews and you know, everything else. Yeah, everything else just kind of adds up, which is crazy. I mean, think about it, but I mean, sometimes customers, they just want to be in a meeting and they want to talk to you and tell you about all this kind of stuff.
And we've had it where they're like, no, we want all the developers in there, so we only have to explain this one, this . And we're like, well, it would actually be a lot more effective if you just had your PM in there. You explain to them and they kind of, yeah. Iterate out.
[00:13:34] McKay: They give this short version out.
Yes. To everybody. Mm-hmm. . And it's, and it, I think this is the issue people don't think about when they talk team scale too, you know, is basically you just get more overheads. So you throw bodies at the team, but everybody in from maybe a 60% to now a larger team might be 50% to a really large team.
I only be like 35% of their time coding. And so it's like, You, you rapidly have a fall off curve that occurs there because of the overheads. But, but that was a big shocker for me. But by tracking every piece of information and tracking all the staff members. So when we put a, a staff member on a project, you know, we actually know how efficient they're gonna be.
Yeah. And so when we bid that out and we say, oh, this is gonna take two days, well, we know that person's gonna get that done in a half a day, because they're super efficient. Whereas, you know, maybe someone else might take three days to solve it. Right.
[00:14:19] Josh: And, and then you have to take into the count that.
If somebody says it's gonna take eight hours to do it, well that's eight hours of actual dev time, which again, we already said they're gonna get right 50%. It's gonna take 16 hours of real time to get eight hours of dev time. But then if their efficiency is not a hundred percent, they, it could be even longer and stuff.
But since we tracked all those metrics on each individual developer that we have a spreadsheet going, we actually know what the actual true cost is gonna be when they say, I think it's only gonna take eight hours. It's gonna take you this much. And so then we put that into our calculations of our firm fixed bid.
[00:14:53] McKay: Well, and then that's why the discovery is so important. Mm-hmm. , because we actually get to the all, we articulate all the detail of that project, and then we bid that in the same way. And now we apply our efficiency volumes, our values to it, and suddenly we get this magical number that happens to be really, really accurate.
And so now all of a sudden we can firm fix it. You know? And that was kinda the magic of having all those pieces. And I, I think the one other thing though that I mentioned, that really, really, I think deserves. The energy there is one of the big realizations we had as well, in concert with the billing correction.
The firm fixed capacity or capability by doing the tracking and metrics is also, client communications, you know, and just how critical that was. We got to, you know, I, we got to the end of some of these disaster projects and I was just, beside myself. And these are people you get to know really well.
And yeah, things fall apart and it's, uh, extremely emotionally frustrating. And, you know, we all sit around, I for, days and weeks in discussion on these things because of the frustration levels and, just like, you know, what could we done differently? What did we do wrong? You know? Mm-hmm. . And we were all looking at like, We built a, built a dang good product.
You know, like what are they, what are they all mad about? and I think we even built it under budget, right? Right. Of what we thought was realistic. But, what we realized was we just, we hadn't had the communication with the client buttoned up completely.
[00:16:07] Josh: And it's not necessarily even.
Just a client, it's the major stakeholder that's in that division. Cuz this one client in particular that I can remember, we talked to 'em every single day. We had daily standups, but it was a project manager they put on to kind of shepherd us to kind of give the vision. But it turned out that the, the vision of the, the actual stakeholder, that actually cared and was funding the whole thing was completely different from what his project manager did.
And when it, this actually got to the end of this cycle, and then we were called out. Why didn't you build it that way? The, the PM that had led us and told us exactly what to do, said nothing kept quiet and threw us underneath the bo us, you know?
[00:16:43] McKay: right. And so, so we really, we, we kind of had that paradigm shift we needed to make as well, which was, we will not do work.
If we cannot have communications that work because, and we actually track that as a metric, as a kpi, now.
How many meetings that they show up, how many they and how many, yeah,
exactly. You know, there's this, there is an absolute correlation to high miscount equals disaster. You know, it's the, it's the, the looming disaster is coming.
I think the real, the real reason for that is that's the pressure release valve is every couple of weeks we get to sit down with that client. We get to go through the details. We get to, you know, hash out the complexities, and instead of building that up for six months and all this money later, It's, it's released each couple of weeks, and so we can actually create a satisfied experience.
so there's, there's quite a few moving pieces there just from a managerial side. But yeah, we just, we realized that, the product we're offering is really the culmination of all the experience that the customer's having. It's both the, the interaction and also what we're producing is code.
And I think we produce really good. But we weren't producing really good experience for the client. you know, we were trying, but it wasn't well processed. And so,
[00:17:47] Josh: I mean, speaking of experience, one of the things that we did also find was that when we delivered the product to the customer and we said, okay, there it is, it's launched, you know, live.
We found that those first couple weeks after launch is one of the most critical to, to ensure success. And so what we actually do now is we include as part of our fixed bid, Two weeks of time following launch. So, so launch phase is what we call it. And we, we just include that as part of bid. You just have to do it no matter what, because you're rolling out a brand new car that has never been test driven, you know, or it's been tested, but it hasn't been out to the public for the first time and things might just happen, you know? And so,
[00:18:24] McKay: yeah, yeah, you're still, you're still early in the early test phase, you know, and, and we're trying to production harden, but in a way, the only way to do that with tech is to put it out there. You know, you do all the testing you can, and then at some point it's gotta go live, right? yeah. And that's, and that's it is like, we realize that customers will believe you with, with what you tell 'em.
So if you tell 'em that their billing cycle's gonna be 30 days and that you're willing to accept their net terms, they will believe you. And they'll take advantage of that as much as they can. If you tell them that that's not what you do, they'll believe you and they'll work within the boundary of that.
If you tell 'em, yeah, when the project's done and you don't specify, done what that means to a client. , there's this code completion event, there's this live production event, and magically it all works, and I never have to pay another dime. Right? Yeah. It's like I just, I, I went to the car lot and I picked out the car and, and then I, and then it's done, you know, and I never have to touch it again.
And so what we had realized too is we, we weren't communicating well. Some of the expectations. I mean, we knew having done software a hundred times to a production server is like, well, this isn't the end. Yeah. You know, like, this is the beginning of the next stage, but your and your costs are gonna decrease, but there's gonna be chaos for a little while.
We got a bunch of stuff to do, and then even still, you've still got a bunch of costs that are gonna be ongoing with this. And so we realized, like if we didn't explicitly tell the client, they didn't know that. Right. Right. And so there was all this angst, frustration of like, oh, wait, what? So it's not. You know, well, it's like it's, we have to define what done even means.
Right. You know, and, and that's a complex problem with software,
[00:19:51] Josh: which, which one of the things that I do like when we do these firm fixed bids and we have our design discovery phase, we actually timestamp the designs and it'll say mvp. And so that way when we go back and say, it is done, this is what it looked like.
This is kind of what you agreed upon, that is what it is. And we, we realized, People, they didn't put as much thought into it or things have changed as they started to see it and do it. And so we allow change orders and, and that just increases the cost. And, and what I really love about it, when we were talking to a, a customer that's just about to get onboarded to, they said, Josh, one of the issues that we have is we've got a lot of people giving our ideas out.
You know, and a lot of people saying, well, what if it did this? And what if it did that? And it was just like, we need somebody to kind of rein this in and, and say, Nope, these are the requirements. And, and we said, yes, we can do. . And when somebody has that idea, we'll say, great, let's take a look at it. We think it's gonna be X number of dollars.
Is it worth it to you for that change? Right. . And then then
[00:20:47] McKay: be like, oh, to the timeline and the cost. Right? Yeah. Yep. And so, yeah, it can't be free. You know that that's not a real thing. Like that doesn't exist in the real world. So here's the cost in the timeline adjustment.
[00:20:56] Josh: Yep. So making it easy to do change orders was one thing that also was required to do.
Fixed bidding.
[00:21:02] McKay: Yeah. You, there had to be a change process cuz I mean that was, and that's kinda the difference of. People are like, well, agile versus water flow waterfall. You know, it's like the classic, and in a way we're, we're kind of running a little bit of a waterfall methodology with this, but it's a segmented waterfall.
And I think the problem with like the idea of just purely agile from, especially from a project scoping and billing standpoint, that might work well for a large group, large company that has tons of resource and they have a product and they just are okay pouring a bunch of money down it. Or they know that they have to have constant build resource.
But for most companies and certainly startups, mid-face, mid-size businesses, they can incur that kind of cost basis for years on end, right? They have to have scoping to it. and so as a development shop, your goal is like, yeah, we're a little more expensive than if you were to maybe hire up an entire team in-house, but it's also a temporary team, right?
and so at some point that number goes way less so you pay a little more for the time, but you get really good process, really good oper operation, and then at the end of the day, you can actually spin it down a little bit. So yeah. Anyway, I, it it's been all three of those are so crucial to the journey.
and not just dev shop, but, but I mean we were talking about other business models too. Mm-hmm. , it's the same kind of thing. You know, anyone that is, anyone that has creative capacity are gonna be really problematic with detail. And so you're juggling all those pieces together and I think that's why you've got to get the billing up front because you're never gonna think about it in the end.
And you've got to really operate your processes and find someone that can help you dial in the numbers. even if we weren't doing fixed. The number dialing actually allows us to see what realistic estimates are. Either way, you know, because even, even if we're doing time and materials, everyone wants an estimate.
I mean, in fact, our process is we go before we even start down into, uh, design and discovery, we sit down with the sales and with, you know, some of the senior architects and stuff and just sit down and say, what do we think roughly the scope of this is like, let's, let's put this in within 50 to a hundred thousand dollars or so, or maybe 20% of the total project value.
What do we think falls into, give us a range. Yeah. Cause otherwise they're like, are we even in the same ballpark? And we've had a few of those where, you know, we've come back and said, well, it's probably gonna be, you know, 200,000 or $250,000 to do this. And they're like, oh man, you know, my budget's only realistically a hundred.
It's like, well then we need to rescope your project. Yeah, right. Because this is not gonna happen for a hundred thousand dollars. So think that that's the value that those numbers give you, whether you're fixed bidding or not, is you actually have the ability to scope stuff. And so for us, it was easy to take that into a fixed bid once we got enough information, but
[00:23:29] Josh: Yeah. So kind of in summary, Red Sky Engineering switched to a retainer base as much as we can. And if it wasn't that they couldn't get on a retainer, they had to be an established business and they pay us within a week of, of short billing cycle cycles. Cycles, yep. Uh, we still do time and materials where it just makes sense where we just cannot.
Get our minds wrapped around what it is that you actually want delivered, but they want people working on it. Usually that's like a team augmentation where they already have, software development going and they just need some, I just need three engineers just to work on it for the next month and I'll
[00:24:00] McKay: give 'em Well, and it's us taking the risk from them for that.
Yeah. Because otherwise we're, what you're really saying to a client if you're, if you're not fixed bidding, is you're saying, okay, well cuz they always want a budget. Yeah. They always want a window budget cuz they only can afford so much. And by not actually doing a fixed bid, they're the ones at the risk position for the.
So you lose your upside because they hold the risk of the project going on as an overrun. Right? So if we can fix, bid it, and we can actually wrap our heads around it, then we actually hold the risk of accuracy and completion. Right. You know, which they love. But on the flip side of her dev shop, some clients, they come in and we're just like, we cannot get your project in a state where we can fix.
[00:24:35] Josh: We think it's something like Twitter with a cross between LinkedIn, right? With a little bit of Facebook thrown in there. How much is
[00:24:41] McKay: that? ? Yeah. We're like, well, I don't know. Find out how much, uh, how much has Facebook spent on building Facebook, you know? Mm-hmm. . Yeah. Like, it's not probably in your budget, And
[00:24:49] Josh: so with these changes that we have, we've completely been able to kind of flip around red sky engineering into a profitable state, into something that we want to keep on going long term. And it's been very helpful. So thank you for coming on today, McKay, and thanks for listening to our story. We'll be back next week with more stories, personal experiences, and advice on running a dev shop.
.png)
