Developer Efficiency

The hidden cost of blockchain dev isn't just in writing code—it's in setting up your environment, testing, and debugging. Mirror eliminates these friction points by providing instant sandbox environments that mirror mainnet conditions, cutting dev cycles dramatically and saving tens of thousands in developer costs.

Solana development used to be branded as “chewing glass” from the famous Elon Musk because of how painful it is. Solana development is often like wandering in the jungle because many tools you would just expect as a developer are simply not there. For example, in web development, you have package managers such as NPM where if you are doing something someone else has done, i.e. generate a random number between 1-10, you can just download a package and get going. The suite of tutorials and guides are endless, and there exist companies such as Vercel that let you deploy your website in under 15 minutes. These tools are so easy to use, many AIs are capable of coding entire websites with a few prompts.

Solana development is anything but easy. There are well documented TS/Rust packages, but if you want to do anything slightly off the beaten path, good luck finding anything documentation or a tutorial, let alone a pre-built SDK. To be fair, the Solana Foundation has made huge strides over the past few years, but there is still so much work to be done.

Arguably the most important part of software development is the testing. In testing there are three types of tests that are each useful:

1. Unit tests - These tests are small tests that test snippets of code/individual functionality. Many developers will run these tests each time they hit save, and could be run 100s of times an hour.

2. Integration tests - These tests are meant to test your entire system as a whole. Often tests like these are run in a CICD pipeline before a system is re-deployed or code is pushed.

3. End 2 end tests - These tests are often intensive and test your entire systems, i.e. the frontend code along with the backend code as well as your payments systems. These are often run before a major release.

In Solana, there are currently three types of environments you can develop in:

1. Localnet - This is a local environment specific to your computer. It is useful for unit tests because you can spin one up, clear the history, and even import state from mainnet. Its biggest weaknesses though are that it only works on your device, so testing in a pipeline doesn’t work. Also, you need to be slightly technical to spin one up which means less technical members of your team, i.e. product managers or testers can’t access this testing environment.

2. Devnet - This is a shared environment across all of Solana. It benefits from the shortcomings of localnet in that it doesn’t require any technical ability to access it and it can be shared between developers; however it has a few flaws that make it very difficult to work with.

   1. Devnet has a problem with people hoarding development tokens, i.e. devnet Sol. You can only airdrop yourself a small amount each day, so you must keep track of any wallets that contain devnet Sol.

   2. Devnet has rate limits, only allowing you to hit the APIs so often before you get rate-limited.

   3. Devnet doesn’t behave like mainnet (live Solana environment) in that transactions finalize too quickly.

   4. Devnet doesn’t have the key tokens/programs you as a developer may be working with such as USDC or an AMM your program interacts with.

3. Mainent - Mainnet is the live environment of Solana. This is not actually a testing environment; however, many projects elect to test in mainnet because it doesn’t have the shortcomings of devnet or localnet. It is often cheaper for companies to spend real Solana tokens than it is to test in a free environment simply because it is faster to test “in production”.