1-man show, coder/marketing/everything else... 10 months in the making, too long?

As a 1-man show I've been building a social startup for the last 10 months. A lot of the time on development has been spent learning a new programming language (Ruby on Rails) and also all the other stuff around it.

I think I've already spent too much time on design. 4 months ago I came across the "Lean Startup" model, so I've skipped some features and ideas and plan to release my app very soon now. Although it still isn't perfect in all areas, it should just work for the majority of users.

I have set up a closed beta page with codes, so only users with a code can signup, to limit the number of users. Sometimes it feels like it never stops, and the launch date will be pushed back every day. Sometimes it feels like this thing will never be "ready for launch."

How do you tackle this kind of emotion? I know next time things will go much faster, but for now those last features and bugfixes are almost killing me - since I want to really know how my idea and startup is perceived by end-users. (Some friends think its awsome, which keeps me going.) Taking all this into consideration, should I consider the 10 months I've spent too long for an MVP?

Are you aware of Parkinsons Law:

Work expands so as to fill the time available for its completion

 

Work always fills the time you have

 

When developing, break everything up into small modules or stories. Each story should be self contained but part of the whole e.g.(Build login - flip card around and write in detail what needs to be achieved). Figure out how many parts you need to complete the whole. Methodically approach each problem until done. Write down how long each story should take for completion.

Continue this approach for each release. The stories act as a log of what you have achieved and can be added to your release notes.

This sort of planning make a massive difference.

The rest is psychological. A well balanced day will help you think clearly and rid some of the frustrations.

The answer to your question is highly subjective. Here are a few answer points that might give you some clarity:

• Though We've seen a lot of awesome Startups from single founders, it's always better to have a co-founder. Being a single founder is #1 on The 18 Mistakes That Kill Startups by Paul Graham. Also, it's more like having a co-pilot, it's not about how good a pilot you are. At times when you're down, your co-founder, if selected wisely, can dust you up and inspire you to go on. GIST: It's always better to have 1 or 2 co-founders.
• Lean Startup is more than just releasing your app soon. It's all about The 3 Steps (Build, Measure, Learn). Each time you iterate, you add value to the product (aka Build), measure the response from the Users/Customers, and draw Inferences from the metrics (aka Learn).
• It's common to feel this way (esp. given the fact that you're a single founder). You should probably stop worrying about the minor details and think about them in coming B-M-L iterations.

Good Luck with whatever you are building.

I started my own company in 2005. At that time, my company was the only one in Brazil developing that kind of software ( instant messaging solutions ). When I saw the opportunity, I did some research and found out that there were some very expensive solutions by Symantec and Akonix ( don't know if still exists ).

So I started coding and 6 months later I had a first version of the software and I had to launch it because the bills were pilling up :-). The first version was far from what I was expecting to put in the software, but the launch was good because I started getting some customers and they started to provide me good feedback of what to prioritize for the next version.

Some time later, the product was selling very well but I got myself in troubles because even having some employees I had no one that could replace me in the development ( I was living in a small city and there was no good universities there ). Then I realized that I had 2 options - a) move to a bigger city where I could find a good developer or b) sell the company - and I took the second option.

So my advise for you is: if you want to grow up you need to start getting someone else to be in the core of your business ( you can offer a share of the company, doesn't need to be 50% ). But if you want to grow up consistently you'll need someone else. I know how hard is to take that decision ( it was YOUR idea, you put much effort on it ) - but you'll need to take it.

As there's nothing you can do about the time you've already invested, there's no value in worrying whether you should have got to market earlier. You've already got double value: (i) you have a product that your friends, at least, are getting excited about; (ii) you've acquired a bunch of skills in taking a Ruby project from ideas to a running system. So focus on what's coming up.

And you do have some important choices, as you go from here to a more generally released product.

Minimum viable product ≠ not finishing every feature There's a lot to be said for the "ship it now" approach. As long as you're upfront about it, users are generally far more ready to accept shortcomings than the developer.

But that's not all there is to the MVP approach.

A lot of the value of an MVP is in getting clear signals from users. The fewer features you have, the easier to determine what is, and what isn't, generating value. Lots of features, on the other hand, will leave you with lots of questions.

However, what if your product has lots of capabilities, each incomplete? That's often the case when you have a clear view of the end goal: like an artist, you may have sketched the broad outline, without painting in any of the detail. If that's where you are, then getting to an MVP may mean scything out features you've built.

Or, to put it the 37 Signals way,

> Build half a product, not a half-ass product So here's your choice: go forward, or go backward, to find "good enough." Only you can make that decision. Though you can and should call on the people who've supported you to this point.

Then set a time limit. Commit to the direction you've chosen, then promise yourself that six weeks after that day, wherever you've reached, you'll launch.

Good luck!

I feel you should go ahead and release it as soon as you can - because at that point, the problem of creation that you are currently facing, turns into a problem of optimization. Optimizing stuff is easier and more fun for most developers I know - compared to creating something.

I've been in a sort of similar situation as yours and things that get stuck, often remain stuck. You need to release - so that you can quickly get validation from real users and decide to change course (or not) depending on feedback.

There have been so many times - we have spent weeks building a feature and tweaking it to realise that hardly anyone uses it.

As for your 10 months question - IMO, if you are moonlighting on the project, then it feels like about the right tome to launch. If you are working on this full time, then I would probably not take a risk of more than 3 - 4 months without launching something and getting feedback on it. So you are probably 6 months late on that front. Again, depends on the size of the project - but I would plan my MVP around the 3 month mark.

All the best with your product :)

i think also think a small quick release is better than a big release with many features. you so get more feedback from customers and you don't take the risk that your project developes itself in the wrong way.