Hacker News new | past | comments | ask | show | jobs | submit login

It's not about making the ultimate right choice. It's about not getting trapped in a dead end, or in a situation where you can't change your mind.



There is virtually no dead end corner that the OP can paint him/herself into. They could pick literally any language or approach, platform or format, and create a successful business from it. The risks come from not being able to _easily_ make changes, but those risks are mitigated by the choices you make in developing the software, at an architecture level, using proper design and weighing out the realistic possibilities, not the universe thereof.

Concretely, if you create a web-based API, then you can put any front-end on it. If you layer the application correctly, you can move some of the layers closer to the client as needed, adding caching for performance. If the problem is one that can only be solved through a desktop application, then the whole question was moot to begin with.

I've seen enough Excel-spreadsheets-as-million-dollar-business to know that the only thing standing between you and your completed product is yourself, especially when you have technical skills to actually do the work.


The risks come from not being able to _easily_ make changes

In my experience, this is pretty much the same thing as being unable to change your mind.


If you are a developer and good at what you do, you will layer your application to buffer against changes. If you aren't then just write the code the best you know how because building a business AND learning how to be a good coder at the same time is not the most efficient path. That path is littered with constantly rewritten, half-finished, failures.

Get a product out and then figure out where you could have done better.


If you are a developer and good at what you do, you will layer your application to buffer against changes.

That's a good place to start. That's 80's and 90's best practice, though. (Most of the industry is stuck in this mindset, to be fair.) I'd say the 21st century version of this would be to structure your code in such a way that transformation tools can be easily applied.


So you understand my point.


The code architecture "win" is always to dodge the big manual rewrite. The "lose" is to have to do the big manual rewrite. People make it into a game of ideological purism, but really, it's as simple and pragmatic as just that.

They who dodge the manual rewrite -- those are the real gurus.


Being a guru and finishing product have close to 0 correlation. It doesn't matter how you would've/could've/should've done it if in the end, you didn't do it.

I'm just trying to encourage OP to finish a product and we've gone pretty far from that starting point with this discussion.


Being a guru and finishing product have close to 0 correlation.

Finishing a project and the number of large-scale manual rewrites tend to be negatively correlated.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: