# Hidden costs of your technical decisions and some rules to make your life less hell in the future I want to go over a couple decisions I've seen made and maybe why you should consider otherwise. At the very least, this is food for thought. If you're facing some of these in your future, which you definitely will, or already have I want to make the argument about why you should maybe reconsider. I'm mostly targeting this towards pure Software Engineers or CTOs, probably at a startup, having to make technical decisions outside of software features. ## 1. Stick with a monolith first If you do this you **NEED** to have good code separation, following something like [Domain Driven Design](https://en.wikipedia.org/wiki/Domain-driven_design). It doesn't need to be strictly followed, but as long as you don't have separate feature sets reaching into other feature sets, you should generally be ok. If it needs to be shared it can be but then it doesn't belong to a feature set. Also avoid on-prem support at all costs, stick to being a hosted SaaS company. I can go into more detail but I hope the implications are obvious. And it'll be obvious if you think about your release process. ## 2. Your release comes first (CI/CD) This is the heart of what will be a majority of your headache if you get this wrong. One big thing I would try to do is separating your releases from your deployments, if possible. It probably isn't practical at the start, but keep it in mind always, you should make that transition early. ## 3. You don't need more tools, work under constraint Here's the tools you need at the start: 1. Access 2. CI/CD 3. Monitoring 4. Documentation Another thing is you don't need more tools, also you don't need to create workarounds for these tools. If you do, you may be doing something wrong or so unique that you need to re-think your architecture. ## 4. You don't have a Linux team, go serverless To start for this one, I'm not talking about lambda or function running. I'm talking more about [Fargate](https://aws.amazon.com/fargate/) or [GCP Cloud Run](https://cloud.google.com/run?hl=en). ## 5. Monitoring I've seen it multiple times at companies, and all over the internet. Usually referencing Datadog costs being expensive, that's likely only the case if you're going into microservices, Datadog biggest expenses are going to be host monitoring for each service, you can avoid that with Fargate's better pricing tier or sticking and scaling with a monolith. The reason why I'm going to say just use Datadog is in my experience, it is the best possible monitoring platform. Bar none. And getting users to use it and having a single place where everyone can go to for anything involving the status of the application provides a significantly better user experience. Also for the engineer or DevOps person who'll be integrating things into it, it's easily the best developer experience also. # Closing Comments The best thing about these decisions? When you seek to scale, make the team pods and apply these principles to each pod. With that, you can truly scale infinitely and you won't run into the problem almost every mid-sized company runs into. Another broad topic is you may think it's cheaper to roll your own monitoring or Kubernetes or whatever else, and it may be at the upfront cost. But please. Price in your sanity, and price in the engineering cost it takes to upkeep and upgrade it.