Comment by forgottenacc57 | Hacker News Reader

Comment by forgottenacc57 | Hacker News Reader

Parent Full thread

My most recent project has taken more than 18 months.

I implemented 2 major subsystems that I later realized I could simplify the system by throwing out.

My product is very technical so there was probably about four months trying to make things work and learning what did and did not work.

I had to learn about 75% of the development tools and languages I was building with.

I don't like the idea of releasing half baked, half working software that represents half of my vision.

I had to fit the project in between my money paying job, family, friends, life.

I had lots of great ideas and the fun bit about developing software is when you get to implement those "wow it would be cool if...." functions.

I just want to fix bugs after the software is released, not just be starting on the code.

I want the software to be so far along that it would cause a competitor to think twice about copying.

I think software should be great, not just barely functional, so I added lots of things to polish and make it awesome.

Near the end of the build I realized I could make a major leap forward so I redesigned a key area of the UI.

I built as much of it as I could before release because after release its MUCH harder to add new features.

There you go, that's why it took me so long.

I have been working on a product with my cofounder for around 18 months; spent around six months of this doing consulting to keep the lights on. Released a few early videos, gauged interest, but had to keep fending off users who wanted the promised software immediately. Those emails kept us going - even though we didn't validate by asking for money, the fact that people pestered us even after we told it won't be ready for a long while, gives us hope that when we release there will be at least a few people who would find it useful enough to pay money.

I've been asked by a lot of people why we haven't released yet. We're dogfooding it; it is useful to us today, but it is not where I want it to truly be. Since I'm my own customer (this is a technical product, scratching my own itch), I will know when it is ready. It will be ready when I can build a functional front-end application from a design in two days, that would otherwise take me a month.

What is taking us so long? We had to learn the internal API of an ever-changing software, learn a new language, build a Rails server, a Node server, a chrome extension, a Sketch plugin, an entire compiler-like thing, we had to figure out new ways of solving the design -> code problem, we had to duct-tape the hell out of so many things, and in the meantime we had to content with other aspects of life that are not technical.

It is quite annoying to see the way people talk about the Lean MVP approach being the only way to build software. Some stuff takes time - not everything is a CRUD application that you can throw out into the void, put up some marketing pages, and have a hockey stick in three months. But the downside to my attitude is that most people who fail typically use the same argument - that we're exceptional and the lean MVP approach doesn't work for us. I actually think the produce I'm building is an exceptional case, but hey, isn't hindsight the only true foresight?

I think if you try to solve a complicated domain problem AND turn that solution into a product, you can't also learn too much other stuff at the same time. Too many rabbit holes to go down.

Simply building a simple polished product with the stack you know best ist plenty of work.

Kudos on taking the risk to release a bit later and delivering something that meets your higher standards, that's going against accepted business wisdom but it is only because 'everybody else releases barely functional crap too' that that became the norm for competition.

I get a vision in my head of what the software should be and I'm compelled as though by force to make it match the vision. I don't seem to have much choice.

That's not usually the reason to ship early. Common wisdom is to ship early because it's very possible that you do not have a good understanding of the problem you are trying to solve, or how your users will use your solution. The only way to find a better understanding is to release your product and see how it does. It is usually efficient to find this information out before you spend time polishing the wrong parts of the solution.

Can you tell us what it is?

Reply on news.ycombinator.com