I quit my job to start my own SaaS product. I’m now looking to hire my first employee (another developer).

I will be taking appropriate legal precautions to protect my IP, but I’m wondering what other reasonable actions that I can take to further protect my code / data. The last thing that I want happen is what happened to Tesla where someone dumped the source code onto iCloud and ran off with it to a competitor.

I know that it is practically impossible to prevent this 100% from happening and that I need to make sure that I hire quality people and offer meaningful pay and have the appropriate legal documents signed. Apart from this, what else can I do to protect myself from inside threats? I am pouring in my entire life’s savings into this and I will be devastated to lose what I spent the better part of 2 years coding.

Here’s what I’ve thought of so far:

  • Buy a work laptop for them
  • Encrypt the hard drive (like with Bitlocker)
  • Disable all USB ports
  • Create a non-admin / limited user account with no install permissions and just the IDEs (e.g. Visual Studio) installed. I use Windows 10 for most development with the exception of a Mac for the iOS portion of the app development.
  • Install some kind of employee logging software.
  • Disable access to file hosting websites.
  • Somehow detect and stop when a certain folder is being uploaded or copied somewhere?
  • Somehow make the git repository only accessible from that machine.
  • Install some kind of remote admin management system? Azure Active Directory or something?

This must be a common problem for businesses but I must be searching for the wrong thing because I can’t seem to find a guide anywhere on this issue.

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop
    Commented Jul 5, 2020 at 15:17
  • 1
    I have never in my career had an employer try to give me access to their source code, but also try to prevent me from stealing it. That's pretty much impossible, and counter-productive.
    – user229044
    Commented Jul 6, 2020 at 21:49

11 Answers 11


For the most part this is not a technical problem but a human problem. So while technology has a role to play it has limits.

If the employee will be working from home supervision is more difficult. If you'll be monitoring his/her activity you don't want to be in breach of applicable privacy laws.

The computer has to be secured obviously but the rest of the environment is important too. If you have a corporate LAN there should be adequate protections like an IDS/firewall. But the equipment is often useless without somebody keeping an eye on the logs and the alerts.

Since you mentioned Visual Studio, the developer may need to be at least a local admin to work in optimal conditions. If you cripple their environment they may be tempted and even forced to find workarounds and defeat your security measures which is what you want to avoid.

I'm afraid we all have to trust other people and take risks. The more you monitor your employees, the more you make it obvious to them that you don't trust them and make them feel untrustworthy. At some point the surveillance effort becomes counter-productive because you frustrate and demotivate them. They may become less productive, less loyal.

Security training may be beneficial too. The employee could be honest and acting in good faith but vulnerable to social engineering, and unwittingly jeopardize the company and its assets. Naïveté can be as dangerous as malicious intent. I would say that many developers lack cybersecurity awareness.

Perhaps you should order a penetration test against your company and learn from it. Thus your security posture will improve and you'll be better equipped to fend off attacks.

Employees are often the weakest link but you should also consider the threat of hackers and unethical competitors. In other words don't focus too much on your employees, but develop a 360° security approach for your company.

Physical security is important too. A lost laptop should be no big deal if the hard drive is encrypted and has a strong password. But your backups should be in a safe place. Consider the risk of burglary.

Yes backups are extremely important. Make sure you have a solid backup plan in place, test it from time. Prepare a disaster recovery plan. What would happen if your office burns with all your computer equipment ? You need to protect your source code but also plan for business continuity. Hint: insurance.

If you have valuable IP you could consider applying for patents. Again, this is a lawyer's job here.

Probably you can find insurance to cover the risk. The question is whether it's worth paying for a low risk.

I would also offer shares or some equity in the company. Then your employees have less incentive to go rogue and sabotage your enterprise.

