Welcome to No Compromises. A peek into the mind of two old web devs who have seen some things. This is Joel.

And this is Aaron. As a developer, I've ran into a couple different situations where I'm no longer going to be working on a project. Those are all different. One could be my contract work is over, so I'm just kind of winding it down, wrapping it up, and either the existing team or another contractor will take it over. There's obviously the other option, which is they're unhappy with the work.

So it's kind of a more of a, "Alright. Sorry, let's go our separate ways." And then there's the third option, which is actually a little bit more confusing and sometimes frustrating, but it does involve some more work for us. Is, what happens when the company that you're doing development for is closing its doors and shutting down.

Yeah. I mean, we've dealt with that, right? And I think that's sort of what made us think about talking about this today. Because those other scenarios probably happen more frequently. Not the one where they're unhappy with us, Aaron. Everyone loves us.

Well, yeah. I mean, I was just making that up. I have no idea.

I was thinking maybe the other scenario would be you get that massive inheritance from some oil well you didn't know your great uncle owned.

Oh, sure, yeah.

But anyways, I think in particular sunsetting a project, instead of leaving a project, there's a slightly different set of tasks. Leaving the project is more about handoff and having continuity. Sunsetting the project is shutting it down and stopping, getting charged for things.

Yeah. And let's make sure we define it as sunsetting even the whole company. Because there are larger companies where you might have projects. So some of the things that we might consider now, we're going to focus on the whole company is just kind of shutting down. Because some of the other things you may not want to do if you have other business things going on.

Right. No, that's a good way of framing it. Yeah, for this discussion it's not just a project but the whole company. Some startup, they ran through their money, they're done, they want to close the doors.

I can think of a couple different things that come to my brain. First of all, right away when I think about trying to get out to get this project is, first of all I want to make sure the client and myself are not being charged for anything more. And then second of all, I want to make sure I'm not holding onto any of their data. I don't have any other code locally, I don't have any of their data locally, and I'm not in charge of any of their stuff. Sounds like a lot to kind of handle though, so what's sort of the plan there? How do you handle something like that?

And I would say, I agree it's a lot. And the amount of a lot is proportional to how long the project ran. So if it ran for six months and shut down, one set of a lot. If it ran for 15 years and shut down, very different. And the one I'm thinking of... This was the decade plus the company running and I wasn't even the original developer on it.

So the one thing I will say, because you're asking, "Where would you start?" Where I would start is I would get in a time machine and I would go back and I would document everything from the beginning. Now, thankfully we do that. But I'm just saying, the advice I'm going to give is to document your project. We had a whole episode on this a couple months ago about... That was more in the context of handing off, but it really pays here as well when you're shutting something down.

I would say it sounds almost counterintuitive. But if you're shutting something down and you don't have some stuff documented, it may make more sense to start documenting all the things you want to shut down before you go and start shutting them down. Because I know it's super frustrating too. You say, "I want to shut down X, Y, Z service." You do, and then turns out that's the service that you use to sign in to another service which is being billed and now you can longer access it, and things like that.

Oh, yeah. All the interdependencies to think through. I was joking a little bit but really, I think what made this not terrible for us was having the documentation. And I'm going to divide into to two types of documentation. There might be more if we tease this apart more. But one is, the project documentation in the README if it's a larger project, I know sometimes we've even had a PRODUCTION.md file that talks about all the services used in production. So that's one place and that's probably the obvious place.

The other one that I found very helpful was just in our... we have a password manager for the company to share between us. And we tag things based on the client it's for sure. So any credentials that we have... and this is not just for paid projects or for paid services, digital ocean, things like that. But even free services, you still want to sunset those. Don't leave those up, you don't want to be getting emails for the rest of your life notifying you that some site is down and now you can't log in and turn that off.

But having that centralized as well was yet another checklist to run through to make sure there were no loose ends hanging around.

So you look through your README or the documentation for production, you look through your shared password manager. That kind of talk tells you a little bit about the feature or the services and stuff. Is there anything else you can think of besides? Because I'm trying to see, is there anything else I want to use my code for or my data for before I remove it from my computer?

Yeah. And that's a good question. I want to come back to removing it from your computer. But yes, there's the decision of... Like, the classic example, "I'm shutting down the database server. Does somebody want a backup of that data?" Who wants that? How big is it? Where does it get stored? Does the storage of that require ongoing payment? So those are really case by case questions that you'll have to talk to the company about.

They may want to have a copy of the code, the database. They probably are going to want that. I mean, I would if it was my thing I was shutting down and it was going to either not cost me anything or cost me a negligible amount just to have it just in case a year from now I want to look at it. I would do that. But yes, it's a conversation you have to have with a client.

Yeah. That's code or code is probably in the repo that they have access to because we talked about that in one of our other episodes. Make sure they have access to their own code. Database, they would have access to that because it's their account, but probably don't know how to necessarily retrieve that so you could retrieve that for them. Then of course, any other user land data sort of thing. Images people have uploaded, probably put on S3 or something like that. But make sure that the client knows, "Hey, that's where that information is. Do you want it? Do you want to keep paying for it?" things like that.

That makes perfect sense. I think the one thing that I do that's probably a little bit strange, and it's only because I know that I'm the worst, is I'll also before I start thinking about deleting my project and all that kind of stuff, I've taken care of everything else. I've shut down all the services. I think I'll still go look at my projects .gitignore file and see if there's any other files in there that I am ignoring. And then look at my local file system for this project too, and look for any other dotfiles or .config folders and stuff like that.

