Sometimes lead developers disappear, your technical co-founders leave, and dev shops go out of business — don’t be left holding half a product and mysterious assets with no momentum.

Disruption comes in many shapes — some more rapid than others, some more bridge-burny than others, and occasionally, totally calm, expected and mutually agreed upon.

• You’re using a dev team that has some internal strife — all of a sudden, they tell you that they’re restructuring and can’t support your project.
• Or the primary developer on your team, inhouse or offshore, has decided to leave.
• Or you have a technical co-founder/lead developer sort of situation and there’s a fallout due to project direction, differences of opinion, or any other reasons. Or not even a fallout — maybe they went and got a full time job and simply lost interest.

These are just a couple of examples but they all lead to the same situation — someone, not you, built a whole lot of something, that you have a vague idea about, but no way to transfer that knowledge to a new developer, team or anyone else without simply dumping everything you have on them in a “figure it out” sort of fashion.

That might work if there’s simply not much to dump, but don’t underestimate how much even a single good developer can do in as little as a month. Chances are, there are dozens, if not hundreds, of architectural, design, infrastructure, functional, and otherwise technological decisions they’ve made that, without clarity, any future developer or team might look at with absolute confusion.

When a new developer or a dev team looks at code with confusion, the de facto recommendation will be to throw it out and start anew. Don’t end up in that situation — especially if the decisions that were made, even if you don’t know what they are, were generally good.

Hope for the best, prepare for the worst

If things are going downhill with your developer(s) for any reason, it’s probably too late to start thinking about these things — especially if tensions are high.

The best way to prepare for a smooth development transition is to start on day one. In fact, having the assets we’re about to discuss is a big part of Due Diligence, Checkup and even the Crowdfunding Score reports we execute every day — even if the original developer(s) are still with the organization. In our reports, it’s a combination of maintainability, documentation, process, and dev onboarding — almost every section of the due diligence process touches on the ability of a developer to come on board, be productive, and move the product and company forward— with or without the original developer(s) in the picture.

I really can’t stress this enough — having the processes in place on day one to ensure a smooth transition or addition of developers in the future will save you time (months), money (thousands of dollars up to the entire cost of development to date) and headaches in the future and can be the difference between being able to raise money and not. Every point in the checklist below comes straight from our Data Room Request List and would be part of most due diligences performed by anyone.

The Checklist:

This checklist varies by type of company — software, hardware, etc — but I’ll focus on the types of companies we work with most often that run into this problem — companies whose primary product is a website or an app of some sort — whether social, SaaS or some other model.