To sum up: there are so many possible risks, I think you are putting too much emphasis on the insider threat. You are more likely to get hacked, than sack someone for misconduct. Your employees must be your allies and considered as such - not as potential foes.

  • 27
    "I would also offer shares or some equity in the company. Then your employees have less incentive to go rogue and sabotage your enterprise." Give the employee some skin in the game and that will be better than any technological solution to prevent him from going rogue.
    – FreeMan
    Commented Jun 29, 2020 at 12:19

Don't do this:

Create a non-admin / limited user account with no install permissions and just the IDEs (e.g. Visual Studio) installed.

Disable access to file hosting websites.

Install some kind of remote admin management system? Azure Active Directory or something?

A lot of developers, myself included, are not going to work for you on this machine unless you're willing to really make it worth their while. It will offer little security, but will be incredibly frustrating to work on.

Here's a simple rule of thumb:

A malignant developer will be able to hack their way into to anything (data, source code, network) used by the product they are working on. They will also hack the laptop you gave them. Thus, protecting and securing your IP in this context is not a technical matter, it is an organisational matter.

I need to make sure that I hire quality people and offer meaningful pay and have the appropriate legal documents signed.

This is your answer.

  • Comments are not for extended discussion; this conversation has been moved to chat.
    – schroeder
    Commented Jun 30, 2020 at 14:59
  • 18
    Pretty much like games with obnoxious DRM: they hurt legitimate consumers, but those that just want to crack it and download it for free will manage to do it anyway.
    – o0'.
    Commented Jun 30, 2020 at 15:06
  • 3
    If a company refuses to give me local admin access to my dev box, odds are good I'm looking for another job. It's not certain because on rare occasions the company knows what they're doing and it's easy to get an IT guy to help me on the rare occasion they haven't already set something up I need. But most of the time I only see restricted local access in companies where the IT people don't know what I need, and every time I need elevated privileges I have to waste my time, IT's time, and probably two manager's time to get approval and then get it done. It's not worth it. Commented Jul 1, 2020 at 21:59

The last thing that I want happen is what happened to Tesla where someone dumped the source code onto iCloud and ran off with it to a competitor.

And after that Tesla failed and were never heard of again? Or Valve after the Half-Life leak?

Or, in reality, mere source code isn't all that valuable. It's generally a pain to integrate with other projects, so unless someone's going to clone the business entirely (which is very obvious and can be dealt with by legal action), having a copy of your source is much less helpful than you think.

The important thing to secure is credentials and customer data. Secure the live servers, access to them, and any AWS or similar accounts. Getting hacked on AWS is far more likely to destroy the business than a source code leak. Even accidentally failing to control costs on AWS could destroy you. Leaking customer data can expose you to GDPR liabilities.

Two-factor authentication is probably a sensible baseline. This can be integrated with Active Directory when you get that (I don't recommend it below 10 employees).

For especially sensitive systems, having segregated "test", "staging" and "production" areas where only you (or cleared employees) have access to "production", and only production has the real customer data, is a good idea.

  • To really appreciate the truth of this answer, try to evaluate what it would take to start a line of business after buying a company's IP from their bank/creditors/etc. If all you have is the code and not the people who understand it, it's a huge undertaking. And if you hire a bunch of people to do something patently illegal, chances that one if them will eventually turn on you are... not low. The risk/reward just isn't there. Commented Jul 1, 2020 at 1:40
  • 3
    Actually, I've seen some companies where the best way to take out a competitor might be to convince them to try to use your source code.
    – cjs
    Commented Jul 1, 2020 at 8:21
  • @cjs That makes so much sense... You might not have been thinking of angular.js when you wrote this, but anyway: If you ever want to write a gmail-killer, think about why google suggests you use angular for that :)
    – Douwe
    Commented Jul 2, 2020 at 10:28
  • @Douwe I certainly was not thinking about angular.js, because I try very had not to think about it. :-)
    – cjs
    Commented Jul 3, 2020 at 15:55

