You're obviously a critical component of your startup's continued existence. Plenty of people have addressed the issue that your work-life-balance is screwed and your employer undervalues you by a great margin (money talks). I will speak to your worth as a programmer.
You say (I paraphrase) you don't come up with your own solutions, you just plug things/ideas from other sources. Well, that is every creative endeavour for you. Every author, painter, musician and yes - programmer - does that. If you take ideas from different sources, combine them, take them to a new conclusion - you already have created something new. You most likely already are an amazing programmer. Your workflow is industry standard. It is a good thing to approach the world with open eyes and not reinvent the wheel all the time.
I consider myself a genius level programmer (bragging is a valuable skill if you want your employer to compensate you). I listen to talks from great programmers, read books like The Pragmatic Programmer (still valuable after more than 20 years) and absorb ideas. I am driven by the hunger to find an application for them. At no point do I come up with my own algorithms or new industry changing paradigms.
I create value by writing interface driven software. This applies for any interface, networking, APIs, CLIs and even GUIs. It all starts with a problem you want to solve. A use case in industry speak. And I usually already have an idea what the software needs to do to achieve this. But the focus here is on how it is used:
- It needs to be concise and unambiguous in its use (the documentation should lay out which problem it solves and how it is supposed to be used for that)
- It should make it difficult to make mistakes, e.g. require explicit units in configuration files etc.
- Give expressive negative feedback as soon as possible, when you're programming an API, it is often possible to make things fail at compile time
- Allow the user to pick up where they failed, make a correction and continue, this is a non-issue when you're writing an API or a command-line tool, it's critical when designing a GUI
So I focus on making it intuitive to use, or at least easy to learn. It needs to provide real value (and the documentation should explain that value first and foremost). I focus on errors and how to recover from them (as part of this concern).
Often this breaks the cleanly layered design you had in mind at first, the kind of design a software developer immediately comes up with when they see a problem and consider what needs to happen in order to solve it. This kind of design focuses on the happy path. If you focus on interface and how to handle errors and feedback, you will need access to a lot of information that the whiteboard design would have encapsulated. This is why your software architecture should be interface driven.
One last thing, a warning about stack overflow. Incorrect but simple solutions have a tendency to win on stack overflow when the correct solution is complex and hard to understand. It is also rampant with wrong/dated ideas, such as multiplication is more expensive than addition (it needs more die space, but multiplication and addition both are a single cycle in most modern architectures). Division on the other hand is always expensive, there is just no way around it. That said, you still can find amazing value on SO.