I hate to break the news to you, but “systems analyst” is a job title that’s pretty much exclusive to the enterprise world. For the most part, start-ups don’t really have a place for “business/system analysts”. Let me explain…
School of Thought A: Call it SDLC (Systems Development Life Cycle), the project approach, or the waterfall approach goes something like this: Define a need, conduct analysis to answer the question “What”, conduct design to answer the question “How”, program, test, program, test, compare to the Functional Specs from the Analysis Phase, conduct User Acceptance Testing, promote, deploy, repeat anything as required. The more rigorous the documentation and project management, the better.
School of Thought B: Build something ASAP. Get it out there ASAP. Get feedback ASAP. Iterate
indefinitely.
For the most part (I’m sure there are many counter-examples), enterprises employ School of Thought A and Start-Ups employ School of Thought B. There simply isn’t a need for systems analysis in School of Thought B. By the time you’re done analyzing, someone else is servicing the customers you sought.
My advice: Combine a love for building stuff with your love of systems analysis. They go perfectly together. In fact, we now have a name for that: “programmer/analyst”.
The systems analyst who can code is a better systems analyst because he can test/evaluate his ideas. The programmer who can conduct analysis is a better programmer because he knows what to work on. This may not be what you wanted to hear, but you’re in a perfect position to do both, so do it.