4 ms·

Mostly I learn while I go along and probably I'm not doing this for much longer than yourself (1 year now). I have a similar background, as I tried to start a g

Mostly I learn while I go along and probably I'm not doing this for much longer than yourself (1 year now). I have a similar background, as I tried to start a game company before that. That didn't work out because even though we created the game which we had planned, it had taken us too long to finish and it completely failed to sell afterwards. So I started to work as freelancer using at first mostly the technology which I had developed in that company. I care now a lot that new projects will always improve my tool chain. I think in the long run that's my best chance as a solopreneur. So I try to get projects where I can learn new skills and I make contracts which allow me to use the sources I developed afterwards. And now I mostly hope I manage to learn fast enough to survive. I learned already a lot about negotiating by now, for example that I will always underestimate project time (even if I know it...) and therefore I really need to demand higher rates than I had originally expected. Also I have some long-term targets for own products. So I'm not just doing blindly projects, but I care that projects always get me closer to that. Originally I had hoped to find time beside the official projects, but that was not the case so far. Trying to get a new project while still working on the old is also tricky. I learned by now that I need full concentration for the current task. This means delaying everything that has no connection with my current project by all means until I can spend a full day on the other project. And then I will stay on the other until everything that was accumulated is done even if it needs more than the time I planned for it.

hhm 18y ago
Thanks for your reply. What I found useful whenever I could was setting rates per hour or per time unit (say, month) of development time, in large projects no one can really estimate how much time they will take to finish (for example, these days I'm developing some kind of 2.0 video streaming app for a client, and we're always testing it with people and adding features, thinking of new security measures and so on... we couldn't have written a full requirements doc at the start of this specific project). This protects your budget, but also your client's budget in the end (you don't need to do over-estimations for the costs to be safe). About parallel projects for products... I have none of them, but I use development work to learn more and more about difficult subjects that would take a long time of research or study to learn well (for example, on an older project I learned some basics of computer vision, etc). In the end that makes my development time more expensive and useful with every project. But maybe I should think in products too.

hhm 18y ago

Thanks for your reply. What I found useful whenever I could was setting rates per hour or per time unit (say, month) of development time, in large projects no one can really estimate how much time they will take to finish (for example, these days I'm developing some kind of 2.0 video streaming app for a client, and we're always testing it with people and adding features, thinking of new security measures and so on... we couldn't have written a full requirements doc at the start of this specific project). This protects your budget, but also your client's budget in the end (you don't need to do over-estimations for the costs to be safe). About parallel projects for products... I have none of them, but I use development work to learn more and more about difficult subjects that would take a long time of research or study to learn well (for example, on an older project I learned some basics of computer vision, etc). In the end that makes my development time more expensive and useful with every project. But maybe I should think in products too.