1. A developer should be able to pull down the code from wherever it lives and follow simple instructions on how to get it to run on their local machine. These instructions should include a list of prerequisites that should be installed and could take the form of READMEs in the code, wiki pages, or even a short video. These guides change over time as the code changes so make sure it’s still relevant from time to time.
2. Speaking of code, make sure the code lives in a place owned by the company — not some developer’s or dev team’s github account. Some offshore teams will give you all sorts of excuses about why the code should be in their github (or wherever) — those excuses are usually bogus. If a relationship goes downhill, make sure that your consulting agreement is explicit about you owning the code and that the code is in a place you own — avoid any potential problems.
3. Since you should never commit passwords, keys and other secrets and code sometimes can’t run locally without some of those, there should be a place where those are stored that you as the founder or executive in charge (WISP, etc) has access to. There are some things like database root/sa passwords that, if lost, can cause a whole lot of problems. AWS and others have resources for this or you can use something like secure notes in LastPass and others — the key point here is that if your developer “gets hit by a bus”, secrets should not be lost.
4. SDLC diagram/workflow — a new developer should not have to guess at this process and it doesn’t take much to convey it — it could be sophisticated diagrams with git workflows, etc but it could be as simple as a paragraph or two that explains what happens — what branches are there, are topic branches used, are there restrictions for merging, how CI/CD works, how tests work, how repos interact, what depends on what, etc. This is more or less a “this is how we do things around here” document.
5. Infrastructure diagram — this is a “what’s where” sort of thing. Again, we’re not looking for anyone to spend days putting together some complex Visio diagram, but a picture of a whiteboard that explains that you have these services hosted on AWS (or whatever), they talk to each other through some other thing, you’re using S3 for images, cloud functions for this, SQS for that, MySQL for production, Redis for cache — whatever it may be — you need it in some easy to digest document that a developer can look at and see what devices and services are in play for what reason.
6. Software diagram — similar to the infrastructure diagram but for the actual code — what projects are there, how do they interact, how are they laid out, why are they laid out that way? What functions/modules of the application do different parts of the code represent? This is often easily accomplished by a recorded codewalk — I’ve seen this be done well in 15–20 minutes but can sometimes take as long as an hour or more.
7. Even if the description of software interaction above can be accomplished without a codewalk, there should still be a recorded codewalk that a new developer can watch and which should be reviewed every couple of months or when the project structure changes significantly. Most codewalks can be done in ~20 minutes. If there are multiple projects in play, make sure you cover all of them and if there are different lead developers per project, make sure that the code walk is recorded by someone with the best knowledge of the code.
8. Database diagram and/or recorded walkthrough. Ideally, your database(s) tables, fields, and other assets should be well named, well organized and self-explanatory. Unfortunately, that’s rarely the case— even if something is “self-explanatory” to the developer that made it, it’s still worth explaining. If you have a proper database model, most database IDEs will allow you to export a diagram with table relationsso this should be a 5 minute task. If, for whatever reason, you’re struggling to export anything meaningful, that should be a (big) red flag that your team is doing something wrong.
9. A demo of the product or products. Developers that are starting from scratch have it pretty hard — they have to pull information out of the heads of founders and turn it into something. But developers that come in to an existing product have it much harder — not only do they need to do the same thing, but they need to figure out how the previous developer(s) went about it, whether it was right, whether there are gaps, and how to proceed. This can sometimes take weeks before a new developer is truly productive. You should ease the transition by having a concise demo of what you have to date. Not a pitch or a sales demo but an honest recording of someone going through the application and pointing out how things work, whether that’s good, what’s missing, what can be better, etc — all of this adds necessary color for anyone coming onboard — whether in a replacement or additive capacity.
10. And finally, round it out with a list of other tools and resources that might not be covered above and any other diagrams or explanations that are worth having — maybe you have complicated algorithms or a unique or esoteric way of dealing with a specific problem — a paragraph written by a friendly developer now can save a week of a new developer’s time digging around in the future.

Every company is different

The list above fits the vast majority of companies, but it’s possible that you’re doing something that makes one of the items above not applicable or that you feel you need another asset to ensure a smooth possible transition — that’s OK.

Trust but verify

Some founders are really happy with their developers — whether it’s a technical co-founder or an inhouse or offshore team. Just because you’re happy and just because you feel they’re highly competent, doesn’t mean they’re doing any of the things above or even have the experience to know they should. That doesn’t speak to anything negative beyond that most developers simply don’t think about these things, no matter how good they are.

Work with your developer(s) to make sure that the list above is always current and up to date. It doesn’t hurt to even include an occasional, short meeting to go over it

If disaster strikes, planned or unplanned, agreeable or not, ensuring the business continuity of your company is your responsibility — even in a startup.

And, of course, we’re always here to help any founders that need help. Preparing startups for success from day one and working with dev teams to ensure these kinds of processes is our bread and butter. 

This post was written by Igor Belagorudsky (Boston-based Founder, President, Advisor, Board Member, and CTO of a number of startups, and a Mentor in the Boston Founder Institute), and was originally published on Medium. 

FastCTO is a network of real CTOs that work with early stage startups and mature companies to provide CTO services and help companies succeed. Startups can get access to experienced, high valued CTOs for a few hours a week from formation through Series A and beyond. FastCTO also provides highly specific buy-side and sell-side due diligences and audits, and is the home of the FastCTO Crowdfunding Score and Report. FastCTO is not a dev shop, an agency, or a staffing company.