First I'd suggest you to estimate the real value of the software that you are going to develop. Is it really the most valuable asset that you will have? What would it cost you if somebody obtains the source code?

Think of Facebook or Linkedin. They were not the first ones in their field. And their software was not the most valuable asset (yes, they developed and later on open sources Bootstrap, React, Kafka, Samza, to name a few).

After estimating the risks and the costs in case somebody get the code, estimate how much money you can invest into securing it.

Here are just a few points to consider:

  1. One task would be to know what exactly is sent from computer to the internet. The most sites use HTTPS. You cannot decrypt it. One option might be to force all connections to use your VPN, to force install your CA certificates and tom implement man-in-the-middle. Another option might be using some spy software on the computer.
  2. Another task would be to classify the data sent to the Internet. If some encryption or obfuscation is used, it can be very hard to prevent it.
  3. Technical implementation may be very complicated. A developer, to perform its daily work, may need several messengers, several browsers, Email. You would need to control everything.
  4. Even if you would have such tools, still it is possible to make pictures of the screen with the contents of the the most important classes, config files, etc.

Preventing leakage via Internet connection may be pretty expensive and only few companies can afford it.

Considering this, disabling USB does not help much. The main advantage of disabling USB may be preventing the laptop from being infected by malicious code via USB.

Encryption doesn't cost anything and make sense. If the developer is loyal and does not distribute your code, then encryption can help if case the laptop is stolen or lost.

  • 9
    First paragraph is the most important (and at this time I don't see the same thought in other answers). It's unlikely that your source code, downloaded directly from github, is where the value of your business is. Most likely the value of your business is in keeping customers happy by understanding and meeting their needs, including handholding and other services, meeting operational SLAs for availability and performance, and maintaining their data securely. Most likely your code, downloaded from a public github repository, will give your competitor nothing at all towards any of those.
    – davidbak
    Commented Jun 29, 2020 at 16:45
  • @davidak I agree in a sense, except isn't a well written, secure code base a majority of meeting operational SLAs and maintaining data security? And makes it easier to provide other services, offer hand holding, and/or be in tune with a businesses needs. Just because a business shouldn't expect the code base to provide value to their customer, doesn't mean it wouldn't be substantially easier for a competitor to offer the same value with access to their source code.
    – TCooper
    Commented Jun 30, 2020 at 18:45
  • @TCooper This assumes that the only way (or the easiest way, by a significant margin) for OP's competitors to obtain a well written, secure codebase, is to steal it from OP. This in turn assumes that OP's competitors know who he is, and know that his codebase is well written enough to be worth stealing. I could go out and steal a sweet car if I wanted to, but since I have the money, buying one legally seems much easier. If the competitor knew they wanted OP's code that badly, they could just buy him out. I somehow doubt that his price would be that excessive, on a corporate scale.
    – Steve-O
    Commented Jun 30, 2020 at 19:24
  • @Steve-O If it's a unique SaaS start up, it very well could be. And this is more about the concern of an internal employee stealing the code and creating a competitor, not an outside entity. I really don't see your point / the relation of your car analogy either. Again, talking about an employee hired by the start up, not a large corporation.
    – TCooper
    Commented Jun 30, 2020 at 21:10
  • 1
    What is "smb" in this context? If it's "somebody", please just write that.
    – Guy G
    Commented Jul 1, 2020 at 10:29

Let's break this down into 3 sections: Digital, Physical, and Human


I'd recommend giving them a company computer, whether they're working on- or off-site. This will allow you to restrict and monitor some of their activities. However, don't go so far as to install a keylogger. No one wants a keylogger on their system, even if it's a company PC. They'll need to use logins with passwords, which don't go well with keyloggers.

Most of your monitoring should be on the server-side. Monitor traffic from and to the server. Activities should be logged, whether or not they're an employee, if it tries to interact with your server. You can go as far as logging every single request (which is not that uncommon I believe), or just logging things that interact with the important parts of your system like direct access to the database.

Usual traffic may indicate malicious activities. For example, if you see 1GB of outbound data, you may wanna check it it's just your employee retrieving some data for work or someone trying to export your data. Seeing 500GB of data flow from/to a single IP should be an immediate red flag.

Any and all administrative work should be done from your internal network. This means they should have to be from inside to even see your admin portal. If you want to allow them to work remotely, I'd suggest you set up a VPN to allow your employee(s) to connect to your internal network remotely.


There are 2 main things you'll have to watch out for: access to the physical office and the work computer. I'll only discuss the company computer.

Well, actually, there's not much you can do when they have the physical computer in their hands. The best you can do would probably by to put seals on the computer, such that any attempt to open up the computer hardware would be visible to you or at least detected by a forensics professional.

This is law 3 of security:

If a bad guy has unrestricted physical access to your computer, it's not your computer anymore


This is the main factor here. As mentioned by @Anonymous, this is mostly a human problem.

First of all, hire someone you can trust. We have penetrations testers trying to break into systems all the time on purpose. One of the main reasons they're allowed to do this is because they have little reason to do bad things to your system. In order to qualify, we have to be thoroughly vetted by the hiring company. Trust and interest are the main things keeping people with access to your system from intentionally doing damage.

Notice I said intentionally. Insider threats aren't always intentionally malicious. The TSA keys were leaked no because someone wanted to do harm, but because of blunders by internal and third parties. An untrained employee can easily wipe out your entire database by mistake with a single command. Untrained employees are often vulnerable to social engineering attacks and can let an outsider in when they shouldn't.

To avoid such problems, you have to train your employees on both in system administration and security. Training will help with little accidents, but only thorough vetting can keep malicious actors from becoming part of your company.

Now to address your suggested ideas

Buy a work laptop for them

Good idea

Encrypt the hard drive (like with Bitlocker)

This will protect data at rest. Great idea, but not gonna help much against an employee with access to the computer and the password(s).

Disable all USB ports

We use USB ports all the time. USB mouse, keyboards, webcams, etc. This will also be the main means of conveniently transporting data for most people. Instead of disabling them all, use software to prompt the user every time a USB device is plugged in. You'll also have to train your employee(s) not to plug some random USB they found on the street into the work computer. The most you can realistically do is train and whitelist their USB devices such that only registered devices can connect to the computer.

Create a non-admin / limited user account with no install permissions and just the IDEs (e.g. Visual Studio) installed. I use Windows 10 for most development with the exception of a Mac for the iOS portion of the app development.

Again, software preference is personal. This will be entirely your choice to restrict their work performance should you not allow them to use their preferred tools. Restricted non-administrative accounts is advisable, though you'll have to manage installing tools for them yourself.

Install some kind of employee logging software.

Most of this should be on the server-side rather than the employee's computer. Logging their local activities will make it easier to monitor them and sue them for malicious activities but be careful not to go too far. Children don't like their parents watching everything they do, and neither do your employees. Server-side logging shouldn't make them uncomfortable so it's a great way of monitoring.

Disable access to file-hosting websites.

This may be difficult to do, but I'm not sure how you can do this yourself.

Even if you can do it, they may need to access their personal drives for some work, but it's your choice to be restrictive.

Somehow detect and stop when a certain folder is being uploaded or copied somewhere?

Monitor traffic to and from your server. It's their choice to copy your files to a USB stick and upload it elsewhere. You can only monitor to detect unusual/suspicious traffic from/to your server.

Somehow make the git repository only accessible from that machine.

Use a VPN for this, as well as all your administrative portals.

Install some kind of remote admin management system? Azure Active Directory or something?

I mainly use Linux so I'm not well-versed on Windows, but Active Directory should be accessible only from the internal network. Again, use a VPN for remote access.

  • 8
    This will be entirely your choice to restrict their work performance should you not allow them to use their preferred tools. Keep in mind that forcing developers to use tools they don't like is not just a hit to productivity, and otherwise cost-free. It can also (depending on the developer) make her frustrated, which paradoxically may have the direct effect of encouraging employees to work around your security policies.
    – cjs
    Commented Jun 29, 2020 at 23:44
  • 4
    "use software to prompt the user every time a USB device is plugged in" Confirmation dialogues where the response is the same nearly 100% of the time just train the user to click "ok" without thinking about it. They arguably make security worse because the user is not thinking about security, they're thinking how annoying the confirmation popup is. A prompt when an unrecognized USB device is plugged in is more useful with Allow Once, Allow Always, Disallow, and Disallow Always options.
    – Schwern
    Commented Jun 30, 2020 at 0:34
  • @Schwern You're right. It's usually better to have a list of allowed devices instead of prompting every time. Commented Jun 30, 2020 at 2:00

I once had a job interview at a prop trading company that was worried about insider risks. The mitigations they used were:

  • All work conducted on-premises
  • No bags, phones or cameras allowed into the offices
  • No e-mail
  • Corporate network not connected to the internet
  • No laptop computers, only thin clients
  • All thin clients in locked cupboards, only screen keyboard and mouse accessible
  • No local admin access
  • Approved-software-only rule strictly enforced.
  • Metal detector and guard at every entrance
  • No out-of-hours working allowed

I didn't take the job because I thought I'd take a big productivity hit from all those restrictions. But they did manage to hire quite a few people, because they offered exceptionally high pay.

  • 13
    Those mitigation's are to be expected in defense contracting, and other high profile, high risk environments. For OP hiring his first employee though it might be overkill.
    – Douwe
    Commented Jun 30, 2020 at 9:25
  • 3
    Sounds more like a prison to me, not even the highest pay would hire me with such crazy working conditions, screw them.
    – DARKGuy
    Commented Jun 30, 2020 at 16:12
  • Did they ever hit the news for suffering a breach ? No? Then while it feels like overkill, probably achieved the goal.
    – Criggie
    Commented Jul 1, 2020 at 21:27
  • 2
    @Criggie Actually they did - or at least, their response made the news. It was before I interviewed there, and might explain why they had so many restrictions. I'll have to be coy about the company name though, as I can't remember the expiry date for the interview NDA.
    – mjt
    Commented Jul 1, 2020 at 22:00

Your focus seems to be on protecting yourself from adversarial insiders, i.e., those who are consciously and deliberately trying to breach your security.

As others have pointed out, it's probably impractical to have significant protection against deliberate attacks via technical means. mjt's excellent answer gives a typical set of restrictions, but even these can't prevent people from taking information out in their heads. And as others have pointed out, these have a large negative impact on productivity. In particular entirely disallowing any Internet access from development machines is likely to be troublesome in this day and age. (You'd probably at least want to provide a second "air-gapped" machine connected to the Internet so that people can look up documentation and the like, though this now exposes you to someone reading code from the secure system and typing it in on the insecure system.)

However, when looking at internal technical security measures, what you do want to focus on is mitigating the risk of inadvertent security breaches. These are far more common than deliberate attacks and much more easily preventable.

The most important part of the approach for doing this, and the one that many companies get quite wrong, is to make it easy for the developers to securely do what they want to do. Often technically this isn't too difficult and most of the work is in support and training.

Important aspects of this approach are:

  1. Be willing to take short-term productivity hits in order to do training and security fixes. For example, if you have a policy that developers' ssh keys must remain only on the system into which they log in, and the developer is having difficulty with ssh-agent, make sure you're clear in both your words and actions that getting her working smoothly and correctly with ssh-agent is a higher priority than getting feature X done.

  2. When a developer says she wants to do X, work with her immediately to figure out the core thing she wants to achieve and a way to do that both securely and easily. You want the developer to go away happy that she has a good solution to this problem, rather than looking for work-arounds because she finds the solution you offered to be inconvenient or, worse yet, is being penalized for lower productivity when trying to work securely.

  3. Ensure you're able to provide training and immediate support for doing work within your security policies. If a developer is having trouble getting file X to system Y while following your policies, you need to show her right then and there your easy and secure way to do this, rather than leaving her frustrated and looking for other ways to do it.

  4. Follow your own security policies and fix problems pointed out by developers. If you have a policy that you should never be moving sensitive data over HTTP, and a developer points out that she tried using an internal system that she thought should be using HTTPS but wasn't, get that fixed immediately rather than telling her just to ignore the problem. If you do the latter, she'll learn that ignoring things that look wrong is the correct thing to do. If the company policies say otherwise, she'll learn that ignoring company policies is the correct thing to do in some circumstances.

