Editor’s note: LimeLight, the newest addition to WRAL TechWire’s growing lineup, offers ways for companies and individuals to bring more attention to their efforts. Today we feature Ben Gilman, CTO, Developer and Product Strategist at Dualboot Partners. With almost 20 years of experience in design thinking, product creation and successful launches, the breadth and depth of Ben’s skills combined with a strong business acumen make him a distinguished leader for new digital products.
When you’re building a tech company or product, what you don’t know can hurt you.
We’ve seen it time and again with the clients we work with: They are building a business around technology, while they have a limited technical background. Unsurprisingly, they hire developers (either in-house or outsourced) to build the tech side while they focus on everything else — sales and marketing, growth and scale. They build a team in which everyone gets to do what they do best, and it feels like the right move.
The problem is, as an owner, you don’t have the luxury of staying in your lane. While you certainly don’t need to know how to write code, you do need to understand how to retain ownership of the technology that you’re building so that, if you lose a member of your team, your business stays secure.
Over the course of building hundreds of software projects for our clients and ourselves, we’ve learned there are five things businesses and founders need to understand to maintain control over what they’re creating. We’ve listed them below, to help current and future founders save themselves from the mistakes we’ve seen more often than we’d like.
Let’s be clear: This is not a matter of trust — most developers, in our experience, are not out to deceive the companies they work for — but it is a matter of making sure you have what you need to protect the longevity and viability of your business, no matter what.
Own your source code
Most entrepreneurs and leaders understand the need to own the source code behind what they’re building, but in our experience, only about half of them actually do. That’s why this ranks first on our list.
While it sounds simple, there are technical complexities that give owners a false sense of ownership when it comes to their source code. The key distinction is this: To own your source code, it must be housed in your company’s account, not your developer’s.
For instance, we worked with one company that had previously hired its own in-house development team. The company technically owned its source code, but each of the in-house developers were using encryption keys that were linked to their personal GitHub accounts. When the developers left, the company removed their encryption keys and, in the process, lost the ability to deploy their code.
There are ways to get around a situation like that, but they can be complicated and frustrating. You can try talking to the developers and asking for their help, but if they left on bad terms, that’s unlikely to work. There are ways to legally hack the systems and regain access that way (which is what we were able to do for the company), but that requires an investment of time and resources for something that could be avoided from the start.
So, first thing’s first: Whether you’re using Github, Bitbucket, Gitlab or anything else on the market, all your source code should be in your account, not your developer’s. Even if you’re never checking in code, you should have the ownership rights to that account.
Own your cloud environment
Similar to the above, it’s not enough to store your source code and other information in a safe place. You have to own the systems that run your application.
While your developers can and should have administrator access to your infrastructure, you also need to be an owner for all remote cloud environments (such as Amazon Web Services). It’s really as simple as that. You have to plan for the potential that even the most important members of your team will leave. If that happens and you aren’t prepared, with guaranteed access to all important resources, you’re going to have problems bringing in new technical resources to keep your company going.
Which brings us to our next point…
Limit “key-employee risk”
No one person on your team should hold all the important information.
It’s true for pretty much everything in your business, and it’s especially important with your technology. Your company must be able to go on, even if a “key employee” leaves. That means you need to spread the knowledge around. You should have multiple developers who understand the core areas of your infrastructure and code base. That way, you have people on your team who can step up in the event of any personnel disruptions — whether that’s a vacation or the loss of an employee.
Have admin access to all third-party service providers
Do you use Asana? Github? SendGrid? MailChimp? You’re going to need ownership access to every account for every third-party service provider you use. Here’s why.
Inside every software application a company is building, there are typically a handful of third-party services providers in use, and your app won’t run without them. If you don’t have ownership access to every single one, you put the viability of your application at risk. You need to know how to log into each account. You need to own the credit cards each one is linked to. That way you’ll know, if you lose key members of your team, your application will remain functional.
Document your deployment process
This is the most complicated — and the most frequently missed — step in the development process.
When you’re launching a platform or application, your deployment process should be documented and, ideally, scripted. Translation: It’s not enough to own your source code; you need to know how it was built, how it’s intended to work, and how to get new versions of your code out to your users. That process cannot rely on any specific developer to execute. Without this documentation in place, you can experience a variety of problems that range from minor inconveniences to complete outages of production systems.
That’s why it’s important to require thorough documentation for your deployment process from the start, using deployment-specific access keys that are not tied to a particular individual. Think of it like a playbook: with a strong one in place, your team has what it needs to succeed. Without it, you’re left standing on the sidelines, with no idea what to do.
We know how important each of these items are because we’ve been there. We’ve seen what happens when companies don’t protect themselves from the start. And you can’t do that effectively if you don’t know what you don’t know.
We hope this shines a light on what you need when you’re building a technology platform or business. If it saves you from massive headaches and expensive fixes, we’ll call that a win.
Ben Gilman: CTO, Developer and Product Strategist
With almost 20 years of experience in design thinking, product creation and successful launches, the breadth and depth of Ben’s skills combined with a strong business acumen make him a distinguished leader for new digital products.
