Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

As a one-person ISV, what are the major challenges you faced? How did you overcome these challenges?

share|improve this question

closed as primarily opinion-based by MichaelT, Dan Pichelman, GlenH7, Bart van Ingen Schenau, gnat Sep 23 '14 at 9:23

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

up vote 2 down vote accepted

Lots of good points, but one more: many clients will regard the fact that there's only you as a risk.

With larger teams or organisations if anything happens to one person (they fall ill or whatever) then others on the team will tend to have the knowledge to cover them. Where it's just one person that sort of thing isn't possible.

This will particularly be true where there may be some on-going component to the work such as third line support. If you're away, or on another project, will they be confident that they're going to get the service they need.

share|improve this answer
Thanks for pointing this out, my brain didn't even go there. That's exactly what I was looking for... I knew way to evaluate the whole MicroISV thing. I guess that's why most of my friends keep telling me to turn one of my software products into a book. Book authors don't have these issues. – Michael Riley - AKA Gunny Jan 31 '11 at 13:59

Pierre already named some issues, here is another list:

  • motivation - can you work without a boss or will you be distracted?

  • credibility - clients will ask you "what happens if you die or stop working?"

  • project size - when you work alone, and have all those other tasks Pierre mentioned, it will be hard to work on a reasonably large project and finish it before retirement

  • speed - whatever your idea is, chances are that larger teams can and will implement it faster and publish it before you

share|improve this answer
+0.5 for motivation and +0.5 for credibility – user2567 Nov 25 '10 at 14:25

You must assume all roles, including sales, marketing, finance, development, administrative, legal, and more importantly product development. To name a few.

This means that most of your time, you will eventually do something you dislike or you are not good at.

That's the major challenge.

If you can cope with that, I'm sure you will be successful.

share|improve this answer
Being a developer and a tester of your own stuff is hard enough, never mind throwing sales, marketing, etc. into the mix as well. – Wilka Nov 25 '10 at 16:43

One of the things that gets me is time it takes to type everything.

  • When you're writing requirements docs for the client to sign off on - you're not coding
  • When you're filling out use cases/user stories - you're not coding
  • When you're updating the schedule - you're not coding
  • etc.

Honestly; it's not so much that these roles 'take time'; obviously they do. It's not even, as Pierre said, that I don't like them; I like doing these things. It's the fact that I'm sitting at my machine, with my IDE open, but I'm typing in Word, or the bug tracker, or something of that ilk when I have solutions to problems in my head trying to claw their way out.1

How do I get around it? I try to use tools and processes that can cut down on it as much as possible. Right now I'm giving FogBugz + Kiln another shot so that checkins can be tied to cases more easily. I try to keep things like use cases in FogBugz labelled as features, and I modify them there. I only copy them out into a word document when someone needs to see the document. Likewise for specific requirements. FogBugz also has some automated scheduling built in, which is nice (though I haven't really used that part of it).

There's other tools that can do these things as well, but I'm just telling you whave I've chosen.

1: I have an irrational fear that if I don't get my 'solutions' out of my head and into a compiler as soon as they come to me, then I'll forget them and they'll end up lost in my head forever.

share|improve this answer
Do you think the Dragon naturally speaking tool would work for you? – Michael Riley - AKA Gunny Jan 31 '11 at 13:54
@Cape Cod Gunny: For some of these documents, sure. Because a lot of things like user stories/use cases/docs are mostly prose, then speaking the documentation might speed things up. I don't really think it would be by a large margin though. Most people don't speak faster than 80-100wpm. – Steve Evers Jan 31 '11 at 15:12

Not the answer you're looking for? Browse other questions tagged or ask your own question.