Because I've had it happen in the past too, where you're just like, "Oh, I totally forgot that I have access to one more thing," and that was in the auth.json for Composer. Or I'm using one other service and I didn't have to document that because it was like an email that it got me and it gave me a credential, and I put that in my local... I'd never really thought about it again. So there's other things like that you might also find.

I just had flashbacks to... we don't do mobile things and we haven't for a while. But iOS application signing keys, and it would stick things in your private key chain. Like, all this just debris that if you're not extremely careful ends up only living on your machine and is not easily regenerated. So that's a good point. The .gitignore could be a clue, and then maybe some of those other things too. Even just brainstorm, like me and you, would probably sit down like, "All right, what else are we thinking about? What did we forget?" after we look at the checklist.

So you've went through and you looked at your services, you shut down the services, you looked through your password manager, you looked through your code, you got your database structures, you got your code out there. I think everything's all shut down now, Joel. All I have left is a Docker container running on my machine, the data in it and some source code. And I have access to their GitHub and stuff like that. What do I do next?

I'm going to push this back to you. Because I will be honest, for a while I would just hold onto it. It wasn't even a decision I was making, but it's just like, "Okay, I'm done," and I would move on. And I know you are much more diligent for multiple reasons that I would like you to explain. Which is, "No, that can't live on my machine anymore. That has to go away." And it's not even the client... Certainly if the client asked me, if we were getting taken off a project or something I would clean up.

But if it was sunsetting, if the project just ran its course, I wouldn't be like... You've seen my downloads folder, I don't like to delete things so it would just stick around. But I know you're diligent about that so I want to put it back on you. Why do you like to go that extra step and clean it up locally?

I'll just delete everything. So first of all, taking down the database, getting rid of my volumes and stuff like that, that's probably test data. But you never know what I might have accidentally put in there one time.

Sure.

We've all been there. Grab something from production, put it in your test data just to see what it looks locally. I don't want that, I'm going to get rid of that. I want to make sure that's not hanging around on my machine ever. And even if I had to bring up my project, which I think is kind of what you're maybe alluding to, I could bring it up in the future. I don't want that data, I want my fresh, clean stuff. I don't want anything of that user's. But second of all, it kind of comes with difference between are we coming off the project or is the company going just away?

But I don't like to make that decision because then there's too many other little decisions that you're like, "Well, they've taken me off the project, but they might bring me back," so there's a lot of wiggle room. I just make the rule, which is, "As soon as it's done, it's done. I delete it." And that gives me a couple different things. One, obviously the space back, things like that. Two, things are always a little faster. A huge project no longer being indexed or something in my tools. Then three, it's all about security and risk.

I make the decision for ongoing projects not to have that code on my machine, even though it's encrypted, because I don't want the risk of potentially leaking out that code and any of the law responsibilities that come with that. Same thing with this company that's going out of business. They're technically not out of business if they're still talking to us. So they technically still own all this stuff and I don't know what's going to happen. I assume they're going to go out of business completely but they may get reborn and I don't want someone stealing that from me.

Again, it probably won't happen but we think about security in depth.

Yeah. And as you were talking, I thought of one other one, and I don't know if this resonates with you. It's even just mental weight, right? Scanning my projects folder or looking at my Docker containers. Just not seeing that stuff in there anymore is kind of a relief and it just keeps you focused on what's actually important and you should be thinking about in the given moment.

Yeah, except for you're the one with a giant downloads folder. What are you talking about?

Even though I'm a productivity nerd. I have systems for tracking to-dos and I have ways of capturing them. I can use my Apple watch, I can do it from my phone, it all syncs and that's why I'm so efficient. That's why I get so much stuff done.

That's true.

No follow-up there. But a lot of times when I'm capturing an idea, like maybe I'm out for a walk. I'm like, "Oh, I got to do this," it'll be short. And then usually the end of the week, I kind of triage my notes, and some of these will either make no sense to me, and I don't know what I meant at all. Or just the phrasing of it is so surprising that it just shocks me at first. So the one I had this week, literally all it said was, "Fix time machine." And at first I'm like, "Is somebody messing with me?"

I literally thought one of my kids was being funny and typed it in there. But then I realized, "Oh no, my time machine backups on my Mac weren't working," and it's like a whole thing. I figured it out, but... So, has that ever happened to you? It could be a notebook by the bed. and you scribble something down or anything like that.

I would've thought that it was maybe me from the future coming in and writing something in there.

That's right.

No, I've had it where I was working with the, I'm not going to say her name out loud, but the automation tool built into Apple. And it was writing stuff to things three, which is what I used for my to-dos. But it would only get half of it and I would just talk normal language. So I'd have a to-do that said, "Don't forget to." And I was like, what? Don't forget to what?

Oh, that's worse than not even having it at all. Because now you're just racking your brain. Like, what am I not supposed to forget?

Well, it's always like when... I don't know if you remember this. But back in the day, people used to say, "Tie a string around your finger," or something like that to remember. Like, no, that makes me just remember I have string on my finger not remember the thing I was supposed to remember. What are you talking about? Things happen but you're documenting great, right? But is it great?

Aaron and I would be happy to audit your project, check that documentation, find the gaps, and give you peace of mind that your project is ready for whatever happens in the future. Head over to masteringlaravel.io and schedule a call with us today.