The main differences between development at a startup and at any other enterprise are that at a startup, you are more likely to have fewer developers, rapid releases, scattered code and deployments, and overall, more chaos.
However, in a modern software company -- startup or otherwise -- it is unrealistic to expect that your employees won't have access to your codebase. Even if you attempt to partition the code based on access rights to repositories, your developers are likely to intermix and re-deploy your code as it suits their productivity.
There are some basic best practices you should follow, some of which it sounds like you already are:
Store your code in an enterprise-ready source management tool, and make sure each person who has access rights has their own account. If possible, use a solution that can log check-outs in addition to check-ins. As stated, this will not really prevent people from copying your code around, but it is a good first line of defense.
Restrict access to your source repository to your VPN if you have one, or if not, see if you can configure it in such a way that nobody in the outside world can "see" your server. Again, this does not guarantee anything, but minimizes the risk of unauthorized accesses to your repository, and discourages employees from doing things like checking out code at home.
Minimize the number of deployments to necessary systems. Too often, a startup moves rapidly enough that pieces of code get strewn all over servers in development environments, temporary servers, and so on. Often times developers will be deploying things themselves to test configurations, and nobody ever cleans things up. Just because it is a startup doesn't mean you shouldn't strive to have a clean set of environments with a minimal number of code deployments. Make sure that when developers deploy code, they are doing it only to systems that you own or maintain.
Restrict access to non-production environments to your VPN if you are able. Restrict access to product environments to as few people as possible. Restrict access to actual production data to the fewest number of people possible. None of these will necessarily protect your code, but in many cases, the only thing worse than giving up your code is giving up your (customer) data, for privacy and other reasons.
Now, with all of that said, always assume that your code has and will leave the building. Whether innocently or maliciously, once you have employees, your precious software will be out in the wild somewhere. If you are lucky, nothing will ever come of it, but if you are unlucky, somebody may either (a) use it to develop a competing product, or (b) attempt to claim copyright.
Although there is a cost involved, if you see true value in the proprietary nature of the software you are developing or planning to develop, you need to retain legal services and make sure that at a bare minimum:
Every in-house developer has signed an employment agreement that specifies the work they do for you as work for hire. This is not always straightforward but best practices do exist and they hold up pretty well in court.
Every external developer or development firm has signed a contract prior to any work being completed that clearly specifies the design requirements, and clearly identifies your company as the owner of any resulting software. There can be a lot of gray areas in third party work, especially when requirements are loosely given, and copyright of the resulting software can often be claimed by the third party after the fact.
Every developer, internal or external, has signed some form of a no-compete agreement in your area. Generally speaking, these are not very enforceable in court. However, just by having it, it will often discourage developers from attempting to do things like steal and repurpose code or ideas, and it certainly won't hurt you.
Finally, that copyright notices, licenses, and so forth are all correctly inserted into your code and checked in to your repository, and logged, so that you have a pristine legal record of the creation and ownership of your software. If you do need to challenge somebody on the ownership of your code down the line, you will want a timestamped record of your claim of ownership.
Although there are best practices for some of these, the law around software is constantly evolving, and many gray areas do exist. There is no substitute for real legal counsel on these matters, and if you are serious about protecting proprietary software inventions, you need to have somebody audit everything and make sure you are on track.
These issues are ones that every software company faces, regardless of size. My final advice is, don't get bogged down worrying about all of these details, but do spend as much time as you feel is necessary given your investment in the software. If, as you say, the entire value of your company is in the software product, then you stand to lose a lot if somebody attacks the code. Were it me in that situation, I would immediately seek legal counsel and look for next steps in securing your investment in your product.