In short, you need not only to set up security-conscious systems and policies, and tell developers about them, but also demonstrate that these are important to you by a) being willing to put in the work to make doing things securely easy, and b) prioritizing them over getting features done. If you do this well it won't slow you down in the long run, but if your actions don't match your words in this area, your security systems and policies will be a cost with little benefit.


Ok, let's play this through: I want to steal your code.

I plug in devices, nothing works. I then make some zip-files and mail it home. No, you blocked all mail webclients? Ok, so I go ftp / ssh/whatever. You blocked those too? So I upload it to a website. You blocked thousands of them? As a developer I own some domains anyways, so I just upload it to one of them. Those you can stop you don't want to hire.

Here is a solution: Give them access on a need to know basis. Only let every dev work on a part of your project, and no-one has the full code. Create multiple repositories, and parts that are high-value and little-change go into a restricted one. You can still share documentation for the API.

I don't know your field of work, but in most SaaS projects, the secret is not how you do something - that's mostly straight forward. What you want to protect is your advantage over competition, as they would need to put in the work you already have. So even if they know how your stuff works (or how they could make it work anyways), having them to develop instead of copy is all you need.

  • 10
    "Only let every dev work on a part of your project, and no-one has the full code". These are Manhattan Project levels of security and need Manhattan Project levels of resources. OP is hiring their first employee.. it's a bit much don't you think?
    – Douwe
    Commented Jun 30, 2020 at 9:28
  • 3
    "Those you can stop you don't want to hire." => I like this and it's true, a competent developer would find a way.
    – Kate
    Commented Jun 30, 2020 at 16:47
  • 1
    @Douwe that depends on how the system is built. Many modern systems are split up into different repositories anyway, so it's just a matter of assigning work on the less sensitive ones and not granting access to the other repos in such a case. I like this idea as it gives the dev all the freedom how to work on the stuff they need to work on while not having to worry about those other parts that aren't their responsibility. It's a win-win in my book, if done right. It requires a lot less effort than shutting down the Dev's machine and taking care of all admin tasks on it. Scales better, too. Commented Jul 1, 2020 at 21:00
  • @FrankHopkins I'm all for (micro-) service architectures, however when there's only 2 devs on a team, I don't really see this work in practice. The single point of failure problem of not letting the other dev have access is worse imho. And let's be honest, in practice these small teams are more akin to a marriage than to a big firm with a complex security strategy. Your main advantage as a small shop is that you lack the overhead and bureaucracy that hinder the big boys. Startups (should) operate differently.
    – Douwe
    Commented Jul 2, 2020 at 9:56
  • @Douwe I have different repositories for different pieces even for my private projects I work alone on. I'm not saying they need a microservice architecture - and sure for some type of projects it may not fit, but it's not that hard to move some essentials into a separate library if you so wish and I don't see any big admin or convenience impact - except that OP won't get coding help on the repos he puts aside. Commented Jul 2, 2020 at 9:58

I am surprised I haven't seen the answer that most start ups use.

Give the employee equity. Make them a co owner, doesn't have to be 50-50 but give them an incentive to make the business succeed. Many start ups do this with equity or profit sharing etc.

Instead of trying to restrict them. I guarantee if you give your employee the promise of 10% profits (assuming this is significant) and gave them a open non restricted laptop that they will work really hard to make sure the business succeeds.

Source: I have worked at small start ups and large tech companies. I can guarantee you none of them restricted the laptops like you mentioned and the ones that did do not hire top tier engineering talent.


There are two possibilities here, you hire someone trustworthy or you hire someone untrustworthy. If you want someone trustworthy, the job needs to be attractive to someone trustworthy, and the work conditions of the job need to be such that you keep the trustworthy employee.

If you hire someone untrustworthy they are going to do whatever they want regardless of what steps you take. They will always be for sale to the highest bidder.

If you lock things down to make sure whoever you hire will be frustrated at every turn, you are making it hard for the trustworthy employee to do their job and at the same time sending the message you don't trust them. The trustworthy employee is likely to be less money oriented, and more about doing a quality job, but they will want a quality work environment. Lack of trust does not make a quality work environment, neither does having to code on a very locked down machine.

Abandon the technical solutions and focus on making the job conditions and work environment attractive to the trustworthy employee.


