About 12 years ago I made my first serious attempt at building a side project. It was a list app with some todo-like functionality. I had just started learning Python and Django and I focused exclusively on the code of the app. No research. It's what developers do, right?
But at some point I realised I had half a product (maybe not even that), no idea if anyone would ever pay for it, and many doubts about whether I was spending my time on something useful. Big surprise - my first side project failed even before launching. My take-aways?
1) Just because you have a "good" idea for something that you can see yourself using, doesn't mean that everybody else will think it's a good idea too. And even if they do, it doesn't mean they'd be willing to pay for it.
2) If you start by building the product, by the time you launch you will have spent countless hours on something that might not succeed. Of course you can never be sure, even with research, but rather first get (or try to get) some validation for your idea.
4) Keep your expenses to a minimum in the early stages. Sure, you might think, "It's only a few dollars", and it is, but if your idea fails, you might feel that you wasted money - and that only adds to the disappointment. So keep it lean early on.
5) You probably need to build an audience before anything else. I hate to say this. But that's how this world works. Yes, I wish that "marketing" wasn't necessary, and that people would just automatically discover your great product. But you have to face reality.
The difference between "null" and "blank" on Django models? They are related, but "null" is applied on a DB level, and "blank" is applied on a validation level. For example, if "null" is False and "blank" is True, it means you can input a blank string into that field. #django
Some tips for running a small business where one person is solely responsible for responding to all support requests.
1. Anticipate the question. Many support threads are submitted because, even if you think it's clear on the website, it's not. I've made this mistake many times.
In Django, sometimes you have a model method that filter on a related (M2M) model. But what if the originating queryset used prefetch_related? Then you are creating extra queries. But also, if you assume it was used, and it wasn't, you're retrieving more than you need. Solution?
I believe that "Mark as read" reveals a design mistake in email clients. Most people treat the "unread" flag more as a "to be actioned" flag. "Mark as read" to them means "doesn't require my attention"; it's a work-around. The feature should be named better, e.g. "acknowledge".