which actually matters when you go from prototype to real

I’ve been bouncing between side projects for the past year and one thing that keeps happening is that I ship something that works on its own, but then reality changes. I wanted to write down what I noticed, because the advice online is usually too abstract or too specific

the important thing is that a working demo and a working product operate under completely different constraints. in a demo that you optimize for ‘can I show this to someone and have it work right now’. in production you are optimizing for ‘will this still work if I don’t pay attention to it’. these are sometimes almost opposite goals.

I always thought it was important to write perfect code in advance. now I think it’s more important to build in a way where mistakes are obvious and can be easily fixed. that usually means simpler architecture than smart architecture, even though simple means more code. it means choosing boring tools with good documentation. used blink for the backend of a recent project, mainly because I didn’t want to spend mental energy discussing infrastructure options. let me focus on the product behavior instead

the other thing is that some corners are worth cutting and some are not. Cutting back on validation logic is bad, because it’s all about money and data integrity. cutting back on the original database schema is bad because large-scale migrations are painful. but limiting perfect error messages or a polished admin panel or extensive monitoring, that’s actually fine in the beginning. you learn what you really need by doing it

timing is also important. I shipped things too early where the core flow still had issues. I’ve also shipped things late because I was optimizing for edge cases that never happened. the trick seems to be to send when the main path is solid, and not when everything is perfect