A bit of a mean answer but think about it this way. If they really want to steal your code they could just take photos of the screen. As such I would advise you to lock the screen brightness at 0% so that they can't see what they are working on.

... Or you might want to make sure that they don't have an incentive to steal from you, like taking care of your employees and treating them like a friend. Sooner or later when your business gets big enough you will need to trust a lot of people, like finances, IT department. Better get used to trusting people sooner, rather than later.

To add to this, if someone with sufficient knowledge wants to get your code they will. There is nearly no way of stopping that. What's way more likely to happen is an outsider attack via social engineering or a direct hack. Insider attacks are way too dangerous (in legal and financial terms) and time-consuming in most cases. If you are just starting out as a company your legal protection should stop such an attack. That's a different case is your a billion-dollar company, but you don't seem to be a billion-dollar company yet, so probably not the one thing you need to worry about most.

  • Legal protections are less effective in companies just starting out. IP leaks shutter the company even with legal protections. Sure, you could sue, but you won't have a company anymore when someone else hits the market before you with your own product. Finances and IT are not the "crown jewels" of a company. Yes, you need to trust people to take care of those things, but it's a lot harder to sink a company completely in those areas. And legal protections are easier in those other areas. IP is your company. "Just trusting" a stranger with it is a problem.
    – schroeder
    Commented Jul 8, 2020 at 7:44
  • @schroeder I don't quite agree. In finances it's quite common for smaller companies to only have one, maybe two people, without supervision. This leaves open the possibility for said people to siphon of money without anyones knowledge. But to get to legal protection. If op is really a one man SaaS company I doubt that there will be a multitude of competitions that'll infiltrate his business and steal his data (I'm thinking short term). When hiring a new employee make sure they don't own their own SaaS business or worked for another really small SaaS business recently.
    – The_Moth
    Commented Jul 8, 2020 at 7:55
  • "siphon money" will not "shutter the company" and such a situation is recoverable. Both are points I've mentioned above.
    – schroeder
    Commented Jul 8, 2020 at 7:59
  • Your answer is "make friends and trust people - legal protections take care of the rest". For a small company who is looking to go to market, this advice is not effective and naive. Plus, you're not saying anything more than many other answers have, but with a lot better supplemental advice.
    – schroeder
    Commented Jul 8, 2020 at 8:01
  • @schroeder In no way do I wan't to imply that op should just trust a stranger with it, op definitely needs proper legal protection and the like, but I don't think that this level of paranoia is at all useful in a new business. A new business is a risk and should be treated as such, you never have guarantees in life. If you think everyone around you is out to get you you won't get anywhere.
    – The_Moth
    Commented Jul 8, 2020 at 8:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .